cmdb.external#
Die Einbindung externer Datenquellen in die Configuration Management Database (CMDB) kann durch verschiedene Maßnahmen vereinfacht werden. Zunächst ist es wichtig, dass die Daten in einem standardisierten, leicht zu verarbeitenden Format vorliegen, um das Auslesen und Übernehmen in die CMDB zu erleichtern. Darüber hinaus sollten Funktionen implementiert werden, die eine vollständige, einmalige Datenübernahme sowie regelmäßige, automatisierte Synchronisationen ermöglichen. Dabei ist es entscheidend, dass jedes Datenelement in der CMDB mit seiner Herkunft verknüpft wird, um die Identifizierbarkeit der Datenquellen sicherzustellen. Gleichzeitig müssen klare Regeln und Richtlinien definiert werden, um den Geltungsbereich der Daten aus den einzelnen Quellen abzugrenzen. Die simultane Integration mehrerer Datenquellen sollte ebenfalls unterstützt werden, wobei Konflikte und Inkonsistenzen erkannt und aufgelöst werden müssen. Schließlich sollten Single-Request Operationen implementiert werden, die es Anwendern ermöglichen, Datenimporte, -synchronisationen und -abfragen über eine einzige Schnittstelle durchzuführen, um die Benutzerfreundlichkeit und Effizienz zu erhöhen.
cmdb.external#
Was sind External Identifier?#
- Benutzerdefinierte String-basierte stabile und eindeutige IDs
- Zusammengesetzt aus einem "type" und einer "id"
Zum Beispiel my_vendor_id / my_object_id
.
Warum brauchen wir External Identifier?#
- Klare Identifizierung von Objekt- und Kategorie-Datensätzen
- Scoping: Abgeschlossene Datenbereiche
- Caller muss interne Datensatz-IDs nicht kennen
Wie funktionieren External Identifier?#
- Hierarchischer Ansatz
- User definiert einen External Identifier für das Objekt
- extType: Identifikator für die Datenquelle/Vendor
- extId: Identifikator für das Objekt
- User definiert zudem einen Identifier (ohne extType) für jeden Kategorieeintrag
- API erstellt ein Mapping zwischen Identifier und internen IDs
Beispiele dazu wären:
- External Identifier für ein Objekt
datenquelle-1 / windows-server100
- External Identifier für jeden Kategorieeintrag
datenquelle-1 / windows-server100 / C__CATG__CPU / intel-1
Auf der ersten Ebene befindet sich das Objekt. Hierbei definieren wir zum einen den extType und zum anderen die extId. Beides im Verbund bildet den vollständigen Identifier und identifiziert das erstellte Objekt eindeutig.
Auf der nächsten Ebene hingegen haben wir unsere Kategorie Ebene. Dabei startet jede Kategorie mit der zugehörigen Konstante und erhält auf der darunterliegenden eine eindeutige Id.
Aus dieser Struktur ermittelt i-doit dann automatisch den finalen Identifier hier am Beispiel von intel-1 und intel-2 verdeutlicht.
Hier ein beispielhafter Push-Request zur Erstellung eines Objektes über den neuen Endpunkt.
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 |
|
und erfasst das ganze in einer internen Mapping Tabelle.
Scoping#
Das Scoping soll sicherstellen, dass sich zwei Datenquellen nicht in die Quere kommen, da wir folgendes annehmen:
Wenn unterschiedliche Datenquellen zugleich ihre Daten in i-doit einspeisen, so nehmen wir an, dass jede Datenquelle für sich genommen führend ist und als Single-Source-of-Truth betrachtet werden kann. Das heisst im Umkehrschluss, dass ein Objekt niemals zugleich in mehreren Datenquellen auftauchen kann.
Basierend auf dieser Annahme implementiert i-doit daher folgendes Sicherheitsnetz:
- Es gibt eine klare Zuweisung von Objekten zu Datenquellen
- Ein Objekt kann lediglich einer Datenquelle zugewiesen sein
- Ein Datenquelle-Objekt kann nicht von mehreren Datenquellen verwaltet werden
- Eine weitere Feinheit: Bestehende Objekte können einer Datenquelle nicht manuell zugewiesen werden
- Ein Objekt kann lediglich einer Datenquelle zugewiesen sein
Auf der Kategorie Ebene haben wir ein ähnliches Handling:
- Klare Zuweisung von Kategorieeinträgen zu Datenquellen
- Eine Besonderheit bei MV: MV-Einträge können manuell bearbeitet werden auch wenn sie aus einer Datenquelle kommen
- Der umgekehrte Weg jedoch, also manuell erstellte multi-value Kategorieeinträge bleiben vor dem Zugriff der Datenquelle geschützt
- Aber auch hier gibt es eine Ausnahme, nämlich bei single-value Kategorien: Manuell erstellte single-value Kategorieeinträge können durch Datenquellen manipuliert werden
- Rechts unten gibt es zudem noch einen unerlaubten und nicht abbildbaren Case: Die Datenquelle "datenquelle-2" kann keinen CPU-Eintrag in einem Objekt besitzen, was durch die "datenquelle-1" verwaltet wird
cmdb.external.push.v2#
Erstellung und Aktualisierung von Objekten und Kategorieeinträgen durch einen einzelnen Request. Zudem erlauben uns verschiedene "strategies" die Abbildung verschiedener Use-Cases, wobei aber erwähnt werden sollte, dass diese lediglich auf der Kategorieschicht angesiedelt sind.
Außerdem verfügt auch die Push-API über Prozeduren, um Human-Readable Werte in ihre technische Repräsentation zu überführen, beispielsweise Dialog+, Objekt-Referenzen oder Kategoriereferenzen. Und ganz wichtig:
Durch die Verwendung der Push-API muss man nicht auf generelle CMDB-Strukturen verzichten, wie zum Beispiel das Rechtesystem, Validierungsregel oder das Logbuch. Alles greift wie bisher!
Strategy | Eintrag existiert single-value | Eintrag existiert multi-value | Eintrag existiert nicht single-value | Eintrag existiert nicht multi-value |
---|---|---|---|---|
create | wird übersprungen | wird übersprungen | wird erstellt | wird erstellt |
update | wird aktualisiert | wird aktualisiert | wird erstellt | wird erstellt |
overwrite | wird aktualisiert | wird aktualisiert | wird erstellt | wird erstellt |
overwrite löscht alle multi-value Einträge aus i-doit, die nicht im Request enthalten sind. Bestehende werden aktualisiert oder erstellt.
Request parameters#
Key | JSON data type | Required | Description |
---|---|---|---|
extType | String | Ja | Datenquelle, zum Beispiel: datenquelle-1 |
extId | String | Ja | Objekt, zum Beispiel: windows-server100 |
class | String | Ja | Objekttyp, zum Beispiel: C__OBJTYPE__SERVER |
title | String | Ja | Objekt Bezeichnung, zum Beispiel: Server 100 |
Example#
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#
Lesen von CMDB-Daten basierend auf dem "External Identifier". Beim Pull bestimmt der External Identifier die abgefragten Daten zum Beispiel:
extType | extId | Aktion |
---|---|---|
datenquelle-1 | null | Liest alle Objekte und jegliche Kategoriedaten |
datenquelle-1 | windows-server100 | Liest windows100 und jegliche Kategoriedaten |
datenquelle-1 / windows-server100 / C__CATG__CPU | null | Liest windows100 und alle CPU-Einträge |
datenquelle-1 / windows-server100 / C__CATG__CPU | intel-1 | Liest windows100 und nur den CPU-Eintrag intel-1 |
Request parameters#
Key | JSON data type | Required | Description |
---|---|---|---|
extType | String | Ja | Datenquelle, zum Beispiel: datenquelle-1 |
extId | String | Ja | Objekt, zum Beispiel: windows-server100 |
Example#
1 2 3 4 5 6 7 8 9 10 |
|
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 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 |
|