GRLoader-XML

Dieser Artikel enthält die folgenden Themen:
casm173
Dieser Artikel enthält die folgenden Themen:
GRLoader erfordert eine Eingabe über XML-Dokumente, die aus einer Dokumentenkopfzeile mit darauf folgenden einschließenden <GRLoader>-XML-Element-Tags bestehen, die ein oder mehrere <ci>-Tags (für Configuration Item-Definitionen) oder <relation>-Tags (für Beziehungen) enthalten.
Geben Sie die XML-Dokumentkopfzeile folgendermaßen an:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
Aktualisieren Sie das Codierungsattribut nach Bedarf, gemäß den entsprechenden Anforderungen der Zeichenverarbeitung. Geben Sie beispielsweise "ISO-8859-1" an, um norwegische Sonderzeichen zu verarbeiten.
Beispiel: Formatieren einer GRLoader-XML-Datei
Die folgende Vorlage stellt das Format für eine GRLoader-XML-Datei dar:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <GRLoader> <ci> [define a CI: common and family-specific attributes, versioning, reconciliation, MDR] </ci> [repeat as necessary for each CI] <relation> <type>relationship_type</type> <delete_flag>active_state</delete_flag> <provider> <name>resource name</name> <serial_number>serial number</serial_number> <system_name>host name</system_name> <asset_num>resource tag</asset_num> <mac_address>mac address</mac_address> <dns_name>dns name</dns_name> <id>ci_uuid</id> </provider> <dependent> <name>resource name</name> <serial_number>serial number</serial_number> <system_name>host name</system_name> <asset_num>resource tag</asset_num> <mac_address>mac address</mac_address> <dns_name>dns name</dns_name> <id>ci_uuid</id> </dependent> </relation> [repeat as necessary for each relationship] </GRLoader>
XML-Inhalt: der Configuration Item-Tag
GRLoader verwendet die XML-Definition des Configuration Items, um die Attributwerte und Beziehungen eines Configuration Items zu laden. Die Definition des Configuration Item muss einen Mindestsatz aus erforderlichen Attributen enthalten, um mit Hilfe der
<ci>
-XML-Element-Tags erstellt oder aktualisiert zu werden.
Sie definieren die XML für einen CI, indem Sie Werte für die folgenden Attribute angeben:
  • Klassenidentifikation (obligatorisch)
  • Abstimmungsattribute (erforderlich)
  • gemeinsame Attribute
  • familienspezifische Attribute
  • MDR-Identifikationsattribute
  • Versionskontrollenattribute
Der CI-Tag: Identifikation von Familie und Klasse
Die Klassenidentifikation muss für jedes CI angegeben werden, um die richtige Familie und Klasse mit dem CI verknüpfen zu können.
Geben Sie mit den folgenden XML-Tags die Familien- und Klassenattribute an:
  • <family>
    (Optional) Eine Sammlung von CIs mit ähnlichen Attributen.
  • <class>
    (Erforderlich) Eine Untergruppe von CIs in einer Familie.
Wenn GRLoader die Familie oder Klasse nicht finden kann, wird das CI weder erstellt noch aktualisiert.
Beispiel: Identifizieren eines CI nach Familie und Klasse
Das folgende Beispiel zeigt ein CI mit dem Namen "ServerCI", das nach der Familie
"Hardware.Server" und der Klasse
"Windows" identifiziert ist.
<ci> <name>ServerCI</name> <family>Hardware.Server</family> <class>Windows</class> ... </ci>
Der Configuration Item-Tag: Abstimmungsattribute (erforderlich)
Beim Erstellen, Aktualisieren eines oder Verweisen auf ein Configuration Item sind ein oder mehrere Abstimmungsattribute erforderlich. GRLoader verwendet diese Attribute, um das Configuration Item, das erstellt oder aktualisiert werden soll, eindeutig zu kennzeichnen. Abstimmungsattribute werden auch verwendet, um die übergeordnete/untergeordnete Beziehung zwischen zwei Configuration Items zu kennzeichnen.
Geben Sie die Abstimmungsattribute mit den folgenden XML-Element-Tags an:
  • -- Der Name des CIs oder der Ressource (erforderlich beim erstmaligen Erstellen des CIs)
  • -- Die eindeutige Kennung des Herstellers
  • -- Alternative Ressourcenkennung, zum Beispiel eine alternative ID, die auf dem Aufkleber auf dem Computer angegeben ist.
  • -- Computername (nur Hardware)
  • -- Der Name, unter dem dieses Gerät beim DNS-Server bekannt ist
  • -- MAC-Adresse. (nur Hardware)
  • -- UUID des CIs; wird für die direkte Aktualisierungen verwendet, wenn die ID bekannt ist
