myCMDB Anwenderhandbuch

Bei der Definition von Serveraufgaben können folgende Platzhalter verwendet werden:

[$DBO]        wird ersetzt mit dem Datenbankowner, der über den OServerManager bei der entsprechenden Datenbankschnittstelle gesetzt wurde.

[$MANDANT]        wird ersetzt mit dem Datenbankmandant, der über den OServerManager bei der entsprechenden Datenbankschnittstelle gesetzt wurde.

[$CRLF]        wird ersetzt mit einem manuellen Zeilenumbruch. Falls dieser Platzhalter im Basis-SQL verwendet wird, wird der Platzhalter mit der Zeichenkette <crlf> ersetzt.

[$HEUTE]        wird ersetzt mit dem Tagesdatum im Format DD.MM.YYYY

[$MORGEN]        wird ersetzt mit dem morgigen Tagesdatum im Format DD.MM.YYYY

[$GESTERN]        wird ersetzt mit dem gestrigen Tagesdatum im Format DD.MM.YYYY

[$PERIODE]        wird ersetzt mit dem aktuellen Monat im Format YYYY.MM

[$JETZT]        wird ersetzt mit dem Tagesdatum inkl. aktueller Uhrzeit im Format DD.MM.YYYY HH.MM.SS

Falls einer der Datumsplatzhalter im Basis-SQL verwendet wird, wird der Platzhalter ins entsprechende Datenbankformat übersetzt.

Zielinformationen

LDAP.Filter

Mit der Zielfeldvariablen LDAP.Filter kann ein Filterkriterium angegeben werden, welches erfüllt sein muss, damit der Quell-Datensatz überhaupt abgeglichen wird.

Bsp:

LDAP.FILTER=([LDAP:sAMAccountName]<>"");

bedeutet, dass nur die User aus dem AD abgeglichen werden, deren Attribut SAMAccountName nicht leer ist.

OSP.INITSQL

Mit der Zielfeldvariable OSP.INITSQL kann ein SQL-Statement angegeben werden, welches einmalig zu Beginn eines jeden Laufes ausgeführt wird.

Bsp:

OSP.INITSQL=update attrPerson set myOSStatus = ".";

bedeutet, dass zu Beginn des Laufes in allen Datensätzen von attrPerson die Spalte myOSStatus auf die Zeichenkette mit einem Punkt gesetzt wird. Wenn jetzt noch eine Einzelzuordnung angegeben wird, in der als Zielinformation dasselbe Ziel genannt wird, also im Bsp: attrPerson.myOSStatus erhält  man im Ergebnis in allen Person-Items, die nicht abgeglichen wurden, in myOSStatus einen Punkt.

Bitte in diesem Zusammenhang auch die Möglichkeit beachten, die hier unter Xxxxx.OTS.Yyyyy beschrieben ist.

OSP.Filter

Mit der Zielfeldvariablen OSP.Filter kann ein Filterkriterium angegeben werden, welches erfüllt sein muss, damit der Quell-Datensatz überhaupt abgeglichen wird.

Bsp:

OSP.FILTER=([SQL:Alias]<>"");

bedeutet, dass der Quell-Datensatz nur dann abgeglichen wird, wenn die Spalte „Alias“ nicht leer ist.

Xxxxx.OSP.Filter

Für jedes myCMDB-Item, das abgeglichen werden soll, kann ein Filterkriterium angegeben werden, welches erfüllt sein muss, damit der Teil des Quell-Datensatzes, welches das entsprechende myCMDB-Item betrifft (siehe ZielInformation), überhaupt abgeglichen wird.

Bsp:

attrKommunikation.OSP.Filter=([LDAP:mail] <> "") 

bedeutet, dass das myCMDB-Item Kommunikation nur dann abgeglichen wird, wenn das Attribut Mailadresse des Users aus dem AD nicht leer ist. Beispielsweise können damit Pflichtfelder definiert werden.

Xxxxx.OSP.Klasse

