Identifizierungs- und Abgleichsmodul (Ire)

  • Freigeben Version: Yokohama
  • Aktualisiert 30. Januar 2025
  • 9 Minuten Lesedauer
  • Ire ist eine zugrunde liegende Schlüsselkomponente bei Identifizierung und Abgleich und bietet ein zentralisiertes Framework für Identifizierungs- und Abgleichsprozesse über verschiedene Datenquellen hinweg. Ire verwendet Identifizierungsregeln, Abgleichsregeln und Ire-Datenquellenregeln bei der Verarbeitung eingehender Daten, 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-Identifizierungsprozess 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.

    Ein eindeutiger CI-Bezeichner kann optional 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 ausführt (abhängige Klasse). 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 erst dann im Kontext des Hosts die Tomcat-Anwendung selbst eindeutig zu identifizieren.

    Identifikation 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 sys_object_source_infoObjekt.
    • Attribute des Identifizierungskriteriums.
    Ire speichert die Bezeichnerschlüssel, die Teilelementen zugeordnet sind, in der Tabelle „Index der partiellen Nutzlasten des CMDB-Ire“ [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 immer CIs last_discoveredUnd discovery_sourceAttribute während der Nutzlastverarbeitung, auch wenn keine anderen CI-Attribute aktualisiert werden. Wann last_discoveredWird in der Nutzlast angegeben. 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_updating_source_last_discovered_if_older Und glide.identification_engine.ire_message_listener_skip_updating_source_last_discovered_to_now Systemeigenschaften zum Ändern dieses Standardverhaltens.

    • Zuerst erkannt ( first_discovered) Ist der Zeitstempel, der angibt, wann das CI zum ersten Mal erstellt wurde.

      • Beim ersten Erstellen des CI: 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, um zu aktualisieren last_scanAttribut in der Quelltabelle [sys_object_Source]:

    Erweiterte Ire-Funktionen

    Die ErstellenOrUpdateCIErweitert() ​​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. Wann 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 bestätigt werden. Wenn eine Nutzlast Elemente mit Fehlern enthält, werden die verbleibenden gültigen Elemente in der Nutzlast weiterhin von Ire bestätigt. 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 die erforderlichen Daten für eine eindeutige Identifizierung enthält und einen der folgenden Fehler aufweist. 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 Identifizierungskriteriumsattribute, um mindestens einen Bezeichnereintrag 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 „Teilnutzlasten für CMDB-Ire“ [cmdb_ire_partial_payloads] im JSON-Format für die spätere potenzielle Verarbeitung gespeichert. ​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, stimmt Ire die eingehende Nutzlast mit den gespeicherten Teilnutzlasten ab. Ire führt dann alle übereinstimmenden Teilnutzlasten mit der eingehenden Nutzlast zusammen. Zum Auflösen von in Konflikt stehenden Attributen verwendet Ire eine der beiden 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 jeweiligen CIs zu erstellen oder zu aktualisieren.

    Teilnutzlasten, die älter als 90 Tage sind, werden aus der Tabelle „Teilnutzlasten für CMDB-Ire“ [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, und Ire kann es daher nicht verarbeiten. Jedoch source_nameUnd Source_native_key Werden bereitgestellt, was es zu einem Teilelement macht. Da das Computerelement teilweise ist, ist das vom Computerelement abhängige Datenträgerelement auch 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 ErstellenOrUpdateCIErweitert() ​​.

    Unvollständige Elemente

    Ein Nutzlastelement wird als unvollständiges Element bestimmt, wenn:
    • 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 „unvollständige Nutzlasten für CMDB-Ire“ [cmdb_ire_incomplete_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, indem verwiesen wird 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 ErstellenOrUpdateCIErweitert() ​​.

    Referenzen zwischen Nutzlastelementen werden hinzugefügt

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

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

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

    CI-Neuklassifizierung

    Verwenden Sie updateWithoutUpgrade, updateWithoutDowngrade, Und updateWithoutSwitchKennzeichnungen in den Einstellungen blockieren in einer Nutzlast, um unbeabsichtigte Aktualisierungen der Klasse von CIs zu verhindern. Diese Kennzeichnungen verhindern ein Upgrade, ein Downgrade oder ein Wechseln der Klasse eines CI, das mehrere Datenquellen versehentlich versuchen könnten, während dasselbe CI aktualisiert wird. Weitere Informationen und Codebeispiele finden Sie unter ErstellenOrUpdateCIErweitert() ​​.

    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 Importsatz-Zeilentabelle 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 -Ausgabenutzlasten gewähren. Mit einem anwenderdefinierten After-Skript können Sie:
    • Vergleichen Sie einfach die Eingabe- und Ausgabenutzlasten, 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 im Skript, die die Ire-Ausgabenutzlast verwendet.