Das Namensattribut ist erforderlich, wenn ein Configuration Item zum ersten Mal erstellt wird. Wenn GRLoader die angegebenen Abstimmungsattribute nicht auflösen kann, wird ein bestehendes Configuration Item nicht aktualisiert. Abstimmungsattribute sind allgemeine Attribute mit speziellem Zweck, die zu Identifikationszwecken genutzt werden.
Beispiel: Identifizieren eines CIs beim Erstellen oder Aktualisieren
Im folgenden Beispiel verwendet die Configuration Item-Definition den Namen, serial_number, dns_name, mac_address und system_name, um das Configuration Item beim Erstellen oder Aktualisieren eindeutig zu kennzeichnen.
<ci> <name>ServerCI</name> <serial_number>HMVV081</serial_number> <dns_name>serverci.myco.com</dns_name> <mac_address>00:12:3F:48:F0:95</mac_address> <system_name>ServerCI</system_name> ... </ci>
Der Configuration Item-Tag: gemeinsame (allgemeine) Attribute
Allgemein handelt es sich hierbei um gemeinsame Attribute, die in jeder CMDB-Familie oder -Klasse verwendet werden können. Der XML-Element-Tag, der für das Attribut verwendet wird, ist mit dem Attributobjektnamen identisch. Der Attributwert hängt von dem Typ ab, der eine Konstante oder ein SREL-Wert sein kann, der einen Fremdschlüsselverweis zu einer anderen Tabelle darstellen kann.
Beispiel: Angeben von gemeinsamen Attributen
Im folgenden Beispiel gibt die Configuration Item-Definition Server-Configuration Item die folgenden gemeinsamen Attribute an: Hersteller, Modell und alarm_id (IP-Adresse). Der Name "ServerCI" ist auch ein gemeinsames Attribut.
<ci> <name>ServerCI</name> ... <manufacturer>Dell Inc.</manufacturer> <model>OptiPlex GX280</model> <alarm_id>130.200.19.220</alarm_id> ... </ci>
Der CI-Tag: familienspezifische Attribute
Klassenattribute gelten spezifisch für eine bestimmte Configuration Item-Familie oder -Klasse. Der XML-Element-Tag, der für das Klassenattribut verwendet wird, ist mit dem Attributobjektnamen identisch, der sich in den familien- und klassenspezifischen Tabellen befindet.
Beispiel: Angeben von familienspezifischen Attributen
Im folgenden Beispiel gibt die CI-Definition mit dem Namen "ServerCI" die Attribute an, die für die
Familie "Hardware.Server" spezifisch sind. Dazu gehören "bios_ver", "cd_rom_type", "hard_drive_capacity" usw.
<ci> <name>ServerCI</name> ... <bios_ver>A04</bios_ver> <cd_rom_type>DVD+-RW DVD8701</cd_rom_type> <hard_drive_capacity>90 MB</hard_drive_capacity> <number_net_card>3</number_net_card> <number_proc_inst>1</number_proc_inst> <phys_mem>2048 MB</phys_mem> <proc_speed>2793 MHz</proc_speed> <swap_size>4959 MB</swap_size> ... </ci>
Der Configuration Item-Tag: MDR-Identifikation
Ein Management Data Repository (MDR) kennzeichnet den Datenanbieter für ein Configuration Item, und gibt an, wie das Configuration Item wieder dem entsprechenden MDR zugeordnet wird.
CA SDM verwendet MDR-Informationen, um folgende Aufgaben auszuführen:
  • Startet im Kontext des CI-Protokolls direkt im MDR-Datenanbieter.
  • Verfolgt Änderungen am CI-Attribut direkt zum Quell-MDR zurück.
  • Erkennt, wenn mehr als ein MDR ein CI-Attribut aktualisiert. Dieser Fall kann eintreten, wenn mehrere MDRs unabhängig Daten zu einer CI-Definition beitragen.
  • Identifizieren des maßgeblichen Quell-MDRs