Jedem myCMDB-Item, das abgeglichen werden soll, kann eine Klasse zugeordnet werden. Dann muss eine Einzelzuordnung eingefügt werden, die als Zielfeldfunktion „myCMDB-Item-Tabellenname.OSP.Klasse” enthält. In dieser Einzelzuordnung muss dann als Quellfeldkonstante zuerst der Itemtyp der Klasse und dann, mit Komma getrennt, alle Ebenen einer Klasse aufgeführt werden.
Bsp:
attrBerechtigung.OSP.Klasse=Berechtigung,Windows;
bedeutet, dass jedem Berechtigungs-Item eine Klasse mit Itemtyp „Berechtigung“ und Klasse 1 „Windows“ zugeordnet wird. Klasse 2 und folgende sind in dieser Klasse dann leer.

Xxxxx.OSP.Ident

Für jedes myCMDB-Item, das abgeglichen werden soll, muss eine Ident-Information vorliegen. Dies entspricht einer Festlegung, wie das myCMDB-Item über die Schnittstelle eindeutig ermittelt werden kann. Die Festlegung stammt entweder aus der myCMDB-Itemdefinition, oder aus der Serveraufgabe selbst. Falls Letzteres muss als Zielfeldfunktion „myCMDB-Item-Tabellenname.OSP.Ident” verwendet werden und als QuellInformation werden mit Komma getrennt, alle Informationen aufgeführt, die zu einer eindeutigen Identifikation führen. Dabei wird in der Regel ein oder mehrere Zielfeldvariablen verwendet. 
Bsp: 
attrPerson.SSOAccount=UO\[LDAP:sAMAccountName];
attrPerson.OSP.Ident=attrPerson.SSOAccount
bedeutet, dass die Person eindeutig über das Feld SSOAccount ermittelt wird. Der Inhalt dieses Feldes entspricht dabei der konstanten Zeichenfolge „UO\“ gefolgt von dem SAMAccountName aus dem AD.
Somit kann in der Serveraufgabe auch eine zu myCMDB abweichende Eindeutigkeit definiert werden, beispielsweise weil die Serveraufgabe nur eine Teilmenge aller myCMDB-Person-Items mit dem AD abgleichen soll.
Zusätzlich oder anstatt ein oder mehrerer Zielfeldvariablen kann auch die Quellfeldfunktion „OSP.Verbindung“ verwendet werden. Dies bedeutet, dass das Item mit dem führenden Item aktuell gültig verbunden sein muss.
Zusätzlich oder anstatt ein oder mehrerer Zielfeldvariablen kann auch die Quellfeldfunktion „myCMDB-Item-Tabellenname.OSP.Klasse“ verwendet werden. Dies bedeutet, dass das Item aus einer bestimmten Klasse zugeordnet sein muss. 
Bsp:
attrBerechtigung.Ident=UO\[LDAP:sAMAccountName];
attrBerechtigung.OSP.Klasse=Berechtigung,Windows;
attrBerechtigung.OSP.Ident=attrBerechtigung.Ident,attrBerechtigung.OSP.Klasse;
bedeutet, dass der Ident des Berechtigung-Items mit dem SAMAccountname aus dem AD gefüllt wird und das Berechtigung-Item der Klasse Windows zugeordnet sein muss und dass zur eindeutigen Identifikation die Berechtigung über den Ident in Kombination mit der Klasse Windows ermittelt werden muss. 

Xxxxx.OSP.Ident.2

Diese Variable entspricht inhaltlich Xxxxx.OSP.Ident mit dem einzigen Unterschied, dass die über Xxxxx.OSP.Ident.2 definierte Ident-Information nur genutzt wird, wenn über Xxxxx.OSP.Ident kein Datensatz gefunden wurde.

Xxxxx.OSP.Insert

Für jedes myCMDB-Item, das abgeglichen werden soll, kann bestimmt werden, ob Neuanlagen erlaubt sind. Standardmäßig sind sie erlaubt. Falls Neuanlagen verhindert werden sollen, muss eine Einzelzuordnung eingefügt werden, die als Zielfeldfunktion „myCMDB-Item-Tabellenname.OSP.Insert” enthält. In dieser Einzelzuordnung muss dann als Quellfeldkonstante „true“ oder „false“ enthalten.

Xxxxx.OSP.ProtIdent

Xxxxx entspricht dem Tabellennamen eines myCMDB-Items.

Hier kann für jedes myCMDB-Item, das abgeglichen werden soll, bestimmt werden, wie der Datensatz in der Protokolldatei optimal identifiziert werden kann. Die Zeile hat keine Einfluss auf die Verarbeitung der Daten, lediglich auf die Protokollierung der Verarbeitung der Daten.

