Relations des éléments de configuration et Graphique de connaissances

Les relations d’éléments de configuration (CI) permettent Graphique de connaissances de répondre à des questions en langage naturel sur les dépendances de service et la topologie de l’infrastructure en stockant les relations parent-enfant saisies entre les CMDB éléments de configuration.

La CMDB_REL_CI table stocke les relations entre les éléments de configuration (CI) dans ServiceNow CMDB. Chaque relation relie un CI parent à un CI enfant via un type de relation défini, ce qui permet Graphique de connaissances de comprendre et de parcourir la topologie de votre environnement informatique.

La prise en charge des relations CI dans Knowledge Graph permet aux utilisateurs de poser des questions en langage naturel sur la façon dont les services, les serveurs, les bases de données et les autres CI sont liés les uns aux autres sans écrire de requêtes ni naviguer directement dans CMDB les tables.

Activation de la relation CI pour Graphique de connaissances

La prise en charge des relations CI pour est Graphique de connaissances désactivée par défaut. Définissez les deux propriétés système suivantes sur vrai pour l’activer :

Tableau 1. Propriétés système pour la prise en charge des relations CI

Propriété système	Objectif
sn_kg.description_generation.enable_cmdb_rel_ci	Active la génération de description pour les données de relation CI
sn_kg.query.enable_cmdb_rel_ci	Active l’interrogation Graphique de connaissances sur les données de relation CI

Remarque :

Après avoir activé les deux propriétés, laissez le temps aux données de relation CI d’être entièrement indexées avant d’exécuter des requêtes. Les résultats peuvent être incomplets tant que l’indexation n’est pas terminée.

Comment les données de relation CI sont stockées

Chaque enregistrement dans la table CI relationship (Relations CI) représente une relation bidirectionnelle entre deux CI. Les relations sont décrites par un type de relation qui se compose d’une relation de parent à enfant et d’une relation d’enfant à parent, séparées par des doubles deux-points :

<descripteur parent> ::<descripteur enfant>

Cela signifie que chaque relation peut être lue dans deux directions :

• Parent → enfant : lecture à l’aide de la relation de parent à enfant (descripteur parent)
• Enfant → parent : lecture à l’aide de la relation d’enfant à parent (descripteur enfant)

Par exemple, un enregistrement dans la table Relation CI a Bond Trading (cmdb_ci_service) comme parent, lnux100 (cmdb_ci_linux_server) comme enfant et un type de relation Depends on ::Used by. Cette relation se lit comme suit :

• Le trading d’obligations dépend de lnux100
• lnux100 est utilisé par Bond Trading

Remarque :

La direction de la relation affecte la façon dont vous formulez les requêtes au Graphique de connaissances. Les requêtes de parent à enfant (par exemple, « dépend de ») renvoient des résultats plus fiables que les requêtes d’enfant à parent (par exemple, « utilisé par »).

Graphique de connaissances prise en charge des relations CI

Peut Graphique de connaissances répondre aux questions sur les relations CI lorsque la requête spécifie clairement les trois éléments suivants :

• Classe du CI parent (par exemple, service)
• Le sens de la relation : relation de parent à enfant ou relation d’enfant à parent (par exemple, dépend de)
• Classe du CI enfant (par exemple, Linux serveur)

Héritage de la hiérarchie des classes

Lorsque vous définissez une relation entre deux classes CI, cette relation s’étend Graphique de connaissances automatiquement à toutes les classes situées plus haut dans la hiérarchie des classes CI. Cela signifie que les utilisateurs peuvent interroger à un niveau de classe plus général tout en obtenant des résultats sur toutes les sous-classes correspondantes.

Par exemple, une relation définie entre le service et le serveur Linux s’applique également au serveur, qui est une classe parent de Linux serveur dans la hiérarchie. L’interrogation des serveurs plutôt que Linux des serveurs renvoie des résultats dans toutes les sous-classes de serveurs, y compris Linux serveur, serveur Windows, UNIX serveur et autres.

Remarque :

Si une requête renvoie moins de résultats que prévu, essayez d’utiliser une classe parente plus large dans la hiérarchie (par exemple, « serveur » au lieu de «Linux serveur ») pour inclure tous les types de CI hérités.

Schémas de requête pris en charge

La table suivante présente des exemples de requêtes auxquelles le graphe de connaissances peut répondre à l’aide des données de relation CI. Chaque requête spécifie une classe parent, un descripteur de relation et une classe enfant.

Tableau 2. Schémas de requête pris en charge

Scénario	Exemple de requête :
Service qui dépend d’un serveur spécifique Linux	Quels services dépendent du serveur « lnux100 » Linux ?
Serveurs dont dépend un service spécifique	Le service 'Bond Trading' dépend de quel UNIX serveur ?
Tous les types de serveurs dont dépend un service (à l’aide de la hiérarchie)	Le service 'Bond Trading' dépend de quel serveur ?
Ordinateurs connectés à une base de données	Quelles bases de données sont connectées par des ordinateurs ?
Relation à sauts multiples sur trois types de CI	Quelle base de données s’exécute sur UNIX un serveur qui se connecte à l’équipement réseau 'nc6500-a01' ?

Schémas de requête non pris en charge

Les types de requête suivants ne sont pas pris en charge actuellement. Utilisez les alternatives recommandées pour obtenir les résultats dont vous avez besoin.

Tableau 3. Schémas de requête non pris en charge

Limitation	Requête non prise en charge	Alternative recommandée
Négation d’une relation	Quelles options d’entreprise n’ont pas d’applications d’entreprise connexes ?	Reformulez pour demander ce qui existe plutôt que ce qui n’existe pas.
Type de relation non spécifié	Montrez-moi les services liés aux Linux serveurs.	Montrez-moi les services qui dépendent des Linux serveurs.
Ignorer des étapes dans un chemin à sauts multiples	Montrez-moi les serveurs à New York.	Montrez-moi les serveurs dans les racks présents dans les centres de données situés à New York.