Weitere Informationen zu MDRs finden Sie in diesem Thema.
Verwenden Sie die folgenden XML-Element-Tags, um MDR-Attribute anzugeben:
  • <mdr_class>
    Gibt die MDR-Klasse an, um MDRs zu gruppieren, die in ähnlicher Weise von der CA SDM bearbeitet werden können.
  • <mdr_name>
    Gibt den MDR-Namen an, den ein MDR verwendet, um auf sich selbst zu verweisen. Stellen Sie sicher, dass die Kombination "mdr_name" und "mdr_class value" im Unternehmen eindeutig ist.
  • <federated_asset_id>
    Gibt die föderierte Asset-ID an, die die eindeutige Kennung eines MDR für ein CI anzeigt.
Wenn GRLoader die angegebene "mdr_class" und den "mdr_name" nicht in einem bestehenden MDR auflösen kann, dann wird das Configuration Item nicht von GRLoader importiert. Ein CI ohne verbundene federated_asset_id-Zuordnung ist nicht föderiert.
Beispiel: Identifizieren eines CIs im MDR
Im folgenden Beispiel gibt die CI-Definition Server-CI "mdr_class" an, um das MDR und die Federated-Asset-ID eindeutig zu kennzeichnen und damit auch das CI in dem MDR zu kennzeichnen.
CA SDM verwendet die Zeichenfolge "mdr_class"
Cohesion
, wenn Daten aus dem Produkt [Zuweisen der Wert für Acm in Ihrem Adressbuch] Föderiert.
<ci> <name>ServerCI</name> ... <federated_asset_id>1001118</federated_asset_id> <mdr_class>Cohesion</mdr_class> <mdr_name>CohesionServer</mdr_name> ... </ci>
Der Configuration Item-Tag: Versionskontrolle-Attribute
Sie können GRLoader verwenden, um Attribute der Versionskontrolle für ein CI festzulegen.
Weitere Informationen zur Versionskontrolle finden Sie im Abschnitt "Versionskontrolle".
Geben Sie die Versionskontrolle-Attribute mit den folgenden XML-Element-Tags an:
  • <milestone>
    Gibt die Bezeichnung an, die mit dem Meilenstein verknüpft ist, der in der Registerkarte "Versionskontrolle" angezeigt wird.
  • <standard_ci>
    Name des Standard-CIs, der für Grundvergleiche in der Registerkarte "Versionskontrolle" verwendet wird.