Bsp:

attrRaum.OSP.ProtIdent=Geb:[SQL:Gebaeude] Raum:[SQL:EtageRaum];

attrPerson.OSP.ProtIdent=Person:[SQL:DomainUserName];

attrKommunikation.OSP.ProtIdent=[SQL:Email]/[SQL:DomainUserName];

Xxxxx.OSP.Sync

wurde inzwischen mit Xxxxx.OSP.Ident ersetzt.

Xxxxx.OSP.Update

Für jedes myCMDB-Item, das abgeglichen werden soll, kann bestimmt werden, ob Änderungen (Updates) erlaubt sind. Standardmäßig sind sie erlaubt. Falls Änderungen verhindert werden sollen, muss eine Einzelzuordnung eingefügt werden, die als Zielfeldfunktion „myCMDB-Item-Tabellenname.OSP.Update” enthält. In dieser Einzelzuordnung muss dann als Quellfeldkonstante „true“ oder „false“ enthalten.

Xxxxx.OSP.Verbindung

Xxxxx entspricht dem Tabellennamen eines myCMDB-Items.

Für jedes, auf das erste (= führende) Item, nachfolgende myCMDB-Item, muss eine Verbindung-Information vorliegen. Dies entspricht einer Festlegung, wie das myCMDB-Item mit dem führenden Item verbunden ist. Die Festlegung stammt entweder aus der myCMDB-Verbindungsdefinition, oder aus der Serveraufgabe selbst. Falls Letzteres muss als Zielfeldfunktion „myCMDB-Item-Tabellenname.OSP.Verbindung” verwendet werden und als QuellInformation wird zuerst das übergeordnete Item und dann mit Doppelpunkt getrennt, das untergeordnete Item aufgeführt. 

Daran anschließend können Verbindungsoptionen angefügt werden. 
Bsp: 
attrKommunikation.OSP.Verbindung=Person:Kommunikation;
bedeutet, dass das Kommunikation-Item als untergeordnetes Item mit der Person verbunden ist.

Verbindungsoptionen:

Folgende Verbindungsoptionen sind vorgesehen:
Verbindungszusatz, Verbindungstyp und Kardinalität = Verbindungsrichtung

(Verbindungszusatz):
Der Verbindungszusatz beschreibt die einzelne Verbindung. Zum Beispiel könnten jede Verbindung zwischen Person und Projekt mit dem Zusatz „Projektleiter“ oder „Projektcontroller“ oder „Projektmitarbeiter“ genauer beschrieben werden.

(Verbindungstyp):
Gültige Werte für den Verbindungstyp sind: keine Angabe: Die Items werden über Verbindung verknüpft. (VTYP2): Die Items werden über Verbindung2 verknüpft. (VTYP3): Die Items werden über Verbindung2 verknüpft. (ID) Die Items werden ohne Verbindungstabelle über ein idFeld verknüpft.

(Kardinalität = Verbindungsrichtung)

Gültige Werte sind: (1:1), (1:N), (N:1), (N:M)

Die Kardinalität beschreibt die Art der Verbindung zwischen zwei Items.

Beispiel: Verbindung zwischen Trainer und Sportlerin

Modell „persönlicher Trainer“

• jeder Trainer betreut genau einen Sportler. Jeder Sportler wird von genau einem Trainer betreut.
• Verbindung 1:1 bzw. Verbindung ist eindeutig nach oben und unten (B)

Modell „Nationalmannschaft“

• jeder Trainer betreut mehrere Sportler, jeder Sportler wird von mehreren Trainern betreut.
• Verbindung N:M bzw. Verbindung ist weder eindeutig nach oben noch nach unten (_)

Modell „Sportverein“

• jeder Trainer betreut mehrere Sportler, jeder Sportler wird von genau einem Trainer betreut.
• Verbindung 1:N bzw. Verbindung ist eindeutig nach oben (U) ( = up )

Modell „Profitennis“

• jeder Trainer betreut genau einen Sportler, jeder Sportler wird von mehreren Trainern betreut.
• Verbindung N:1 bzw. Verbindung ist eindeutig nach unten (D) ( = down )

