Directives générales pour l’utilisation de l’identification CMDB

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 3 minutes de lecture

    • Passez en revue les directives générales suivantes pour utiliser efficacement l’identification CMDB.

    Règles d’identification

    Une règle d’identification indépendante identifie un CI en fonction des attributs du CI, indépendamment des autres CI.

    Une règle d’identification dépendante identifie un CI par ses CI dépendants et les relations du CI identifié avec ces CI dépendants. L’identification avec une règle d’identification dépendante est basée sur les CI dépendants et sur les relations et qualificateurs entre le CI identifié et ses CI dépendants. L’identification nécessite alors plus de temps qu’avec une règle d’identification indépendante et est sujette à certaines erreurs d’identification. L’utilisation de règles dépendantes doit donc être réduite au minimum.

    La modélisation des CI détermine le type de règles d’identification requis pour une identification correcte des CI.

    Créez des règles d’identification à l’aide de l’ordre d’importance suivant :
    1. Règles d’identification indépendantes — Il est toujours préférable de créer des règles d’identification indépendantes plutôt que des règles d’identification dépendantes. Lorsque vous modélisez un CI, définissez-le avec un ensemble complet d’attributs qui se prêtent à une identification indépendante, éliminant ainsi la nécessité d’utiliser des CI supplémentaires pour l’identification.
    2. Règles d’identification dépendantes : s’il est nécessaire de créer des règles d’identification dépendantes, définissez un niveau unique de dépendance. Deux est le nombre maximal de niveaux de dépendance pris en charge.
    3. Évitez de créer des entrées d’identificateur de recherche. L’utilisation de l’entrée d’identificateur de recherche est fortement déconseillée car elle peut réduire les performances. Si cela n’est pas inévitable, assurez-vous d’examiner d’abord les définitions de classe et envisagez des mises à jour qui autorisent l’utilisation de règles d’identification indépendantes.
    4. Limitez le nombre d’entrées d’identificateur dans une règle d’identification, idéalement à 1. Une deuxième entrée d’identificateur peut réduire davantage les performances, tout comme chaque entrée d’identificateur supplémentaire.
    5. Créez des règles d’identification forte dans lesquelles les entrées d’identificateur les plus fortes et les entrées connexes sont définies avec la priorité la plus élevée.
    6. Assurez-vous que la règle d’identification se trouve au niveau de classe requis.

    Charge utile

    Créez la charge utile en suivant l’ordre d’importance suivant :

    1. Taille de la charge utile : limite le nombre de CI par charge utile à 500.
    2. Évitez les entrées en double dans la charge utile.
      Exemple : si une règle d’identification a un attribut de critère pour le champ Name ( Nom ), les éléments en double de la charge utile suivante entraînent un échec :
      var payload = {
    items: [{
        className:'cmdb_ci_linux_server',
        values: {
            name:'Win Server 200',
            ram:'2048'
        }},
{
        className:'cmdb_ci_linux_server',
        values: {
            name:'Win Server 200',
            ram:'4096'
        }}]
};
    3. Ne transmettez pas de données système telles que les suivantes dans la charge utile.
      var payload = {
    items: [{
        className:'cmdb_ci_linux_server',
        values: {
            name:'Win Server 200',
            sys_domain:'global',
            sys_domain_path:'xyz',
            sys_updated_on:'2017-06-15 16:25:11',
            sys_mod_count:23,
        }}]
};
    4. Fournissez l’ensemble minimal nécessaire d’attributs de critères pour chaque élément de charge utile, conformément à ce qui est spécifié dans les règles d’identification correspondantes.
    5. Lorsque vous mettez en correspondance des CI, utilisez les sysIds des CI si disponibles. S’il est fourni, IRE peut utiliser le sysId pour localiser directement un CI sans avoir besoin d’attributs de critères de la part de la règle d’identification. Dans ce cas, IRE n’utilise pas le sysId dans le processus de correspondance.
      • Exemple : CI indépendant à mettre à jour : sysId est disponible. 
        var payload = {
    items: [{
        className:'cmdb_ci_linux_server',
        values: {
            sys_id:'194876usytrr65378098',
            ram:'2048',
        }}]
};
      • Exemple : CI dépendant qui doit être inséré. Le CI de guerre Tomcat dépend du CI Tomcat et le CI Tomcat dépend du CI du serveur Linux. Les SysId pour les CI Tomcat et Linux sont disponibles.
        var payload = {
        items: [{
            className:'cmdb_ci_app_server_tomcat_war’, 
            values: {
                name:'war1',
                short_description:'my description'            }
        }, {
            className:'cmdb_ci_app_server_tomcat',
            values: {
                sys_id:'194876usytrr65378098'
            }
        }, {
            className:'cmdb_ci_linux_server',
            values: {
                sys_id:'09876tysueyt6345lakiu'
            }
        }],
        relations: [{
                    parent:1,
                    child:0,
                    type: 'Contains::Contained by’}, {
                        parent:1,
                        child:2,
                        type:'Runs on::Runs'}
                    ]
                };
      • Exemple : CI dépendant qui doit être mis à jour : le sysId est disponible.
        var payload = {
        items: [{
            className:'cmdb_ci_app_server_tomcat_war', 
            values: {
                sys_id:'039387euey637465sytet',
                short_description:'my description new'            }
        }]
                };
    6. Lors de l’insertion de nombreux CI, qui dépendent tous du même CI, vous devez sérialiser vos appels d’API. Dans le cas contraire, tenter de traiter simultanément de nombreux CI peut obstruer le système et dégrader considérablement les performances globales du système.