Das CI, das für das Attribut "standard_ci" angegeben ist, muss bereits in der CMDB existieren oder angegeben werden, bevor die CI-Definition in der XML-Datei angegeben wird. Der generierte Meilenstein erfasst den Zustand des CI zu dem Zeitpunkt, an dem GRLoader ausgeführt wird.
Beispiel: Angeben von Grundvergleichen
Im folgenden Beispiel gibt die CI-Definition mit dem Namen "ServerCI"das Standard-CI mit dem Namen
"standard server config" für Grundvergleiche mit "ServerCI" (dem Fokus-CI) an. In diesem Beispiel wird davon ausgegangen, dass das Standard-CI bereits in der CA SDM vorhanden ist. Außerdem wird ein Meilenstein mit dem Namen Ende Geschäftsjahr 2008 erstellt, um den Zustand des Configuration Item zum Zeitpunkt beizubehalten, an dem GRLoader die XML-Datei importiert.
<ci> <name>ServerCI</name> <class>Server</class> <standard_ci>standard server config</standard_ci> <milestone>Fiscal year end 2008</milestone> ... </ci>
XML-Inhalt: der Tag "Relation"
GRLoader kann Beziehungen zwischen Configuration Items durch Verwenden des XML-Element-Tags <relation> erstellen oder aktualisieren. Es bestehen vielfältige Beziehungen, und dieser Beziehungstyp gibt an, wie zwei übergeordnete/untergeordnete Configuration Items sich in CMDB zueinander verhalten.
Geben Sie die Beziehungsattribute mit den folgenden XML-Element-Tags an:
  • <type>
    (Optional) Der Name des Beziehungstyps.
  • <delete_flag>
    Legt die Beziehung als inaktiv oder aktiv fest. Geben Sie "1 (one)", "yes" oder "true" an, um die Beziehung auf inaktiv einzustellen. Geben Sie "0 (zero)", "no" oder "false" an, um die Beziehung wieder auf aktiv einzustellen. Durch Einstellen von "delete_flag" auf "true" bleibt die bestehende Beziehung intakt, wird aber als inaktiv markiert.
  • <provider>
    (Erforderlich) Kennzeichnet das übergeordnete CI für die Beziehung, die ein oder mehrere CI-Abstimmungsattribute enthält.
  • <dependent>
    (Erforderlich) Kennzeichnet das untergeordnete CI für die Beziehung, die ein oder mehrere CI-Abstimmungsattribute enthält.
Wenn GRLoader den angegebenen Typ oder das über- bzw. untergeordnete CI nicht finden kann, wird die Beziehung erstellt oder aktualisiert.
Beispiel: Definieren einer Beziehung zwischen CIs
Das folgende Beispiel definiert eine Beziehung zwischen den CIs mit dem Namen
"ServerCI" (übergeordnet) und "ServerCI|NetworkAdaptor-0" (untergeordnet). Der Beziehungstyp ist enthält. In diesem Beispiel wird davon ausgegangen, dass beide CIs bereits in CMDB definiert wurden oder vor der Beziehungsdefinition in einer XML-Datei angegeben wurden. Außerdem müssen die übergeordneten und untergeordneten Configuration Items mit allen Abstimmungsattributen übereinstimmen, damit die Beziehung erstellt werden kann.
<relation> <type>contains</type> <provider> <name>ServerCI</name> <serial_number>HMVV081</serial_number> <dns_name>serverci.myco.com</dns_name> <mac_address>00:12:3F:48:F0:95</mac_address> <system_name>ServerCi</system_name> </provider> <dependent> <name>ServerCI|NetworkAdaptor-0</name> </dependent> </relation>
XML-Inhalt: Sonderwerte
XML-Attribute für besondere Zwecke können angeben, wie ein CI-Wert beim Importieren durch GRLoader eingestellt oder aktualisiert wird. Mit diesen Attributen können Sie beim Festlegen des Werts eine spezielle Verarbeitung oder Formatierung ausführen, beispielsweise zum Formatieren eines Datumswerts oder wenn das Ergebnis eines Suchfelds verwendet wird.
Beispiele für besondere XML-Werte:
  • Suche
    Kennzeichnet ein CI durch ein anderes Attribut als "combo_name" (Nachname, Vorname zweiter Vorname). Zum Beispiel: userid,
  • update_if_null
    Gibt die Option "update_if_null" an, die GRLoader verwenden kann, um zwischen leeren Werten und solchen, die in der XML nicht bereitgestellt sind, zu unterscheiden. Die Option "update_if_null" ist standardmäßig auf "" eingestellt, so dass leere oder fehlende Werte von GRLoader ignoriert werden.
    Die folgenden Attributbeschreibungen für Seriennummern sind äquivalent:
    <serial_number></serial_number> <serial_number/> <serial_number update_if_null="">
    Wenn Sie die Seriennummer aus einem CI entfernen möchten, funktioniert der genannte XML-Code
    nicht
    , da GRLoader leere oder fehlende Werte ignoriert. Stattdessen müssen Sie XML für die Seriennummer wie folgt codieren:
    <serial_number update_if_null="true"></serial_number>
    Diese Syntax aktualisiert das Attribut immer, auch wenn der Wert leer ist oder fehlt.
  • dateformat=[utc | localtime]
    Stellen Sie das Attribut
    dateformat
    für das Datumsfeld auf "utc" oder "localtime" ein. Erforderlich, wenn das Format des Datums im UTC-Format (UNIX Time Code) ist. Wenn das Datumsformat nicht eingestellt ist, ist "localtime" der Standard.
