Identification and Reconciliation Engine (IRE)

  • Freigeben Version: Zurich
  • Aktualisiert 31. Juli 2025
  • 9 Minuten Lesedauer

    • IRE ist eine zugrunde liegende Schlüsselkomponente in Identifikation und Abgleich und bietet ein zentralisiertes Framework zur Durchführung von Identifizierungs- und Abgleichsprozessen über verschiedene Datenquellen hinweg. IRE verwendet Identifizierungsregeln, Abgleichsregeln und IRE-Datenquellenregeln, wenn eingehende Daten verarbeitet werden, bevor diese Daten in die CMDB eingefügt werden.

    IRE-Prozesse tragen dazu bei, die Datenintegrität in der CMDB aufrechtzuerhalten.
    • Ire verhindert doppelte CIs, indem CIs eindeutig identifiziert werden. ​
    • IRE stimmt CI-Attribute ab, indem nur autorisierende Datenquellen in CMDB schreiben dürfen.
    ServiceNow® Anwendungen wie Service-Mapping, Horizontale Discovery und Muster-Discovery verwenden APIs, um Identifizierungs- und Abgleichsprozesse anzuwenden. Sie können IRE-Prozesse auch auf Daten anwenden, die von Importsätzen importiert wurden. Wenn Sie andere Datenquellen verwenden, einschließlich Drittpartei-Datenquellen, können Sie REST- oder skriptfähige IRE-APIs nutzen, um die Identifizierung und den Abgleich durchzuführen. ​
    Zusätzliche Informationen:

    CI-Identifizierung

    Der CMDB Identifikationsprozess basiert auf Identifizierungsregeln, um CIs eindeutig zu identifizieren. Wenn möglich, können CIs auch eindeutig mit identifiziert werden source_nameUnd source_native_keyWerte, die in angegeben werden sys_object_source_infoAbschnitt der Nutzlast und die Quelltabelle [sys_object_Source]. Wenn die Identifizierung mit dieser Methode erfolgreich ist, ist es nicht erforderlich, übereinstimmende Algorithmen anzuwenden, die auf Identifizierungsregeln basieren, was eine langsamere Identifizierungsmethode ist.

    Sie können das System so konfigurieren, dass die Verwendung von IRE-Identifizierungsregeln priorisiert wird, auch wenn source_nameUnd source_native_keyWerden bereitgestellt und können zur eindeutigen Identifizierung verwendet werden. Weitere Informationen zur Verwendung von glide.identification_engine.skip_sys_object_source_matchingSystemeigenschaft zum Verwalten dieses Verhaltens siehe Eigenschaften.

    Ein eindeutiger CI-Bezeichner kann optional in angegeben werden sys_object_source_infoObjekt in der IRE-Nutzlast.
    {
  "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"
      }
     }
    ]
  }

    Identifizierungsprozesse basieren auf CIs-Abhängigkeitsklassifizierung Zur eindeutigen Identifizierung von CIs. Beispiel: Um ein Tomcat-CI zu identifizieren, das ein abhängiges CI ist. Angenommen wird ein Windows Server-CI (unabhängige Klasse), das eine Tomcat-Anwendung (abhängige Klasse) ausführt. Die Verwendung von „Konfigurationsdateipfad“ zur eindeutigen Identifizierung des Tomcat-CI ist nicht ausreichend, da die Tomcat-Anwendung auf mehreren Computern mit identischen Pfaden ausgeführt werden kann. Die Identifizierungs-Engine kann kein CI zum Aktualisieren auswählen. Abhängige Beziehungen zwingen den Identifizierungsprozess, zuerst den Windows Server-Host zu identifizieren, auf dem die Tomcat-Anwendung ausgeführt wird, und dann im Kontext des Hosts die Tomcat-Anwendung selbst eindeutig zu identifizieren.

    Identifizierung der Nutzlastelemente

    IRE generiert Bezeichnerschlüssel für alle Nutzlastelemente in einer eingehenden Nutzlast und verwendet diese Schlüssel dann, wenn versucht wird, partielle und eingehende Nutzlasten abzugleichen. Ein Bezeichnerschlüssel basiert entweder auf:
    • Kombination von source_nameUnd source_native_keyWerte aus dem sys_object_source_infoObjekt.
    • Attribute des Identifizierungskriteriums.
    IRE speichert die Bezeichnerschlüssel, die Teilelementen zugeordnet sind, in der Tabelle „Index für partielle CMDB-IRE-Nutzlasten“ [cmdb_Ire_partial_Payloads_index] und verwendet diese Schlüssel dann, um zu versuchen, mit Bezeichnerschlüsseln eingehender Nutzlasten abzugleichen.

    Zeitstempel in Schlüsselattributen

    Um in Konflikt stehende Attributwerte aufzulösen, verwendet IRE Zeitstempel in den folgenden Attributen, um Datensätze zu identifizieren, die älter als der aktuelle Datensatz sind und daher ignoriert werden können:

    • Neueste Discovery ( last_discovered) Und Discovery-Quelle ( discovery_source):

      Neueste Discovery ( last_discovered) Ist der Zeitstempel, der angibt, wann das CI zuletzt erkannt wurde. Ire aktualisiert CIs immer last_discoveredUnd discovery_sourceAttribute während der Nutzlastverarbeitung, auch wenn keine anderen CI-Attribute aktualisiert werden. Wenn last_discoveredWird in der Nutzlast bereitgestellt. IRE aktualisiert das CI nur mit dem angegebenen Wert, wenn der angegeben ist last_discoveredDie Zeit in der Nutzlast ist neuer als die in der CMDB. Wenn last_discoveredIst in der Nutzlast nicht angegeben, IRE aktualisiert last_discoveredAttribut mit dem aktuellen Zeitstempel.

      Sie können verwenden Glide.Identification_Engine.Skip_Update_Source_Last_Discover_if_older Und Glide.Identification_Engine.ire_message_listener_Skip_Update_Source_Last_detected_to_now Systemeigenschaften zum Ändern dieses Standardverhaltens.

    • Zuerst erkannt ( first_discovered) Ist der Zeitstempel der ersten Erstellung des CI.

      • Wenn das CI zum ersten Mal erstellt wird: Wenn in der Nutzlast ein Wert angegeben wird, fügt IRE diesen Wert ein. Andernfalls fügt IRE den aktuellen Zeitstempel ein.
      • Bei nachfolgenden Updates: Wenn ein Wert angegeben wird, aktualisiert IRE das CI mit dem angegebenen Wert. Andernfalls wird das Attribut nicht aktualisiert.
    Sie können auch die folgenden Systemeigenschaften verwenden, um zu ändern, wie IRE verwendet source_recency_timestampWert in einer Nutzlast zum Aktualisieren von last_scanAttribut in der Quelltabelle [sys_object_Source]:

    Erweiterte IRE-Funktionen

    Die CreateOrUpdateCIErweitert() ​​Und IdentifyCIErweitert Skriptfähige APIs bieten die Funktionalität für die folgenden erweiterten IRE-Funktionen, die nach Bedarf aktiviert oder deaktiviert werden können:
    Teilnutzlasten

    IRE isoliert Elemente, für die Datenquellen nicht genügend Informationen zur eindeutigen Identifizierung des CI bereitgestellt haben und die Verarbeitung daher nicht fortgesetzt werden kann. Einige dieser Elemente werden als Teilelemente identifiziert, die zur potenziellen späteren Verarbeitung gespeichert werden. Andere Elemente werden als unvollständige Elemente identifiziert, die nur zu Protokollierungszwecken gespeichert werden.

    Beispiel: SCCM hat mehrere Feeds, z. B. einen Datenträger-Feed und einen Computer-Feed. Der Datenträger-Feed enthält möglicherweise vollständige Informationen zum Datenträger, aber unzureichende Informationen zum Computer-CI, von dem er abhängt.

    API-Option: partial_payloadsDie standardmäßig aktiviert ist. Wenn partial_payloadsIst aktiviert, partial_commitsUnd deduplicate_payloadsWerden unabhängig von ihrer Einstellung in den Optionen automatisch aktiviert.

    Teilweise Commits

    Fehler in einigen Elementen verhindern nicht, dass die restlichen Elemente in einer Nutzlast Commits gemacht werden. Wenn eine Nutzlast Elemente mit Fehlern enthält, werden die verbleibenden gültigen Elemente in der Nutzlast weiterhin von IRE übernommen. In dieser Situation werden einige der nicht bestätigten Elemente als Teilnutzlasten gespeichert, und andere nicht bestätigte Elemente werden als unvollständige Nutzlasten gespeichert.

    API-Option: partial_commitsDie standardmäßig aktiviert ist.

    Nutzlastelemente deduplizieren

    IRE dedupliziert doppelte Elemente innerhalb der Nutzlast und führt diese Duplikate zur Verarbeitung zu einem einzelnen Nutzlastelement zusammen.

    API-Option: deduplicate_payloadsDie standardmäßig aktiviert ist.

    Zusammenfassung generieren

    IRE generiert Zusammenfassungen in der Ausgabenutzlast mit Verarbeitungsdetails wie der Anzahl der Updates pro Klasse.

    API-Option: generate_summaryDie standardmäßig deaktiviert ist.

    Teilelemente

    Ein Nutzlastelement wird als Teilelement bestimmt, wenn es nicht die erforderlichen Daten für die eindeutige Identifizierung enthält und wenn einer der folgenden Fehler vorliegt. Die eindeutige Identifizierung erfordert, dass das Nutzlastelement über verfügt sys_object_source_infoAbschnitt mit source_nameUnd source_native_keyWerte oder der vollständige Satz der für die CI-Klasse angegebenen Identifizierungskriteriumsattribute oder beides.

    Ire-Fehler für ein Teilelement:
    • MISSING_MATCHING_ATTRIBUTES – Element verfügt nicht über Identifizierungskriterienattribute, um mindestens einen Identifier-Eintrag für den Abgleich zu verwenden. ​
    • REQUIRED_ATTRIBUTE_EMPTY: CI kann nicht erstellt werden, da ein erforderliches Attribut fehlt​.
    • MISSING_DEPENDENCY – für abhängiges CI fehlt eine Abhängigkeitsbeziehung, die in der Nutzlast angegeben ist​.
    • INSERT_NOT_ALLOWED_FOR_SOURCE: Eine IRE-Datenquellenregel verhindert, dass die angegebenen Datenquellen CIs der angegebenen Klasse erstellen.

    Weitere Informationen zu IRE-Fehlermeldungen finden Sie unter Ire-Fehlermeldungen.

    Wenn die Verarbeitung fehlschlägt, da Nutzlastelemente als Teilelemente bestimmt werden, werden die Teilelemente als Teilnutzlasten in der Tabelle „teilweise CMDB IRE-Nutzlasten“ [cmdb_Ire_partial_Payloads] im JSON-Format gespeichert, um später potenzielle Verarbeitungsvorgänge zu ermöglichen. ​IRE verwendet Bezeichnerschlüssel, um zu versuchen, eingehende Nutzlasten mit gespeicherten Teilnutzlasten abzugleichen.

    Wenn später eine Datenquelle die Daten sendet, die im Teilelement fehlten, gleicht IRE die eingehende Nutzlast mit den gespeicherten Teilnutzlasten ab. IRE führt dann alle übereinstimmenden Teilnutzlasten mit der eingehenden Nutzlast zusammen. Um Konflikte mit Attributen aufzulösen, verwendet IRE entweder source_recency_timestamp(Wenn source_native_keyUnd source_nameSind identisch) oder statische Abgleichsregeln, die für die Klasse angegeben sind. Das Ergebnis ist eine vollständige und gültige Nutzlast, die IRE dann verarbeitet, um die entsprechenden CIs zu erstellen oder zu aktualisieren.

    Teilnutzlasten, die älter als 90 Tage sind, werden aus der Tabelle „teilweise CMDB IRE-Nutzlasten“ [cmdb_IRE_partial_Payloads] gelöscht.

    Beispiel für eine Teilnutzlast: 
    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"}
              ]
}
    Das Computerelement in der obigen Nutzlast hat keine Attribute, daher kann IRE es nicht verarbeiten. Jedoch source_nameUnd Source_native_key Werden bereitgestellt, wodurch es zu einem Teilelement wird. Da das Computerelement teilweise ist, ist auch das vom Computerelement abhängige Datenträgerelement ein Teilelement.
    Beispiel für eine nachfolgende Nutzlast, die die vorherige Teilnutzlast durch Angabe der fehlenden Details abschließt:
    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"
      }
    }
  ]
}
    Der Computer in der Teilnutzlast und der Server in der neuen Nutzlast stimmen überein, da sie identisch sind source_nameUnd source_native_key. Daher werden die Teilnutzlast und die neue Nutzlast zusammengeführt, der Vorgang wird bestätigt, und die Teilnutzlast wird aus der Tabelle „Teilnutzlasten“ gelöscht.

    Es gibt einen Grenzwert für die Anzahl der Elemente pro Teilnutzlast, der von festgelegt wird Glide.Identification_Engine.partial_Payload_items_max_size Eigenschaft (standardmäßig 1000). Das Speichern zugeordneter Beziehungen, Referenzen und abhängiger Elemente in einer Teilnutzlast kann dazu führen, dass dieser Grenzwert erreicht wird. In diesem Fall wird die Nutzlast in mehrere Teilnutzlasten aufgeteilt.

    Weitere Informationen zu Teilnutzlasten finden Sie unter CreateOrUpdateCIErweitert() ​​.

    Unvollständige Elemente

    Ein Nutzlastelement wird als unvollständiges Element bestimmt, wenn:
    • Es enthält nicht alle Daten, die für eine eindeutige Identifizierung erforderlich sind
    • Es liegt ein Fehler vor, der keinem Teilelement zugeordnet ist
    Eine eindeutige Identifizierung ist nicht möglich, wenn auch nicht source_nameUnd source_native_keyInnerhalb von sys_object_source_infoObjekt oder der vollständige Satz von Identifizierungskriteriumsattributen, die für die CI-Klasse angegeben sind, wird angegeben.

    Unvollständige Elemente werden als unvollständige Nutzlasten in der Tabelle „CMDB-IRE-unvollständige Nutzlasten“ [cmdb_Ire_unvollständig_Payloads] im JSON-Format gespeichert. Unvollständige Elemente werden zum Zweck der Protokollierung von Nutzlasten mit nicht behebbaren Fehlern gespeichert und nie mehr verarbeitet.

    Beziehungen werden hinzugefügt

    Fügen Sie Beziehungen hinzu, indem Sie entweder Indizes oder das optionale JSON Internal_ID-Element verwenden.

    Verwenden Sie relationsObjekt in der Nutzlast, auf das Beziehungen hinzugefügt oder aktualisiert werden sollen internal_idsVon Elementen. Beziehungen können mithilfe von Hauptelementen und zugehörigen Elementen in der Nutzlast erstellt werden. Zum Beispiel:
    • Beziehung (übergeordneter Index, untergeordneter Index, Beziehungstyp)
    • Beziehung (übergeordnete interne ID, untergeordnete interne ID, Beziehungstyp) ​

    Weitere Informationen und Codebeispiele finden Sie unter CreateOrUpdateCIErweitert() ​​.

    Referenzen zwischen Nutzlastelementen werden hinzugefügt

    Fügen Sie Referenzen zwischen zwei Nutzlastelementen hinzu, indem Sie das optionale JSON-Element verwenden internal_idElement, das Nutzlastelemente eindeutig identifiziert.

    Verwenden Sie referenceItemsBlock zum Hinzufügen oder Aktualisieren von Referenzen. Sie können Verweise zwischen zwei beliebigen Elementen, einschließlich Hauptelementen, Suchelementen und zugehörigen Elementen, in einer einzigen Nutzlast hinzufügen.

    Weitere Informationen und Codebeispiele finden Sie unter CreateOrUpdateCIErweitert() ​​.

    CI-Neuklassifizierung

    Verwenden Sie updateWithoutUpgrade, updateWithoutDowngrade, Und updateWithoutSwitchKennzeichnungen im Einstellungsblock in einer Nutzlast, um unbeabsichtigte Aktualisierungen der Klasse von CIs zu verhindern. Diese Kennzeichnungen verhindern ein Upgrade, ein Downgrade oder einen Wechsel der Klasse eines CI, das mehrere Datenquellen versehentlich versuchen könnten, während sie dasselbe CI aktualisieren. Weitere Informationen und Codebeispiele finden Sie unter CreateOrUpdateCIErweitert() ​​.

    Kennzeichnungen für die Neuklassifizierung haben Vorrang vor allen anderen Systemeinstellungen für Konfigurieren Sie die CI-Neuklassifizierung während der IRE-Verarbeitung.

    Anwenderdefinierte vor- und Nachskripts werden hinzugefügt

    Verwenden Sie IntegrationHub ETL Bis Fügen Sie anwenderdefinierte Java-Skripts für eine Datenquelle einer CMDB-Integrationsanwendung hinzu . Diese Skripts bieten während der Verarbeitung von CMDB-Integrationen Zugriff auf die IRE-Eingabe- und -Ausgabennutzlasten.

    Bevor Skripts Zugriff auf einen Batch von Eingabenutzlasten gewähren, die an IRE gesendet werden. Mit einem anwenderdefinierten vor-Skript können Sie:
    • Überspringen Sie eine Nutzlast im Batch, indem Sie festlegen statusBis ÜBERSPRUNGEN . Geben Sie optional einen Grund für das Überspringen der Nutzlast an, der als Kommentar in der jeweiligen Importsatzzeilentabelle angezeigt wird.
    • Ändern Sie die Eingabenutzlast.
    • Schreiben Sie eine andere anwenderdefinierte Logik innerhalb des Skripts, die die IRE-Nutzlast verwendet.
    Nachdem Skripts Zugriff auf die IRE-Eingabe- und -Ausgabennutzlasten gewähren. Mit einem anwenderdefinierten After-Skript können Sie:
    • Vergleichen Sie einfach die Eingabe- und Ausgabennutzlasten, und identifizieren Sie die verschiedenen Vorgänge, die IRE für jedes CI ausgeführt hat.
    • Greifen Sie auf die sys_IDs der CIs zu, die IRE erstellt oder aktualisiert hat.
    • Schreiben Sie eine andere anwenderdefinierte Logik innerhalb des Skripts, die die IRE-Ausgabenutzlast verwendet.