Moteur Identification et réconciliation (IRE)

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 12 minutes de lecture

    • L’IRE est un composant clé sous-jacent de l’identification et du rapprochement, fournissant un cadre de travail centralisé pour effectuer des processus d’identification et de rapprochement sur 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 l’insertion de 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 les identifiant de façon unique.
    • IRE réconcilie les attributs de CI en permettant uniquement aux sources de données de référence d’écrire dans CMDB.
    ServiceNow® les applications telles que Mappage des servicesla découverte horizontale et la découverte de modèles utilisent des API pour appliquer des processus d’identification et de rapprochement. Vous pouvez également appliquer des processus IRE à des données importées par des ensembles d’importation. Lorsque vous utilisez d’autres sources de données, y compris des sources de données tierces, vous pouvez utiliser les API REST ou IRE scriptables pour effectuer l’identification et la réconciliation.
    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. Si possible, les CI peuvent également être identifiés de façon unique à l’aide source_name des valeurs et source_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 réussit à l’aide de cette méthode, il n’est pas nécessaire d’appliquer des algorithmes de correspondance qui reposent sur des règles d’identification, qui est une méthode d’identification plus lente.

    Un identificateur 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 de 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 de serveur Windows (classe indépendante) qui exécute une application Tomcat (classe dépendante). Il ne suffit pas d’utiliser le « chemin d’accès au fichier de configuration » pour identifier de manière unique le CI Tomcat, 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 du serveur Windows sur lequel l’application Tomcat est en cours d’exécution, puis à identifier de façon unique l’application Tomcat elle-même, dans le contexte de l’hôte.

    Identification des éléments de charge utile

    IRE génère des clés d’identification pour tous les éléments de charge utile dans une charge utile entrante, puis utilise ces clés lorsqu’il essaie de faire correspondre des charges utiles partielles et entrantes. Une clé d’identificateur est basée sur :
    • Combinaison des valeurs et source_namesource_native_key de l’objet sys_object_source_info .
    • Attributs de critères d’identification.
    IRE stocke les clés d’identificateur associées aux éléments partiels dans la table Index des charges utiles partielles IRE de 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 aider à résoudre les valeurs d’attribut conflictuelles, IRE utilise des horodatages dans les attributs suivants pour identifier les enregistrements qui sont 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

      La détection la plus récente (last_discovered) est l’horodatage de la dernière détection 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. Lorsqu’elle last_discovered est fournie 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 de 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écouverte (first_discovered) est l’horodatage de la création du CI.

      • Lorsque le CI est créé pour la première fois : si une valeur est fournie dans la charge utile, IRE insère cette valeur. Dans le cas contraire, IRE insère l’horodatage actuel.
      • Dans les mises à jour suivantes : si une valeur est fournie, IRE met à jour le CI avec la valeur fournie. Dans le cas contraire, 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 valeur d’une source_recency_timestamp 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 identifyCIEnhanced fournissent les fonctionnalités pour les 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 de façon unique le CI 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 en vue d’un éventuel traitement ultérieur. D’autres éléments sont identifiés comme des éléments incomplets, qui ne sont stockés qu’à des fins de journalisation.

    Par exemple : SCCM comporte plusieurs flux tels qu’un flux sur disque et un flux d’ordinateur. Il se peut que l’alimentation sur disque contienne 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 la validation du reste des éléments dans une charge utile. Par conséquent, lorsqu’une charge utile contient des éléments présentant 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 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 le 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 déterminé comme un élément partiel s’il contient les données nécessaires pour une identification unique et s’il présente l’une des erreurs suivantes. L’identification unique nécessite que l’élément de charge utile ait la section avec source_name les sys_object_source_info valeurs et source_native_key ou l’ensemble complet des attributs de critères d’identification spécifiés pour la classe de CI, ou les deux.

    Erreurs IRE pour un élément partiel :
    • MISSING_MATCHING_ATTRIBUTES –— L’élément n’a pas d’attributs de critères d’identification afin d’utiliser au moins une entrée d’identificateur pour la correspondance.
    • REQUIRED_ATTRIBUTE_EMPTY : impossible de créer un CI car un attribut obligatoire est manquant.
    • MISSING_DEPENDENCY –— Le CI dépendant n’a pas de 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 déterminés comme éléments partiels, les éléments partiels sont enregistrés en tant que charges utiles partielles dans la table Charges utiles partielles IRE [cmdb_ire_partial_payloads] CMDB au format JSON pour un traitement ultérieur éventuel. IRE utilise des clés d’identificateur pour tenter de faire correspondre les charges utiles entrantes avec les charges utiles partielles stockées.

    Si, ultérieurement, 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 conflits d’attributs, IRE utilise soit source_recency_timestamp (quand source_native_key et source_name sont identiques), soit des règles de rapprochement statiques 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 de plus de 90 jours sont supprimées de la table Charges utiles partielles IRE [cmdb_ire_partial_payloads] CMDB.

    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 pas d’attributs et IRE ne peut donc pas le traiter. Cependant, et source_native_key sont fournis, source_name ce qui en fait un élément partiel. Étant donné que l’élément ordinateur est partiel, l’élément disque qui dépend de l’élément ordinateur est également un élément partiel.
    Exemple d’une charge utile suivante 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, car 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 de relations, de références et d’éléments dépendants associés dans une charge utile partielle peut permettre d’atteindre cette limite, auquel cas la charge utile est divisé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
    • Une erreur s’est produite qui n’est pas associée à un élément partiel.
    L’identification unique n’est pas possible si ni dans source_namesource_native_key l’objet sys_object_source_info ni l’ensemble complet des attributs de critères d’identification spécifiés pour la classe de CI n’est fourni.

    Les éléments incomplets sont enregistrés en tant que charges utiles incomplètes dans la table Charges utiles incomplètes [cmdb_ire_incomplete_payloads] IRE de CMDB au format JSON. Les éléments incomplets sont stockés dans le but de consigner 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 de 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 des éléments principaux et des éléments connexes de 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 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 referenceItems bloc pour ajouter ou mettre à jour des références. Vous pouvez ajouter des références entre deux éléments quelconques, y compris des éléments principaux, des éléments de recherche et des é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 marqueurs , updateWithoutDowngrade, updateWithoutUpgradeet updateWithoutSwitch dans 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 sont prioritaires sur tous les autres paramètres système pour Configurer la reclassification CI pendant le traitement IRE.

    Ajout de scripts avant et après personnalisé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 les scripts permettent d’accéder à un lot de charges utiles d’entrée qui seront envoyées à IRE. L’utilisation d’un script Before personnalisé vous permet de :
    • Ignorez une charge utile dans le lot en définissant la status sur IGNORÉ. Vous pouvez également fournir un motif pour ignorer la charge utile, qui s’affiche sous forme de commentaire dans la table de lignes de jeu d’importation respective.
    • Modifiez la charge utile entrée.
    • Écrivez une autre logique personnalisée à l’intérieur du 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 After personnalisé vous permet de :
    • Comparez facilement les charges utiles d’entrée et de sortie et identifiez les différentes opérations qu’IRE a effectuées sur chaque CI.
    • Accédez aux sys_ids des CI créés ou mis à jour par IRE.
    • Écrivez une autre logique personnalisée à l’intérieur du script qui utilise la charge utile de sortie IRE.