Moteur Identification et réconciliation (IRE)

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 12 minutes de lecture

    • L’IRE est un élément clé sous-jacent de l’identification et de la réconciliation, fournissant un cadre centralisé pour effectuer des processus d’identification et de rapprochement entre différentes sources de données. IRE utilise des règles d’identification, des règles de rapprochement et des règles de source de données IRE lors du traitement des données entrantes avant d’insérer ces données dans la CMDB.

    Les processus IRE contribuent au maintien de l’intégrité des données dans la CMDB.
    • IRE empêche les CI en double en identifiant de manière unique les CI.
    • IRE réconcilie les attributs de CI en permettant uniquement aux sources de données de référence d’écrire à CMDB.
    ServiceNow® Les applications telles que Mappage des servicesDétection horizontale et Détection de modèle utilisent des API pour appliquer des processus d’identification et de rapprochement. Vous pouvez également appliquer des processus IRE aux données importées par les jeux d’importation. Lorsque vous utilisez d’autres sources de données, y compris des sources de données tierces, vous pouvez tirer parti des API REST ou IRE scriptables pour effectuer l’identification et le rapprochement.
    Informations supplémentaires :

    Identification du CI

    Le processus d’identification CMDB s’appuie sur des règles d’identification pour identifier de façon unique les CI. Dans la mesure du possible, les CI peuvent également être identifiés de manière unique à l’aide source_namesource_native_key des valeurs fournies dans la sys_object_source_info section de la charge utile et dans la table Source [sys_object_source]. Si l’identification est réussie à l’aide de cette méthode, il n’est pas nécessaire d’appliquer des algorithmes d’appariement qui reposent sur des règles d’identification, qui est une méthode d’identification plus lente.

    Un identificateur de CI unique peut être fourni dans l’objet facultatif sys_object_source_info de la charge utile IRE.
    {
  "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"
      }
     }
    ]
  }

    Les processus d’identification s’appuient sur la classification des dépendances des CI pour identifier de façon unique les CI. Par exemple, pour identifier un CI Tomcat qui est un CI dépendant. En supposant un CI Windows Server (classe indépendante) qui exécute une application Tomcat (classe dépendante). L’utilisation du « chemin d’accès au fichier de configuration » pour identifier de manière unique le CI Tomcat n’est pas suffisante, car l’application Tomcat peut s’exécuter sur plusieurs machines avec des chemins identiques. Le moteur d’identification ne sera pas en mesure de choisir un CI à mettre à jour. Les relations dépendantes forcent le processus d’identification à identifier d’abord l’hôte Windows Server sur lequel l’application Tomcat s’exécute, puis à identifier de manière unique l’application Tomcat elle-même.

    Identification des éléments de charge utile

    IRE génère des clés d’identificateur pour tous les éléments de charge utile d’une charge utile entrante, puis utilise ces clés pour essayer de faire correspondre les charges utiles partielles et entrantes. Une clé d’identificateur est basée sur :
    • Combinaison des valeurs et de l’objet source_namesys_object_source_info.source_native_key
    • Attributs du critère d’identification.
    IRE stocke les clés d’identificateur associées aux éléments partiels dans la table d’index de charges utiles partielles IRE CMDB [cmdb_ire_partial_payloads_index], puis utilise ces clés pour essayer de les faire correspondre aux clés d’identificateur des charges utiles entrantes.

    Horodatages dans les attributs clés

    Pour résoudre les valeurs d’attributs en conflit, IRE utilise des horodatages dans les attributs suivants pour identifier les enregistrements plus anciens que l’enregistrement actuel et qui peuvent donc être ignorés :

    • Dernière découverte (last_discovered) et source de découverte (discovery_source) :

      Dernière découverte (last_discovered) est l’horodatage de la dernière découverte du CI. IRE met toujours à jour les CI et discovery_source les attributs pendant le traitement de la charge utile, même lorsqu’aucun autre attribut de CI n’est last_discovered mis à jour. Quand last_discovered il est fourni dans la charge utile, IRE met à jour le CI avec la valeur fournie uniquement si l’heure last_discovered dans la charge utile est plus récente que celle dans la CMDB. S’il last_discovered n’est pas fourni dans la charge utile, IRE met à jour l’attribut last_discovered avec l’horodatage actuel.

      Vous pouvez utiliser les propriétés système glide.identification_engine.skip_updating_source_last_discovered_if_older et glide.identification_engine.ire_message_listener_skip_updating_source_last_discovered_to_now pour modifier ce comportement par défaut.

    • Première détection (first_discovered) est l’horodatage de la première création du CI.

      • Lors de la première création du CI : si une valeur est fournie dans la charge utile, IRE insère cette valeur. Sinon, IRE insère l’horodatage actuel.
      • Dans les mises à jour ultérieures : Si une valeur est fournie, IRE met à jour le CI avec la valeur fournie. Sinon, l’attribut n’est pas mis à jour.
    Vous pouvez également utiliser les propriétés système suivantes pour modifier la façon dont IRE utilise la source_recency_timestamp valeur d’une charge utile afin de mettre à jour l’attribut last_scan dans la table Source [sys_object_source] :

    Fonctionnalités IRE améliorées

    Les API scriptables CreateOrUpdateCIEnhanced() et identifyCIEnenhanced fournissent la fonctionnalité des fonctionnalités IRE améliorées suivantes, qui peuvent être activées ou désactivées selon les besoins :
    Charges utiles partielles

    IRE isole les éléments pour lesquels les sources de données n’ont pas fourni suffisamment d’informations pour identifier le CI de façon unique et par conséquent, le traitement ne peut pas continuer. Certains de ces éléments sont identifiés comme des éléments partiels, qui sont stockés pour un éventuel traitement ultérieur. D’autres éléments sont identifiés comme des éléments incomplets, qui sont stockés uniquement à des fins de journalisation.

    Par exemple : SCCM a plusieurs flux tels qu’un flux de disque et un flux d’ordinateur. Le flux du disque peut contenir des informations complètes sur le disque, mais pas suffisamment d’informations sur le CI de l’ordinateur dont il dépend.

    Option API : partial_payloads qui est activée par défaut. Quand partial_payloads est activé et deduplicate_payloads sont automatiquement activés, partial_commits quel que soit leur paramètre dans les options.

    Validations partielles

    Les erreurs dans certains éléments n’empêchent pas de valider le reste des éléments d’une charge utile. Par conséquent, lorsqu’une charge utile contient des éléments avec des erreurs, IRE valide toujours les éléments valides restants dans la charge utile. Dans ce cas, certains des éléments non validés sont enregistrés en tant que charges utiles partielles et d’autres éléments non validés sont enregistrés en tant que charges utiles incomplètes.

    Option API : partial_commits qui est activée par défaut.

    Dédupliquer les éléments de la charge utile

    IRE déduplique les éléments en double dans la charge utile, en fusionnant ces doublons en un seul élément de charge utile pour traitement.

    Option API : deduplicate_payloads qui est activée par défaut.

    Générer un résumé

    IRE génère des résumés dans la charge utile de sortie avec des détails de traitement tels que le nombre de mises à jour par classe.

    Option API : generate_summary qui est désactivée par défaut.

    Éléments partiels

    Un élément de charge utile est considéré comme un élément partiel s’il contient les données nécessaires pour une identification unique et s’il comporte l’une des erreurs suivantes. L’identification unique exige que l’élément de charge utile ait la section avec source_name et sys_object_source_info valeurssource_native_key, ou l’ensemble complet des attributs du critère d’identification spécifiés pour la classe CI, ou les deux.

    Erreurs IRE pour un élément partiel :
    • MISSING_MATCHING_ATTRIBUTES : l’élément n’a pas d’attributs de critère d’identification pour utiliser au moins une entrée d’identificateur pour la mise en correspondance.
    • REQUIRED_ATTRIBUTE_EMPTY – Impossible de créer un CI car un attribut requis est manquant.
    • MISSING_DEPENDENCY –— Il manque au CI dépendant une relation de dépendance spécifiée dans la charge utile.
    • INSERT_NOT_ALLOWED_FOR_SOURCE : une règle de source de données IRE empêche les sources de données spécifiées de créer des CI de la classe spécifiée.

    Pour plus d’informations sur les messages d’erreur IRE, reportez-vous à la section Messages d’erreur IRE.

    Si le traitement échoue parce que les éléments de charge utile sont des éléments partiels, les éléments partiels sont enregistrés en tant que charges utiles partielles dans la table Charges utiles partielles IRE CMDB [cmdb_ire_partial_payloads] au format JSON pour un traitement éventuel ultérieur. IRE utilise des clés d’identificateur pour tenter de faire correspondre les charges utiles entrantes avec les charges utiles partielles stockées.

    Si, par la suite, une source de données envoie les données qui manquaient dans l’élément partiel, IRE fait correspondre la charge utile entrante avec les charges utiles partielles stockées. IRE fusionne ensuite toutes les charges utiles partielles correspondantes avec la charge utile entrante. Pour résoudre les attributs en conflit, IRE utilise des source_recency_timestamp règles de rapprochement statiques (lorsque source_native_keysource_name et sont identiques) spécifiées pour la classe. Le résultat est une charge utile complète et valide qu’IRE traite ensuite pour créer ou mettre à jour les CI respectifs.

    Les charges utiles partielles datant de plus de 90 jours sont supprimées de la table Charges utiles partielles IRE CMDB [cmdb_ire_partial_payloads].

    Exemple d’une charge utile partielle : 
    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"}
              ]
}
    L’élément d’ordinateur dans la charge utile ci-dessus n’a aucun attribut et IRE ne peut donc pas le traiter. Cependant, source_name et source_native_key sont fournis, ce qui en fait un élément partiel. Comme l’élément d’ordinateur est partiel, l’élément de disque qui dépend de l’élément d’ordinateur est également un élément partiel.
    Exemple d’une charge utile ultérieure qui complète la charge utile partielle précédente en fournissant les détails manquants :
    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"
      }
    }
  ]
}
    L’ordinateur dans la charge utile partielle et le serveur dans la nouvelle charge utile correspondent parce qu’ils ont des valeurs identiques source_name et source_native_key. Par conséquent, la charge utile partielle et la nouvelle charge utile sont fusionnées, l’opération est validée et la charge utile partielle est supprimée de la table Charges utiles partielles.

    Il existe une limite au nombre d’éléments par charge utile partielle, qui est définie par la propriété glide.identification_engine.partial_payload_items_max_size (1 000 par défaut). Le stockage des relations, des références et des éléments dépendants associés, dans une charge utile partielle, peut entraîner l’atteinte de cette limite, auquel cas la charge utile est fractionnée en plusieurs charges utiles partielles.

    Pour plus d’informations sur les charges utiles partielles, consultez CreateOrUpdateCIEnhanced().

    Éléments incomplets

    Un élément de charge utile est considéré comme un élément incomplet si :
    • Il ne contient pas toutes les données nécessaires à une identification unique.
    • Il comporte une erreur qui n’est pas associée à un élément partiel
    L’identification unique n’est pas possible si ni source_namesource_native_key l’objet sys_object_source_info ni l’ensemble des attributs de critères d’identification spécifiés pour la classe CI ne sont fournis.

    Les éléments incomplets sont enregistrés en tant que charges utiles incomplètes dans la table Charges utiles incomplètes IRE CMDB [cmdb_ire_incomplete_payloads] au format JSON. Les éléments incomplets sont stockés dans le but d’enregistrer les charges utiles avec des erreurs irrécupérables, et ne sont plus jamais traités.

    Ajout de relations

    Ajoutez des relations à l’aide d’index ou de l’élément internal_id JSON facultatif.

    Utilisez l’objet relations dans la charge utile pour ajouter ou mettre à jour des relations en faisant référence à internal_ids des éléments. Les relations peuvent être créées à l’aide d’éléments principaux et d’éléments connexes dans la charge utile. Par exemple :
    • Relation (index parent, index enfant, type de relation)
    • Relation (ID interne parent, ID interne enfant, type de relation)

    Pour plus d’informations et pour des exemples de code, consultez CreateOrUpdateCIEnhanced().

    Ajout de références entre les éléments de la charge utile

    Ajoutez des références entre deux éléments de charge utile à l’aide de l’élément JSON internal_id facultatif, qui identifie de manière unique les éléments de charge utile.

    Utilisez le bloc pour ajouter ou mettre à jour des referenceItems références. Vous pouvez ajouter des références entre deux éléments, y compris les éléments principaux, les éléments de recherche et les éléments connexes, dans une seule charge utile.

    Pour plus d’informations et pour des exemples de code, consultez CreateOrUpdateCIEnhanced().

    Reclassification de CI

    Utilisez les updateWithoutUpgrademarqueurs , updateWithoutDowngradeet dans updateWithoutSwitch le bloc de paramètres d’une charge utile, pour empêcher les mises à jour involontaires de la classe des CI. Ces marqueurs empêchent la mise à niveau, le passage à une version antérieure ou le changement de classe d’un CI que plusieurs sources de données peuvent tenter involontairement lors de la mise à jour du même CI. Pour plus d’informations et pour des exemples de code, consultez CreateOrUpdateCIEnhanced().

    Les marqueurs de reclassification ont priorité sur tous les autres paramètres système pour Configurer la reclassification des CI pendant le traitement IRE.

    Ajout de scripts personnalisés avant et après

    Utilisez Centre d’intégration ETL pour ajouter des scripts Java personnalisés pour une source de données d’une application d’intégration CMDB. Ces scripts permettent d’accéder aux charges utiles d’entrée et de sortie IRE lors du traitement des intégrations CMDB.

    Avant que les scripts ne fournissent l’accès à un lot de charges utiles d’entrée qui seront envoyées à IRE. L’utilisation d’un script personnalisé avant vous permet d’effectuer les opérations suivantes :
    • Ignorez une charge utile dans le lot en définissant le status paramètre sur SKIPPED. Vous pouvez également indiquer la raison pour laquelle vous ignorez la charge utile, qui s’affichera sous forme de commentaire dans la table de lignes de l’ensemble d’importation respective.
    • Modifiez la charge utile en entrée.
    • Écrivez une autre logique personnalisée dans le script qui utilise la charge utile IRE.
    Les scripts After permettent d’accéder aux charges utiles d’entrée et de sortie IRE. L’utilisation d’un script personnalisé après vous permet de :
    • Comparez facilement les charges utiles d’entrée et de sortie et identifiez les différentes opérations effectuées par IRE sur chaque CI.
    • Accédez aux sys_ids des CI créés ou mis à jour par IRE.
    • Écrivez une autre logique personnalisée dans le script qui utilise la charge utile de sortie IRE.