Use Case
Indizierung-beim-XML-Import
Einleitung
An dieser Stelle soll erläutert werden, wie die Indizierung beim Import von CIs per XML funktioniert und wie diese genutzt oder umgangen werden kann.
Prinzip
Das XML-Schema zum Import von CIs in dot4 gibt vor, dass für jedes zu importierende CI neben dem CI-Typ auch eine eindeutige ID vergeben werden muss.
Hinweis: Diese ID steht beim Import nicht als Attribut zur Verfügung. Tipp: Die ID entweder aus einem eindeutigen Attribut des CI-Typs ableiten oder diese ID zusätzlich als Attribut beim CI-Typ im XML mit aufführen.
Weiterhin werden bei der Konfiguration des Importprozesses in der Mapping-Vorlage die Abgleichs-Attribute festgelegt, die dazu führen soll, ob ein CI beim Import als neues CI erkannt wird, welches damit auch neu angelegt wird oder ob die importierten Daten einem vorhandenen CI zugeordnet werden.
Es könnte also der Trugschluss vorliegen, dass beim Import allein das/die Abgleichs-Attribut/e in der Mapping-Vorlage von Relevanz ist/sind, um ein CI als eindeutig zu identifizieren. Das ist nicht der Fall, sondern beim Import über XML-Dateien kann weiterhin die eindeutige ID der zu importierenden CIs von Relevanz sein.
Auch, wenn die ID beim Import nicht als Attribut sichtbar ist, so wird diese beim Import in der Staging Area mit den Staging-Einträgen festgehalten. Erfolgt ein weiterer Import, des gleichen CI-Typs aus der gleichen Import-Quelle, so gleicht der Import die IDs aus der XML-Datei mit den IDs der Staging Area ab. Sind die IDs identisch, so wird das/die Abgleichs-Attribut/e der Mapping- Vorlage aus Gründen der Performance und zur Beschleunigung des Importprozesses nicht mehr berücksichtigt. Die schnelle Entscheidung der Zuordnung von importierten CIs über die ID beschleunigt den Importvorgang. Die aufwändigeren Entscheidungen über das/die Abgleichs-Attribut/e in der Mapping-Vorlage verlangsamt den Importvorgang.
Hinweis: Dies ist auch der Grund, warum der erste, initiale Import von Daten bzw. der Import nach Löschen der Staging Area oftmals wesentlich länger dauert als die wiederholten Importe.
Sollte die Staging Area bzgl. der betroffenen CIs gelöscht worden sein, so kann dieser Abgleich der IDs (mangels entsprechender Daten in der Staging Area) nicht erfolgen. Hinweis: Dies kann auch gewollt sein.
Im Folgenden wird dargestellt, welche positiven oder negativen Auswirkungen ein bestimmter Umgang mit den IDs, der Staging Area und der Import-Konfiguration haben kann.
Fehlerbild: IDs von CIs identisch
Im folgenden Screenshot ist erkennbar, dass die IDs von zwei CIs nicht
eindeutig sind.
Im Importprotokoll wird dies als Warnung ausgeben mit der Mitteilung „Configuration item ID C:\RTCImp\Server-Export-001.xml-node windows server 1 exists more than once in response for mapping „Windows Server“!“.
Folge: Damit wird nur das erste der CIs mit identischer ID importiert.
Wiederholter Import ohne Löschen der Staging Area
Im ersten Schritt wird ein Import (bei leerer Staging Area) durchgeführt, bei dem die IDs eindeutig sind. In der Mapping-Vorlage wird der „Node_Name“ (aus dem XML) auf das Attribut „Name“ gemapped und „Name“ dient auch als Abgleichattribut. Aufgrund der gleichen Werte für „Erstellt am“ und „Letzte Aktualisierung am“ ist zu erkennen, dass die CIs neu angelegt wurden.
Nach dem Import sind beide CIs in der CMDB angelegt:
Weiterhin sind beide CIs über die Importquelle „Server“ in der Staging
Area:
Für den wiederholten Import wurden in der XML-Datei folgende
Änderungen vorgenommen:
Erste Änderung: Der „Node_Name“=“AAA_Server_001“ wurde beibehalten, die ID wurde geändert auf „3“.
Folge: Da die ID=“3“ in der Staging Area für den CI-Typ „Windows Server“ aus vorhergehenden Importen noch nicht vorhanden war, findet keine Übereinstimmung der ID aus XML-Datei und Staging Area statt. Somit erfolgt der Abgleich über das Abgleichattribut in der Mapping-Vorlage, welches in diesem Beispiel der „Name“ ist. Somit werden trotz veränderter ID aber gleichem Wert für den Namen die importierten Werte dem gleichen CI zugeordnet.
Zweite Änderung: Der „Node_Name“ wurde geändert auf “AAA_Server_004“, die ID wurde beibehalten.
Folge: Die Übereinstimmung der ID=“2“ in der Staging Area für den CI-Typ „Windows Server“ aus vorhergehenden Importen und der ID=“2“ in der XML-Datei führt dazu, dass die importierten Daten dem vorhandenen CI zugeordnet werden. Obwohl der „Name“ das Abgleichattribut in der Mapping-Vorlage ist und nicht übereinstimmt, wird dieser beim vorhanden CI durch den Import ersetzt.
Wiederholter Import mit Löschen der Staging Area
Im ersten Schritt wird ein Import (bei leerer Staging Area) durchgeführt, bei dem die IDs eindeutig sind. In der Mapping-Vorlage wird der „Node_Name“ (aus dem XML) auf das Attribut „Name“ gemapped und „Name“ dient auch als Abgleichattribut. Aufgrund der gleichen Werte für „Erstellt am“ und „Letzte Aktualisierung am“ ist zu erkennen, dass die CIs neu angelegt wurden.
Nach dem Import sind beide CIs in der CMDB angelegt:
Weiterhin sind beide CIs über die Importquelle „Server“ in der Staging
Area:
Die Staging Area für den CI-Typ „Windows Server“ wird vor dem nächsten
Import gelöscht.
Für den wiederholten Import wurden in der XML-Datei folgende Änderungen vorgenommen:
Erste Änderung: Der „Node_Name“=“AAA_Server_001“ wurde beibehalten, die ID wurde geändert auf „3“.
Folge: Da die ID=“3“ in der Staging Area für den CI-Typ „Windows Server“ aus vorhergehenden Importen noch nicht vorhanden war, finde keine Übereinstimmung der ID aus XML-Datei und Staging Area statt. Somit erfolgt der Abgleich über das Abgleichattribut in der Mapping-Vorlage, welches in diesem Beispiel der „Name“ ist. Somit werden trotz veränderter ID, aber gleichem Wert für den Namen, die importierten Werte dem gleichen CI zugeordnet.
Zweite Änderung: Der „Node_Name“ wurde geändert auf “AAA_Server_004“, die ID wurde beibehalten.
Folge: Da die ID=“2“ in der Staging Area für den CI-Typ „Windows Server“ nach deren Löschung nicht mehr vorhanden war, findet keine Übereinstimmung der ID aus XML-Datei und Staging Area statt. Da der „Name“ das Abgleichattribut in der Mapping-Vorlage ist und es für den Wert „AAA_Server_004“ noch kein CI mit diesem Namen gibt, wird ein neues CI angelegt.
Löschen der Staging Area vor dem Import
Aufgrund des oben beschriebenen Verfahrens kann es Gründe geben, die Staging Area vor einem wiederholten Import von XML-Dateien zu löschen.
Folgende Möglichkeiten stehen dafür zur Verfügung:
Manuelles Löschen in der Staging Area
In die Staging Area – Configuration Items wechseln, dort den entsprechenden CI-Typ auswählen und für alle Import-Quellen dieses CI-Typs die Staging-Einträge löschen.
Manuelles Löschen im Import
Die entsprechende Import-Quelle selektieren und über das Kontextmenü "Staging-Einträge jetzt löschen" alle Staging-Einträge dieser Quelle löschen.
Automatisches Löschen
In der Konfiguration der entsprechenden Import-Quelle festlegen, dass alle Staging-Einträge dieser Quelle vor der Ausführung eines Imports gelöscht werden.
Tipp
Die IDs der CIs in einer XML-Datei sollten nach Möglichkeit aus einem oder ggf. mehreren Attributen des CIs abgeleitet werden. Dabei sind Attribute zu bevorzugen, aus denen sich die Eindeutigkeit der CIs ableiten lässt, wie z.B. UUIDs, Serien-Nr. (Hinweis: Vorsicht beim Clonen von VMs).
Ergänzende Hinweise
Die IDs der CIs müssen innerhalb einer XML-Datei pro CI-Typ immer eindeutig sein.
Bei unterschiedlichen Importquellen dürfen die CI-IDs zum gleichen CI-Typ identisch sein. Der Importprozess beachtet den Abgleich der CI-IDs über die Staging Area pro CI-Typ und Importquelle.
Unterschiedliche Importquellen können sich sowohl auf einen Importserver als auch mehrere Importserver beziehen.
Versionsinfo
Version 1.03
09.08.2023Dokument basiert auf dot4 Release 2023.2
REALTECH AG
Paul-Ehrlich-Str. 1
69181 Leimen
URHEBERRECHTE UND WARENZEICHEN
© 2024 REALTECH AG. Alle Rechte vorbehalten. Dieses Dokument enthält vertrauliche und rechtlich geschützte Informationen. Das unerlaubte Kopieren und die unbefugte Weitergabe des Dokuments an Dritte (ganz oder in Teilen) sind nicht gestattet. Die in diesem Dokument abgebildeten Produkt-Namen, Logos, Marken und sonstigen Kennzeichen stehen REALTECH oder den Lizenzgebern von REALTECH zu und dürfen nicht ohne vorherige schriftliche Zustimmung des Rechteinhabers verwendet werden.