Identification and Reconciliation Engine (IRE)

  • Freigeben Version: Xanadu
  • Aktualisiert 1. August 2024
  • 9 Minuten Lesedauer

    • IRE ist eine zugrunde liegende Schlüsselkomponente in „Identification and Reconciliation“ und bietet ein zentralisiertes Framework für die Durchführung von Identifizierungs- und Abgleichsprozessen über verschiedene Datenquellen hinweg. IRE verwendet Identifizierungsregeln, Abgleichregeln und IRE-Datenquellenregeln, um eingehende Daten zu verarbeiten, bevor diese Daten in die CMDB eingefügt werden.

    IRE-Prozesse tragen zur Aufrechterhaltung der Datenintegrität in der CMDB bei.
    • IRE verhindert doppelte CIs durch die eindeutige Identifizierung von CIs.​
    • IRE gleicht CI-Attribute ab, indem nur autorisierte Datenquellen in CMDB geschrieben werden können.
    ServiceNow® -Anwendungen wie Service-Mapping, Horizontal-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 (einschließlich Datenquellen von Drittanbietern) verwenden, können Sie REST oder skriptfähige IRE-APIs für die Identifizierung und den Abgleich nutzen.​
    Zusätzliche Information:

    CI-Identifizierung

    Der CMDB Identifikationsprozess basiert auf Identifizierungsregeln, um CIs eindeutig zu identifizieren. Wenn möglich, können CIs auch anhand der Werte source_name und source_native_key im Abschnitt sys_object_source_info der Nutzlast und in der Quelltabelle [sys_object_source] eindeutig identifiziert werden. Wenn die Identifizierung mit dieser Methode erfolgreich ist, müssen keine übereinstimmenden Algorithmen angewendet werden, die auf Identifizierungsregeln beruhen, was eine langsamere Identifizierungsmethode ist.

    Ein eindeutiger CI-Bezeichner kann im optionalen Objekt sys_object_source_info in der IRE-Nutzlast angegeben werden.
    {
  "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 stützen sich auf die Abhängigkeitsklassifizierung von CIs, um CIs eindeutig zu identifizieren. Beispielsweise, um ein Tomcat-CI zu identifizieren, das ein abhängiges CI ist. Angenommen, es wird ein Windows-Server-CI (unabhängige Klasse) angegeben, das eine Tomcat-Anwendung (abhängige Klasse) ausführt. Ein einziger 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 zu aktualisierendes CI auswählen. Abhängige Beziehungen erzwingen, dass im Identifizierungsprozess zuerst der Windows Server-Host identifiziert wird, auf dem die Tomcat-Anwendung ausgeführt wird, und erst dann die Tomcat-Anwendung im Kontext des Hosts eindeutig identifiziert wird.

    Identifizierung von Nutzlastelementen

    IRE generiert Bezeichnerschlüssel für alle Nutzlastelemente in einer eingehenden Nutzlast und verwendet diese Schlüssel dann, wenn versucht wird, teilweise und eingehende Nutzlasten abzugleichen. Ein Identifier-Schlüssel basiert entweder auf:
    • Kombination der Werte source_name und source_native_key aus dem Objekt sys_object_source_info.
    • Identifizierungskriteriumsattribute.
    IRE speichert die Bezeichnerschlüssel, die Teilelementen zugeordnet sind, in der Tabelle „CMDB IRE – Index der teilweisen Nutzlasten“ [cmdb_ire_partial_payloads_index] und verwendet diese Schlüssel dann, um einen Abgleich mit Bezeichnerschlüsseln eingehender Nutzlasten zu versuchen.

    Zeitstempel in Schlüsselattributen

    Um in Konflikt stehende Attributwerte zu lö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):

      Die neueste Erkennung (last_discovered) gibt den Zeitstempel der letzten Erkennung des CI an. IRE aktualisiert die Attribute last_discovered und discovery_source von CIs während der Nutzlastverarbeitung immer, auch wenn keine anderen CI-Attribute aktualisiert werden. Wenn last_discovered in der Nutzlast bereitgestellt wird, aktualisiert IRE das CI nur dann mit dem angegebenen Wert, wenn die Zeit last_discovered in der Nutzlast neuer ist als die in der CMDB. Wenn last_discovered nicht in der Nutzlast angegeben ist, aktualisiert IRE das Attribut last_discovered mit dem aktuellen Zeitstempel.

      Mit den Systemeigenschaften „ glide.identification_engine.skip_updating_source_last_discovered_if_older“ und „glide.identification_engine.ire_message_listener_skip_updating_source_last_discovered_to_now “ können Sie dieses Standardverhalten ändern.

    • „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 ist, fügt IRE diesen Wert ein. Andernfalls fügt IRE den aktuellen Zeitstempel ein.
      • In 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 den Wert source_recency_timestamp in einer Nutzlast verwendet, um das Attribut last_scan in der Quelltabelle [sys_object_source] zu aktualisieren:

    Erweiterte IRE-Funktionen

    Die skriptfähige API „CreateOrUpdateCIEnhanced()​​“und „ identifizierenCIEnhanced “ bietet Funktionen für die folgenden erweiterten IRE-Funktionen, die je nach Bedarf aktiviert oder deaktiviert werden können:
    Teilnutzlasten

    IRE isoliert Elemente, für die Datenquellen nicht genügend Informationen bereitgestellt haben, um das CI eindeutig zu identifizieren, 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 verfügt über 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_payloads, standardmäßig aktiviert. Wenn partial_payloads aktiviert ist, werden partial_commits und deduplicate_payloads 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 committet werden. Wenn eine Nutzlast Elemente mit Fehlern enthält, legt IRE daher weiterhin die verbleibenden gültigen Elemente in der Nutzlast fest. 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_commits, standardmäßig aktiviert.

    Deduplizieren Sie Nutzlastelemente

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

    API-Option: deduplicate_payloads, standardmäßig aktiviert.

    Zusammenfassung generieren

    IRE generiert Zusammenfassungen in der Ausgabenutzlast mit Verarbeitungsdetails, z. B. die Anzahl der Updates pro Klasse.

    API-Option: generate_summary, standardmäßig deaktiviert.

    Teilposten

    Ein Nutzlastelement wird als Teilelement eingestuft, wenn es die erforderlichen Daten zur eindeutigen Identifizierung enthält und einen der folgenden Fehler aufweist. Die eindeutige Identifizierung erfordert, dass das Nutzlastelement den Abschnitt [ sys_object_source_info mit den Werten source_name und source_native_key oder den vollständigen Satz der für die CI-Klasse angegebenen Identifizierungskriterienattribute oder beides enthält.

    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 –— Beim abhängigen 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, weil ermittelt wird, dass Nutzlastelemente Teilelemente sind, werden die Teilelemente als Teilnutzlasten in der Tabelle „CMDB IRE Partial Payloads“ [cmdb_ire_partial_payloads] im JSON-Format für eine spätere potenzielle Verarbeitung gespeichert.​ IRE verwendet Identifier-Schlüssel, um zu versuchen, eingehende abzugleichen Nutzlasten mit gespeicherten Teilnutzlasten.

    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 widersprüchliche Attribute aufzulösen, verwendet IRE entweder source_recency_timestamp (wenn source_native_key und source_name identisch sind) oder statische Abgleichsregeln, die für die Klasse angegeben sind. Das Ergebnis ist eine vollständige und gültige Nutzlast, die von IRE dann verarbeitet wird, um die entsprechenden CIs zu erstellen oder zu aktualisieren.

    Teilnutzlasten, die älter als 90 Tage sind, werden aus der Tabelle „CMDB IRE Partial Payloads“ [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 weist keine Attribute auf und kann daher von IRE nicht verarbeitet werden. source_name und „ source_native_key“ werden jedoch angegeben, sodass es sich um ein Teilelement handelt. Da das Computerelement partiell ist, ist das Datenträgerelement, das vom Computerelement abhängt, auch ein Teilelement.
    Beispiel für eine nachfolgende Nutzlast, die die vorherige Teilnutzlast durch Bereitstellung der fehlenden Details vervollständigt:
    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 source_name und source_native_keyidentisch sind. Daher werden die Teilnutzlast und die neue Nutzlast zusammengeführt, der Vorgang wird committet, und die Teilnutzlast wird aus der Tabelle der Teilnutzlasten gelöscht.

    Es gibt einen Grenzwert für die Anzahl der Elemente pro Teilnutzlast, der durch die Eigenschaft „ glide.identification_engine.partial_payload_items_max_size “ festgelegt wird (standardmäßig 1000). Durch das Speichern zugeordneter Beziehungen, Referenzen und abhängiger Elemente in einer Teilnutzlast kann dieser Grenzwert erreicht werden. In diesem Fall wird die Nutzlast in mehrere Teilnutzlasten aufgeteilt.

    Weitere Informationen zu Teilnutzlasten finden Sie unter CreateOrUpdateCIEnhanced().

    Unvollständige Elemente

    Ein Nutzlastelement wird als unvollständiges Element eingestuft, wenn:
    • Sie enthält nicht alle Daten, die für die eindeutige Identifizierung erforderlich sind
    • Es liegt ein Fehler vor, der keinem Teilelement zugeordnet ist
    Eine eindeutige Identifizierung ist nicht möglich, wenn weder source_name und source_native_key im Objekt sys_object_source_info noch der vollständige Satz der für die CI-Klasse angegebenen Identifizierungskriterienattribute angegeben werden.

    Unvollständige Elemente werden als unvollständige Nutzlasten in der Tabelle „CMDB IRE Unvollständige Nutzlasten“ [cmdb_ire_incomplete_payloads] im JSON-Format gespeichert. Unvollständige Elemente werden gespeichert, um Nutzlasten mit nicht behebbaren Fehlern zu protokollieren, und werden nie wieder verarbeitet.

    Beziehungen werden hinzugefügt

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

    Verwenden Sie das Objekt relations in der Nutzlast, um Beziehungen hinzuzufügen oder zu aktualisieren, indem Sie auf internal_ids von Elementen verweisen. Beziehungen können mit Hauptelementen und zugehörigen Elementen in der Nutzlast erstellt werden. Beispiel:
    • Beziehung (übergeordneter Index, untergeordneter Index, Beziehungstyp)
    • Beziehung (übergeordnete interne ID, untergeordnete interne ID, Beziehungstyp)​

    Weitere Informationen sowie Codebeispiele finden Sie unter CreateOrUpdateCIEnhanced().

    Hinzufügen von Referenzen zwischen Nutzlastelementen

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

    Verwenden Sie den Block referenceItems, um Referenzen hinzuzufügen oder zu aktualisieren. Sie können Referenzen zwischen zwei beliebigen Elementen hinzufügen, einschließlich Hauptelementen, Suchelementen und zugehörigen Elementen, in einer einzigen Nutzlast.

    Weitere Informationen sowie Codebeispiele finden Sie unter CreateOrUpdateCIEnhanced().

    Erneute CI-Klassifizierung

    Verwenden Sie die Kennzeichnungen updateWithoutUpgrade, updateWithoutDowngradeund updateWithoutSwitch im Einstellungsblock in einer Nutzlast, um zu verhindern, dass die CI-Klasse unbeabsichtigt aktualisiert wird. Diese Kennzeichnungen verhindern ein Upgrade, Downgrade oder Klassenwechsel eines CI, das mehrere Datenquellen unbeabsichtigt versuchen könnten, während sie dasselbe CI aktualisieren. Weitere Informationen sowie Codebeispiele finden Sie unter CreateOrUpdateCIEnhanced().

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

    Hinzufügen von anwenderdefinierten Vorher- und Nachher-Skripts

    Verwenden Sie die IntegrationHub ETL -Definition, um anwenderdefinierte Java-Skripts für eine Datenquelle einer CMDB-Integrationsanwendung hinzuzufügen. Diese Skripts bieten Zugriff auf die IRE-Eingabe- und -Ausgabenutzlasten, während CMDB-Integrationen verarbeitet werden.

    Bevor Skripts Zugriff auf einen Batch von Eingabenutzlasten bereitstellen, die an IRE gesendet werden. Mit einem anwenderdefinierten Vor-Skript können Sie:
    • Überspringen Sie eine Nutzlast im Batch, indem Sie status auf ÜBERSPRUNGEN festlegen. Geben Sie optional einen Grund für das Überspringen der Nutzlast an, die als Kommentar in der jeweiligen Importsatz-Zeilentabelle angezeigt wird.
    • Ändern Sie die Eingabenutzlast.
    • Schreiben Sie andere anwenderdefinierte Logik in das Skript, das die IRE-Nutzlast verwendet.
    Nachdem Skripts Zugriff auf die IRE-Eingabe- und -Ausgabenutzlasten gewähren. Mit einem anwenderdefinierten Nachskript können Sie:
    • Vergleichen Sie auf einfache Weise die Eingabe- und Ausgabenutzlast, 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 von der IRE erstellt oder aktualisiert wurden.
    • Schreiben Sie andere anwenderdefinierte Logik in das Skript, das die IRE-Ausgabenutzlast verwendet.