Oder anders:

In der Verbindungs- = Zuordnungstabelle zwischen Trainer und Sportler erscheinen …

Jetzt noch ein Beispiel, wie eine entsprechende Serveraufgabe bestehende Verbindungen korrigieren würde:

Angenommen es gibt folgende Trainer: Hans, Otto, Kurt und folgende Sportlerinnen: Tina, Anna, Ruth und einer Abgleich-Datenmenge mit folgenden Verbindungen:

1.       Hans trainiert Tina

2.       Otto trainiert Tina

3.       Kurt trainiert Anna

4.       Otto trainiert Anna

5.       Hans trainiert Ruth

Bei einer Verbindungsdefinition Trainer:Sportler (N:M) wird im Importlauf NIE irgendeine Verbindung beendet.

Ergebnis:

Hans trainiert Tina

Otto trainiert Tina

Kurt trainiert Anna

Otto trainiert Anna

Hans trainiert Ruth

Bei einer Verbindungsdefinition Trainer:Sportler (1:N), also eindeutig nach oben, d.h. jeder Sportler hat genau einen Trainer, beendet der Abgleich alle vor dem Lauf vorhandenen Verbindungen von Tina und Anna zu irgendeinem Trainer und alle vor dem Lauf vorhandenen Verbindungen von Ruth zu einem anderen Trainer als Hans und bei jedem Lauf mit dieser Abgleich-Datenmenge die Verbindungen 1. und 3. aus dieser Abgleich-Datenmenge.

Ergebnis:

Otto trainiert Tina

Otto trainiert Anna

Hans trainiert Ruth

 

Bei einer Verbindungsdefinition Trainer:Sportler (N:1), also eindeutig nach oben, d.h. jeder Sportler hat einen oder mehrere Trainer, jeder Trainer trainiert genau einen Sportler, beendet der Abgleich alle vor dem Lauf vorhandenen Verbindungen von Hans und Otto zu irgendeinem Sportler und alle vor dem Lauf vorhandenen Verbindungen von Kurt zu einer anderen Sportlerin als Anna und bei jedem Lauf mit dieser Abgleich-Datenmenge die Verbindungen 1. und 2. aus dieser Abgleich-Datenmenge.

Ergebnis:

Kurt trainiert Anna

Otto trainiert Anna

Hans trainiert Ruth

 

Bei einer Verbindungsdefinition Trainer:Sportler (1:1), also eindeutig nach oben und unten, d.h. jeder Sportler hat genau einen Trainer, jeder Trainer trainiert genau einen Sportler, beendet der Abgleich alle vor dem Lauf vorhandenen Verbindungen von Hans und Otto zu irgendeinem Sportler, alle vor dem Lauf vorhandenen Verbindungen von Kurt zu einer anderen Sportlerin als Anna, alle vor dem Lauf vorhandenen Verbindungen von Tina und Anna zu irgendeinem Trainer und alle vor dem Lauf vorhandenen Verbindungen von Ruth zu einer anderen Trainer als Hans und bei jedem Lauf mit dieser Abgleich-Datenmenge die Verbindungen 1. 2. und 3. aus dieser Abgleich-Datenmenge.

Ergebnis:

Otto trainiert Anna

Hans trainiert Ruth

Xxxxx.OTS.Yyyyy

Mit der Angabe von „.OTS.“ kann verhindert werden, dass der Zeitstempel des kompletten Datensatzes aktualisiert wird, wenn nur dieses Feld aktualisiert wird. Diese Option wird meist zusammen mit OSP.INITSQL verwendet.

Bsp:

attrPerson.OTS.myOSStatus=X;

bedeutet, dass das Feld myOSStatus bei jedem Lauf aktualisiert wird, aber wenn es nur das einzige Feld ist, das aktualisiert wird, wird nicht, wie sonst, gleichzeitig LAenderung, LUser und LC mit aktualisiert.

QuellInformationen

OSP.Parentrefid

Dieser Platzhalter kann ausschließlich in Quellfeldvariablen genutzt werden und wird ausnahmsweise nicht mit eckigen, sondern mit geschweiften Klammern abgegrenzt.

Bsp:

attrKommunikation.IDPerson={OSP:PARENTREFID};

