Der Worker-Kontext

Ein Worker kann im backend oder im frontend (Browser) ausgeführt werden. Über die WorkerGroupId kann der Modellierer den Kontext steuern, in dem ein Worker ausgeführt werden soll.

Standardmäßig ist die WorkerGroupId eines Workers leer.

Die Ausführung erfolgt abhängig vom Kontext des vorhergehenden Workers.

Gibt es keinen Vorgänger, so erfolgt die Ausführung bei Leereintrag im frontend (Browser).

Sobald über den Eintrag backend in das Feld WorkerGroupId der Kontext der Workerausführung verändert wird, wird der nachfolgende Worker mit leerem Eintrag im selben Kontext (backend) ausgeführt.

Erst wenn in einem der nachfolgenden Worker unter WorkerGroupId aktiv frontend eingetragen wird, werden die weiteren Worker mit leerer WorkerGroupId wieder im frontend ausgeführt.

Auch das EPK-Element E-Mail ist ein Worker. Der E-Mail-Worker wird immer im aktuellen Kontext ausgeführt.

In der Regel werden Worker im frontend ausgeführt. Das Abändern des Ausführungskontextes kann aber hilfreich sein, wenn Sie beispielsweise rechenintensive Bearbeitungsschritte auf den Server verlagern möchten.

Sonderfälle

Möchten Sie den Kontext verändern, in dem ein Worker ausgeführt wird, beachten Sie die folgenden Sonderfälle:

  • Funktion mit Formular
  • Integration
  • AND-Verzweigungen

Funktion mit Formular

Eine Funktion mit Formular wird immer im Kontext frontend ausgeführt.
Ein nachfolgender Worker mit leerer WorkerGroupId wird daher ebenfalls im frontend ausgeführt.

Nach einer Integration

Prozessschritte, die innerhalb einer Integration modelliert sind, werden immer im backend ausgeführt.
Ein Worker, der auf eine Integration folgt, und der keinen Eintrag unter WorkerGroupId erhält, wird daher ebenfalls im backend ausgeführt.

Innerhalb einer Integration

Eine Integration wird verwendet, wenn man Externe Datenquellen anbinden möchte. In der Regel werden Daten entweder aus BPaaS heraus an das Fremdsystem übertragen oder aus dem Fremdsystem gezogen, um sie in BPaaS weiterverarbeiten zu können.

Daten, die per SAP-Restifier oder REST-Element ermittelt werden, werden im backend verarbeitet.

Ein Worker, der nach einem Restifier oder REST-Element Daten verarbeiten soll, muss daher auch im backend ausgeführt werden.

Achten Sie darauf, dass in Workern, die nach einem Adapter modelliert werden, nicht explizit frontend als WorkerGroupId eingetragen ist. Dies führt bei Ausführung des Modells zu einer Fehlermeldung (weitere Informationen erhalten Sie im Support-Bereich).

AND-Verzweigungen

Eine AND-Verzweigung wird immer backendseitig gestartet. Alle Worker, die direkt nach der öffnenden AND-Klammer folgen, werden also ebenfalls im Kontext backend ausgeführt. Wird in einem Worker, der auf ein öffnendes AND folgt, die WorkerGroupId frontend eingetragen, stoppt der Prozess an dieser Stelle: Die Ausführung des Workers muss dann manuell über die Liste Ihre nächsten Arbeitsschritte angestoßen werden.

Beispiel: Workerausführung in einer AND-Verzweigung

In unserem Beispielprozess befindet sich der erste Worker noch vor der AND-Verzweigung. Da er auf ein Formular folgt und unter WorkerGroupId nichts eingetragen wurde, wird Worker 1 automatisch im frontend ausgeführt.

Im Anschluss bewirkt der öffnende AND-Konnektor den Kontextwechsel auf backend:

Worker 2 folgt direkt auf den AND-Konnektor und wird daher ebenfalls im Kontext backend ausgeführt:

Worker 3 wird erst nach dem Speichern von Formular 3 ausgeführt. Da das Formular den Kontext auf frontend setzt, wird auch Worker 3 im frontend ausgeführt:

Worker 4 soll im frontend ausgeführt werden.

Da er aber direkt auf den AND-Konnektor folgt, muss dafür der Kontext verändert werden. Worker 4 erhält also im Feld WorkerGroupId den Eintrag frontend.

Durch den Kontextwechsel stoppt der Prozess bei der Ausführung im Schritt Dritter Strang - Schritt 1:

Die Ausführung von Worker 4 muss manuell angestoßen werden, daher erscheint der Prozessschritt Dritter Strang - Schritt 1 in der Liste Ihre nächsten Arbeitsschritte.
On this Page:
Related Pages:
Related Documentation:

  • No labels