Administration - Workflows
Allgemeines
Workflows dienen der Automatisierung von Aktionen, welche ausgeführt werden, sobald bestimmte Bedingungen erfüllt sind. Die Bedingungen beziehen sich dabei auf Attribute von Configuration Items (CIs / Tickets), die einer CI-Kategorie oder einem CI-Typ angehören, der beim Anlegen des Workflows festgelegt wird. Die konfigurierten Workflows können sowohl ereignis- als auch zeitgesteuert ausgelöst werden. Zur Konfiguration der Workflows steht ein grafischer Workflow-Editor zur Verfügung, mit dem die Elemente (Bausteine) der Workflows per Drag-and-Drop angeordnet und zum Regelwerk verbunden werden können.
Hinweis
Es kann sowohl die Situation eintreten, dass CIs mit ihren Attributwerten bereits vorhanden sind und das Erstellen/Aktivieren eines Workflows dann zu Aktionen führt, als auch, dass die Workflows bereits erstellt/aktiviert sind und dann erst die CIs angelegt oder verändert werden. Dies ist bei der Planung und Umsetzung von Workflows zu berücksichtigen. Inbesondere bei den systemseitige bereitgestellten WF-Triggern sollte in diesem Zusammenhang auf die "Create"- oder "Update"-Trigger geachtet werden.
Workflow-Übersicht
Die Workflow-Übersicht zeigt alle definierten Workflows übersichtlich in Tabellenform an. In der Übersicht können sowohl neue Workflows erstellt, als auch bestehende Workflows bearbeitet oder gelöscht werden. Des Weiteren ist es möglich, an dieser Stelle direkt einen oder mehrere (Mehrfachselektion) Workflow zu aktivieren oder de-aktivieren.
Hinweis
Durch die Workflow-Engine werden nur aktive Workflows berücksichtigt.
Hinweis
Bei einer großen Menge an Workflows empfiehlt sich die Filter-Option in der Übersichtstabelle, insbesondere auf CI-Kategorie / CI-Typ. Beispielsweise kann mit der Option "Beginnt mit" auch auf alle Workflows gefiltert werden, die unterhalb einer CI-Kategorie liegen.
Allgemeines zur Erstellung von Workflows
Beim Erstellen eines neuen Workflows muss die CI-Kategorie/der CI-Typ angegeben werden auf den sich der Workflow beziehen soll (Pflichtfeld).
Hinweis
Eine spätere Änderung von CI-Kategorie/-Typ ist nicht möglich
Workflow-Bausteine
Allgemeines zu Workflow-Bausteinen
Jeder Workflow-Baustein, der einen Attributwert verändert, speichert diesen sofort ab. Folgende Bausteine (z.B. Bedingungs-Beusteine) greifen auf diese aktualisierten Werte zurück und nicht auf die Attributwerte, die ein CI initial beim Start des Workflows hat.
Alle Workflow-Bausteine bis auf UND- und ODER-Bedingungen enthalten ein HTML-Feld "Baustein-Dokumentation" mit unbegrenzter Zeichenanzahl, welches für Dokumentationszwecke zur Verfügung steht, aber keinen Einfluß auf die im Workflow verarbeiteten CIs hat.
Jeder Workflow beinhaltet die Bausteine "Start" und "Ende", welche nicht entfernt werden können. Über den Baustein "Start" können während der Workflow-Bearbeitung folgende Parameter geändert werden:
der "Name",
die "Beschreibung",
die "Workflow Trigger",
der "Ausführungsplan" des Workflows.
Workflows müssen nicht die Option "Pflichtfeld" bei CIs berücksichtigen. Ein Workflow kann also ein CI abspeichern, ohne das ein Attribut gesetzt (befüllt) wurde, welches als Pflichtfeld definiert wurde.
Bedingungsbausteine im Allgemeinen
Bedingungsbausteine stehen oft am Beginn von Workflows, um zu entscheiden, ob Aktionen im Workflow für die gewählte CI-Kategorie/-Typ ausführt werden soll oder nicht. Weiterhin können Bedingungsbausteine auch zu bedingungsabhängigen Verzweigungen innerhalb der Workflows führen.
Hinweis
In Bedingungsbausteinen stehen immer nur die CI-Attribute zur Überprüfung zur Verfügung, die sich aus der beim Erstellen des Workflows referenzierten CI-Kategorie/-Typ ergeben.
Hinweis
CI-Attribute, welche auf CI-Typ-Ebene definiert wurden, stehen auch nur für Workflows zur Verfügung, die sich genau auf diesen CI-Typ beziehen. Da z.B. ein Lebenszyklusmodell immer nur auf CI-Typ-Ebene definiert wird kann die Überprüfung des Lebenszyklus auch nur erfolgen, wenn der Workflow auf die Ebene CI-Typ definiert wurde und für diesen CI-Typ ein Lebenszyklusmodell zugeordnet ist.
Hinweis:
Bitte beachten sie bei Attributen vom Datentyp "HTML-Text", dass aufgrund der im Text enthaltenen HTML-Steuerzeichen folgende Vergleichsoperatoren ggf. nicht einwandfrei funktionieren: "ist gleich", "ist nicht gleich", "beginnt mit", "endet mit". Wir empfehlen, die Nutzung der Vergleichsoperatoren: "Beinhaltet", "Beinhaltet nicht"
Hinweis
Durch die Einführung von Zeittriggern wurde der Bedingungsbaustein "Zeitereignis" abgeschafft".
Hinweis
Durch die Einführung von Zeittriggern wurden den Bedingungsbausteinen das Feld "Tracking" hinzugefügt.
BedingungsTracking
Das Tracking einer Bedingung ist nur für Workflows mit einem Zeittrigger interessant und aktiv. Mit dem Tracking kann festlegt werden, welcher Ausgang der Bedingung getrackt werden soll. Wird ein Zeittrigger ausgelöst, prüft dieser immer, ob ein Tracking für das gerade behandelte CI existiert. Ist das Tracking einmalig erfüllt, so wird dieses CI nicht mehr vom Workflow behandelt. Das Tracking für ein CI setzt sich zurück, sobald das Attribut, auf welches die Bedingung sich bezieht, geändert wird.
Bedingungsbaustein "Bedingung"
Der Bedingungsbaustein "Bedingung" verzweigt den Workflow anhand einer Bedingung, die entweder für ein Attribut der CIs der/des gewählten CI-Kategorie/-Typ oder für die Zugehörigkeit zu einer Sicherheitsgruppe oder für die Workflow-Rolle definiert wird. Der Baustein führt die gewünschte Überprüfung durch und leitet je nach logischem Resultat der Überprüfung den weiteren Verlauf des Workflows in einen der beiden Ausgänge (WAHR oder FALSCH).
Die möglichen Bedingungen für den Vergleich innerhalb des Bausteins "Bedingung" sind abhängig vom Datentyp des Kriteriums, für welches der Vergleich festgelegt werden soll.
Die Möglichkeiten der Vergleichsoptionen in Bezug auf den Datentyp des gewählten Kriteriums (CI-Attribut, Sicherheitsgruppe oder Workflow-Rolle) sind gängigerweise selbsterklärend und werden deshalb an dieser Stelle nicht näher erläutert.
Für den Bedingungsbaustein "Bedingung" muss noch die "Workflow-Rolle" als Vergleichsoptionen erläutert werden.
Das Rückführen des Ausgangs eines weiter unten liegenden Bausteins auf den Eingang des Workflow-Bausteins "Bedingung" ist nicht möglich.
Bedingungsbaustein "Switch"
Der Bedingungsbaustein "Switch" verzweigt den Workflow anhand mehrerer Bedingungen für sowohl mehrere Ein- als auch Ausgänge. Es wird für jeden Verbindungspunkt (Ausgang) eine Bedingung bzw. Bedingsungsgruppe eingestellt, bei der auch komplexe Und- bzw. Oder-Verknüpfungen/-Gruppierungen möglich sind.
Ein typisches Beispiel für den Einsatz dieses Bausteins zeigt folgendes Diagramm:
Die Verbindungspunkte sind durchnummeriert und werden gemäß der Nummerierung abgearbeitet: Bei der Ausführung des Workflows läuft er im ersten mit erfüllter Bedingung weiter. Sollte keine Bedingung erfüllt sein, geht der Workflow in den mit "D" (für Default) gekennzeichneten Pfad.
Der Konfigurationsdialog kann folgendermaßen aussehen:
Über den "+ Neuer Filter"-Button können ein oder mehrere Bedingungen definiert werden, die eintreten müssen, damit der jeweilige Verbindungspunkt gewählt wird. Hier können dann bestimmte Eigenschaften von Attributen wie zum Beispiel "Name enthält abc" oder eine Workflow-Rolle eingefordert werden.
Falls mehrere Filter auf einer Ebene überprüft werden, gilt eine Und- oder Oder-Verknüpfung je nach aktiviertem Schalter über deren Bereich.
Soll eine bestimmte Menge an Filtern auf einer Ebene wie ein Filter behandelt werden, wird dies über die Definition einer Gruppe mit dem "+ Neue Gruppe"-Button erreicht.
Die Definition eines weiteren Verbindungspunktes wird mit dem "+ Hinzufügen"-Button gestartet.
Bedingungsbaustein "UND-Bedingung"
Der Baustein "UND-Bedingung" verbindet zwei oder mehrere Bausteine durch eine logische UND-Verknüpfung. Nur, wenn alle Bedingungen erfüllt sind, läuft der Workflow über den Ausgangspfad WAHR weiter, ansonsten über den Ausgangspfad FALSCH.
Konfigurationshinweis: Bei der Konfiguration erst den Baustein "UND-Bedingung" per Drag-and-Drop in den Konfigurationsbereich ziehen und dann entsprechende Zahl des Bausteins "Bedingung" ebenfalls per Drag-and-Drop in den Konfigurationsbereich auf den Baustein "UND-Bedingung" ziehen.
Bedingungsbaustein "ODER-Bedingung"
Der Baustein "ODER-Bedingung" verbindet zwei oder mehrere Bausteine "Bedingung" durch eine logische ODER-Verknüpfung. Wenn eine der Bedingungen erfüllt ist, läuft der Workflow über den Ausgangspfad WAHR weiter. Wenn keine der Bedingungen erfüllt ist, über den den Ausgangspfad FALSCH.
Konfigurationshinweis: Bei der Konfiguration erst den Baustein "ODER-Bedingung" per Drag-and-Drop in den Konfigurationsbereich ziehen und dann entsprechende Zahl des Bausteins "Bedingung" ebenfalls per Drag-and-Drop in den Konfigurationsbereich auf den Baustein "ODER-Bedingung" ziehen.
Bedingungsbaustein "Genehmigung"
Der Baustein "Genehmigung" erstellt ein CI vom CI-Typ "Genehmigung", benachrichtigt den/die Genehmiger und läßt den Workflow aufgrund der Genehmigungsentscheidung gezielt weiter ausführen. Der Baustein "Genehmigung" hat zwei Ausgänge (WAHR/FALSCH). Über welchen Ausgangspfad der Workflow weiter läuft ergibt sich aus dem Ergebnis der "Genehmigung".
Name: Pflichtfeld für den Betreff bei einer Email zur Genehmigung, für den Titel bei einer Tool-internen Systemnachricht zur Genehmigung, sowie für den Namen/Titel des CIs vom Datentyp Genehmigung.
Beschreibung: Pflichtfeld für die Beschreibung in Email, Systemnachricht und CI vom Datentyp Genehmigung.
Mögliche Empfänger:
Anwender: Der Genehmiger ist der Benutzer, der die Beziehung "Person ist Anwender von Service Operation Ticket" zum CI hat.
Hinweis
Anwender als Genehmiger steht nur zur Verfügung, wenn der Workflow sich auf die CI-Kategorie "Service Operation" oder darunter liegende CI-Kategorie/Typen bezieht.
Benutzer: Auswahl eines Benutzers, der benachrichtigt werden soll.
Hinweis
Hier kann als Genehmiger ein beliebiger Benutzer definiert werden. Zu beachten ist, dass dieser die Bearbeitungsberechtigung für CIs unter CI-Kategorie "Aufgaben" hat.
Benutzergruppen: Auswahl einer Personengruppe, deren Mitglieder benachrichtigt werden (siehe Konfiguration von "Personengruppen").
Hinweis
Über das Feld "Mindestanzahl von Zustimmungen" kann definiert, wie viele Zustimmungen es bedarf, damit der Genehmigung erfolgt und der Baustein "Genehmigung" damit über den "WAHR"-Pfad weitergeführt wird.
Hinweis
Zusätzliche Möglichkeiten bei Workflows die sich auf die CI-Kategorie "Service Operation" beziehen: - Automatische Kategorisierung: Benutzergruppe die sich anhand der automatischen Kategorisierung ergibt (siehe Konfiguration von "Kategorisierung"). - Zuständige 1st/2nd/3rd Level Benutzergruppe: Benutzergruppe die sich anhand der Zuständigkeiten ergibt (siehe Konfiguration von "Zuständigkeiten"). - Zuständige Benutzergruppe: Benutzergruppe, die die Beziehung "Personengruppe bearbeitet Service Operation Ticket" zum betroffenen CI hat.
Beziehungen zu Benutzer/Benutzergruppe: Der ausgewählte Benutzer oder die Mitglieder der ausgewählten Benutzergruppe, die in einer Beziehung zum CI stehen, wird/werden benachrichtigt.
CI-Ersteller: Der Benutzer wird benachrichtigt, der das CI oder z.B. Ticket angelegt hat (siehe bei allen CIs das Attribut "Erstellt durch").
Kundenverantwortlicher: Der Genehmiger ist der Benutzer, der die Beziehung "ist Kundenverantwortlicher von" zu dem Unternehmen hat, dem auch der Anwender des CI über die Beziehung "Unternehmen hat Mitarbeiter Person" zugehörig ist.
Hinweis: Kundenverantwortlicher als Genehmiger steht nur zur Verfügung, wenn der Workflow sich auf die CI-Kategorie "Service Operations" oder darunter liegende CI-Kategorie/Typen bezieht.
Vorgesetzter: Der Benutzer wird benachrichtigt, der die Beziehung "Person ist Vorgesetzter von Person" zu der Person hat, die die Beziehung "Person ist Anwender von Service Operation Ticket" zum CI hat.
Hinweis: Für die Zuständigkeit 'Vorgesetzter' einer Genehmigung, wird als Genehmiger der Vorgesetzte des Anwenders eines CIs ermittelt. Ist kein Anwender angegeben, wird dem Vorgesetzten des CI-Erstellers die Genehmigung vorgelegt. Die Beziehung "Person ist Vorgesetzter von Person" ist dabei von Relevanz.
Zuständiger Benutzer: Benutzer der die Beziehung "xyz" zum betroffenen CI hat.
Max. Genehmigungsdauer (Tage): Anzahl der Tage, die die Genehmigungsanfrage gültig ist und vom Genehmiger genehmig oder abgelehnt werden kann.
Begründung bei Genehmigen: Wenn der Button aktiviert ist, ist die Begründung für die Genehmigung obligatorisch.
Begründung bei Ablehnen: Wenn der Button aktiviert ist, ist die Begründung für die Ablehnung obligatorisch.
Zusätzliche Authentifizierung: Wenn der Button aktiviert ist, muss sich der Benutzer bei der Abstimmung über eine Genehmigung auf jeden Fall authentifizieren (auch wenn er schon eingeloggt ist).
Hinweis
In den Feldern "Name" und "Beschreibung" können Platzhaltervariablen ($Variablen$) verwendet werden: Dies können Werte aus den Attributen des CIs sein, das den Workflow initiiert hat, oder in den Systemeinstellungen > Systemvariablen definierte Werte. Beziehen sich die Platzhaltervariablen auf CI-Attribute, stehen nicht die Anzeigenamen der Attribute, sondern die Technischen Namen der Attribute zur Verfügung. Die Liste der nutzbaren Platzhaltervariablen wird automatisch angezeigt, wenn das $-Zeichen eingegeben wird.
Hinweis
Jeder Benutzer kann unter seinen persönlichen Einstellungen festlegen, ob er die Benachrichtigung zur Genehmigung per Email und/oder Systemnachricht erhalten möchte. Sollten Benachrichtigungen den Benutzer nicht reichen, sollte dies kontrolliert werden.
Aktionsbaustein "Aktion - Änderung" bzw. "CI-Attribut ändern"
Der Baustein "Aktion - Änderung" ermöglicht die Modifikation von CI-Attributen des betroffenen CIs. Zunächst wird unter "Zu änderndes Attribut" das entsprechende Attribut ausgewählt und in der neu erscheinenden Zeile eingetragen. Die zu setzenden Werte variieren hierbei in Abhängigkeit vom Datentyp des Attributs. Außerdem können in Attributen vom Datentyp Text Platzhaltervariablen ($Variablen$) verwendet werden: Dies können Werte aus den Attributen des CIs sein, das den Workflow initiiert hat, oder in den Systemeinstellungen > Systemvariablen definierte Werte. Sollen mehrere Attribute geändert werden, können weitere aus dem Drop-Down-Menü gewählt werden. Um einzelne Attributsänderungen wieder zu entfernen, kann das Symbol mit dem Papierkorb in der jeweiligen Zeile geklickt werden.
Hinweis
Beziehen sich die Platzhaltervariablen auf CI-Attribute, stehen nicht die Anzeigenamen der Attribute, sondern die Technischen Namen der Attribute zur Verfügung. Die Liste der nutzbaren Platzhaltervariablen wird automatisch angezeigt, wenn das $-Zeichen eingegeben wird.
Aktionsbausteine "Aktion - Übernahme (Holen/Setzen)"
Mit diesen Bausteinen werden die Werte von Attributen eines CIs auf ein anderes CI übertragen. Die beiden CIs sind dabei über eine Beziehung miteinander verbunden. Beim Baustein Setzen werden Werte des Quell-CIs (das CI, auf dem der Workflow gerade läuft) auf Attribute des Ziel-CIs übertragen. Beim Baustein Holen werden Werte aus dem verbunden CI gelesen und in das CI, auf dem der Workflow gerade läuft, geschrieben. Quell- und Ziel-Attribute müssen jeweils den gleichen Daten-Typ haben.
Der Baustein "Aktion - Übernahme" benötigt folgende Einstellungen:
Beziehungstyp: Die für den Workflow bewählte CI-Kategorie/Type bestimmt, welche Beziehungstypen für dieses Feld zur Auswahl stehen. Es können lediglich Beziehungstypen ausgewählt werden, die der Kardinalität 1:1, 1:N oder N:1 entsprechen.
Attributfilter, Operator und Filterattribut
Wenn nicht alle CIs der gewählten Beziehung und des CI-Typs durch diesen Workflow-Baustein geändert werden sollen, kann zusätzlich ein Attributfilter gesetzt werden. Es werden dann nur die CIs geändert, die die Filterbedingung erfüllen. Der Wert des Filters kann erst gesetzt werden, wenn das Attribut (bzw. der Attributname) eingestellt ist.
Mindestens ein CI-Attribut, dessen Wert aus dem Quell-CI gelesen wird: Als Quell-CI-Attribute stehen Attributtypen zur Auswahl, die den nachfolgenden Kriterien entsprechen:
eindeutig bei einer Kardinalität von 1:1 oder 1:N
keine Mehrfach-Attributtypen
der Datentyp entspricht einem der Folgenden: ein-/mehrzeiliger Text, Boolesch, Zahl, Version, Auto-Nummer, Auto-Name, Tag, E-Mail, IP-Adresse
Zu jedem gelesenen CI-Attribut muss ein CI-Attribut im betroffenen Ziel-CI zugeordnet werden, dessen Wert überschrieben wird: Als Ziel-CI-Attribute stehen Attributtypen zur Auswahl, die den nachfolgenden Kriterien entsprechen:
eindeutig bei einer Kardinalität von 1:1 oder N:1
keine Mehrfach-Attributtypen
die auswählbare Datentyp wird eingeschränkt durch den Datentyp des Quell-CI-Attributs
der Datentyp entspricht einem der Folgenden: ein-/mehrzeiliger Text, Boolesch, Zahl, Version, Auto-Nummer, Auto-Name, Tag, E-Mail, IP-Adresse
Beispiel: Für Personen im Raum 123 soll in der benutzten Hardware der Benutzername vom Personen-CI ins Hardware-CI übertragen werden. Hierfür wird zunächst ein Workflow für den CI-Typ "Person" gewählt. Im Baustein wird der Beziehungstyp "Person verwendet Hardware" eingestellt, der die Kardinalität 1:N hat. Die Bedingung "Raum 123" wird über einen Attributfilter erreicht. Als Quell-CI-Attribut wird "Name" gewählt, als Ziel-CI-Attribut "Benutzername".
Aktionsbaustein "Aktion - CI erstellen"
Mit dem Baustein "Aktion - CI erstellen" kann als Aktion ein neues Configuration Item CI erstellt werden. Der CI-Typ des neuen CIs kann dabei beliebig festgelegt werden.
Der Baustein "Aktion - CI erstellen" bietet folgende Einstellungen:
CI-Kategorie/-Typ: Pflichtfeld zur Definition des CI-Typs für den das CI angelegt werden soll.
Beziehungstyp: Option zur Festlegung einer Beziehung zwischen initialem CI und dem neu anzulegendem CI. Hier steht die Beziehungen zur Auswahl, die zwischen den beiden CI-Typen der beiden CIs mögich sind.
Attribut hinzufügen: Optional können hier mehrere Attribute des neu zu erstellenden CI ausgewählt werden, die über den Workflow mit Werten befüllt werden sollen. In der Konfigurationsoberfläche des Baustein werden damit weitere Zeilen (je Attribut) hinzugefügt und können dort auch wieder entfernt werden (Lösch-Icon).
Name: Pflichtfeld/-Attribut, welches mit einem Wert für den Namen des neuen CI gefüllt werden muss, da "Name" ein Pflichtfeld-Attribut ist.
Weitere Attribute: Pflichtfeld-Attribut des neuen CI werden automatisch angezeigt und müssen mit Werten befüllt werden.
Hinweis
In Attributen des zu erstellenden CI vom Datentyp Text können Platzhaltervariablen ($Variablen$) verwendet werden: Dies können Werte aus den Attributen des CIs sein oder in den Systemeinstellungen > Systemvariablen definierte Werte. Beziehen sich die Platzhaltervariablen auf CI-Attribute, stehen nicht die Anzeigenamen der Attribute, sondern die Technischen Namen der Attribute zur Verfügung. Die Liste der nutzbaren Platzhaltervariablen wird automatisch angezeigt, wenn das $-Zeichen eingegeben wird.
Aktionsbaustein "REST"
Dieser Baustein ermöglicht es, einen externen REST-fähigen HTTP-Endpunkt aufzurufen.
Der Baustein "REST" benötigt folgende Eingaben:
Name des zuvor eingerichteten HTTP-Endpunktes
Hinweis
Beim Aufruf des Endpunktes übergibt der Baustein alle Attribute des CIs, das vom Workflow verarbeitet wird, als JSON-Payload-Daten and den REST-Aufruf
Aktionsbaustein "Aktion - Beziehung"
Mit dem Baustein "Aktion - Beziehung" kann eine Beziehung zwischen zwei CI erstellt werden. Ein CI ist das (initiale) Quell-CI, für welches der Workflow ausgelöst wurde. Die Beziehung wird erstellt, wenn die Werte der definierten Quell- und Ziel-CI-Attribute übereinstimmen. Falls die definierte Beziehung zwischen den beiden betroffenen CIs mit dem benannten Beziehungstyp bereits besteht, wird dieser automatisch vor Anlegen der neuen Beziehung gelöscht.
Der Baustein "Aktion -- Beziehung" benötigt folgende Eingaben:
Beziehungstyp
Auswahl des Typs der anzulegenden Beziehung.
Es können Beziehungstypen ausgewählt werden, die für die/den ausgewählten CI-Kategorie/CI-Typ des Workflows existieren.
Es können Beziehungstypen ausgewählt werden, die der Kardinalität 1:1, 1:N oder N:1 entsprechen.
Quell-CI-Attributstyp
Auswahl eines Attributs des Quell-CI-Typs
Zur Auswahl stehen CI-Attributtypen, die den nachfolgenden Kriterien entsprechen:
eindeutig bei einer Kardinalität von 1:1 oder 1:N
keine Mehrfach-Attributtypen
der Datentyp entspricht einem der folgenden: einzeiliger/mehrzeiliger Text, Boolesch, Zahl, Version, Auto-Nummer, Auto-Name, Tag, E-Mail, IP-Adresse
Ziel-CI-Attributstyp
Auswahl eines Attributs des Ziel-CI-Typs
Zur Auswahl stehen CI-Attributtypen, die den nachfolgenden Kriterien entsprechen:
eindeutig bei einer Kardinalität von 1:1 oder N:1
keine Mehrfach-Attributtypen
der Datentyp entspricht einem der folgenden: einzeiliger/mehrzeiliger Text, Boolesch, Zahl, Version, Auto-Nummer, Auto-Name, Tag, E-Mail, IP-Adresse
Beispiel:
Beziehungstyp: "Person verwendet Hardware"
Quell-CI-Typ "Person"
Ziel-CI-Typ: "Hardware"
Quell-CI-Attribut: "E-Mail (unique)"
Ziel-CI-Attribut: "Erstellt durch"
Aktionsbaustein "CIs ändern"
Mit dem Baustein "CIs ändern" können in Beziehung stehende CIs geändert werden.
Es werden folgende Eingaben benötigt:
Beziehungstyp
Auswahl des Typs der Beziehung.
Es können Beziehungstypen ausgewählt werden, die für die/den ausgewählten CI-Kategorie/CI-Typ des Workflows existieren.
CI-Typ
Auswahl eines CI-Typs, der sich unter dem Ziel-CI-Typs befindet
Attributfilter, Operator und Filterattribut
Wenn nicht alle CIs der gewählten Beziehung und des CI-Typs durch diesen Workflow-Baustein geändert werden sollen, kann zusätzlich ein Attributfilter gesetzt werden. Es werden dann nur die CIs geändert, die die Filterbedingung erfüllen. Der Wert des Filters kann erst gesetzt werden, wenn das Attribut (bzw. der Attributname) eingestellt ist.
Zu ändernde Attribute
Auswahl von Attributen des ausgewählten CI-Typs. Es können mehrere Attribute gesetzt werden, indem man sie eins nach dem anderen auswöhlt.
Hinweis
Bei der Eingabe der Attributwerte können auch Platzhaltervariablen ($Variablen$) verwendet werden.
Aktionsbaustein "Beziehungen löschen"
Mithilfe dieses Workflow-Bausteins können "veraltete" Relationen zwischen CIs automatisiert gelöscht werden. Hierzu wird der Wert eines CI-Beziehungs-Attributs eines bestimmten CI-Beziehungstyps überprüft und es werden alle Beziehungen dieses CI-Beziehungstyps, die einer bestimmten Bedingung entsprechen, gelöscht.
So werden bspw. im folgenden Workflow alle auf Rechnern installierten Anwendungen gelöscht, sofern sie älter als 2 Jahre sind.
Hinweis
Da die Löschbedingung in diesem Baustein direkt eingetragen wird, wird kein Bedingungsbaustein vorangestellt.
Aktionsbaustein "Aktion - Erhöhen/Reduzieren"
Dieser Baustein erhöht oder erniedrigt den Wert eines Attributs des betroffenen CIs. Hierfür stellt er eine Liste der möglichen Attribute (beschränkt auf Attribute vom Typ Zahl und Datum) zur Verfügung sowie ein Textfeld, in welches zum Erhöhen ein positiver Wert und zum Erniedrigen ein negativer Wert eingetragen werden kann. Bei Datums- und Zeit-Attributen erscheint noch ein Auswahlfeld, um festzulegen, ob Jahre, Monate, Tage usw. addiert werden sollen.
Aktionsbaustein "Aktion - Aufgabenplan Starten"
Mit diesem Baustein lassen sich vordefinierte Aufgabenpläne starten, indem die durch den Aufgabenplan festgelegten Tasks als Configuration Items an das betroffene Configuration Item angehängt werden.
Aktionsbaustein "Aktion - Systemvariable ändern"
Mit diesem Baustein können Systemvariablen ($tnt_ und $wfr_) gesetzt oder manipuliert werden. Hierfür wählt man zunächst eine vorab definierte Variable unter "Zu ändernde Variable" aus. Danach werden der Änderungstyp und der Wert festgelegt:
Attributwert: Wählen Sie diese Option zum Setzen einer Systemvariablen mit einem Attributwert des betroffenen CIs. Bei Auswahl dieser Option erscheint eine weitere Auswahlmöglichkeit, in der ein passendes Attribut gewählt werden muss.
Systemvariablenwert: Wählen Sie diese Option zum Setzen einer Systemvariablen mit dem Wert einer anderen Systemvariable ($sys, $tnt, $wfr). In diesem Fall erscheint eine weitere Eingabemöglichkeit zum Festlegen der zu kopierenden Variable.
Wert: Wählen Sie diese Option zum Setzen einer Systemvariablen mit einem festen Wert. Bei Auswahl dieser Option erscheint eine weitere Eingabemöglichkeit, in der je nach Datentyp der zu ändernden Variablen der gewünschte Wert konkretisiert wird.
Aktionsbaustein "Aktion - KI Änderung"
Mit diesem Baustein können beliebige Prompts definiert und die resultierenden KI-Antworten automatisch in CI-Attributen gespeichert werden. Hierfür stehen in der Konfiguration dieses Bausteins folgende Möglichkeiten zur Verfügung:
Prompt: Prompt/Text, der an die KI geschickt wird. Hier können $-Variablen genutzt werden, um den Prompt dynamisch für jedes CI anzupassen/anzureichern, oft insbesondere mit aktuellen Werten von CI-Attributen.
Zu änderndes Attribut: Hier wird ein Zielattribut ausgewählt, in den die Antwort der KI-Anfrage geschrieben wird. Falls es nicht vom Datentyp Text ist, muss im Prompt entsprechend eine Konversionsanfrage formuliert werden. Ansonsten antwortet die KI normalerweise in einem vollständigen Satz, den Dot4 nicht im benötigten Datentyp abspeichern kann, was dann zu einem Fehler im Ausgang des Bausteins führt. Soll zum Beispiel in ein Attribut vom Typ Zahl geschrieben werden, kann folgendes an den Prompt angehängt werden: "Das Ergebnis darf nur die Zahl enthalten und keinen weiteren Text!". Beziehungsattribute, Auswahllisten, Lebenszyklus und CI-Auswahllisten stehen bei den Zielattributen nicht zur Verfügung.
Eine Test-KI-Antwort generieren: Schicke den momentan eingetragenen Prompt zum Testen an die KI. Falls $-Variablen zum Einsatz kommen, erscheint ein Dialog, in den konkrete Testwerte eingetragen werden müssen.
Zurücksetzen: aktuelle Konfiguration zurücksetzen
Eingabe hinzufügen: Ein weiteres Prompt-Zielattribut-Paar hinzufügen.
Ausgang des Workflow-Bausteins:
Erfolg: Alle Anfragen wurden beantwortet, Ergebnisse wurden von KI geliefert und konnten in den gewünschten Datentyp konvertiert werden.
Fehler: Fehler bei mindestens einer Abfrage oder beim Konvertieren
Aktionsbaustein "Aktion - Befehlsausführung"
Mit diesem Baustein können Befehle auf Betriebssystemebene eines Import-Servers ausgeführt werden. Hierfür werden in der Konfiguration dieses Bausteins folgende Werte festegelegt:
Import Server: Zur Auswahl stehen alle zuvor für diesen Dot4-Mandanten konfigurierte Import-Server.
Befehl: Ein Moniker (also beliebiger Text, wie z. B. cmd1), der in der Datei "Settings.config" des ImportServers im value eines add-Tags mit dem key="CommandsToExecute" in den tatsächlichen Befehl (welches Programm, Batchdatei oder Skript ausgeführt werden soll) übersetzt wird. Durch diese Maskierung wird sichergestellt, dass über das Dot4-Frontent keine möglicherweise sicherheitskritischen Befehle eingegeben werden müssen, sondern mit direktem Zugriff auf den ausführenden Server. Sofern im add-Tag mehrere Befehle angegeben werden sollen, müssen sie durch ein Semikolon getrennt werden. Beispiel für einen Eintrag in "Settings.config":
Befehlsparameter: Optional können Parameter zur Kommandoausführung an den ImportServer übertragen werden, die bei der Ausführung seitens ImportServer anstelle des Sterns (*) im value mit den tatsächlichen Befehlen eingesetzt werden. Die Parametersequenz kann zusammengesetzt werden aus:
festen Werten
Attributwerten des betroffenen CIs mit der $-Schreibweise, bspw. $technicalname$ oder $autoNumber$
Systemvariablen $sys_, $tnt_ und $wfr_
Aktionsbaustein "Rolle zuweisen"
Dieser Baustein ermöglicht, einem CI vom CI-Typ "Person" Rollen zuzuweisen oder zu entfernen.
Hinweis
Der Baustein steht nur zur Verfügung, wenn der Workflow sich auf den CI-Typ "Person" bezieht.
Im Baustein selbst kann man zum einen zwischen 3 Aktionen wählen:
| Aktion | Beschreibung |
|---|---|
| Entfernen | Entfernt die unter Rollen ausgewählten Rollen vom Personen CI. |
| Hinzufügen | Fügt die unter Rollen ausgewählten Rollen dem Personen CI hinzu. |
| Überschreiben | Ersetzt alle vorhandenen Rollen des Personen CI's mit den unter Rollen ausgewählten Rollen. |
Aktionsbaustein "Aktion - Authentifizierung"
Mit diesem Workflow-Baustein kann die Authentifizierungsmethode für Benutzer festgelegt werden (z.B. beim Import von Personen aus dem Active Directory). Dieser Baustein steht nur für CIs vom Typ "Person" zur Verfügung. Durch entsprechendes Auswählen der Schalter kann eine der folgenden Authentifizierungsmethoden zugewiesen werden:
Externe Authentifizierung deaktiviert bedeutet, der Benutzer loggt sich mit Benutzername und Passwort ein.
Externe Authentifizierung über Azure Active Directory
Externe Authentifizierung über Active Directory Federation Service
Aktionsbaustein "Aktion - CI löschen"
Der Baustein "Aktion - CI löschen" dient dazu, ein CI zu löschen. Er kann nicht in Kombination mit anderen Aktionsbausteinen verwendet werden. Der Baustein selber verfügt über keine Optionen.
Hinweis
Falls ein CI durch einen Workflow mit diesem Baustein gelöscht wird, ist dies endgültig und kann nicht rückgängig gemacht werden. Beim Hinzufügen des Bausteins in den Konfigurationsbereich erscheint ein entsprechender Warnhinweis.
Hinweis
Der Baustein "Aktion - CI löschen" steht nur in der Kombination mit den Bedingungsbausteinen zur Verfügung. Wird der "Aktion - CI löschen" in der Konfigurationsbereich gezogen, so stehen die anderen Bausteine nicht mehr im Auswahlbereich zur Verfügung. Umgekehrt steht Baustein "Aktion - CI löschen" auch nicht mehr zur Verfügung, wenn andere Bausteine bereits in den Konfigurationsbereich gezogen wurden.
Aktionsbaustein "Benachrichtigung"
Der Baustein "Benachrichtigung" sorgt dafür, dass eine E-Mail an einen oder mehrere Empfänger versandt wird.
Der Baustein "Benachrichtigung" bietet folgende Einstellungen:
Empfänger: Pflichtfeld zur Definition des Empfängerkreises für die Benachrichtigung
Mögliche Empfänger:
Anwender: Der Empfänger ist der Benutzer, der die Beziehung "Person ist Anwender von Service Operation Ticket" zum CI hat.
Hinweis: Anwender als Empfänger steht nur zur Verfügung, wenn der Workflow sich auf die CI-Kategorie "Service Operation" oder darunter liegende CI-Kategorie/Typen bezieht.
Benutzer: Auswahl eines Benutzers, der benachrichtigt werden soll.
Benutzergruppen: Auswahl einer Personengruppe, deren Mitglieder benachrichtigt werden (siehe Konfiguration von "Personengruppen")
Zusätzliche Möglichkeiten bei Workflows die sich auf die CI-Kategorie "Service Operation" beziehen:
Zuständige Benutzergruppe: Benutzergruppe, die die Beziehung "Personengruppe bearbeitet Service Operation Ticket" zum betroffenen CI hat.
Automatische Kategorisierung: Benutzergruppe die sich anhand der automatischen Kategorisierung ergibt (siehe Konfiguration von "Kategorisierung").
Zuständige 1st/2nd/3rd Level Benutzergruppe: Benutzergruppe die sich anhand der Zuständigkeiten ergibt (siehe Konfiguration von "Zuständigkeiten").
Beziehung zu Benutzer/Benutzergruppe: Dann werden Beziehungen des betroffenen CI-Typs zu Personen oder Personengruppen ausgewählt werden. Personen oder Personengruppen dieser Relation zum CI werden dann benachrichtigt. Beispiel: Der Nutzer eines Computers.
CI-Ersteller: Der Benutzer wird benachrichtigt, der das CI oder z.B. Ticket angelegt hat (siehe bei allen CIs das Attribut "Erstellt durch").
Rolle: Auswahl einer Rolle, deren zugeordnete Benutzer benachrichtigt werden sollen.
Vorgesetzter: Der Benutzer wird benachrichtigt, der die Beziehung "Person ist Vorgesetzter von Person" zu der Person hat, die die Beziehung "Person ist Anwender von Service Operation Ticket" zum CI hat.
Hinweis: Für die Zuständigkeit 'Vorgesetzter' einer Benachrichtigung, wird als Empfänger der Vorgesetzte des Anwenders eines CIs ermittelt. Ist kein Anwender angegeben, wird dem Vorgesetzten des CI-Erstellers die Nachricht gesendet. Die Beziehung "Person ist Vorgesetzter von Person" ist dabei von Relevanz.
Zuständiger Benutzer: Benutzer der die Beziehung "xyz" zum betroffenen CI hat.
Kundenverantwortlicher: Der Empfänger ist der Benutzer, der die Beziehung "ist Kundenverantwortlicher von" zu dem Unternehmen hat, dem auch der Anwender des CI über die Beziehung "Unternehmen hat Mitarbeiter Person" zugehörig ist.
Hinweis: Kundenverantwortlicher als Empfänger steht nur zur Verfügung, wenn der Workflow sich auf die CI-Kategorie "Service Operations" oder darunter liegende CI-Kategorie/Typen bezieht.
Mitteilung: Pflichtfeld, für den Betreff bei der Benachrichtigung per Email bzw. der Tool-internen Systemnachricht.
Beschreibung: Optionaler Wert für die Beschreibung in der Benachrichtigung
Hinweis
In den Feldern "Mitteilung" und "Beschreibung" können Platzhaltervariablen ($Variablen$) verwendet werden: Dies können Werte aus den Attributen des CIs sein, das den Workflow initiiert hat, oder in den Systemeinstellungen > Systemvariablen definierte Werte. Beziehen sich die Platzhaltervariablen auf CI-Attribute, stehen nicht die Anzeigenamen der Attribute, sondern die Technischen Namen der Attribute zur Verfügung. Die Liste der nutzbaren Platzhaltervariablen wird automatisch angezeigt, wenn das $-Zeichen eingegeben wird.
Hinweis
Jeder Benutzer kann unter seinen persönlichen Einstellungen festlegen, ob er die Workflow-Updates per Email und/oder Systemnachricht erhalten möchte. Sollten Benachrichtigungen den Benutzer nicht reichen, sollte dies kontrolliert werden.
Aktionsbaustein "Aktion - Sicherheitsgruppen"
Dieser Baustein ändert die Zugehörigkeit eines CIs zu den Sicherheitsgruppen.
Der Baustein "Aktion -- Sicherheitsgruppen" benötigt folgende Eingaben:
Beziehungstyp
Änderungsart:
Hinzufügen: Das CI wird zu den im folgenden Feld definierten Sicherheitsgruppen hinzugefügt. Bereits vorhandene Sicherheitsgruppenzuordnungen des CIs bleiben erhalten.
Überschreiben: Das CI wird zu den im folgenden Feld definierten Sicherheitsgruppen hinzugefügt. Bereits vorhandene Sicherheitsgruppenzuordnungen des CIs bleiben werden entfernt.
Sicherheitsgruppen: Auswahl keiner, einer oder mehreren Sicherheitsgruppen, denen das CI hinzugefügt werden soll.
Tipp
Die Kombination aus der Änderungsart "Überschreiben" und der Auswahl keiner Sicherheitsgruppe führt zum Entfernen eines CIs aus allen Sicherheitsgruppen.
Beispiel: Falls ein CI vom Typ Service Request der Kategorie 'HR' zugewiesen wird, soll automatisch die Sicherheitsgruppe 'HR' gesetzt werden, um sicherzustellen, dass nur Personen mit einer Rolle, die dieser Sicherheitsgruppe zugewiesen sind, die entsprechenden Service-Requests bearbeiten können. Zusätzlich kann durch einen weiteren Baustein des Typs sichergestellt werden, dass sämtliche Zuweisungen an andere Sicherheitsgruppen vor der Zuweisung an 'HR' entfernt werden.
Konfiguration der Workflows
Sofern der Benutzer gemäß seiner Rolle die Berechtigung hat, kann er die Workflows unter Administration > Workflows > Workflow-Übersicht konfigurieren und erhält dort ein Liste der vorhandenen Workflows.
Bereits aufgelistete Workflows können über die Schaltflächen auf der Zeile bearbeitet werden:
Schaltfläche "Löschen": Löschen des Workflows
Schaltfläche "Bearbeiten": Editieren des Workflow-Namen und der Beschreibung
Schaltfläche "Details": Wechsel in den Konfigurationsbereich des Workflows
Bei Neuanlage eines Workflows über die Schaltfläche "Workflow erstellen" ("+"-Zeichen) stehen folgende Eingabemöglichkeiten zur Verfügung:
Name: Pflichtfeld für den Namen des Workflow
Beschreibung: Optional für eine Beschreibung des Workflow
CI-Kategorie/-Typ: Pflichtfeld zur Festlegung der CI-Kategorie oder CI-Typ, auf den sich der Workflow beziehen soll.
Die Konfigurationsoberfläche für Workflows besteht aus zwei Hauptbereichen:
Linker Bereich "Bausteine" zeigt die zur Verfügung stehenden Bausteine (siehe Detailbeschreibungen) an. Bausteine werden ggf. automatisch ausgeblendet, wenn diese aufgrund der bereits erfolgten Konfiguration im Arbeitsbereich für die Nutzung ausgeschlossen werden.
Rechter Bereich ist der Arbeitsbereich zur Festlegung / Konfiguration der Workflows. Die Bausteine können aus dem linken Bereich per Drag-and-Drop in den rechten Bereich gezogen werden.
Arbeiten im Konfigurationsbereich
Beim Erstellen eines neuen Workflows stehen initial der "Start"- und "Ende"-Baustein zur Verfügung, die miteinander verbunden sind. Der "Start"- und "Ende"-Baustein können nicht gelöscht werden und definieren selbsterklärend den Start- und End-Punkt der Workflows. Die Verbindunglinie zwischen beiden anklicken und mit der "Entf"-Taste der Tastatur löschen.
Allgemeine Regeln zu Workflows
eine Aktion muss vorhanden sein
die (Pflicht)-Felder aller Bausteine müssen korrekt befüllt sein
Drag-and-Drop-Funktionen
Bausteine hinzufügen: Im linken Bereich "Bausteine" einen Baustein auswählen und in den rechten Bereich (Arbeitsbereich) ziehen.
Bausteine entfernen: Baustein im Arbeitsbereich selektieren (fetter Rahmen) und mit "Entf"-/"Del"-Taste entfernen.
Linien entfernen: Linie im Arbeitsbereich selektieren (Linie wird fett) und mit "Entf"-/"Del"-Taste entfernen.
Bausteine bewegen: Baustein im Arbeitsbereich selektieren (fetter Rahmen) und mit gedrückter linker Maustaste bewegen.
Linie bewegen: Linie im Arbeitsbereich selektieren (Linie wird fett) und mit gedrückter linker Maustaste bewegen.
Linie ziehen/erstellen: Baustein einfach wählen, von dem die Linie ausgehen soll (Mauszeiger wandelt sich in eine Hand) und zum Baustein ziehen, zu dem die Linie gehen soll. Bei Bedingungs-Bausteinen als Startpunkt der Verbindungslinie den gewünschten Ausgang (WAHR oder FALSCH) auswählen und von dort die Linie erstellen.
Tipps zum Thema Workflows:
In der "Administration > Workflows > Workflow-Übersicht" kann man die Spalten einblenden, wer und wann einen Workflows angelegt oder zuletzt verändert hat.
Oberhalb des Arbeitsbereiches zur Konfiguration eines Workflows finden sich mehrere Icons zur Optimierung der Darstellung wie "Automatische Anordnung", "Größe dem Inhalt anpassen", "Vergrößern" und "Verkleinern". Dies kann helfen, die Übersichtlichkeit beim Anlegen von Workflows zu verbessern.
Beim versehentlichen Ziehen einer Verbindungslinie im Arbeitsbereich die "esc"-Taste drücken, um dies abzubrechen.
Tipp
Vergessen Sie nicht, vor dem Abspeichern eines neuen Workflow den Status des Workflow im Kopfbereich auf Aktiv zu setzen.
Workflow-Trigger
Durch Workflow-Trigger wird die Ausführung eines Workflows auf bestimmte auslösende Ereignisse beschränkt. Dafür gibt es aktuell folgende System-Trigger:
| Name | Beschreibung |
|---|---|
| Always | Der Workflow (WF) wird beim Schreiben eines CI ausgelöst. Es wird nicht unterschieden, ob der Schreibprozess durch die UI, einen Import oder einen API-Aufruf ausgelöst wird. Er wird sowohl beim Anlegen als auch beim Ändern eines CI ausgelöst. Dieser Trigger ist aus Kompatibilitätsgründen vorhanden. |
| API CI Create | Der WF wird beim Anlegen eines CI über einen API-Aufruf ausgelöst |
| API CI Update | Der WF wird beim Aktualisieren eines CI über einen API-Aufruf ausgelöst |
| Import CI Create | Der WF wird beim Anlegeneines CI über einen Import ausgelöst |
| Import CI Update | Der WF wird beim Aktualisieren eines CI über einen Import ausgelöst |
| Ticket to E-mail Create | Der WF wird ausgelöst, wenn ein Ticket aus einem E-Mail erstellt wird |
| Ticket to E-mail Update | Der WF wird ausgelöst, wenn ein Ticket aus einem E-Mail aktualisiert wird |
| UI CI Create | Der WF wird beim Anlegen eines CI in der Benutzeroberfläche ausgelöst |
| UI CI Update | Der WF wird beim Aktualisieren eines CI in der Benutzeroberfläche ausgelöst |
Daneben gibt es noch selbstdefinierte Trigger. Diese Art von Trigger werden verwendet, um - abseits der oben genannten Ereignisse - in der Detailsicht eines CI Workflows über Schalter auszulösen.
Beim Anlegen benötigt folgende Angaben:
| Feld | Beschreibung |
|---|---|
| WF-Trigger Name | Ein aussagekräftiger, frei wählbarer Name |
| Beschreibung | Angaben über Verwendung und Zweck des Triggers |
| Workflows | Ein oder mehrere Workflows, die beim Auslösen des Triggers ausgeführt werden |
Um einen solchen WF-Trigger auszulösen, erstellen Sie in einer CI-Kategorie oder -typ ein CI-Attribut vom Typ Aktion > Workflow Trigger.
Hinweis
Es gibt nun auch Zeittrigger.
Durch einen Zeit-Trigger haben Sie die Möglichkeit einen Workflow in einem geplanten Rhytmus ausführen zu lassen.
Folgende Intervalle stehen zur Verfügung:
| Name | Beschreibung |
|---|---|
| Einmalig | Der WF wird einmalig zu einem gewünschten Zeitpunkt geplant. |
| Stündlich | Der WF wird stündlich zu einer gewünschten Minute geplant. |
| Täglich | Der WF wird täglich zu einer gewünschten Uhrzeit geplant. |
| Wöchentlich | Der WF wird wöchentlich zu einem gewünschten Tag und Uhrzeit geplant. |
| Monatlich | Der WF wird monatlich zu einem gewünschten Tag im Monat geplant |
Hinweis
Es handelt sich immer um geplante Zeiten die tatsächliche Ausführungszeit ist abhängig vom Background Job Runner. Dieser prüft alle 30 Minuten ob die Ausführung eines Workflows auf Grund eines Zeittriggers fällig ist und fürht diesen dann aus.
Hinweis
Sollten mehrere Zeittrigger gleichzeitig erfüllt sein so wird der Workflow nur einmal ausgeführt und beide Trigger als behandelt betrachtet.
HTTP-Endpunkte
HTTP-Endpunkte sind URLs zu RESTful API Web-Services, die die Übergabe von dot4 CI-Daten per POST zur Weiterverarbeitung ermöglichen.
HTTP-Endpunkte werden in einem Workflow vom Baustein REST verwendet.
Ein HTTP-Endpunkt benötigt folgende Eingaben:
Name: Aussagekräftige bezeichnung des HTTP-Endpunktes (Pflichtfeld)
Beschreibung: Erläuternder Text zu Zweck und Ziel des Endpunktes
URL: Die URL des Endpunktes (Pflichtfeld)
Timeout: Die Zeitspanne in Sekunden, bevor der Aufruf des Endpunktes mit Fehler abgebrochen wird (Default: 30 sek)
Authentifizierung: Falls eine Authentifizierung bei der REST--Schnittstelle nötig ist, muss dieser Schalter aktiviert werden
Benutzer: Der Benutzername, mit dem sich der HTTP-Endpunkt authentifiziert
Passwort: Das Kennwort, mit dem sich der HTTP-Endpunkt authentifiziert. Das Passwort kann zur Überprüfung mit dem Auge-Symbol im Klartext angezeigt werden.
Mit dem Schalter Verbindung testen kann überprüft werden, ob der Aufruf des HTTP-Endpunktes erfolgreich ist.
Hinweis
Beim Aufruf eines Endpunktes durch einen Workflow werden die CI-Attribute des vom Workflow verarbeiteten CIs als JSON-Datenformat gesendet.
Workflow-Log
Die Workflow-Log wird aktiviert, indem unter "Administration > Systemeinstellungen > Allgemeine Einstellungen" für den "Workflow Log-Level" ein anderer Wert als "Aus" festgelegt wird. Die einstellbaren Log-Level sind:
Aus (Workflow-Log ausgeschaltet, es werden keine Logeinträge geschrieben)
Debug (alle Events vom Level Info, Warnung, Fehler werden in die Log geschrieben)
Info (alle Events ab Level Info werden in die Log geschrieben)
Warnung (alle Events ab Level Warnung werden in die Log geschrieben)
Fehler (alle Events ab Level Fehler werden in die Log geschrieben)
Die Kachel für die Workflow-Log steht unter "Administration > Workflows > Übersicht" zur Verfügung.
Anmerkungen / Hinweise
Die Workflow-Log verfügt über keine Funktionen zum Löschen der Einträge. Aus diesem Grund sollte die Workflow-Log nur sehr restriktiv genutzt werden und nach Verwendung / Analyse wieder ausgeschaltet werden.
Hinweis: Ab Version 2021.5 werden alle Einträge die älter als 3 Tage sind durch eine Hintergrund-Prozess aus der Workflow-Log gelöscht.
Das Setzen des "Workflow Log-Level" auf "Aus" stoppt das Schreiben der Log. Bereits vorhandene Einträge können weiterhin ausgewertet werden.
Die Workflow-Log verfügt über die folgenden Spalten:
Benutzer (Bei Workflows, welche über einen Zeittriugger ausgeführt wurden ist dies immer "System". Bei allen anderen Workflows der Nutzer, der eine Änderung durchgeführt hat, die zum Auslösen des Workflows geführt hat.)
Benutzer ID
Beschreibung (Anmerkung: Der Wert wird aktuell nicht befüllt)
CI ID (Interne ID des betroffenen CIs)
CI Name (Name des CI / Titel des Tickets)
CI Typ (siehe CMDB-Modell)
Dauer (Sek.) (Dauer der Ausführung des Workflows zum betroffenen CI/Ticket)
Endzeit (Ende der Ausführung des Workflows zum betroffenen CI/Ticket)
Mandant (der aktuelle Mandant)
Startzeit (Beginn der Ausführung des Workflows zum betroffenen CI/Ticket)
Version (Version des Workflows; siehe auch in der Workflow-Übersicht)
Workflow ID (Interne ID des Workflows)
Workflow Log ID (Durchlaufende ID der Workflow Log)
Workflow Name (Name des Workflows)
Workflow Status (z.B."Erfolg", "Warnung", "Fehler")
Workflow Typ ("Timed" = zeitgesteuert, "Default" = ereignisgesteuert)
Workflow-Log Details
Durch Doppelklick bzw. Detailsicht kann jeder Eintrag der Workflow-Log geöffnet und weitere Details eingesehen werden. Je nach eingestelltem "Workflow Log-Level" sind vertiefende Details an dieser Stelle einsehbar.