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.
Die Art der Auslösung entscheidet darüber, welche CIs ein Lauf erfasst:
Ein zeitgesteuerter Workflow verarbeitet bei jedem Lauf alle aktiven CIs der beim Anlegen referenzierten CI-Kategorie bzw. des referenzierten CI-Typs einschließlich der darunter liegenden Ebenen. Der Ausführungsplan legt nur den Zeitpunkt des Laufs fest, nicht dessen Umfang.
Ein ereignisgesteuerter Workflow verarbeitet nur das CI, dessen Anlegen oder Ändern ihn ausgelöst hat.
Welche der erfassten CIs tatsächlich verändert werden, entscheiden erst die Bedingungsbausteine. Dauerhaft vom Durchlauf ausgenommen sind nur zwei Gruppen: deaktivierte CIs, die ein zeitgesteuerter Lauf gar nicht erst lädt, und CIs mit einem Eintrag des Bedingungs-Trackings, die von folgenden Läufen desselben Workflows übersprungen werden.
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.
Sie erreichen die Liste über Administration > Workflows > Workflow-Übersicht.
Die Spalte "Aktiv" zeigt, ob der Workflow von der Workflow-Engine berücksichtigt wird. "Geplant" kennzeichnet Workflows mit einem Ausführungsplan; nur für diese sind "Letzte Ausführung" und "Nächste geplante Ausführung" gefüllt. Die Spalte "Aktivierbar" kennzeichnet Workflows, die in sich vollständig sind; nur für diese erscheinen die Schaltflächen "Aktivieren" und "Deaktivieren". Die Spalte "Version" erhöht dot4 bei jedem Speichern eines bestehenden Workflows um eins; Version und "Workflow ID" erscheinen auch im Workflow-Log und ordnen einen Log-Eintrag damit einem bestimmten Konfigurationsstand zu. Über die Spaltenauswahl in der Werkzeugleiste blenden Sie die ausgeblendeten Spalten "Erstellt durch", "Erstellt am", "Letzte Aktualisierung durch" und "Letzte Aktualisierung am" ein. Die Spalten "Aktivierbar" und "Workflow-Trigger" sind bereits eingeblendet, liegen in der Abbildung aber rechts außerhalb des sichtbaren Bereichs – scrollen Sie waagerecht oder passen Sie die Spaltenbreiten an.
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
Für den CI-Typ "Genehmigung" lässt sich kein Workflow anlegen; dot4 weist das Speichern ab. Genehmigungen entstehen ihrerseits durch den Bedingungsbaustein "Genehmigung".
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"
Nicht jedes Attribut der referenzierten CI-Kategorie/-Typ lässt sich in einer Bedingung prüfen. Attribute der folgenden Datentypen stehen in der Auswahl nicht zur Verfügung: "Anhang", "Passwort", "QR-Code", "Tag", "Komplex", "Datumsintervall", "Datum und Zeit Intervall", "Zeitintervall", "Beziehungsliste" und "Workflow Trigger". Nicht als Bedingung verwendbar sind außerdem die System-Datentypen, die dot4 selbst pflegt und die Sie an einem CI-Attribut nicht auswählen können (darunter Versionsstand und Systembild).
Unabhängig vom Datentyp stehen außerdem nicht zur Auswahl:
Mehrfach-Attribute,
Subattribute komplexer Attribute,
das System-Attribut für die Punktzahl (ausgeliefert unter dem Namen "Punktzahl"),
das System-Attribut für die Benutzer-Id (ausgeliefert unter dem Namen "Benutzer Id").
Das Attribut für den Lebenszyklusstatus (ausgeliefert unter dem Namen "Lebenszyklusstatus") fehlt in der Auswahl vollständig. Das Attribut der Lebenszyklusphase erscheint nicht unter seinem ausgelieferten Namen, sondern unter der Bezeichnung "Lebenszyklus".
Hinweis
Die genannten Attributnamen sind Auslieferungsbezeichnungen und in Ihrem Mandanten änderbar. Der Ausschluss hängt am Attribut selbst, nicht an seinem Namen: Ein umbenanntes Attribut bleibt ausgeschlossen.
Diese Aufzählung gilt für die Bedingungsbausteine "Bedingung" und "Switch". Der Aktionsbaustein "Aktion - Änderung" und der Bedingungsbaustein "Eindeutigkeit" filtern die Attributauswahl jeweils anders und kommen zu einem anderen Ergebnis: Der Baustein "Eindeutigkeit" bietet auch Mehrfach-Attribute an, schließt dafür aber die Datentypen "Boolesch" und "Kategorie" aus, die in einer normalen Bedingung zulässig sind.
BedingungsTracking
Das Tracking einer Bedingung ist nur für Workflows mit einem Zeittrigger interessant und aktiv. Über das Feld "Tracking" wird festgelegt, welcher Ausgang der Bedingung getrackt werden soll. Zur Auswahl stehen "Wahr", "Falsch" und "Wahr und Falsch"; bleibt das Feld leer, findet kein Tracking statt. Das Feld erscheint nur bei eigenständigen Bedingungsbausteinen — in Bausteinen, die zu einer UND- oder ODER-Bedingung gehören, steht es nicht zur Verfügung.
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. Getrackt wird dabei ausschließlich, dass der Workflow dieses CI bereits behandelt hat; der damalige Attributwert wird nicht gespeichert.
Das Tracking für ein CI setzt sich zurück, sobald das Attribut, auf welches die Bedingung sich bezieht, tatsächlich einen anderen Wert erhält. Danach behandelt der Workflow das CI wieder.
Beispiel
Ein täglich ausgeführter Workflow prüft "Priorität ist gleich Hoch" und benachrichtigt anschließend den Bearbeiter. Wird der Ausgang "Wahr" getrackt, erhält der Bearbeiter die Benachrichtigung einmal und nicht an jedem folgenden Tag erneut. Wechselt die Priorität später auf einen anderen Wert und wieder zurück auf "Hoch", benachrichtigt der Workflow erneut.
Bedingungsbaustein "Bedingung"
Der Bedingungsbaustein "Bedingung" verzweigt den Workflow anhand einer Bedingung. Das Kriterium der Bedingung wählen Sie in einer Baumauswahl mit vier Gruppen:
CI-Attribut
Sicherheitsgruppe-Zugehörigkeit
Workflow Rolle
Systemvariablen
Die Gruppe "Sicherheitsgruppe-Zugehörigkeit" erscheint nur, wenn Ihre Rolle die Berechtigung "Anzeigen" unter "Sicherheitsgruppenadministration" besitzt. Sie enthält die Einträge "In keiner Sicherheitsgruppe", "In irgendeiner Sicherheitsgruppe" und "Sicherheitsgruppenzugehörigkeit".
Die Gruppe "Workflow Rolle" enthält den Eintrag "Anwender". Diese Bedingung prüft, ob der im Ticket eingetragene "Anwender" dieselbe Person ist wie die, unter deren Identität der Workflow ausgeführt wird — bei ereignisgesteuerten Workflows also die Person, die die Änderung gespeichert hat. Die Bedingung hat deshalb keinen Operator und keinen Vergleichswert. Sie trifft nur auf Ticket-Typen zu; bei allen anderen CI-Typen folgt der Workflow immer dem Ausgang FALSCH.
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.
Bei Attributen mit Datums- bzw. Zeit-Datentyp und bei Systemvariablen legen Sie zusätzlich den "Vergleichstyp" fest. Zur Auswahl stehen:
| Vergleichstyp | Bedeutung |
|---|---|
| Wert | Vergleich mit einem festen Datum bzw. einer festen Uhrzeit |
| CI Attribut | Vergleich mit dem Wert eines anderen Attributs desselben CIs |
| Zeitversatz zur Workflow-Ausführungszeit | Vergleich mit einem Zeitpunkt, der relativ zur Ausführungszeit berechnet wird |
| Systemvariable | Vergleich mit dem Wert einer Systemvariablen |
Beim "Zeitversatz zur Workflow-Ausführungszeit" geben Sie einen Wert und eine Einheit an. Ein positiver Wert bezeichnet einen Zeitpunkt in der Zukunft, ein negativer einen in der Vergangenheit. Als Einheit stehen "Minuten", "Stunden", "Tage", "Wochen", "Monate" und "Jahre" zur Verfügung.
Beispiel
Die Bedingung "Erstellt am" mit dem Operator "<" und einem Zeitversatz von -14 Tagen ist für alle CIs wahr, die zum Zeitpunkt der Workflow-Ausführung älter als 14 Tage sind.
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.
Für den Inhalt einer UND- oder ODER-Bedingung gilt dabei:
Hineinziehen lassen sich ausschließlich die Bausteine "Bedingung" und "Genehmigung". Andere Bausteine nimmt der Editor nicht an.
Eine UND-Bedingung kann eine ODER-Bedingung aufnehmen und umgekehrt, aber keine Verknüpfung derselben Art — und nur eine Ebene tief. Eine Verknüpfung, die selbst schon in einer anderen liegt, nimmt keine weitere auf.
Ziehen Sie die Bausteine gleich in die Verknüpfung hinein. Ein Baustein, der bereits außerhalb im Konfigurationsbereich liegt, lässt sich nachträglich nicht in eine Verknüpfung verschieben.
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.
Für Inhalt und Schachtelung gelten dieselben Regeln wie bei der UND-Bedingung.
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 hat drei Ausgänge: "Ja" für die Zustimmung, "Nein" für die Ablehnung und "Exp." für den Ablauf der Genehmigungsfrist. Über welchen Ausgangspfad der Workflow weiter läuft ergibt sich aus dem Ergebnis der "Genehmigung".
Den Ausgang "Exp." beschreitet der Workflow, wenn die Genehmigung innerhalb der unter "Max. Genehmigungsdauer (Tage)" gesetzten Frist weder genehmigt noch abgelehnt wurde. dot4 setzt die Genehmigung dann auf den Lebenszyklusstatus "Abgelaufen" des Lebenszyklusmodells "Genehmigungen Lebenszyklus" und führt den Workflow über diesen Ausgang weiter. So legen Sie fest, wie auf eine unbeantwortete Genehmigung reagiert werden soll — etwa mit einer Benachrichtigung oder einer Eskalation.
Hinweis
In Workflows, die den Baustein "Genehmigung" bereits vor dem Release-Update genutzt haben, ist der Ausgang "Exp." automatisch mit dem Baustein "Ende" verbunden. Diese Workflows verhalten sich damit wie bisher, bis Sie die Verbindung durch einen eigenen Pfad ersetzen.
Die folgende Abbildung zeigt einen Workflow aus einer Fassung vor dem Release-Update: Der Baustein "Genehmigung" trägt dort nur die beiden Ausgänge "Ja" und "Nein", der Ausgang "Exp." fehlt noch.
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: Optionale Angabe (maximal 2000 Zeichen) für die Beschreibung in Email, Systemnachricht und CI vom Datentyp Genehmigung.
Mögliche Empfänger: Anders als beim Baustein "Benachrichtigung" können Sie hier keine Rolle als Empfängerkreis wählen.
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. Das Feld erscheint nur, wenn als Genehmiger eine Benutzergruppe gewählt ist.
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. Zulässig sind nur Werte ab 1.
Erinnerung (alle x Tage): Tragen Sie einen Wert zwischen 1 und 30 ein, damit dot4 die Genehmiger in diesem Abstand per E-Mail erinnert, solange die Genehmigung offen ist. Erinnert wird nur, wer noch nicht abgestimmt hat und in seinen persönlichen Einstellungen den Mailversand für Genehmigungsanfragen aktiviert hat. Ist eine Ablauffrist gesetzt und abgelaufen, werden keine Erinnerungen mehr verschickt. Den Text der Erinnerung pflegen Sie im E-Mail-Template "Erinnerung an Genehmigung" mit der auslösenden Aktion "RequestApprovalReminder" (siehe E-Mail Templates).
Ausstehende Genehmigungen: Das Feld erscheint nur, wenn zu diesem Baustein noch offene Genehmigungen vorliegen. Es nennt deren Anzahl und bietet die Möglichkeit, sie zu löschen.
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.
Die von dot4 ausgelieferten Systemvariablen sind beim Aktionsbaustein "Aktion - Änderung" aufgeführt.
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.
Bedingungsbaustein "Eindeutigkeit"
Der Baustein "Eindeutigkeit" prüft, ob ein Wert in einem Attribut bereits bei einem anderen CI vorkommt. Damit lassen sich Dubletten erkennen, bevor der Workflow sie weiterverarbeitet. Der Baustein hat die beiden Ausgänge "Wahr" und "Falsch":
"Wahr": Der Wert ist eindeutig, also bei keinem anderen CI vergeben.
"Falsch": Der Wert ist bereits vergeben — oder er ließ sich nicht ermitteln. Ein Konfigurationsfehler lässt ein CI also nie als eindeutig durchlaufen.
Im Dialog "Eindeutigkeit prüfen" konfigurieren Sie:
Zu prüfendes Attribut: Angeboten werden die Attribute des CI-Typs, die genau einen vergleichbaren Wert tragen — Attribute der Datentypen "Einzeiliger Text", "Mehrzeiliger Text", "Auswahlliste", "Statischer Verweis", "Dynamischer Verweis", "RDP Verweis", "Ganzzahl", "Gleitkommazahl", "Dezimalzahl", "CI-Auswahl", "Datum", "Datum und Zeit", "Zeit", "Monat und Jahr" und "Jahr". Die Option "Mehrfach-Attribut" schränkt die Auswahl nicht ein; auch Mehrfach-Attribute stehen zur Verfügung. Attribute jedes anderen Datentyps stehen nicht zur Auswahl — insbesondere "Boolesch" (zwei Zustände können über mehrere CIs nie eindeutig sein), "Kategorie", "Auto-Nummer", "Auto-Name" und "Beziehung". Ebenfalls nicht zur Auswahl stehen die Lebenszyklus-Attribute, die System-Attribute "Erstellt am", "Letzte Aktualisierung am", "Letzter Vergleich am", "Erstellt durch", "Letzte Aktualisierung durch" und "Benutzer Id" sowie die Subattribute komplexer Attribute.
Der Wert, der auf Eindeutigkeit geprüft wird (Pflichtfeld). Über die Schaltfläche neben dem Feld wechseln Sie zwischen der direkten Eingabe und der Auswahl einer Systemvariable. Die Schaltfläche erscheint nur, wenn Systemvariablen mit einem zum gewählten Attribut passenden Datentyp vorhanden sind.
Baustein-Dokumentation: optionale Beschreibung, die auch die Suche im Arbeitsbereich durchsucht.
Verglichen wird innerhalb des CI-Typs, an dem das Attribut definiert ist, und aller darunter liegenden CI-Typen — dieselbe Menge, die auch die Attribut-Option "Eindeutig" absichert. Das gerade verarbeitete CI selbst zählt nicht mit.
Hinweis
Der zu prüfende Wert ist ein Pflichtfeld; ohne Wert lässt sich der Baustein nicht speichern. Löst ein Platzhalter oder eine Systemvariable zur Laufzeit dennoch auf einen leeren Wert auf, gilt dieser als eindeutig und führt über den Ausgang "Wahr", ohne dass dot4 die Datenbank befragt. Auch die Attribut-Option "Eindeutig" prüft einen leeren Wert nicht.
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 ändernde Attribute" 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.
Die Auswahl "Zu ändernde Attribute" ist nicht identisch mit der Attributauswahl der Bedingungsbausteine. Ausgeschlossen sind zunächst dieselben Datentypen wie dort (siehe Bedingungsbausteine im Allgemeinen) — mit zwei Ausnahmen: Attribute mit der Option "Mehrfach-Attribut" und Attribute vom Datentyp "Komplex" sind hier wählbar (siehe Attribute mit der Option "Mehrfach-Attribut" und Attribute vom Datentyp "Komplex"). Zusätzlich stehen in diesem Baustein nicht zur Auswahl:
Attribute der Datentypen "Auto-Nummer" und "Auto-Name" — diese Werte vergibt dot4 selbst,
Subattribute komplexer Attribute einzeln — sie kommen mit ihrem komplexen Attribut (siehe Attribute vom Datentyp "Komplex"),
die System-Attribute für Ersteller, letzten Bearbeiter, Asset-Nummer und Benutzer-Id (ausgeliefert unter den Namen "Erstellt durch", "Letzte Aktualisierung durch", "Asset Nummer" und "Benutzer Id").
Umgekehrt lässt sich das System-Attribut für die Punktzahl ("Punktzahl") hier — anders als in Bedingungsbausteinen — ändern. Das Attribut für den Lebenszyklusstatus ("Lebenszyklusstatus") fehlt in der Auswahl vollständig; das Attribut der Lebenszyklusphase erscheint unter der Bezeichnung "Lebenszyklus". Auch hier sind die genannten Namen Auslieferungsbezeichnungen: Der Ausschluss hängt am Attribut selbst, ein umbenanntes Attribut bleibt also ausgeschlossen.
In Attributen vom Datentyp "Text" 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.
In Attributen vom Datentyp "Beziehung" oder "CI-Auswahl" können Werte aus einer Systemvariable ($tnt_, $wfr_) vom Datentyp "CI-ID" geholt und gespeichert werden: Hierfür definiert man zunächst die Systemvariable unter "Administration > Systemeinstellungen > Systemvariablen" und lässt diese dann von einem Workflow-Baustein des Typs "Aktion - Systemvariable ändern" befüllen. Nun steht diese hier im Baustein "Aktion - Änderung" zur Verfügung, wenn der Wechsel-Button neben dem Feld, in dem der Wert ausgewählt werden kann, gedrückt wird.
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.
Attribute mit der Option "Mehrfach-Attribut"
Attribute mit der Option "Mehrfach-Attribut" können mehrere Werte gleichzeitig tragen. Der Baustein setzt je Attributzeile genau einen Wert; wie dieser Wert auf die vorhandenen Werte wirkt, wählen Sie deshalb in der Zeile zusätzlich aus:
"Überschreiben": Löscht die vorhandenen Werte des Attributs und setzt den neuen Wert. Das ist die Vorgabe.
"Hinzufügen": Fügt den Wert zu den vorhandenen Werten hinzu.
"Leeren": Löscht alle Werte des Attributs. Ein Wert wird dann nicht mehr abgefragt; das Attribut ist danach leer.
Attribute vom Datentyp "Komplex"
Ein Attribut vom Datentyp "Komplex" fasst mehrere Subattribute zu einem Wertesatz zusammen. Wählen Sie es unter "Zu ändernde Attribute" aus, erscheint eine Zeile mit dem Namen des komplexen Attributs und darunter je eine Eingabezeile für seine Subattribute. Die Subattribute werden als ein Wertesatz geschrieben; angeboten werden deshalb nur Subattribute, deren Datentyp dot4 im Workflow schreiben kann — "Einzeiliger Text", "Mehrzeiliger Text", "Auswahlliste", "Statischer Verweis", "Dynamischer Verweis", "RDP Verweis", "Boolesch", "Kategorie", "Ganzzahl", "Gleitkommazahl", "Dezimalzahl", "CI-Auswahl", "Datum", "Datum und Zeit", "Zeit", "Monat und Jahr" und "Jahr". Ein komplexes Attribut ohne ein einziges solches Subattribut steht nicht zur Auswahl.
Hat das komplexe Attribut zusätzlich die Option "Mehrfach-Attribut", trägt seine Zeile dieselbe Auswahl "Überschreiben" / "Hinzufügen" / "Leeren" wie ein einfaches Mehrfach-Attribut. In den Modi "Überschreiben" und "Hinzufügen" muss dann mindestens ein Subattribut gefüllt sein — andernfalls meldet dot4 beim Speichern, dass für das komplexe Attribut kein Wert angegeben ist. Bei einem einfachen komplexen Attribut ist ein leerer Wertesatz zulässig; er leert das Attribut, wie es ein leerer Wert bei jedem anderen Attribut tut.
Das Entfernen wirkt immer auf das ganze komplexe Attribut: Der Papierkorb in der Zeile des komplexen Attributs nimmt seine Subattribut-Zeilen mit.
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.
Neben den selbst definierten Systemvariablen ($tnt_, $wfr_) liefert dot4 15 Systemvariablen mit dem Präfix
$sys_ aus. Sie stehen überall dort zur Verfügung, wo Platzhaltervariablen erlaubt sind. Die Namen werden
klein geschrieben und in Dollarzeichen eingeschlossen:
| Allgemeine Systemvariablen | Kommentarbezogene Systemvariablen |
|---|---|
$sys_now$ |
$sys_last_comment$ |
$sys_systemlink$ |
$sys_last_comment_datetime$ |
$sys_tenant_name$ |
$sys_last_comment_user_name$ |
$sys_technical_tenant_name$ |
$sys_last_comment_user_id$ |
$sys_workflowname$ |
$sys_last_comment_person_id$ |
$sys_workflowtrigger$ |
$sys_last_comment_private_type$ |
$sys_workflow_triggered_by_user$ |
$sys_comment_amount$ |
$sys_new_comment$ |
Hinweis
Die kommentarbezogenen Systemvariablen tragen nur dann einen Wert, wenn am betroffenen CI ein letzter Kommentar existiert. Ist kein Kommentar vorhanden, bleiben sie leer.
Hinweis
Läuft der Workflow zeitgesteuert, ist kein Benutzer angemeldet: $sys_workflow_triggered_by_user$ enthält dann "System" und $sys_workflowtrigger$ einen automatisch erzeugten Text.
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: Sowohl bei "Übernahme (Setzen)" als auch bei "Übernahme (Holen)" stehen alle aktiven Beziehungstypen zur Auswahl, an denen der CI-Typ des Workflows beteiligt ist — in beiden Leserichtungen und unabhängig von der Kardinalität des Beziehungstyps. Die Kardinalität schränkt die Auswahl nicht ein; eine Einschränkung auf bestimmte Kardinalitäten gibt es nur beim Aktionsbaustein "Aktion - Beziehung".
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.
Die von dot4 ausgelieferten Systemvariablen sind beim Aktionsbaustein "Aktion - Änderung" aufgeführt.
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.
Die von dot4 ausgelieferten Systemvariablen sind beim Aktionsbaustein "Aktion - Änderung" aufgeführt.
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.
Der Baustein verlangt die folgenden Angaben. Alle Felder sind Pflichtfelder:
| Feld | Beschreibung |
|---|---|
| Beziehungstyp | Der Beziehungstyp, dessen Beziehungen geprüft und gelöscht werden |
| Vergleichsattribut | Das Attribut der Beziehung, dessen Wert geprüft wird. Immer verfügbar sind "Startdatum", "Letzter Vergleich am" und "Letzte Aktualisierung am"; zusätzlich stehen die Beziehungsattribute mit Datums- bzw. Zeit-Datentyp zur Auswahl |
| Vergleichstyp | Legt fest, womit der Wert des Vergleichsattributs verglichen wird |
| Operator | Der Vergleichsoperator |
| Zeitversatz | Wert und Einheit des Zeitversatzes |
Ein Import erkennt nicht, dass Quelldaten entfallen sind: Eine einmal importierte Beziehung bleibt bestehen, auch wenn es sie in der Quelle nicht mehr gibt. Über das Alter der letzten Aktualisierung bleibt die Datenqualität dennoch prüfbar — Beziehungen, die über einen festgelegten Zeitraum nicht mehr aktualisiert wurden, entfernt dieser Baustein automatisiert.
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 Ganzzahl, Dezimalzahl 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.
Der Baustein hat genau eine Einstellung: das Pflichtfeld "Aufgabenplan". Damit ein Aufgabenplan in dieser Aktion zur Auswahl steht, müssen Sie in den "Benutzer-Rollen" des Aufgabenplans eingetragen sein und über das Recht "Aufgabenpläne" (Anzeigen) oder "Aufgabenplan starten" (Anzeigen) verfügen. Beim Ausführen des Workflows spielen Berechtigungen keine Rolle: Der Aufgabenplan wird unabhängig von den Rechten der Person gestartet, die den Workflow ausgelöst hat. Wie Sie Aufgabenpläne anlegen und pflegen, ist unter Aufgabenpläne verwalten beschrieben.
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.
Der Schalter "Als HTML bearbeiten" erscheint nur beim Änderungstyp Wert und nur, wenn die zu ändernde Variable den Datentyp "Text" hat. Er legt fest, mit welchem Editor Sie den Wert erfassen. Eingeschaltet — das ist die Vorgabe — steht der HTML-Editor mit Formatierungsleiste zur Verfügung; ausgeschaltet erfassen Sie den Wert als einfachen mehrzeiligen Text. Die Liste der Platzhaltervariablen steht in beiden Editoren gleichermaßen zur Verfügung.
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 innerhalb des appSettings-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 können. Nur mit Zugriff auf den ausführenden Server kann der tatsächlich auszuführende Befehl definiert werden. 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":
Alternativ kann ein Section-Tag namens CommandMonikers in "Settings.config" verwendet werden. Die section muss außerhalb des appSettings-Tags definiert werden. In der Section können add-Tags definiert werden, die jeweils einen Befehl maskieren können. Bspw.:
...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_
Die von dot4 ausgelieferten Systemvariablen sind beim Aktionsbaustein "Aktion - Änderung" aufgeführt.
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).
Hinweis
Der Baustein steht nur zur Verfügung, wenn der Workflow sich auf den CI-Typ "Person" bezieht.
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. Auf den Baustein darf nur der Baustein "Ende" folgen; sonst lässt sich der Workflow nicht aktiv speichern.
Bitte beachten Sie
Stellen Sie diesem Baustein immer einen Bedingungsbaustein voran. Fehlt die Bedingung, löscht ein zeitgesteuerter Workflow bei jedem Lauf alle aktiven CIs der referenzierten CI-Kategorie bzw. des referenzierten CI-Typs einschließlich der darunter liegenden Ebenen (siehe Allgemeines). Der Vorgang ist endgültig.
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.
Die von dot4 ausgelieferten Systemvariablen sind beim Aktionsbaustein "Aktion - Änderung" aufgeführt.
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:
Änderungsart:
Hinzufügen: Das CI wird zu den im folgenden Feld definierten Sicherheitsgruppen hinzugefügt. Bereits vorhandene Sicherheitsgruppenzuordnungen des CIs bleiben erhalten.
Überschreiben: Die Sicherheitsgruppenzuordnungen des CIs werden durch die im folgenden Feld getroffene Auswahl ersetzt. Bereits vorhandene Sicherheitsgruppenzuordnungen des CIs werden entfernt.
Sicherheitsgruppen: Auswahl keiner, einer oder mehrerer Sicherheitsgruppen (Mehrfachauswahl).
Daneben steht das Feld "Baustein-Dokumentation" zur Verfügung.
Der Baustein steht nur zur Verfügung, wenn Ihre Rolle unter "Sicherheitsgruppenadministration" die Berechtigungen "Anzeigen" und "Bearbeiten" besitzt.
Bitte beachten Sie
Die Änderungsart "Überschreiben" ersetzt die Sicherheitsgruppenzuordnungen des CIs vollständig. Bleibt die Auswahl im Feld "Sicherheitsgruppen" leer, verliert das CI alle Sicherheitsgruppen. Die Oberfläche verhindert das nicht: Die leere Auswahl ist ein zulässiger Zustand des Dialogs. Ein CI ohne Sicherheitsgruppenzuordnung ist anschließend für jede Rolle unsichtbar, die einer Sicherheitsgruppe angehört (siehe Wie Sicherheitsgruppen den Zugriff verändern).
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
Schaltfläche "Aktivieren" bzw. "Deaktivieren": Schaltet den Workflow für die Workflow-Engine frei bzw. wieder ab. Die Schaltflächen erscheinen nur bei Workflows, die aktivierbar sind.
Schaltfläche "Jetzt starten": Plant einen zeitgesteuerten Workflow zur sofortigen Ausführung ein. dot4 legt dazu einen einmaligen Plan-Eintrag auf den aktuellen Zeitpunkt; ausgeführt wird dieser Eintrag wie jeder andere beim nächsten Prüflauf des Background Job Runners.
Bei Neuanlage eines Workflows über die Schaltfläche "Workflow erstellen" ("+"-Zeichen) öffnet der Workflow Editor den Dialog "Workflow - Allgemeine Daten". Dort 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.
Workflow Trigger: Optionale Zuordnung eines oder mehrerer Workflow-Trigger, die den Workflow auslösen.
Ausführungsplan: Tabelle der Zeitpläne, zu denen der Workflow zeitgesteuert laufen soll, mit den Spalten "Häufigkeit", "Monat", "Tag", "Uhrzeit" und "Letzte Ausführung". Über das "+"-Zeichen legen Sie einen Eintrag an.
Diesen Dialog rufen Sie später jederzeit über den Baustein "Start" wieder auf, um die Angaben zu ändern.
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. Über die Suchzeile "Bausteine filtern" oberhalb der Liste lässt sich die Anzeige auf die Bausteine einschränken, deren Beschriftung den eingegebenen Text enthält. Eine leere Suchzeile zeigt wieder alle Bausteine an.
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.
Bausteine kopieren und einfügen
Bausteine lassen sich innerhalb des Arbeitsbereiches kopieren, statt sie erneut aus der Baustein-Liste zu ziehen und neu zu konfigurieren. Kopiert werden die Bausteine mit ihrer Konfiguration und mit den Verbindungslinien, die zwischen den kopierten Bausteinen verlaufen. Kopieren und Einfügen stehen nur im Bearbeitungsmodus zur Verfügung: Im Anzeigemodus werden die Schaltflächen nicht angezeigt, und auch die Tastenkürzel bleiben dort ohne Wirkung.
Alles auswählen: "Strg"+"A" selektiert alle Bausteine im Arbeitsbereich.
Kopieren: "Strg"+"C" oder die Schaltfläche "Kopieren" oberhalb des Arbeitsbereiches.
Ausschneiden: "Strg"+"X".
Einfügen: "Strg"+"V" oder die Schaltfläche "Einfügen". Die Bausteine werden gegenüber dem Original versetzt eingefügt und sind anschließend selektiert, so dass Sie sie in einem Zug an ihren Platz ziehen können.
Beide Schaltflächen sind nur aktiv, wenn es etwas zu kopieren beziehungsweise etwas einzufügen gibt. Es gelten folgende Einschränkungen:
Die Bausteine "Start" und "Ende" werden nicht kopiert. Sie bleiben je Workflow einmalig; eine Auswahl, die sie enthält, wird ohne sie kopiert.
Eine Verbindungslinie allein lässt sich nicht kopieren. Eine Linie wird nur übernommen, wenn beide Bausteine, die sie verbindet, mit kopiert werden.
Die Gruppen-Bausteine "UND-Bedingung" und "ODER-Bedingung" lassen sich kopieren, aber nicht ausschneiden: Beim Entfernen einer Gruppe fragt dot4 zunächst, was mit ihren Bausteinen geschehen soll, und ein Ausschneiden würde diese Abfrage umgehen.
Ein Baustein "Genehmigung", zu dem noch offene Genehmigungen vorliegen, lässt sich kopieren, aber nicht ausschneiden: Der eingefügte Baustein ist ein neuer Baustein, und die offenen Genehmigungen des ausgeschnittenen gingen beim Speichern verloren.
Die Zwischenablage gehört zum geöffneten Editor. Zwischen zwei Workflows können Sie keine Bausteine übertragen; um einen ganzen Workflow als Vorlage zu nutzen, legen Sie stattdessen eine Kopie des Workflows an (siehe Tipps zum Thema Workflows).
Suche im Arbeitsbereich
Über die Schaltfläche "Bausteine durchsuchen" oberhalb des Arbeitsbereiches wird ein Eingabefeld für einen Suchbegriff geöffnet. Alle Bausteine, deren Beschreibungstexte den Suchbegriff enthalten, werden im Arbeitsbereich farbig umrandet. Groß- und Kleinschreibung werden dabei nicht unterschieden.
Wird das Eingabefeld wieder geschlossen, bleiben der Suchbegriff und die Hervorhebung erhalten. Die Schaltfläche bleibt so lange hervorgehoben, wie ein Suchbegriff gesetzt ist. Das Leeren des Eingabefeldes hebt die Markierung auf.
Anordnung im Arbeitsbereich
Über die Schaltfläche "Anordnung" oberhalb des Arbeitsbereiches werden die Bausteine automatisch angeordnet. Zur Auswahl stehen "Von oben nach unten" und "Von links nach rechts". Beide Anordnungen richten den Workflow entlang seiner Flussrichtung aus, setzen den "Start"-Baustein an den Anfang und den "Ende"-Baustein an das Ende und verlegen die Verbindungslinien zwischen den Bausteinen neu.
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 "Anordnung" mit den Optionen "Von oben nach unten" und "Von links nach rechts", "Größe dem Inhalt anpassen", "Vergrößern" und "Verkleinern". Dies kann helfen, die Übersichtlichkeit beim Anlegen von Workflows zu verbessern.
gibt es einen Button, mit dem eine Kopie eines Workflows angelegt werden kann. Der Name der Kopie ist der gleiche wie im Original, allerdings ergänzt um einen Zähler am Ende. Die Kopie ist direkt nach der Erzeugung auf inaktiv gesetzt.
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. Die Liste aller Trigger finden Sie unter Administration > Workflows > Workflow-Trigger.
Die Spalte "Workflows" zeigt, welche Workflows der jeweilige Trigger ausführt; die Spalte "System" kennzeichnet die mitgelieferten Trigger, deren Name und Beschreibung nicht geändert werden können.
Es gibt 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 |
| E-mail to Ticket create | Der WF wird ausgelöst, wenn ein Ticket aus einer E-Mail erstellt wird |
| E-mail to Ticket update | Der WF wird ausgelöst, wenn ein Ticket aus einer E-Mail aktualisiert wird |
| Import CI create | Der WF wird beim Anlegen eines CI über einen Import ausgelöst |
| Import CI update | Der WF wird beim Aktualisieren eines CI über einen Import ausgelöst |
| 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.
Einen eigenen Trigger legen Sie über das "+"-Zeichen in der Werkzeugleiste der Trigger-Liste an. Der Dialog verlangt 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 |
So richten Sie einen selbstdefinierten Trigger vollständig ein:
Legen Sie den Trigger unter Administration > Workflows > Workflow-Trigger an und ordnen ihm im Feld "Workflows" die Workflows zu, die er ausführen soll.
Erstellen Sie an der CI-Kategorie oder am CI-Typ ein CI-Attribut mit dem Basis-Datentyp Aktion und dem Datentyp Workflow Trigger. Wählen Sie in diesem Attribut den zuvor angelegten "Workflow Trigger" sowie das "Bild" für die Schaltfläche aus.
In der Detailsicht der betroffenen CIs steht die Schaltfläche anschließend zum manuellen Auslösen bereit.
Durch einen Zeit-Trigger haben Sie die Möglichkeit einen Workflow in einem geplanten Rhytmus ausführen zu lassen.
Folgende Häufigkeiten stehen zur Verfügung:
| Häufigkeit | Beschreibung | Erforderliche Angaben |
|---|---|---|
| Einmalig | Der WF wird einmalig zu einem gewünschten Zeitpunkt geplant. | Datum und Uhrzeit |
| Stündlich | Der WF wird stündlich zu einer gewünschten Minute geplant. | Minute |
| Täglich | Der WF wird täglich zu einer gewünschten Uhrzeit geplant. | Uhrzeit |
| Wöchentlich | Der WF wird wöchentlich zu einem gewünschten Tag und Uhrzeit geplant. | Wochentag und Uhrzeit |
| Monatlich | Der WF wird monatlich zu einem gewünschten Tag im Monat geplant | Tag im Monat und Uhrzeit |
| Jährlich | Der WF wird jährlich zu einem gewünschten Tag geplant. | Monat, Tag und Uhrzeit |
Wählen Sie bei der Häufigkeit "Jährlich" den 29. Februar, weist dot4 Sie bei der Eingabe darauf hin, dass die Ausführung in Nicht-Schaltjahren am 28. Februar erfolgt.
Ein Ausführungsplan kann mehrere Einträge enthalten. Einen Eintrag, der mit einem bereits vorhandenen Eintrag identisch ist, weist dot4 ab.
Ein Plan-Eintrag mit der Häufigkeit "Einmalig" wird nach dem Lauf automatisch aus dem Ausführungsplan entfernt. Der Workflow selbst bleibt erhalten — möchten Sie ihn erneut zeitgesteuert ausführen, legen Sie einen neuen Plan-Eintrag an. Bei allen anderen Häufigkeiten berechnet dot4 nach jedem Lauf den nächsten Ausführungszeitpunkt.
Hinweis
Die geplante Zeit ist der früheste Ausführungszeitpunkt, nicht der garantierte. Zeitgesteuerte Workflows führt nicht die Anwendung selbst aus, sondern der Background Job Runner: Er prüft in festen Intervallen, ob die Ausführung eines Workflows aufgrund eines Zeittriggers fällig ist, und führt sie dann aus; zwischen der geplanten Zeit und der tatsächlichen Ausführung liegt daher bis zu ein Prüfintervall. Das gilt für jeden Betriebsweg. Wie oft geprüft wird, legt die Einrichtung Ihrer Installation bzw. Ihrer Betriebsumgebung fest. Bei einer On-premise-Installation legt das Setup für diese Prüfung einen Takt von 30 Minuten an, sofern bei der Installation kein anderer Wert angegeben wird. Sind mehrere Zeittrigger desselben Workflows gleichzeitig fällig, wird der Workflow nur einmal ausgeführt und alle fälligen Trigger werden als behandelt betrachtet.
Tipp
Für eine halbstündliche Ausführung legen Sie zwei stündliche Einträge an, beispielsweise auf Minute 5 und Minute 35.
Welche CIs ein zeitgesteuerter Lauf erfasst, ist unter Allgemeines beschrieben; über das Bedingungs-Tracking begrenzen Sie die Wiederholung auf noch nicht behandelte CIs. Einen zeitgesteuerten Workflow können Sie zusätzlich über die Schaltfläche "Jetzt starten" zur sofortigen Ausführung einplanen: dot4 legt dazu einen einmaligen Plan-Eintrag auf den aktuellen Zeitpunkt, den der Background Job Runner bei seinem nächsten Prüflauf ausführt (siehe Konfiguration der Workflows).
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.
Die eingerichteten Endpunkte verwalten Sie unter Administration > Workflows > HTTP-Endpunkte.
Die Übersicht führt je Endpunkt die Spalten "Name", "Beschreibung" und "URL".
Legen Sie einen neuen Endpunkt über das "+"-Zeichen in der Werkzeugleiste an.
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 (in Sekunden): 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 der Schaltfläche 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.
Einen Endpunkt, den noch ein Workflow verwendet, lehnt dot4 zum Löschen ab. Entfernen Sie zuerst den betreffenden Baustein REST aus allen Workflows, die den Endpunkt nutzen; danach lässt er sich löschen.
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)
Sie erreichen die Workflow-Log über Administration > Workflows > Workflow-Log.
Über die Schaltfläche "Alle löschen" in der Werkzeugleiste leeren Sie das Protokoll vollständig. Der Vorgang läuft im Hintergrund und setzt voraus, dass Ihre Rolle die Löschberechtigung für den Workflow-Editor besitzt.
Anmerkungen / Hinweise
Das Setzen des "Workflow Log-Level" auf "Aus" stoppt das Schreiben der Log. Bereits vorhandene Einträge können weiterhin ausgewertet werden.
Ein Hintergrund-Prozess löscht Einträge, die älter als der eingestellte Aufbewahrungszeitraum sind. Der Standardwert beträgt 3 Tage und ist konfigurierbar.
Ein leeres Protokoll bedeutet entweder, dass noch kein Workflow gelaufen ist, oder dass der "Workflow Log-Level" auf "Aus" steht.
Welche Spalten angezeigt werden, legen Sie über die Spaltenauswahl in der Werkzeugleiste fest; die Einstellung wird pro Benutzer gespeichert. Die Workflow-Log verfügt über die folgenden Spalten:
Benutzer (Bei Workflows, welche über einen Zeittrigger 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-Trigger (Name des Workflow-Triggers, der die Ausführung ausgelöst hat)
Workflow-Log Details
Jeden Eintrag der Workflow-Log öffnen Sie per Doppelklick oder über die Zeilenaktion "Anzeigen". Je nach eingestelltem "Workflow Log-Level" sind vertiefende Details an dieser Stelle einsehbar.
Für die Fehlersuche an einem einzelnen Workflow hat sich folgendes Vorgehen bewährt: Setzen Sie den "Workflow Log-Level" auf "Debug", lösen Sie den Workflow aus, werten Sie den Log-Eintrag aus und setzen Sie den Log-Level anschließend wieder auf "Aus".
Hinweis
Der "Workflow Log-Level" gilt mandantenweit für alle Workflows, nicht nur für den Workflow, den Sie untersuchen.