Technical Workflow Diagramme
Verwendung
Technical Workflows nutzen Sie zur Implementierung Ihrer fachlichen Modelle, die z.B. als Business Process Diagramme vorliegen.
Sie können einen Technical Workflow mit dem dazugehörigen fachlichen Modell verlinken, um möglicherweise im Betrieb entstehende Fehler fachlich einzuordnen.
|
Eine Einführung in das Thema Technical Workflows siehe Systeme integrieren und Prozesse automatisieren. |
Änderungen an verlinkten Diagrammen signalisieren
Wenn Ihr fachliches Modell mit einem Technical Workflow verlinkt ist, dann werden Änderungen am fachlichen Modell und am Technical Workflow signalisiert.
Technical Workflows modularisieren
Komplexe Technical Workflows können Sie modularisieren und die Module in verschiedenen Technical Workflows wiederverwenden.
Ausführung konfigurieren
Von jedem Technical Workflow können mehrere Instanzen parallel ausgeführt werden. Die Ausführungseigenschaften legen Sie am Workflow-Diagramm fest.
Human Workflows
Zur Integration von Mitarbeitern oder Geschäftspartnern in Ihre Technical Workflows nutzen Sie Task Generatoren.
Siehe Task Generator.
Ad-hoc-Prozesse
Sie können Prozesse aus der Taskliste des INUBIT Cockpits heraus spontan starten, wenn Sie Module in diesen Technical Workflows entsprechend konfiguriert haben. Auf diese Weise können Sie z.B. jederzeit eine neue Task für Mitarbeiter erzeugen.
Siehe Prozesse ad hoc erzeugen.
Technical Workflows validieren
Sie können Technical Workflows validieren lassen. Dabei werden u.a. folgende Aspekte überprüft:
-
Gibt es Demultiplexer ohne otherwise-Zweige?
-
If- ohne else-Zweige?
-
Gibt es Deadlocks?
-
Sind die Verlinkungen funktional?
Tools in Technical Workflow Diagrammen
| Name | Erläuterung | Siehe |
|---|---|---|
Switch |
Mit einem Switch-Tool können Sie den Nachrichtenfluss abhängig von einer oder mehreren Bedingungen steuern, indem Sie in dem Switch- Element mehrere Teilprozesse erstellen und für jeden Teilprozess festlegen, unter welchen Bedingungen dieser ausgeführt werden soll. |
|
If |
Mit dem If-Tool können Sie die weitere Ausführung eines Prozesses von Bedingungen abhängig machen. Dazu erzeugen Sie im If-Tool mehrere Teilprozesse und definieren für jeden Teilprozess eine oder mehrere Bedingungen. Beim Konfigurieren der Bedingungen können Sie selbst definieren, in welcher Reihenfolge die Teilprozesse geprüft werden sollen. Es wird immer der erste Teilprozess ausgeführt, dessen Bedingungen erfüllt sind. |
|
While |
Das While-Tool enthält einen Teil-Prozess, prüft vor dessen Ausführung die angegebene Abbruchbedingung und wiederholt den Teil-Prozess, solange die Abbruchbedingung noch nicht erfüllt ist. |
|
Repeat |
Until Das Repeat Until-Tool enthält einen Teil-Prozess, führt diesen einmal aus, prüft dann die angegebene Abbruchbedingung und wiederholt den Teil-Prozess, bis die Abbruchbedingung erfüllt ist. |
|
For Each |
Das For Each-Tool enthält einen Teil-Prozess und führt diesen so oft aus, bis ein vorher festgelegter Endwert erreicht ist. |
|
Flow |
Mit dem Flow-Tool lassen Sie zwei Teil-Prozesse (oder mehr) parallel ausführen. |
|
Pick |
Mit dem Pick-Tool legen Sie fest, dass der Workflow auf das Eintreffen einer Nachricht warten soll. Das Pick-Tool kann Nachrichtentypen unterscheiden: es enthält ein oder mehrere OnMessage-Module, an denen jeweils der Nachrichten-Typ definiert ist, auf den das Pick-Tool warten soll. |
|
Scope |
Ein Scope fasst mehrere Aktivitäten zu einer Einheit zusammen, der Sie eine gemeinsame Fehler- und Kompensationsbehandlung zuordnen können. |
|
Transaktions-Scope |
Mit einem Transaktions-Scope können Sie die Aktionen mehrerer datenbankbasierter Systemkonnektoren, die auf dieselbe Datenbank zugreifen, zu einer Transaktion zusammenfassen:
|
|
Partnermanagement |
Mit dem Partnermanagement können Sie eine Vielzahl externer Geschäftspartner in die Supply Chains und damit in die Geschäftsprozesse Ihres Unternehmens einbinden. Das Partnermanagement unterstützt Sie bei folgenden Aufgaben:
|
|
Rahmen |
Zum Einfügen eines Rahmens, mit dem Sie inhaltlich zusammengehörende Elemente eines Diagramms optisch gruppieren können. |
|
Kommentar |
Zum Hinzufügen eines Kommentars, den Sie auf der Arbeitsfläche anordnen können. |
|
Text |
Zum Einfügen beliebiger Textanmerkungen, die Sie frei auf der Arbeitsfläche anordnen können. |
Switch-Elemente verwenden
Mit einem Switch können Sie den Nachrichtenfluss abhängig von einer oder mehreren Bedingungen steuern, indem Sie in dem Switch-Element mehrere Teilprozesse erstellen und für jeden Teilprozess festlegen, unter welchen Bedingungen dieser ausgeführt werden soll.
Beim Konfigurieren der Bedingungen können Sie definieren, in welcher Reihenfolge die Teilprozesse geprüft werden sollen. Es wird immer der erste Teilprozess ausgeführt, dessen Bedingungen erfüllt sind.
Um Fehler abzufangen, können Sie einen Teilprozess definieren, der immer dann ausgeführt wird, wenn keine Bedingung zutrifft. Dieser Teilprozess ist der sogenannte Otherwise-Zweig:
Trifft keine im Switch definierte Bedingung zu, und haben Sie auch keinen Otherwise-Zweig definiert, wird die Verarbeitung am Ende des Switches fortgesetzt.
|
Sie können die Hintergrundfarbe, die Linienfarbe und den Linientyp eines Switches ändern. Siehe Layout von Diagrammelementen bearbeiten. |
So gehen Sie vor
-
Öffnen Sie in der Sidebar die Palette Tools, klicken Sie auf Tools und ziehen das Switch auf die Arbeitsfläche.
-
Erstellen Sie die Teilprozesse im Switch.
-
Verbinden Sie die ersten Module der Teilprozesse mit dem Eingang des Switches.
-
Verbinden Sie die Module am Ende der Teilprozesse mit dem Ausgang des Switches.
-
So legen Sie Bedingungen fest:
-
Markieren Sie eine Verbindung zwischen dem Eingang des Switches und einem Teilprozess.
-
Öffnen Sie das Kontextmenü und wählen Sie Switch Konfiguration ändern. Alternativ doppelklicken Sie die Verbindung.
Der folgende Dialog öffnet sich:
Erläuterungen zu den Bedienfeldern siehe Dialog Demultiplexer Konfiguration.
-
-
Klicken Sie auf OK, um den Dialog zu schließen.
While-Schleifen verwenden
Mit einer While-Schleife können Sie einen Workflow oder Teile davon wiederholt ausführen lassen. Der Workflow wird solange wiederholt, bis eine Abbruchbedingung zutrifft.
Die Abbruchbedingung wird geprüft, bevor der Workflow ausgeführt wird. Unter Umständen wird daher ein Workflow gar nicht ausgeführt, weil die Abbruchbedingung bereits erreicht ist.
|
Wenn die Abbruchbedingung nie erreicht wird oder nicht definiert ist, dann wird der Workflow endlos wiederholt! |
Um die Anzahl der Schleifendurchläufe abhängig von einer Zählervariable zu machen, kann ein XSLT Converter oder das Variablen-Mapping für das Inkrementieren des Variablenwertes verwendet werden.
Beispiel
Im abgebildeten Beispiel wird die Schleife, solange ausgeführt, wie der Wert der Variable Counter (vom Typ String) größer als der String 0 (Null) ist.
Bei jedem Durchlauf reduziert der XSLT Converter den Wert von Counter um 1 und schreibt ihn in einen Textknoten.
Der Wert des Textknotens wird im folgenden Assign-Modul wieder der Variable Counter zugewiesen.
Vor jedem Durchlauf wird dann der aktuelle Wert von Counter mit der Bedingung Counter größer als String 0 verglichen.
So gehen Sie vor
-
Ziehen Sie aus der Sidebar das While-Symbol auf die Arbeitsfläche.
-
Ziehen Sie Module, deren Aktionen wiederholt werden sollen, auf das While-Symbol.
-
Verbinden Sie das erste Modul mit dem Eingang der While-Schleife (links), das letzte Modul mit dem Ausgang (rechts).
-
Zum Festlegen der Abbruchbedingung doppelklicken Sie die Verbindung zwischen dem Eingang und dem ersten Modul.
Der folgende Dialog öffnet sich:
-
Geben Sie eine Beschreibung der Bedingung ein. Die Beschreibung wird auf der Verbindungslinie angezeigt. Wenn keine Beschreibung angegeben ist, dann wird die Bedingung selbst angezeigt.
-
Bedingung hinzufügen (Button)
Blendet die folgenden Bedienfelder zum Festlegen von Bedingungen ein:
-
Operator für Verknüpfungen: Zum Verknüpfen von mehreren Bedingungen.
-
AND: Alle Bedingungen müssen zutreffen.
-
OR: Eine der Bedingungen muss zutreffen.
-
-
Button D: Die Bedingung bezieht sich auf ein Element in der XML-basierten Nachricht. Im Eingabefeld muss ein XPath-Ausdruck eingegeben werden.
Falls eine Beispiel-XML-Datei vorliegt, klicken Sie auf den
-Button und wählen das Element aus. -
Button V: Die Bedingung bezieht sich auf eine Variable. Alle vorhandenen Variablen werden in der nebenstehenden Liste angezeigt.
-
Button X: Die Bedingung bezieht sich auf einen XPath-Ausdruck. Der XPath wird auf einem leeren Dokument ausgeführt (nicht auf dem Datenstrom). Der
-Button öffnet einen Assistenten zum Anlegen des XPath-Ausdrucks. -
Operator
Zur Auswahl eines Operators für den Werteabgleich. Es gibt folgende Operatoren:Operator Bedeutung =
Gleich
<
Kleiner als
>
Größer als
>=
Größer gleich
<=
Kleiner gleich
!=
Ungleich
Exists
Existiert
NotExists
Existiert nicht
XPath
XPath-Ausdruck
-
Buttons D und V: Siehe oben.
-
Button S: Die Bedingung bezieht sich auf die eingegebene Zeichenkette.
Beispiele:
-
/AUFTRAG/AUFTRAGSSUMME > 1000 -
/AUFTRAG/LIEFERUNG/ = Express -
/IBISProfile/Profile/Name ExistsWenn der Knoten
Namein der Eingangsnachricht vorhanden ist, dann wird die Schleife erneut durchgeführt. -
count(/Order/test1)> 1Wenn die Auswertung der XPath-Funktion
count()ergibt, dass der Knoten/Order/test1mehr als einmal existiert, dann wird die While-Schleife wieder ausgeführt.
-
-
-
Schließen Sie den Dialog.
Die Bedingungen werden auf der Verbindungslinie angezeigt. -
Fügen Sie einen XSLT Converter ein, in dem der Wert des Zählers hoch- bzw. heruntergesetzt wird.
For Each-Schleifen verwenden
Verwendung
Zum Ausführen eines Teilprozesses bis ein definierter Endwert erreicht ist, fügen Sie eine For Each-Schleife aus der Tools-Sidebar hinzu.
Jede For Each-Schleife beinhaltet implizit auch einen Scope, daher können sowohl ein Fehler- und Kompensationsausgang festgelegt als auch Variablen mit auf das Tool begrenzter Lebensdauer definiert werden, siehe Workflow-Variablen und Mappings.
Aufruf
Um die For Each-Moduleigenschaften zu konfigurieren, doppelklicken Sie auf die Verbindung zwischen dem linken F- Symbol und dem ersten Modul innerhalb des For Each-Rahmens.
Beispiel
Dialogbeschreibung
-
Name des Zählers
Geben Sie einen eindeutigen Namen für den Zähler ein. -
Startwert des Zählers
-
Button D: Der Wert bezieht sich auf ein Element in der XML-basierten Nachricht. Im Eingabefeld muss ein XPath-Ausdruck eingegeben werden.
Falls eine Beispiel-XML-Datei vorliegt, klicken Sie auf den Button und wählen das Element aus. -
Button V: Der Wert bezieht sich auf eine Variable. Alle vorhandenen Variablen werden in der nebenstehenden Liste angezeigt.
-
Button X: Der Wert bezieht sich auf einen XPath-Ausdruck. Der XPath wird auf einem leeren Dokument ausgeführt (nicht auf dem Datenstrom). Der Button
öffnet einen Assistenten zum Anlegen des XPath-Ausdrucks. -
Button S: Der Wert bezieht sich auf einen statischen Wert.
-
-
Endwert des Zählers
Siehe oben Startwert des Zählers. -
Abschlussbedingung verwenden
Zum Definieren eines Wertes, der die Ausführung der For Each-Schleife beendet. Wenn ausgewählt, endet die Ausführung, wenn die Anzahl der Ausführungen den angegebenen Wert erreicht hat.Der Wert wird nur bei der ersten Ausführung der For Each-Schleife ermittelt, beispielsweise aus einem XPath, und in weiteren Durchläufen wird nur noch der ermittelte Wert mit dem Zähler verglichen.
Siehe oben Startwert des Zählers.
Fehlerbehandlung und -unterdrückung
In jedem Workflow kann es Ausnahmen zum erwarteten Ausführungsfluss geben. Um diese Ausnahmen zu bewältigen, bietet die Software verschiedene leistungsfähige Mechanismen zur Fehlerbehandlung und Wiederherstellung.
Fehleranalyse
Standardmäßig werden alle Workflows, bei deren Ausführung ein unbehandelter Fehler an einem Modul auftritt, im Queue Manager mit dem Status Error angezeigt. Die Ausführung des Workflows wird abgebrochen.
Zur Analyse des Fehlers können Sie im Queue Manager alle Prozessschritte bis zum Fehler, die aktuelle Nachricht inkl. der Workflow-Variablen am fehlerhaften Modul und die Fehlermeldung anzeigen.
Den fehlerhaften Workflow können Sie im Queue Manager mit einer neuen oder geänderten Datei neu starten.
Benachrichtigungen im Fehlerfall
Die Software kann bei fehlerhaften Workflowausführungen automatisch Benachrichtigungen an den Eigentümer des Workflows und den Systemadministrator (root) versenden.
Siehe Alarme.
Fehler-Variablen
Im Fehlerfall werden Error-Systemvariablen erzeugt, die Sie mithilfe des Variablen-Mappings auswerten können.
Siehe Systemvariablen-Übersicht.
Verbindungsfehler vermeiden
Falls die Verbindung zu einem Drittsystem nicht hergestellt werden kann, können Sie Systemkonnektoren so konfigurieren, dass der Verbindungsversuch automatisch wiederholt wird. Während der Wiederholung hat der Prozess im Queue Manager den Status Retry. Bei jedem Verbindungsversuch wird der Eintrag im Queue Manager aktualisiert und der Zähler bei jedem erfolglosen Versuch erhöht.
Fehlerbehandlung
Bei Systemkonnektoren und Modulen haben Sie folgende Optionen, Fehler zu behandeln, damit der Workflow stabil ist und nach Auftreten eines Fehlers fortgeführt wird:
-
Ersatzkonnektor für Systemkonnektoren
Sie können einem Systemkonnektor einen anderen Systemkonnektor als Ersatzkonnektor zuordnen. Im Fehlerfall und nach dem letzten erfolglosen Retry-Versuch wird der Ersatzkonnektor ausgeführt. Damit kann der Workflow trotz des Fehlers erfolgreich abgeschlossen werden.
Siehe Modul als Fehlerausgang verwenden. -
Fehlerausgang an Modulen
Sie können für jedes Modul einen Fehlerausgang definieren. Bei Auftreten eines Fehlers wird die Ausführung des Workflows am Fehlerausgang mit der Eingangsnachricht des Moduls fortgesetzt. Den Fehlerstatus können Sie über Workflow-Variablen abfragen.
Siehe Modul als Fehlerausgang verwenden. -
Throw-Module für definierte Fehler
Ein Throw-Modul erzeugt einen Fehler, der durch den Fehlerausgang eines Scopes oder Moduls oder durch einen Workflow Connector abgefangen und behandelt werden kann.
Siehe Throw.
Modulübergreifende Fehlerbehandlung und Kompensation
Sie können für mehrere zusammenhängende Module einen gemeinsamen Gültigkeitsbereich, einen so genannten Scope, definieren und auf diese Weise die Fehlerbehandlung und die Kompensation modul-übergreifend steuern.
Siehe Kompensation und Fehlerbehandlung mit Scopes.
Fehlerunterdrückung
Wenn ein Fehler an einem Modul oder in einem Scope durch einen der beschriebenen Mechanismen bereits abgefangen und behandelt wird, dann können Sie an dem Modul oder Scope angeben, dass der Fehler unterdrückt werden soll. Mit dieser Konfiguration wird der Workflow am Fehlerausgang fortgeführt und die Workflowausführung als erfolgreich gewertet. Die fehlerhafte Workflowausführung wird im System Log angezeigt, aber es wird kein Eintrag im Queue Manager erzeugt.
-
Fehlerunterdrückung an Modulen: Siehe Dialog Allgemeine Moduleigenschaften
-
Fehlerunterdrückung in Scopes: Siehe Fehlerbehandlung in einem Scope konfigurieren
Fehlerbehandlung bei verlinkten Workflows
Wenn die Ausführung eines Workflows, der mit einem anderen Workflow durch einen Workflow Connector verlinkt ist, mit einem Fehler abgebrochen wird, dann entscheidet die Konfiguration der Fehlerbearbeitung und des Workflow-Aufrufstacks am Workflow Connector über das weitere Vorgehen.
Siehe Dialog Workflow-Auswahl und Eigenschaften.
Modul als Fehlerausgang verwenden
Sie können für jedes Modul ein zweites Modul als Fehlerausgang definieren. Im Fehlerfall erhält der Fehlerausgang die Eingangsnachricht und die Fehlermeldung des fehlerhaften Moduls und kann diese verarbeiten.
Alternativ dazu können Sie ein Scope für die Fehlerbehandlung nutzen, siehe Fehlerbehandlung in einem Scope konfigurieren.
Beispiel
Im folgenden Beispiel werden komprimierte Nachrichten an einen FTP Connector gesendet. Falls der FTP Connector einen Fehler wirft, dann werden die komprimierten Nachrichten an den Fehlerausgang weitergeleitet und vom File Connector im Dateisystem abgelegt. Die Fehlermeldung wird in einer Systemvariablen gespeichert.
So gehen Sie vor
-
Fügen Sie das Modul, dessen Fehler Sie behandeln wollen, und mindestens zwei Module, die Sie als Fehlerausgang nutzen wollen, in den Workflow ein.
-
Halten Sie die Strg-Taste gedrückt und markieren Sie mit der Maus zuerst das Modul, dessen Fehler Sie behandeln wollen, und dann das erste Modul des Fehlerausgangs.
-
Öffnen Sie das Kontextmenü für eines der markierten Module und wählen Sie Verbinden als Fehlerausgang.
Die beiden Module sind als Fehlerausgang verbunden.
Systemkonnektor als Ersatzkonnektor verwenden
Für alle Systemkonnektoren können Sie einen Ersatzkonnektor definieren. Ein Ersatzkonnektor ist ein zusätzlicher Systemkonnektor, der die Aufgabe des primären Systemkonnektors übernimmt, wenn diese nicht erfolgreich durchgeführt werden konnten. Für jeden Ersatzkonnektor kann es wiederum einen Ersatz geben.
Beispiel
Im abgebildeten Beispiel werden komprimierte Nachrichten an einen FTP Connector gesendet. Falls der FTP Connector nicht erreichbar ist, dann werden die komprimierten Nachrichten an den Ersatzkonnektor weitergeleitet und von diesem im Dateisystem abgelegt.
|
Wenn für einen Systemkonnektor sowohl ein Ersatzkonnektor als auch ein Fehlerausgang definiert sind, dann werden beide durchlaufen: zuerst der Fehlerausgang, dann der Ersatzkonnektor. |
So gehen Sie vor
-
Fügen Sie den Systemkonnektor und den Ersatzkonnektor in den Workflow ein.
-
Halten Sie die Strg-Taste gedrückt und markieren Sie mit der Maus zuerst den Systemkonnektor und dann den Ersatzkonnektor.
-
Öffnen Sie das Kontextmenü und wählen Sie Verbinden als Ersatzkonnektor.
Die Verbindung zu dem Ersatzkonnektor wird erstellt.
Kompensation und Fehlerbehandlung mit Scopes
In Technical Workflows können Sie für mehrere, zusammenhängende Module einen gemeinsamen Gültigkeitsbereich (Scope) definieren und auf diese Weise folgende Aspekte modul-übergreifend steuern:
-
Fehlerbehandlung
Alle Module in einem Scope können den Fehlerausgang des Scopes nutzen. An dem Fehlerausgang kann jeder Fehlertyp individuell behandelt werden. -
Kompensation
Mithilfe des Compensate Scope- oder Compensate-Moduls können Sie einen Rollback-Mechanismus definieren. Dabei wird der Scope verlassen, ohne einen Fehler zu erzeugen. -
Kapselung von Workflow-Variablen
Für Informationen über das Variablenhandling in Scopes siehe Gültigkeitsbereiche von Workflow-Variablen.
-
Fehlerunterdrückung
Die Fehlerunterdrückung kann für alle Module eines Scope zentral aktiviert werden.
Scopes können ineinander verschachtelt werden und werden dann von innen nach außen abgearbeitet.
Fehlerbehandlung in einem Scope konfigurieren
Der Fehlerausgang eines Scopes behandelt Fehler, die von Modulen innerhalb des Scopes geworfen werden und nicht durch Fehlerausgänge der Module behandelt werden. Fehler, die bereits durch einen modul-eigenen Fehlerausgang behandelt werden, werden nicht an den Scope weitergereicht, in dem die Module liegen.
Wenn ein Fehler in einem Scope auftritt, wird geprüft, ob an dem Fehlerausgang des Scope ein passend konfigurierter Workflow vorhanden ist. Falls nicht, dann wird der Standard-Ausgang verwendet (wenn vorhanden).
Beispiel
Das Modul A im Scope wirft den Fehler 123. Dieser wird im Fehlerausgang 123 des Scopes von dem Modul Do-Error-Handling-XYZ behandelt. Für andere Fehler als 123 ist kein spezieller Fehlerausgang vorhandenen, daher wird für alle anderen Fehler der Catch-All-Ausgang verwendet.
So gehen Sie vor
-
Ziehen Sie das Modul, mit dem ein Fehler behandelt werden soll, auf die Arbeitsfläche des Designers.
-
Verbinden Sie das Modul mit dem Fehler-Symbol
des Scopes. -
Öffnen Sie das Kontextmenü der Verbindungslinie und wählen Sie Konfiguration ändern. Alternativ doppelklicken Sie die Verbindung.
Der folgende Dialog wird angezeigt:
-
In der Liste wird das Modul angezeigt, das Sie mit dem Fehlerausgang verbunden haben. Das erste Modul, das Sie mit dem Fehlerausgang verbinden, ist standardmäßig als Catch-All konfiguriert. Dieser Ausgang stellt sicher, dass alle Fehler behandelt werden. Mit jedem weiteren Modul können Sie jeweils einen weiteren Fehler spezifisch behandeln.
Statt alle Fehlerbehandlungen einzeln zu konfigurieren und den Dialog mehrfach öffnen zu müssen, können Sie zuerst alle Fehlerbehandlungen anlegen, mit dem Fehlerausgang verbinden und dann alle im abgebildeten Dialog konfigurieren. Dazu wählen Sie nacheinander alle verbundenen Module aus der Liste aus und ordnen diesen jeweils einen Fehlernamen zu.
-
Geben Sie im Feld Fehlername den Namen des Fehlers ein oder wählen Sie einen der vorhandenen Fehlernamen aus: In der Liste werden Fehlernamen aus Throw-Modulen und Web Services Output Connectoren angezeigt. Bei anderen Modulen finden Sie die Fehlernamen nach dem Testen in der Systemvariablen
ISErrorString.
Die Felder im Abschnitt Fehlerdaten beziehen sich auf Fehler, die von Throw- oder WebService-Connector-Modulen geworfen werden.Diese Fehlerdaten-Felder dienen hauptsächlich dazu, Fehler abzufangen, die von einem im Scope liegenden Throw-Modul oder einem Webservice-Connector geworfen wurden. Wenn sich in einem Scope ein Webservice-Connector befindet, und in dessen WSDL eine oder mehrere mögliche Fehlerrückgaben definiert sind, dann werden diese Fehlernamen in der Combobox Fehlername angezeigt.
Jeder Fehler hat einen definierten Fehlerdatentyp. Dieser wird im Feld Typ angezeigt. Die Fehlerdaten können Sie in eine Variable dieses Typs schreiben lassen. Zusätzlich werden die VariablenISErrorTextundISErrorStringgeschrieben.
Bei in dem Scope liegenden Throw-Modulen, werden die daran konfigurierten Fehlernamen auch in der ComboBox Fehlername angezeigt. -
Standard-Fehlerausgang:
Um Fehler abzufangen, für die keine individuelle Fehlerbehandlung vorhanden ist, markieren Sie die Option Diesen Ausgang benutzen, wenn keine Bedingungen an anderen Verbindungen zutreffen (Catch all).Wenn bei einem Scope innerhalb eines anderen Scopes kein Standard-Ausgang gefunden wird, dann wird der Standard-Ausgang des äußeren Scopes ausgeführt.
-
-
Schließen Sie den Dialog mit OK.
Der Fehlername wird auf der Verbindungslinie angezeigt.
Kompensation in einem Scope konfigurieren
Mithilfe eines Compensate-Scope lassen sich im Falle eines Fehlers Veränderungen rückgängig machen, die im Scope von einem oder mehreren Modulen veranlasst wurden. Dies entspricht dem Rollback-Mechanismus bei Transaktionen.
Funktionsweise
Wenn bei einer Folge mehrerer Scopes mit jeweils einzelnen Aktionen ein Fehler bei einer Aktion auftritt, dann werden die Aktionen über einen speziellen Workflow rückgängig gemacht. Dieser Workflow muss über einem Workflow Connector mit dem Compensate-Ausgang des jeweiligen Scopes verbunden sein. Im Workflow Connector muss das für die jeweilige Aktion geeignete Modul konfiguriert werden. Die Scopes mit den Aktionen müssen in einem weiteren Scope angelegt sein. Für diesen Scope muss ein Fehlerausgang mit einem Compensate-Modul definiert sein.
Beispiel
Nach einer fehlerhaften Aktion im ScopeC wird zunächst die Aktion in ScopeB und dann die Aktion im ScopeA rückgängig gemacht.
-
Die Aktionen in ScopeA, ScopeB und ScopeC werden ausgeführt.
-
Die Aktion im ScopeC liefert einen Fehler.
-
Der Fehler wird am Fehlerausgang des CompensateScope durch das Compensate-Modul CompensateIt behandelt.
-
Das Compensate-Modul sorgt dafür, dass für alle Scopes die mit dem jeweiligen Compensate-Ausgang verbundenen Workflow Connectoren gestartet und die darin konfigurierten Workflows ausgeführt werden.
Die Aktionen in den Scopes werden im Unterschied zur Workflow-Ausführung in umgekehrter Reihenfolge rückgängig gemacht, d.h., zuerst ScopeB und dann ScopeA.
So gehen Sie vor
-
Ziehen Sie die Module, welche die Aktionen durchführen, die kompensiert werden sollen, in einen oder mehrere Scopes (im Beispiel die Scopes ScopeA, ScopeB und ScopeC).
-
Erstellen Sie einen weiteren Scope (im Beispiel der Scope CompensateScope).
-
Ziehen Sie die Scopes mit den Aktionen in den im Schritt 2 erstellten Scope.
-
Verbinden Sie die Scopes.
-
Fügen Sie ein Compensate-Modul ein (im Beispiel das Modul CompensateIt).
Siehe Compensate. -
Verbinden Sie das Compensate-Modul mit dem Fehlerausgang des Scopes CompensateScope.
Um bei einem bestimmten Fehler nur eine bestimmte Aktion rückgängig zu machen, können Sie auch das Compensate-Scope-Modul nutzen.
-
Definieren Sie den Workflow, der die Veränderungen rückgängig macht, ggf. mit einem separaten Modul für jeden betreffenden Scope.
-
Verbinden Sie diesen Workflow ggf. über einen Workflow Connector (im Beispiel der Workflow Connector CompensateWF) mit dem Kompensations-Symbol
der Scopes, deren Aktionen im Fehlerfall rückgängig gemacht werden sollen.
Dieser Workflow wird aktiviert, wenn in einem der enthaltenen Scopes ein Fehler auftritt.
Fehlerunterdrückung für alle Module in einem Scope konfigurieren
Für Informationen über die Auswirkungen der Fehlerunterdrückung siehe Fehlerbehandlung und -unterdrückung.
So gehen Sie vor
-
Doppelklicken Sie das Scope-Eigenschaften-Icon am Scope:
-
Ein Dialog öffnet sich.
-
Markieren Sie die Option Workflow trotz durchlaufenem Fehler-Scope als erfolgreich werten.
-
Klicken Sie auf OK, um den Dialog zu schließen.
An allen Modulen im Scope signalisiert ein Blitz-Symbol, dass die Fehlerunterdrückung aktiviert ist.
Transaktionen verwalten mit dem Transaktions-Scope
Mit einem Transaktions-Scope können Sie die Aktionen mehrerer datenbank-basierter Systemkonnektoren, die auf dieselbe Datenbank zugreifen, zu einer Transaktion zusammenfassen:
-
Wenn die Aktionen aller Konnektoren im Transaktions-Scope erfolgreich ausgeführt wurden, wird die Transaktion bestätigt.
-
Andernfalls wird die Transaktion zurückgerollt (rollback).
Unterstützte Systemkonnektoren
Sie können in einem Transaction Scope den folgenden Systemkonnektortyp nutzen:
-
Database Connector mit aktiviertem Transaktionsmodus
Fehler am Transaktions-Scope
Ein Transaktions-Scope besitzt einen Rollback-Ausgang, der mit einem Modul verbunden werden kann. Die Ausführung des Moduls am Rollback-Ausgang wird durch jedes Rollback und durch die folgenden Ereignisse ausgelöst:
-
Undefinierte Fehler bei der Ausführung der Module im Transaktions-Scope.
-
Ein Throw-Modul im Transaktions-Scope wird ausgeführt, das einen definierten Fehler behandelt.
Siehe Throw. -
Das Timeout des Transaktions-Scopes wurde überschritten.
Die Ausführung der Module innerhalb des Transaktions-Scopes dauerte länger, als entsprechend dem Timeout des Transaktions-Scopes zulässig.
Wenn am Rollback-Ausgang kein Modul definiert ist, dann wird die Ausführung des Workflows abgebrochen und ein Eintrag im Queue Manager erzeugt.
Beispiel
Mit diesem Workflow wird zuerst ein Hotelzimmer (Database Connector First_Operation) gebucht und danach ein passender Flug (Database Connector Second_Operation).
Falls kein Hotelzimmer verfügbar ist, dann wird das Throw- Modul ausgeführt und löst damit einen Rollback der Transaktion aus.
Dann wird der Workflow Connector am Rollback- Ausgang ausgeführt und versendet eine Info-Mail an den Verantwortlichen.
Voraussetzungen
Sie können nur Transaktionen von Database Connectoren in einem Transaktions-Scope zusammenfassen, wenn die Konnektoren auf dieselbe Datenbank zugreifen!
So gehen Sie vor
-
Fügen Sie einen Transaktions-Scope in Ihren Technical Workflow ein.
-
Erstellen und konfigurieren Sie die Module in dem Transaktions-Scope.
-
Verbinden Sie das erste Modul im Transaktions-Scope mit dem Eingang des Transaktions-Scopes und das letzte Modul mit dem Ausgang des Transaktions-Scopes.
Transaktionsmodus aktivieren
-
Öffnen Sie das Kontextmenü eines Database Connectors und wählen Sie Transaktions-Marke setzen.
Aktivieren Sie den Transaktionsmodus bei allen Database Connectoren innerhalb des Transaktions-Scopes! Wenn der Transaktionsmodus nicht aktiviert ist, dann arbeiten die Systemkonnektoren wie gewohnt und die Transaktionen werden nicht zusammengefasst!
Timeout definieren
-
Doppelklicken Sie das TA-Symbol des Transaction Scope-Eingangs. Ein Dialog öffnet sich.
-
Geben Sie das Timeout ein.
-
Schließen Sie den Dialog mit OK.
-
Publizieren Sie den Workflow.
Refactoring: Technical Workflows mit Workflow Connectoren verbinden
Das Refactoring bietet Ihnen die Möglichkeit, die Struktur bestehender Technical Workflows nachträglich zu verbessern, ohne deren Verhalten zu ändern. So können Sie die Lesbarkeit und Wartbarkeit von Technical Workflows optimieren und damit den Aufwand für Fehleranalyse und funktionale Erweiterungen deutlich senken.
Beim Refactoring werden ausgewählte Module in einen neuen Workflow ausgelagert, beide Workflows werden durch einen Workflow Connector miteinander verknüpft. Falls Systemkonnektoren ausgelagert werden, dann erhalten diese einen Namenszusatz, damit der Name eindeutig bleibt.
|
Technical Workflows, die Systemkonnektoren enthalten, stehen immer in genau einem Workflow zur Verfügung, weil der Lizenzierungsmechanismus der Software die Nutzung eines Systemkonnektors nur in genau einem Workflow erlaubt. |
So gehen Sie vor
-
Öffnen Sie den Technical Workflow zum Bearbeiten.
-
Markieren Sie im Quell-Workflow alle Module, die in einen neuen Technical Workflow ausgelagert werden sollen.
-
Öffnen Sie das Kontextmenü und wählen Sie Durch Workflow Connector ersetzen. Der Assistent zum Anlegen eines neuen Workflow Connectors öffnet sich.
Siehe Workflow Connector. -
Benennen Sie den Workflow Connector und lassen Sie sich von dem Assistenten durch die Erzeugung des neuen Workflows und des Workflow Connectors führen.
Nach Beenden des Assistenten wird der Quell-Workflow angezeigt, in dem die ausgewählten Module durch einen Workflow Connector ersetzt wurden. Der neue Technical Workflow mit den ausgelagerten Modulen wurde in dasselbe Verzeichnis eingefügt.
Variablenübergabe bei verlinkten Technical Workflows konfigurieren
Verwendung
Sie können in jedem Technical Workflow definieren, ob bei einem Aufruf des Workflows alle oder nur ausgewählte Variablen an den Workflow übergeben werden sollen. Dabei legen Sie auch fest, ob der Workflow Variablen an den aufrufenden Workflow zurückgeben soll.
Mit dieser Funktion können Sie workflow-relevante Variablen kapseln und Fehler vermeiden, die durch die unkontrollierte Weitergabe von Variablen entstehen können.
Vorgehensweise
-
Workflow kapseln
Sie konfigurieren die Variablenübergabe am Workflow in der Palette Variablen.
Siehe Bei Sprung in diesen WorkflowFür Workflows, die in der INUBIT-Version >= 5.3 angelegt wurden, gilt: Die Variablenübergabe bei verlinkten Workflows ist standardmäßig eingeschränkt, d.h. es werden nur Variablen übergeben bzw. übernommen, die explizit als Eingabe-/Ausgabevariablen definiert sind.
Für Workflows, die in INUBIT-Versionen < 5.3 angelegt wurden, gilt: Die Variablenübergabe ist nicht eingeschränkt, d.h. alle Variablen werden übergeben und übernommen.
-
Eingabe- und Ausgabevariablen definieren
Wenn Sie den Workflow gekapselt haben, müssen Sie zusätzlich bei allen Modulvariablen und selbst definierten Variablen angeben, ob diese Workflow-Eingabe- oder Ausgabevariablen oder beides sind:-
Workflow-Eingabevariablen sind Variablen, die der Subworkflow zur Ausführung benötigt. Diese Variablen müssen von dem aufrufenden Workflow bereitgestellt und übergeben werden.
-
Workflow-Ausgabevariablen sind Variablen, die der Subworkflow an den aufrufenden Workflow zurückgibt. Ausgabevariablen werden nur zurückgegeben, wenn der Subworkflow synchron aufgerufen wird.
Siehe Dialogbeschreibungen Workflow Connector.
-
-
Variablenübergabe konfigurieren
Sie legen am Workflow Connector des aufrufenden Workflows fest, wie die Werte für die Workflow-Eingabevariablen an den Subworkflow übergeben werden und wie der Wert der Ausgabevariable in den aufrufenden Workflow übernommen wird.
Bei Aufruf des Subworkflows wird überprüft, ob alle benötigten Eingabevariablen übergeben wurden. Wenn dies nicht der Fall ist, wird eine entsprechende Fehlermeldung ausgegeben.
Voraussetzungen
Mindestens zwei miteinander verlinkte Workflows sind bereits vorhanden.
So gehen Sie vor
-
Öffnen Sie den Subworkflow zum Bearbeiten.
Beginnen Sie grundsätzlich im untersten Workflow, die Variablenübergabe zu definieren. Der unterste Workflow ist derjenige, welcher von einem oder mehreren Workflows aufgerufen wird, selbst aber keine weiteren Workflows aufruft.
Workflow kapseln
-
Öffnen Sie die Palette Variablen und stellen Sie sicher, dass im Bereich Bei Sprung in diesen Workflow die Option Nur Eingabe/Ausgabe-Variablen verwenden markiert ist.
-
Definieren Sie eine Variable oder bearbeiten Sie eine vorhandene.
Siehe Variablen definieren.Funktion der Variablen definieren
-
Zeigen Sie im Dialog Variablendefinition das Register Übergabe bei Workflow-Aufruf an.
-
Legen Sie fest, ob die Variable eine Workflow-Eingabevariable, eine Workflow-Ausgabevariable oder beides ist.
Siehe oben: Eingabe- und Ausgabevariablen definieren -
Geben Sie einen Standardwert (Datentyp string oder XML) an, wenn es sich um eine Workflow-Eingabevariable handelt. Der Standardwert wird genutzt, falls die Variable ohne Wert übergeben wird:
-
Klicken Sie auf OK, um den Dialog zu schließen.
In der Palette Variablen zeigt ein Symbol an der Variablen deren Funktion an. -
Publizieren Sie den Workflow.
Übergabe am Workflow Connector konfigurieren
-
Öffnen Sie den aufrufenden Workflow zum Bearbeiten. Das V-Symbol Variablen-Mapping am Workflow Connector ist nun farbig markiert.
-
Doppelklicken Sie auf das V-Symbol:
Der Dialog öffnet sich:
In diesem Dialog wird eine Mapping-Zeile für jede Variable angezeigt, die als Eingabe- oder Ausgabevariable für den aufzurufenden Workflow definiert ist. Diese Zeilen sind durch eine andere Hintergrundfarbe gekennzeichnet.
Für eine Eingabevariable können Sie im Bereich Quelle alle Arten von Mappingquellen auswählen. Wenn die Eingabevariable einen Standardwert hat, ist dieser standardmäßig voreingestellt. Anderenfalls wird der Eintrag in der Spalte Quelle rot markiert und zeigt an, dass der erwarteten Eingabevariablen im aktuellen Workflow noch keine Workflow-Variable zugeordnet ist.
Klicken Sie in die Zeile mit der gewünschten Abbildungsregel, um eine Quelle zuzuweisen.
Für eine Ausgabevariable können Sie im Bereich Quelle nur eine Variable auswählen.
Standardmäßig ist der Eintrag “–” aus dem Dropdown-Menü voreingestellt, um anzuzeigen, dass der Wert der Ausgangsvariablen im aufrufenden Workflow nicht benötigt wird.Im Bereich Verhalten bzgl. Eingabe/Ausgabe-Variablen können Sie auf den Button 1:1 Abbildung erzeugen klicken, um eine gleichnamige Quellvariable für die Eingabe-/Ausgabe-Variablen des verlinkten Workflows anzulegen.
-
Schließen Sie den Dialog mit OK.
XML-Schemas aus Repository am Workflow referenzieren
Sie können ein oder mehrere XML-Schemas aus dem Repository in Technical Workflows referenzieren, um z.B. die Struktur von XML-Variablen zu definieren.
Bei Einsatz von Tagging
Wenn am Workflow ein Tag aktiviert ist, dann wird dasjenige Schema genutzt, welches mit dem entsprechenden Tag gekennzeichnet ist.
Wenn kein aktives Tag vorhanden ist, wird die HEAD-Version der XML-Schemas genutzt.
Schemas ein- und auschecken
Sie können die XML-Schemas direkt am Workflow bearbeiten. Dabei wird eine Kopie des XML-Schemas erstellt.
Nach dem Bearbeiten können Sie wählen, ob die Änderungen in das Repository zurückgespeichert werden und damit global verfügbar sein sollen oder ob das geänderte Schema nur lokal von dem aktuellen Workflow verwendet werden soll:
-
Änderungen im XML Schema global zur Verfügung stellen
Checken Sie das XML Schema nach dem Bearbeiten wieder in das Repository ein. -
Geändertes XML Schema lokal verwenden
Checken Sie das XML Schema nicht ein. Der Workflow verwendet die lokale Kopie, bis Sie diese entfernen und durch die Referenz zum Schema im Repository ersetzen.
So gehen Sie vor
-
Öffnen Sie den Workflow zum Bearbeiten.
-
Öffnen Sie in der Sidebar die Palette Schemas.
-
Laden Sie das XML Schema aus dem Repository:
-
Klicken Sie auf den
-Button.
Ein Menü öffnet sich. -
Wählen Sie Öffnen von > Repository. Der Repository Explorer öffnet sich.
-
Navigieren Sie zu dem XML Schema und laden Sie es. Das XML Schema wird angezeigt.
-
-
Klicken Sie auf Bearbeiten.
Die aktuelle Version des XML-Schemas und Buttons zum Einchecken bzw. Verwerfen der Änderungen werden angezeigt:
Bearbeiten Sie das XML Schema.
-
Um das XML Schema ins Repository zurückzuschreiben, klicken Sie auf Einchecken.
-
Um die Änderungen zu verwerfen und das Original-XML Schema aus dem Repository erneut zu laden, klicken Sie auf Verwerfen. Nach einer Sicherheitsabfrage wird die aktuell angezeigte Datei mit der Originalversion aus dem Repository überschrieben.
-
Web Services
Aufruf
INUBIT Workbench > Designer > Sidebar > Web Services-Palette
| Option | Erläuterung |
|---|---|
PartnerLinks |
PartnerLinks enthalten die in einen Geschäftsprozess involvierten Webservices. Ein PartnerLink besteht daher immer aus einem lokalen Endpunkt und einem Partner-Endpunkt: Lokale Endpunkte sind jeweils durch die Receive-Module bzw. die Input Web Services Connectoren repräsentiert. Partner-Endpunkte sind die Web Services, die von Invoke-Modulen oder Output Web Services Connectoren aufgerufen werden. |
WSDLs |
Die WSDL-Datei fasst die Operationen, Daten und Austauschprotokolle zusammen, die der Web Service anbietet.
Diese Informationen sind maschinenlesbar. |
CorrelationSets |
Mithilfe des Correlation Mechanismus können bei asynchronen Web Service-Aufrufen die Antwortnachrichten derjenigen Workflow-Instanz zugeordnet werden, welche die Anfrage asynchron verschickt hat. |
Properties |
Properties sind Teile eines CorrelationSets und enthalten innerhalb eines laufenden Workflows eindeutige Werte.
Die Werte können z.B. Auftrags- oder Kundennummern sein. |
PropertyAliases |
Ein PropertyAlias definiert, wie eine Property mit einem konkreten Wert belegt wird. Zum Befüllen können Sie z.B. eine WSDL-Nachricht und einen darauf anzuwendenden XPath angeben. |
Symbole in Technical Workflows und im Verzeichnisbaum
Symbole in Technical Workflows
| Symbol | Explanation | Siehe |
|---|---|---|
|
Der Systemkonnektor ist als Output-Konnektor konfiguriert. |
|
|
Der Systemkonnektor ist als Input-Konnektor konfiguriert. |
|
|
Der Systemkonnektor ist als Medium-Konnektor konfiguriert. |
|
|
Commented System Connector |
|
|
Das Baustellen-Symbol signalisiert Änderungen an miteinander verlinkten BPDs und TWFs. |
|
|
Das Modul ist ein Ad-hoc-Prozessstarter. |
|
|
Ein Transaktionsmarker an einem Systemkonnektor signalisiert, dass der Systemkonnektor im Transaktionsmodus ausgeführt wird. |
|
|
Fehlende Konfiguration am Workflow Connector. Der verlinkte Workflow erwartet eine Eingabevariable. Diese Eingabevariable muss noch einer Variablen des angezeigten Workflows zugeordnet werden. |
|
|
Wenn das Symbol dauerhaft am Modul angezeigt wird, dann ist das Variablen-Mapping konfiguriert. |
|
|
Der Workflow Connector befindet sich im asynchronen Verarbeitungsmodus. |
|
|
An dem Modul ist die Fehlerunterdrückung aktiviert. |
|
|
Das Modul ist gesperrt. Sie können es weder bearbeiten noch dessen Eigenschaften anzeigen. Ein Modul wird als Gesperrt angezeigt, wenn es einer Benutzergruppe gehört, die für den aktuell angemeldeten Benutzer nicht sichtbar ist. Für Benutzer sind nur Module aus der eigenen Gruppe und der direkt übergeordneten Gruppe sichtbar. Diese Situation kann z.B. so entstehen:
|
|
|
Das Scheduler Icon ist sichtbar, wenn der Systemkonnektor
|
|
|
Ein Metadatenwert vom Typ Externes Dokument wird als Icon in der linken unteren Ecke des Elements angezeigt. |
