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 les CI de façon unique.
• IRE réconcilie les attributs de CI en autorisant uniquement les sources de données de référence à écrire dans CMDB.

ServiceNow® des applications telles que Mappage des servicesla détection horizontale et la détection de modèles 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 jeux d’importation. Lorsque vous utilisez d’autres sources de données, y compris des sources de données tierces, vous pouvez utiliser des API IRE REST ou scriptables pour procéder à l’identification et à la réconciliation.

Informations supplémentaires :

• À propos des propriétés qui affectent certaines fonctions d’IRE : reportez-vous à la section Propriétés pour l’identification et la réconciliation.
• À propos de l’utilisation des API IRE : consultez Moteur d’identification - Champ d’application.
• À propos de l’activation du débogage et de la vérification des problèmes liés à une charge utile : consultez la section Comment consigner la charge utile envoyée à IRE et vérifier les problèmes liés à la charge utile [KB0750382].
• À propos des étapes effectuées par IRE pour illustrer le fonctionnement d’IRE, telles que la validation de la charge utile, l’application du rapprochement et la validation des données dans la CMDB : Voir [CMDB - IRE] Fonctionnement du moteur Identification et réconciliation CMDB lors du passage d’un CI (en tant que charge utile) à createOrUpdateCI() [KB0750386].
• À propos de l’exécution d’une charge utile via IRE : Consultez [CMDB IRE] Exécution de l’identification CI sur demande à l’aide de la charge utile [KB0750383].

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"
      }
     }
    ]
  }

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 lors de la tentative de correspondance des 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 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 [cmdb_ire_partial_payloads_index] IRE de CMDB, puis utilise ces clés pour essayer de mettre en correspondance avec les clés d’identificateur des charges utiles entrantes.

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étection (last_discovered) et Source de détection (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’il last_discovered 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 de la CMDB. S’il last_discovered n’est pas fourni dans la charge utile, IRE met à jour l’attribut avec l’horodatage last_discovered 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 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. 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 valeur d’une source_recency_timestamp charge utile pour mettre à jour l’attribut last_scan dans la table Source [sys_object_source] :

• glide.identification_engine.skip_updating_last_scan_if_older
• glide.identification_engine.ire_message_listener_skip_updating_last_scan_to_now

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 le CI de façon unique, de sorte que le traitement ne peut pas se poursuivre. Certains de ces éléments sont identifiés comme des éléments partiels, qui sont stockés en vue d’un traitement ultérieur potentiel. D’autres éléments sont identifiés comme des éléments incomplets, qui sont stockés uniquement à des fins de journalisation.

Par exemple : SCCM comporte plusieurs flux, par exemple un flux sur disque et un flux pour ordinateur. Le flux de 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 la validation du reste des éléments dans 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 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.

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 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.

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, source_nameet source_native_key sont fournis, ce qui en fait un élément partiel. Étant donné que l’élément de l’ordinateur est partiel, l’élément de disque qui dépend de l’élément de l’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 de la charge utile partielle et le serveur de la nouvelle charge utile correspondent, car ils ont des données 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.

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 et n’est pas associée à un élément partiel.

L’identification unique n’est pas possible si source_namesource_native_key ni dans l’objet sys_object_source_info ni l’ensemble complet des attributs de critères d’identification spécifiés pour la classe CI n’est fourni.

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. Des relations peuvent être créées à l’aide d’éléments principaux et d’é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)

Avant que les scripts ne donnent accès à un lot de charges utiles d’entrée qui seront envoyées à IRE. L’utilisation d’un script avant personnalisé vous permet d’effectuer les opérations suivantes :

• Ignorez une charge utile dans le lot en définissant l’option statussur SKIPPED. Vous pouvez également fournir un motif d’omission de la charge utile qui s’affichera sous forme de commentaire dans la table de lignes de jeu d’importation respective.
• Modifiez la charge utile d’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 d’effectuer les actions suivantes :

• 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 à la 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.