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

ServiceNow® Les applications telles que , Horizontal Mappage des services discovery (Détection horizontale) et Pattern discovery (Découverte de schémas) 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 ensembles 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 :

• À propos des propriétés qui affectent certaines fonctions d’IRE : Voir Propriétés pour Identification et rapprochement.
• À propos de l’utilisation des API IRE : Voir IdentificationEngine - Scoped.
• À propos de l’activation du débogage et de la vérification des problèmes avec une charge utile : Consultez Comment journaliser la charge utile envoyée à IRE et vérifier les problèmes avec 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 d’identification et de rapprochement de la CMDB lors du transfert d’un CI (en tant que charge utile) à createOrUpdateCI() [KB0750386].
• À propos de l’exécution d’une charge utile via IRE : Voir [CMDB IRE] How to run the CI identification on demand using the payload [KB0750383].

Un identificateur de CI unique peut être fourni dans l’objet facultatif sys_object_source_info dans 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 lorsqu’il s’agit 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 de critères d’identification.

IRE stocke les clés d’identificateur associées aux éléments partiels dans la table Index de charges utiles partielles IRE [cmdb_ire_partial_payloads_index] de CMDB, puis utilise ces clés pour essayer de faire correspondre les clés d’identificateur des charges utiles entrantes.

Pour résoudre les conflits de valeurs d’attribut, 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. 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 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 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 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 donc le traitement ne peut pas se poursuivre. Certains de ces éléments sont identifiés comme des éléments partiels, qui sont stockés pour 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 dispose de plusieurs flux tels qu’un flux de disque et un flux d’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 de valider le 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 é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 traitement.

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

Générer le 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_name et source_native_key sont fournis, ce qui en fait un élément partiel. Étant donné que 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.

Un élément de charge utile est défini 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_name et source_native_key dans l’objet sys_object_source_info , ni l’ensemble 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. Il est possible de créer des relations à 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)

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 fournir un motif pour ignorer la charge utile, qui s’affichera sous forme de commentaire dans la table des 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.

After scripts fournissent l’accès aux charges utiles d’entrée et de sortie IRE. L’utilisation d’un script after personnalisé vous permet d’effectuer les opérations suivantes :

• 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 à l’intérieur du script qui utilise la charge utile de sortie IRE.