Datumsformat:
CMDB unterstützt die folgenden Localtime-Datumsformate:
  • jjjj mmm tt
  • JJJJ/MM/TT hh:mm
Wenn der Wert keinem dieser Formate entspricht, versucht der Parser, das Datum als eine UTC-Zeit aufzulösen. Wenn das Datumsformat nicht UTC ist, verwendet CMDB folgendes Systemgebietsschema: für US-Englisch das 12-Stunden-Format MM.TT.JJJJ oder MM/TT/JJJJ HH:MM:SS
a
, wobei
a
entweder AM oder PM angibt.
Kontakt und andere Suchfelder
Im Objekt "Kontakt" sind der Vorname, das Mittelinitial und der Nachname kombiniert. Das Objekt hat das folgende Format:
<resource_contact>Lastname, Firstname MiddleInitial</resource_contact>
Wenn Sie ein andere Feld als Suchfeld verwenden möchten, können Sie ein Suchfeld-Attribut angeben. Falls nach John Q. Doe in Anwender-ID gesucht werden soll, verwenden Sie zum Beispiel den folgenden Eintrag:
<resource_contact lookup="userid">doejo04</resource_contact>
Felder, die mit Daten in bestehenden Tabellen (SREL) überprüft werden.
Gemeinsame Attribute akzeptieren nur einen bestimmten Satz von Werten, die in den verwandten Tabellen in CMDB definiert sein müssen. Diese Attribute können auch über zusätzliche Einschränkungen und Ausnahmen verfügen, die erfüllt sein müssen, damit die Zuordnung ausgeführt werden kann. Beispielsweise muss ein Klassenattribut, das in XML angegeben ist, mit einem der bestehenden Klassennamen übereinstimmen (CMDB-Standard oder anwenderspezifisch). Andernfalls wird das Configuration Item nicht erstellt oder aktualisiert. Außerdem kann der Wert nicht auf null eingestellt werden und die Klasse muss aktiv sein, damit die Zuordnung ausgeführt werden kann.
In den folgenden Feldern werden Daten auf Grundlage von Daten in bestehenden Tabellen überprüft:
  • audit_userid
  • bm_rep
  • bm_status
  • Klasse
  • company_bought_for_uuid
  • contact_1
  • contact_2
  • contact_3
  • delete_flag
  • Abteilung
  • expense_code
  • family
  • Standort
  • manufacturer
  • Modell
  • operating_system
  • org_bought_for_uuid
  • priority
  • repair_org
  • resource_contact
  • resource_owner_uuid
  • service_org
  • service_type
  • status
  • supplier
  • vendor_repair
  • vendor_restore
