cmdb.external#
L'intégration de sources de données externes dans la base de données de gestion de la configuration (CMDB) peut être simplifiée par diverses mesures. Tout d'abord, il est important que les données soient disponibles dans un format standardisé, facile à traiter pour faciliter la lecture et le transfert vers la CMDB. De plus, des fonctions doivent être mises en œuvre pour permettre un transfert de données complet et ponctuel ainsi que des synchronisations régulières et automatisées. Il est crucial que chaque élément de données dans la CMDB soit lié à son origine afin de garantir l'identifiabilité des sources de données. En même temps, des règles claires et des directives doivent être définies pour délimiter la portée des données des sources individuelles. L'intégration simultanée de plusieurs sources de données devrait également être prise en charge, les conflits et les incohérences devant être reconnus et résolus. Enfin, des opérations de demande unique devraient être mises en œuvre pour permettre aux utilisateurs d'effectuer des importations de données, des synchronisations et des requêtes via une interface unique afin d'augmenter la convivialité et l'efficacité.
cmdb.external#
Quels sont les identifiants externes?#
- Identifiants uniques et stables basés sur des chaînes définies par l'utilisateur
- Composés d'un "type" et d'un "id"
Par exemple mon_id_fournisseur / mon_id_objet
.
Pourquoi avons-nous besoin d'identifiants externes?#
- Identification claire des enregistrements de données d'objet et de catégorie
- Délimitation : Zones de données complétées
- L'appelant n'a pas besoin de connaître les identifiants d'enregistrement internes
Comment fonctionnent les identifiants externes?#
- Approche hiérarchique
- L'utilisateur définit un identifiant externe pour l'objet
- extType : Identifiant pour la source de données/fournisseur
- extId : Identifiant pour l'objet
- L'utilisateur définit également un identifiant (sans extType) pour chaque entrée de catégorie
- L'API crée une correspondance entre les identifiants et les identifiants internes
Des exemples seraient :
- Identifiant externe pour un objet
source-de-données-1 / serveur-windows100
- Identifiant externe pour chaque entrée de catégorie
source-de-données-1 / serveur-windows100 / C__CATG__CPU / intel-1
L'objet se trouve au premier niveau. Ici, nous définissons le extType d'une part et le extId de l'autre. Ensemble, ils forment l'identifiant complet et identifient de manière unique l'objet créé. Au niveau suivant, cependant, nous avons notre niveau de catégorie. Chaque catégorie commence par la constante correspondante et reçoit un identifiant unique au niveau inférieur.
Dans cette structure, i-doit détermine ensuite automatiquement l'identifiant final, illustré ici à l'aide de l'exemple de intel-1 et intel-2. Voici un exemple de requête push pour créer un objet via le nouveau point de terminaison.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
|
et enregistre le tout dans une table de correspondance interne.
Délimitation#
La délimitation devrait garantir que deux sources de données ne se gênent pas mutuellement, car nous supposons ce qui suit:
Si différentes sources de données alimentent leurs données dans i-doit en même temps, nous supposons que chaque source de données est prépondérante en son propre droit et peut être considérée comme une seule source de vérité. En d'autres termes, cela signifie qu'un objet ne peut jamais apparaître dans plusieurs sources de données en même temps.
Sur la base de cette hypothèse, i-doit met en œuvre le filet de sécurité suivant:
- Les objets sont clairement attribués à des sources de données
- Un objet ne peut être attribué qu'à une seule source de données
- Un objet de source de données ne peut pas être géré par plusieurs sources de données
- Une autre précision: les objets existants ne peuvent pas être attribués manuellement à une source de données
- Un objet ne peut être attribué qu'à une seule source de données
Nous avons un traitement similaire au niveau de la catégorie :
- Attribution claire des entrées de catégorie aux sources de données
- Une caractéristique spéciale de MV : les entrées MV peuvent être éditées manuellement même si elles proviennent d'une source de données
- Dans l'autre sens, cependant, c'est-à-dire que les entrées de catégorie à valeurs multiples créées manuellement restent protégées contre l'accès par la source de données
- Mais il y a aussi une exception ici, à savoir pour les catégories à valeur unique : les entrées de catégorie à valeur unique créées manuellement peuvent être manipulées par les sources de données
- Il existe également un cas non autorisé et non mappable : La source de données "data-source-2" ne peut pas avoir une entrée de CPU dans un objet géré par "data-source-1"
cmdb.external.push.v2#
Création et mise à jour d'objets et d'entrées de catégorie par une seule requête. De plus, diverses "stratégies " nous permettent de mapper différents cas d'utilisation, bien qu'il soit à noter qu'elles se trouvent uniquement au niveau de la catégorie.
L'API Push dispose également de procédures pour convertir des valeurs lisibles par l'homme en leur représentation technique, par exemple dialog+, références d'objets ou références de catégories. Et très important :
En utilisant l'API Push, vous n'avez pas à vous passer des structures CMDB générales, telles que le système de droits, la règle de validation ou le journal. Tout fonctionne comme avant!
Stratégie | Entrée existe en valeur unique | Entrée existe en valeur multiple | Entrée n'existe pas en valeur unique | Entrée n'existe pas en valeur multiple |
---|---|---|---|---|
créer | sera ignoré | sera ignoré | est créée | est créée |
mettre à jour | sera mis à jour | sera mis à jour | est créée | est créée |
écraser | sera mis à jour | sera mis à jour | est créée | est créée |
écraser supprime toutes les entrées en valeur multiple de i-doit qui ne sont pas incluses dans la demande. Les existantes sont mises à jour ou créées
Paramètres de la demande#
Clé | Type de données JSON | Requis | Description |
---|---|---|---|
extType | Chaîne | Oui | Source de données, par exemple : source-de-données-1 |
extId | Chaîne | Oui | Objet, par exemple : serveur-windows100 |
classe | Chaîne | Oui | Type d'objet, par exemple : C__OBJTYPE__SERVEUR |
titre | Chaîne | Oui | Désignation de l'objet, par exemple : Serveur 100 |
Exemple#
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 |
|
cmdb.external.pull.v2#
Lecture des données CMDB basée sur l'"Identifiant Externe". Lors de la récupération, l'identifiant externe détermine les données interrogées, par exemple :
extType | extId | Action |
---|---|---|
data-source-1 | null | Lit tous les objets et toutes les données de catégorie |
data-source-1 | windows-server100 | Lit windows100 et toutes les données de catégorie |
data-source-1 / windows-server100 / C__CATG__CPU | null | Lit windows100 et toutes les entrées CPU |
data-source-1 / windows-server100 / C__CATG__CPU | intel-1 | Lit windows100 et seulement l'entrée CPU intel-1 |
Paramètres de la requête#
Clé | Type de données JSON | Requis | Description |
---|---|---|---|
extType | Chaîne | Oui | Source de données, par exemple : data-source-1 |
extId | Chaîne | Oui | Objet, par exemple : windows-server100 |
Exemple#
1 2 3 4 5 6 7 8 9 10 |
|
1 |
|