bedeutet, dass das Feld attrKommunikation.Refid stets mit der Refid des übergeordneten Items gefüllt wird.

SUB (subselect)

Dieser Platzhalter kann ausschließlich in Quellfeldvariablen genutzt werden. Mit diesem Platzhalter wird der eigentliche Wert über eine SQL-Abfrage ermittelt. Diese wird in acht mit Doppelpunkt getrennten Teilen definiert. Es können auch Teile fehlen, am Ende müssen es aber trotzdem 8 Teile = 7 Doppelpunkte sein. Folgende Teile sind vorgesehen:

[SUB:select-clause:from-clause:where-clause:orderby-clause:groupby-clause:having-clause:Referenzfeld:Alternativwert]

Ergibt folgende SQL-Abfrage:

Select select-clause from from-clause where where-clause group by groupby-clause having having-clause order by orderby-clause . Hier ist prinzipiell alles möglich, es muss halt ein gültiges SQL-Statement herauskommen. Der select-clause darf nur ein Feld enthalten, dieses wird dann als Quelldatum weiterverarbeitet. Es wird stets nur der erste Datensatz verarbeitet. 

Im Teil Referenzfeld wird eine Quellfeldvariable benannt und nur, wenn diese nicht leer ist, wird das SQL überhaupt ausgeführt. Wenn diese leer ist, oder die SQL-Abfrage kein Ergebnis zurück bringt, wird der Teil Alternativwert als Quelldatum weiterverarbeitet.

Bsp:

attrRaum.Immobilie=[SUB:IDENT:ATTRIMMOBILIE:Anschrift='[LDAP:streetAddress]'::::[LDAP:streetAddress]:]; 

bedeutet, dass das Feld „attrRaum.Immobilie“ stets mit „attrImmobilie.Ident“ des über die Adresse zu ermittelnden „Immobilie-Items“ gefüllt wird. Ist „LDAP:streetAddress“ leer oder wird keine Immobilie gefunden, bleibt auch „attrRaum.Immobilie“ leer.

XML-Tags

Aktion

Die Aktion benennt die Verarbeitung. Beispielsweise die Verarbeitung, die für jede per Watchdog gefundene Datei ausgeführt werden soll. Oder die Verarbeitung, die als Aufgabe in einer „Aufgabenliste – Feldzuordnungen“ ausgeführt werden soll. 

Bsp:

<Aktion>Aktionsname</Aktion>

Mögliche Werte für den Aktionsname:

• Import
  bedeutet, dass die Daten importiert werden sollen.

ExportPfad

Der Exportpfad benennt den Pfad, in dem die Exportdatei erstellt werden soll. Der Pfad kann entweder mit einem Laufwerksbuchstabe beginnen, oder mit einem SMB-Freigabenamen.

Bsp:

<ExportPfad>C:\Kundendaten\Personalstamm</ExportPfad>

oder

<ExportPfad>\\Datenserver\Freigabe\Kundendaten\Personalstamm</ExportPfad>

DoneOK

Der Tag DoneOK benennt ein Verzeichnis, in das die verarbeitete Datei verschoben wird, wenn die, gemäß dem Tag „Aktion“ bestimmte Verarbeitung erfolgreich abgeschlossen wurde.

DoneKO

Der Tag DoneKO benennt ein Verzeichnis, in das die verarbeitete Datei verschoben wird, wenn die, gemäß dem Tag „Aktion“ bestimmte Verarbeitung mit Fehler abgeschlossen wurde.

ExportDateiname

Der Exportdateiname benennt die Exportdatei. Im Namen können folgende Platzhalter verwendet werden:

[$JJJJMMTT]
Aktuelles Tagesdatum (am 12. September 2021 ) im Format 20210921.

<ExportDateiname>Personal_export_[$JJJJMMTT].csv</ExportDateiname>

Protokoll

Im Protokoll-Tag kann ein Dateiname inkl. Pfadangabe hinterlegt werden, in dem der komplette Vorgang protokolliert wird.

Bsp:

<Protokoll>C:\Kundendaten\Personalstamm\log\ExportPersonalstamm.log</Protokoll>

Der Dateiname kann folgende Platzhalter enthalten:

[$mmdd] für MonatTag aus dem aktuellen Tagesdatum

