Administration - Workflows

Allgemeines

Workflow_Beispiel

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.

Die Verbindungspunkte sind durchnummeriert und werden von oben nach unten 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.

Workflow_Switch_Beispiel Workflow_Switch_Beispiel

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.

UndBedingung

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.

OderBedingung

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".

WorkflowApproval

  • 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.

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"

CIVariable

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.

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 "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 Bausteime bereits in den Konfigurationsbereich gezogen wurden.

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".

AttrverknuepfteCIs

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 - 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.

WFChangeRelatedCIs

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.

BausteinRelationenLoeschen

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 - 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.

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 "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.

BausteinRelationenLoeschen

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.

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.

StartEnde

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.