識別および調整エンジン (IRE)

  • リリースバージョン: Yokohama
  • 更新日 2025年01月30日
  • 所要時間：16分

    • IRE は、識別および調整の基礎となる主要コンポーネントであり、さまざまなデータソース間で識別および調整プロセスを実行できる、一元化されたフレームワークを提供します。IRE は、受信データを処理する際に、識別ルール、調整ルール、および IRE のデータソースルールを使用してから、データを CMDB に挿入します。

    IRE プロセスは、CMDB 内のデータの完全性を維持するのに役立ちます。
    • IRE は CI を一意に識別することで、CI の重複を防止します。​
    • IRE は、信頼できるデータソースのみに CMDB への書き込みを許可することにより、CI 属性を調整します。
    サービスマッピング、水平ディスカバリー、パターンディスカバリーなどの ServiceNow® アプリケーションでは、API を使用して識別および調整プロセスを適用します。インポートセットによってインポートされたデータに IRE プロセスを適用することもできます。サードパーティのデータソースを含む他のデータソースを使用する場合、REST またはスクリプト可能な IRE API を利用して、識別と調整を実行できます。
    追加情報：

    CI 識別

    CMDB 識別プロセスは、CI を一意に識別するために識別ルールに依存します。ペイロードの sys_object_source_info セクションに記載された source_name と source_native_key の値、およびソース [sys_object_source] テーブルを使用して、CI を一意に識別することができる場合もあります。この方法での識別が成功した場合、識別ルールに依存する一致アルゴリズムを適用する、より時間のかかる識別方法を取る必要はありません。

    IRE ペイロードのオプションの sys_object_source_info オブジェクトには、一意の CI ID を指定できます。
    {
  "items": [
    {
      "className": "cmdb_ci_win_server",
      "values": {
        "name": "SAMLABVM52"
      },
      "sys_object_source_info": {
            "source_native_key": "16777219",
            "source_name": "SCCM",
            "source_feed": "SCCM Computer Identity",
            "source_recency_timestamp": "2019-08-26 13:00:00"
      }
     }
    ]
  }

    識別プロセスは 、CI を一意に識別するために CI 依存関係の分類に依存します。例として、依存 CI である Tomcat CI を識別する場合が挙げられます。Tomcat アプリケーション (依存クラス) を実行している Windows Server CI (独立クラス) を想定しています。Tomcat アプリケーションは同じパスを持つ複数のマシンで実行できるため、Tomcat CI を一意に識別するために、「構成ファイルパス」を頼りにするだけでは不十分です。識別エンジンは、更新する CI を選択することができません。依存関係がある場合、識別プロセスは、Tomcat アプリケーションが実行されている Windows Server ホストを最初に識別する必要があります。そうして初めて、ホストのコンテキストで Tomcat アプリケーション自体を一意に識別できます。

    ペイロードアイテムの識別

    IRE は、受信ペイロード内のすべてのペイロードアイテムの識別子キーを生成し、部分的ペイロードと受信ペイロードを照合するときにそれらのキーを使用します。識別子キーは、次のいずれかに基づいています。
    • sys_object_source_info オブジェクトの source_name と source_native_key の値の組み合わせ。
    • 識別基準属性
    IRE は部分的なアイテムに関連付けられた識別子キーを CMDB IRE 部分ペイロードインデックス [cmdb_ire_partial_payloads_index] テーブルに格納し、それらのキーを使用して受信ペイロードの識別子キーとの照合を試みます。

    重要な属性のタイムスタンプ

    競合する属性値の解決に役立てるために、IRE は、以下の属性のタイムスタンプを使用して、現在のレコードより古いため無視できるレコードを識別します。

    • 最新のディスカバリー (last_discovered) とディスカバリーソース (discovery_source)：

      最新のディスカバリー (last_discovered) は、CI が最後に検出されたときのタイムスタンプです。IRE は、他の CI 属性が更新されていない場合でも、ペイロード処理中に CI の last_discovered と discovery_source の属性を常に更新します。ペイロードに last_discovered が指定されている場合、ペイロードの last_discovered 時間が CMDB の時間よりも新しい場合にのみ、IRE は指定された値で CI を更新します。ペイロードに last_discovered が指定されていない場合、IRE は last_discovered 属性を現在のタイムスタンプで更新します。

      glide.identification_engine.skip_updating_source_last_discovered_if_older および glide.identification_engine.ire_message_listener_skip_updating_source_last_discovered_to_now システムプロパティを使用して、このデフォルトの動作を変更できます。

    • 最初に検出 (first_discovered) は、CI が最初に作成されたときのタイムスタンプです。

      • CI の初回作成時：ペイロードに値が指定されている場合、IRE はその値を挿入します。それ以外の場合、IRE は現在のタイムスタンプを挿入します。
      • 後続の更新時：値が指定されている場合、IRE は指定された値で CI を更新します。それ以外の場合、属性は更新されません。
    次のシステムプロパティを使用して、IRE がペイロードの source_recency_timestamp 値を使用してソース [sys_object_source] テーブルの last_scan 属性を更新する方法を変更することもできます。

    拡張 IRE 機能

    CreateOrUpdateCIEnhanced()​​ および identifyCIEnhanced スクリプト可能 API は、次の拡張 IRE 機能を提供します。これらは必要に応じて有効または無効にできます。
    部分的ペイロード

    IRE は、データソースが CI を一意に識別するための十分な情報を提供しなかったために処理を続行できないアイテムを分離します。これらのアイテムの一部は部分的なアイテムとして識別され、後で処理できるように保存されます。その他のアイテムは不完全なアイテムとして識別され、ログ記録目的でのみ保存されます。

    例：SCCM には、ディスクフィードやコンピューターフィードなどの複数のフィードがあります。ディスクフィードに、ディスクに関する情報はすべて含まれていても、依存するコンピューター CI に関する情報が不十分である可能性があります。

    API オプション：デフォルトで有効になっている partial_payloads。partial_payloads が有効になっている場合は、オプションの設定に関係なく、partial_commits と deduplicate_payloads が自動的に有効になります。

    部分的コミット

    一部のアイテムでエラーが発生しても、ペイロード内の残りのアイテムのコミットが妨げられることはありません。したがって、ペイロードにエラーのあるアイテムが含まれている場合でも、IRE はペイロード内の残りの有効なアイテムをコミットします。この状況では、コミットされていないアイテムの一部は部分的なペイロードとして保存され、コミットされていないその他のアイテムは不完全なペイロードとして保存されます。

    API オプション：デフォルトで有効になっている partial_commits。

    ペイロードアイテムの重複排除

    IRE はペイロード内の重複アイテムを重複排除し、それらの重複アイテムを単一のペイロードアイテムに結合して処理します。

    API オプション：デフォルトで有効になっている deduplicate_payloads。

    サマリーの生成

    IRE は、クラスごとの更新数などの処理の詳細を含むサマリーを出力ペイロードに生成します。

    API オプション：デフォルトで無効になっている generate_summary。

    部分的なアイテム

    ペイロードアイテムは、一意の識別に必要なデータが含まれており、次のいずれかのエラーがある場合、部分的なアイテムであると判断されます。一意の識別では、sys_object_source_info セクションに source_name と source_native_key の値を含むペイロードアイテム、または CI クラスに指定された識別基準属性の完全なセット、あるいはその両方が必要です。

    部分的なアイテムの IRE エラー：
    • MISSING_MATCHING_ATTRIBUTES：アイテムに、1 つ以上の識別子エントリで照合に使用するための識別基準属性がありません。​
    • REQUIRED_ATTRIBUTE_EMPTY：必要な属性が欠落しており、CI を作成できません。​
    • MISSING_DEPENDENCY：依存型 CI に、ペイロードで指定された依存関係がありません​。
    • INSERT_NOT_ALLOWED_FOR_SOURCE：IRE のデータソースルールにより、指定されたデータソースは指定されたクラスの CI を作成できません。

    IRE エラーメッセージの詳細については、「IRE エラーメッセージ」を参照してください。

    ペイロードアイテムが部分的なアイテムであると判断されたために処理が失敗した場合、部分的なアイテムは、以後に行われる可能性がある処理のために、部分的ペイロードとして CMDB IRE 部分のペイロード [cmdb_ire_partial_payloads] テーブルに JSON 形式で保存されます。​IRE は識別子キーを使用して、受信ペイロードと保存された部分的ペイロードとの照合を試みます。

    後でデータソースが部分的なアイテムから欠落していたデータを送信した場合、IRE は受信ペイロードを保存された部分的ペイロードと照合します。次に、IRE は、一致する部分的ペイロードを受信ペイロードと結合します。競合する属性を解決するために、IRE は source_recency_timestamp (source_native_key および source_name が同じ場合) またはクラスに指定された静的調整ルールのいずれかを使用します。結果は完全かつ有効なペイロードで、その後 IRE が処理してそれぞれの CI を作成または更新します。

    90 日より古い部分的ペイロードは、CMDB IRE 部分のペイロード [cmdb_ire_partial_payloads] テーブルから削除されます。

    部分的ペイロードのサンプル： 
    Disk feed:
{
  "items": [
    {
      "className": "cmdb_ci_computer",
      "sys_object_source_info": {
            "source_native_key": "Server001",
            "source_name": "SCCM",
            "source_feed": "DISK_FEED",
            "source_recency_timestamp": "2019-08-26 13:00:00"
      }
    },
    {
      "className": "cmdb_ci_disk",
      "values": {
        "name": "disk1"
      }
    }
  ],
  "relations": [{
              "parent": 0,
              "child": 1,
              "type": "Contains::Contained by"}
              ]
}
    上記のペイロードのコンピューターアイテムには属性がないため、IRE では処理できません。ただし、source_name および source_native_key は、部分的なアイテムとして提供されています。コンピューターアイテムは部分的なアイテムであるため、コンピューターアイテムに依存するディスクアイテムも部分的なアイテムです。
    欠落している詳細を提供することによって前の部分的ペイロードを完了する後続のペイロードのサンプル：
    Server/Computer feed:
 {
  "items": [
    {
      "className": "cmdb_ci_linux_server",
      "values": { "name": 'linux001',
                "ip_address": "100.126.38.19",
                "mac_address": "DSWER4587" },
      "sys_object_source_info": {
            "source_native_key": "Server001",
            "source_name": "SCCM",
            "source_feed": "COMPUTER_IDENTITY",
            "source_recency_timestamp": "2019-08-26 14:00:00"
      }
    }
  ]
}
    source_name と source_native_key が同じであるため、部分的ペイロードのコンピューターと新しいペイロードのサーバーは一致します。したがって、部分的ペイロードと新しいペイロードが結合され、操作がコミットされ、部分的ペイロードが部分的ペイロードテーブルから削除されます。

    部分的ペイロードあたりのアイテム数には制限があり、これは glide.identification_engine.partial_payload_items_max_size プロパティで設定されます (デフォルトでは 1000)。関連する関係、参照、および依存アイテムを 1 つの部分的ペイロードに格納すると、その制限に達することがあります。その場合、ペイロードは複数の部分的ペイロードに分割されます。

    部分的ペイロードの詳細については、「CreateOrUpdateCIEnhanced()​​」を参照してください。

    不完全なアイテム

    次の場合、ペイロードアイテムは不完全なアイテムであると判断されます。
    • 一意の識別に必要なデータが一部含まれていない場合
    • 部分的なアイテムに関連付けられていないエラーがある場合
    sys_object_source_info オブジェクト内の source_name と source_native_key、および CI クラスに指定された識別基準属性の完全なセットのいずれも提供されていない場合、一意の識別はできません。

    不完全なアイテムは、CMDB IRE 不完全ペイロード [cmdb_ire_incomplete_payloads] テーブルに JSON 形式で不完全ペイロードとして格納されます。不完全なアイテムは、回復不能なエラーのあるペイロードをログ記録する目的で保存され、二度と処理されることはありません。

    関係の追加

    インデックスまたはオプションの JSON internal_id 要素のいずれかを使用して、関係を追加します。

    ペイロードの relations オブジェクトを使用して、アイテムの internal_ids を参照して関係を追加または更新します。関係は、ペイロードのメインアイテムと関連アイテムを使用して作成できます。たとえば、
    • 関係 (親インデックス、子インデックス、関係タイプ)
    • 関係 (親内部 ID、子内部 ID、関係タイプ)​

    詳細とコードのサンプルについては、「CreateOrUpdateCIEnhanced()​​」を参照してください。

    ペイロードアイテム間への参照の追加

    ペイロードアイテムを一意に識別するオプションの JSON internal_id 要素を使用して、2 つのペイロードアイテム間に参照を追加します。

    referenceItems ブロックを使用して、参照を追加または更新します。単一のペイロードで、メインアイテム、ルックアップアイテム、および関連アイテムを含む任意の 2 つのアイテム間に参照を追加できます。

    詳細とコードのサンプルについては、「CreateOrUpdateCIEnhanced()​​」を参照してください。

    CI の再分類

    ペイロードの設定ブロックで updateWithoutUpgrade、updateWithoutDowngrade、および updateWithoutSwitch フラグを使用して、CI のクラスが意図せず更新されないようにします。これらのフラグは、同じ CI の更新中に複数のデータソースが意図せずに試行する可能性がある CI のクラスのアップグレード、ダウングレード、または切り替えを防止します。詳細とコードのサンプルについては、「CreateOrUpdateCIEnhanced()​​」を参照してください。

    再分類フラグは、IRE 処理中の CI の再分類を構成するの他のシステム設定よりも優先されます。

    カスタム前スクリプトおよびカスタム後スクリプトの追加

    統合ハブ ETL を使用して、CMDB データ連携アプリケーションのデータソースのカスタム Java スクリプトを追加します。これらのスクリプトは、CMDB 統合を処理しながら、IRE 入力および出力ペイロードへのアクセスを提供します。

    前スクリプトは、IRE に送信される入力ペイロードのバッチへのアクセスを提供します。カスタム前スクリプトを使用すると、次のことができます。
    • status を [スキップ] に設定して、バッチ内のペイロードをスキップする。必要に応じて、それぞれのインポートセット行テーブルにコメントとして表示されるペイロードをスキップする理由を記入する。
    • 入力ペイロードを変更する。
    • IRE ペイロードを使用するスクリプト内に他のカスタムロジックを記述する。
    後スクリプトは、IRE 入力および出力ペイロードへのアクセスを提供します。カスタム後スクリプトを使用すると、次のことができます。
    • 入力ペイロードと出力ペイロードを簡単に比較し、IRE が各 CI で実行したさまざまな操作を識別する。
    • IRE が作成または更新した CI の sys_id にアクセスする。
    • IRE 出力ペイロードを使用するスクリプト内に他のカスタムロジックを記述する。