[$DateiNr] für eine lfd. Nummer der Protokolldatei.

SQL

Im SQL-Tag kann ein beliebiges SQL-Statement hinterlegt werden.

Bsp:

<SQL>select Refid from attrKontakt 
where getdate() > dateadd(day,90,attrKontakt.eroeffnet_am)</SQL>

Im Beispiel „alle Kontakte, die vor über 90 Tagen eröffnet wurden”.

ToDo

Im ToDo-Tag können Aktionen definiert werden. Beispielsweise Folgeaktionen innerhalb der Überwachungsaufgabe SQL-Beobachtung.

Bsp:

<ToDo>Aktion</ToDo>

Aktion:

Folgende Aktionen sind möglich:

DelMail:        [$RefId] löscht alle Mail-Items, die mit dem Item mit der Refid verbunden sind.

DelAnhang:        [$RefId] löscht alle Anhänge, die mit dem Item mit der Refid verbunden sind.

DelItem:        [$RefId] löscht das Item mit der genannten Refid.

DelTexte:        [$RefId] löscht alle Texte, die mit dem Item mit der Refid verbunden sind.

DelHistorie:        Felderliste:[$RefId] löscht alle Historie-Einträge, die mit dem Item mit der Refid verbunden sind und die ein Feld aus der Felderliste betreffen. Die Felderliste kann auch leer bleiben (DelHistorie::[$RefId]), dann wird die Historie für alle Felder gelöscht.

SQL:        sql-statement
hier ist jedes gültige update-statement erlaubt.
Bsp:
update attrKontakt set Vorname = null, Name = null where Refid = [$RefId]

Ziel

Im Tag Ziel wird ein Pfad hinterlegt in den die Exportdatei verschoben wird, wenn der komplette Export durchgeführt wurde. Falls beispielsweise eine Datei von einem anderen System abgeholt werden soll, so kann hierüber sichergestellt werden, dass das andere System die Datei auch erst sieht, wenn die Datei komplett ist.

Bsp:

<Ziel>C:\Kundendaten\Personalstamm\OK</Ziel>

#1#

Der Tag #1# definiert die erste Zeile in jeder Exportdatei.

Bsp:

<#1#>V01;[$JJJJMMTT]</#1#>

Alternativ enthält der #1#-Tag bei einer Serveraufgabe für „Überwachungsaufgaben - Watchdog Import“ die Feldzuordnungen. Die Datei selbst muss dann keine Feldzuordnungen mehr enthalten.

#2#

Der Tag #2# enthält bei einer Serveraufgabe für „Überwachungsaufgaben - Watchdog Import“ die Spaltennamen und ersetzt den Standardinhalt der zweite Zeile einer Importdatei.

Bsp:

<#2#>Ident;Status</#2#>

Bedeutet, dass die Datei bzw. jeder Datensatz aus zwei Spalten besteht und die Namen der Spalten „Ident“ und „Status“ sind.

Alternativ dazu kann auch

<#2#>#Zeile1#</#2#>

angegeben werden. Dies bedeutet, dass die erste Zeile der Importdatei die Spaltennamen enthält.

#3#

Der Tag #3# enthält bei einer Serveraufgabe für „Überwachungsaufgaben - Watchdog Import“ die Nummer der Zeile, die lediglich einen Kommentar enthält

Bsp: 

<#3#>#Zeile2#</#3#>

Bedeutet, dass die Zeile 2 einer jeden Importdatei, die mit dieser Serveraufgabe verarbeitet wird, eine Kommentarzeile ist und überlesen wird.

DATA

Der Tag #DATA# definiert die Spalten, deren Reihenfolge und den Feldtrenner für jede Ausgabezeile.

Bsp:

<#DATA#>[SQL:attrPerson.Name];[SQL:attrPerson.Vorname] </#DATA#>

Aufgabe

Der Aufgabe-Tag enthält die Feldzuordnungen, die für die auszuführende Aufgabe vorgesehen bzw. notwendig sind. 

Bsp:

<Aufgabe>Aufgabendefinition</Aufgabe>

Die Aufgabendefinition enthält genau einen XML-Tag Aktion, der die einzelne Aufgabe definiert und, je nach Aktion, die für die jeweilige Aktion noch zusätzlich notwendigen XML-Tags.