XML-Eingabe
Beim Importieren von CI-Daten formatieren Sie die Daten in einem unterstützten Format, z.B. in XML oder in einer Kalkulationstabelle (XLS oder XLSX).
Beachten Sie das folgende XML-Format-Beispiel:
XML-Dokument
Notizen
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <GRLoader>
Diese Header sind erforderlich.
<ci>
Fügen Sie null oder mehr <ci>-Knoten hinzu, um die Configuration Items zu definieren.
<name>value</name> <mac_address>value</mac_address> <dns_name>value</dns_name> <asset_num>value</asset_num> <serial_number>value</serial_number> <system_name>value</system_name>
Diese sechs Eigenschaften dienen der eindeutigen Kennzeichnung eines Configuration Item in einer Configuration Item- oder Beziehungsdefinition. Es muss mindestens eines davon angegeben sein.
<class>value</class> <family>value</family> <manufacturer>value</manufacturer> <model>value</model>
Diese vier Werte bestimmen die Klasse und die Familie eines Configuration Item. Geben Sie entweder (class) oder (manufacturer/model) an.
<mem_capacity>value</mem_capacity> <number_net_card>value </number_net_card> <phys_mem>value</phys_mem_update> <proc_speed>value</proc_speed> <proc_type>value</proc_type> <server_type>value</server_type> </ci>
Familienspezifische Werte. Sie können null oder mehr familienspezifische Werte angeben, wenn Sie ein Configuration Item definieren.
<relation> <type>relation_type</type>
Fügen Sie null oder mehr <relation>-Knoten ein, um Beziehungen zu definieren. Geben Sie den Beziehungstyp an.
<provider> <name>value</name> <mac_address>value</mac_address> <dns_name>value</dns_name> <asset_num>value</asset_num> <serial_number>value</serial_number> </provider>
Kennzeichnen Sie das übergeordnete Configuration Item mit mindestens einem Attribut.
<dependent> <name>value</name> <mac_address>value</mac_address> <dns_name>value</dns_name> <asset_num>value</asset_num> <serial_number>value</serial_number> </dependent> </relation>
Kennzeichnen Sie das abhängige Configuration Item mit mindestens einem Attribut.
</GRLoader>
Beispiel: XML-Eingabe
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <GRLoader> <ci> <name>Host1</name> <class>Server</class> </ci> <ci> <name>Host2</name> <class>Server</class> </ci> <relation> <type>connects to</type> <provider> <name>host1</name> </provider> <dependent> <name>host2</name> </dependent> </relation> </GRLoader>
MAC-Adressnormalisierung
Frühere Versionen von GRLoader haben die MAC-Adresse von CIs durch Entfernen der Trennzeichen ":" und "-" normalisiert. Diese Normalisierung führt zu einer MAC-Adresse von: "aa:bb:cc:dd:ee", die als "aabbccddee" gespeichert wird.
Betrachten Sie das folgende MAC-Adressenverhalten:
  • Der Standardwert ist keine MAC-Adressnormalisierung.
  • CIs, die ohne Normalisierung in CMDB erstellt wurden, werden mit CIs, die ohne Normalisierung in CMDB r11.x erstellt wurden, zusammengeführt.
  • Ungültige MAC-Adressen werden wie einfache Zeichenfolgen behandelt und unverändert gespeichert.
Die folgenden GRLoader-Parameter lassen Sie die MAC-Normalisierung aktivieren oder deaktivieren:
  • -mn
    Entfernt die Trennzeichen ":" und "-" aus MAC-Adressen (MAC-Normalisierung).
  • -nomn
    Die Trennzeichen ":" und "-" werden nicht aus MAC-Adressen entfernt.
    Wenn Sie eine frühere Version von CMDB installieren, wird die Normalisierung der MAC-Adresse automatisch aktiviert. Sie können die Normalisierung mit Hilfe des Parameters "
    -nomn
    " außer Kraft setzen.
Weil Optionen auf der Befehlszeile sequenziell bearbeitet werden, ist die Reihenfolge der Optionen in der Syntax wichtig.