Ereignisunterprozess

Überblick

Mit einem Ereignisunterprozess können Sie auf Ereignisse im Prozess- oder Unterprozess-Scope reagieren. Es besteht keine Verbindung zum Haupt-Sequence-Flow.

Stattdessen löst die Engine sie aus, wenn ein konfiguriertes Startereignis auftritt, während der umgebende Scope aktiv ist.

Verwenden Sie einen Ereignisunterprozess, wenn Sie Folgendes möchten:

• Zentralisieren Sie die zugehörige Error-Behandlungslogik.
• Vermeiden Sie duplizierte Boundary-Error-Ereignisse über mehrere Aufgaben hinweg.
• Steuern Sie das Verhalten im Prozess- oder Unterprozess-Scope.
• Reagieren Sie zur Runtime auf externe Nachrichten.
• Führen Sie Wiederherstellungs-, Protokollierungs- oder Benachrichtigungslogik konsistent aus.

In Maestro kann ein Ereignisunterprozess beginnen mit:

• einem Startereignis vom Typ Error
• einem Startereignis vom Typ Nachricht

Fehlerstartereignis

Ein Error-Startereignis löst den Ereignisunterprozess aus, wenn ein BPMN-Error auftritt und der Error-Code übereinstimmt, oder wenn das Ereignis als Catch-All konfiguriert ist.

Wenn ein BPMN-Error ausgelöst wird, wertet die Engine übereinstimmende Ereignisunterprozesse im selben Scope aus, bevor sie Boundary-Error-Ereignisse auswertet. Diese Auswertungsreihenfolge räumt dem Ereignisunterprozess Priorität ein.

Ausführungsverhalten

Ein Error-Startereignis wirkt immer unterbrechend.

Wenn der Error auftritt, führt die Engine folgende Schritte aus:

• Löst den Ereignisunterprozess aus.
• Bricht den einschließenden Prozess oder Unterprozess-Scope ab.
• Stoppt alle aktiven Pfade innerhalb dieses Scopes.

Verwenden Sie ein Error-Startereignis, wenn der Error die aktuelle Ausführung ungültig macht.

Beispiele aus der Praxis:

• Eine Zahlungsautorisierung schlägt aufgrund der Betrugserkennung fehl.
• Eine obligatorische Compliance-Validierung schlägt während des Onboardings fehl.
• Eine kritische Systemabhängigkeit ist nicht verfügbar.

Error-Behandlung ohne und mit einem Ereignisunterprozess

Ohne einen Ereignisunterprozess	Mit einem Ereignisunterprozess
Sie hängen Boundary-Error-Ereignisse an einzelne Aufgaben an.	Sie definieren einen Ereignisunterprozess im Prozess- oder Unterprozess-Scope.
Sie duplizieren häufig eine ähnliche Error-Logik über mehrere Aufgaben hinweg.	Sie zentralisieren die zugehörige Error-Behandlungslogik an einem einzigen Ort.
Jede Aufgabe steuert ihre eigene Error-Behandlung.	Der Scope steuert die Error-Behandlung für alle Aufgaben darin.
Die Wartung wird schwieriger, je größer das Modell wird.	Die Wartung wird einfacher, da Sie die Error-Logik an einem Ort aktualisieren.

Auswirkungen auf vorhandene Modelle

Die Engine ändert das Verhalten nur, wenn Sie demselben Scope einen Ereignisunterprozess hinzufügen.

• Modelle, die nur Boundary-Error-Ereignisse verwenden, verhalten sich weiterhin wie zuvor.
• Wenn Sie einen Ereignisunterprozess hinzufügen, behandelt dieser generische Error, die Boundary-Error-Ereignisse im selben Scope nicht abfangen.
• Wenn kein Boundary-Error-Ereignis mit einem ausgelösten Error übereinstimmt, wertet die Engine den Ereignisunterprozess aus.

Konfigurieren Sie nicht sowohl ein Boundary-Error-Ereignis als auch einen Ereignis-Unterprozess, um denselben Error-Verweis innerhalb desselben Scope zu behandeln.

Konfigurationsregeln

Für einen bestimmten Scope (Prozess oder Unterprozess):

• Verwenden Sie nur einen Ereignisunterprozess pro Error-Code.
• Verwenden Sie nur einen Catch-all-Ereignisunterprozess.

Für eine bestimmte Aufgabe:

• Verwenden Sie nur ein Boundary-Error-Ereignis pro Error-Code.
• Verwenden Sie nur ein Catch-all-Boundary-Error-Ereignis.

Nachrichtenstartereignis

Ein Nachrichtenstartereignis löst den Ereignisunterprozess aus, wenn die Engine die konfigurierte Nachricht erhält, während der umgebende Scope aktiv ist.

Ausführungsverhalten

Die Engine hört auf die konfigurierte Nachricht, während der umgebende Scope aktiv ist.Beim Empfang der Nachricht wird der Ereignisunterprozess gemäß seiner unterbrechenden oder nicht unterbrechenden Konfiguration ausgelöst.

Nachrichtenstartereignisse überschreiben andere Nachrichtenereignisse nicht oder haben keine Priorität vor ihnen. Jedes Nachrichtenereignis reagiert unabhängig basierend auf seinem Scope und seiner Konfiguration.

Behandlung von Nachrichten ohne und mit einem Ereignisunterprozess

Ohne einen Ereignisunterprozess	Mit einem Ereignisunterprozess
Sie modellieren die Nachrichtenbehandlung innerhalb des Haupt-Sequenz-Flows.	Sie definieren einen Ereignisunterprozess im Prozess- oder Unterprozess-Scope.
Sie müssen den Hauptflow über Zwischenereignisse zum Nachrichtenempfang weiterleiten.	Die Engine hört auf die Nachricht, während der Scope aktiv ist.
Der Hauptprozess muss explizit das Nachrichtenereignis erreichen, um darauf zu reagieren.	Der Ereignisunterprozess kann jederzeit auslösen, während der Scope aktiv ist.
Die Logik zur Nachrichtenbehandlung koppelt sich eng an die Hauptflowstruktur.	Die Logik der Nachrichtenbehandlung bleibt unabhängig vom Haupt-Sequence-Flow.
Das Ändern des Nachrichtenverhaltens kann eine Umstrukturierung des Hauptflows erfordern.	Sie können die Nachrichtenbehandlung aktualisieren, ohne den Hauptflow zu ändern.
Der Hauptflow pausiert immer beim Nachrichtenereignis.	Sie können das Nachrichtenstartereignis als unterbrechend oder nicht unterbrechend konfigurieren.

Auswirkungen auf vorhandene Modelle

Die Engine ändert das Verhalten nur, wenn Sie ein Nachrichtenstartereignis innerhalb eines Ereignisunterprozesses hinzufügen.

• Modelle, die keinen Ereignisunterprozess verwenden, verhalten sich weiterhin wie zuvor.
• Sobald Sie ein Nachrichtenstartereignis hinzugefügt haben, wartet die Engine auf die konfigurierte Nachricht, während der beigefügte Scope aktiv ist.
• Wenn Sie das Nachrichtenstartereignis als unterbrechend konfigurieren, bricht die Engine den einschließenden Scope ab, wenn sie die Nachricht erhält.
• Wenn Sie es als nicht unterbrechend konfigurieren, startet die Engine den Ereignisunterprozess parallel und lässt den Hauptflow fortfahren.

Konfigurieren Sie nicht mehrere Nachrichtenstartereignisse mit demselben Nachrichtenverweis im selben Scope.

Unterbrechen vs. Nicht-Unterbrechen

Sie können ein Nachrichtenstartereignis als unterbrechend oder nicht unterbrechend konfigurieren.

Unterbrechung

Wenn die Engine die Nachricht erhält, führt sie folgende Schritte aus:

• Löst den Ereignisunterprozess aus.
• Bricht den einschließenden Prozess oder Unterprozess-Scope ab.
• Stoppt alle aktiven Pfade innerhalb dieses Scopes.

Verwenden Sie ein unterbrechendes Nachrichtenstartereignis, wenn die Nachricht ein externes Signal darstellt, das die aktuelle Ausführung anhalten sollte.

Beispiele aus der Praxis:

• Ein Kunde storniert eine Bestellung während der Bearbeitung.
• Eine Regulierungsbehörde sendet eine Anweisung zum Anhalten der Verarbeitung.
• Ein übergeordnetes System sendet einen Beendigungsbefehl.

Nicht Unterbrechend

Wenn die Engine die Nachricht erhält, führt sie folgende Schritte aus:

• Löst den Ereignisunterprozess aus.
• Hält den umschließenden Scope aktiv.
• Führt den Ereignisunterprozess parallel aus.
• Ermöglicht die Fortsetzung des Hauptprozesses.

Verwenden Sie ein nicht unterbrechendes Nachrichtenstartereignis, wenn die Nachricht zusätzliche Logik triggern soll, ohne den Hauptfluss zu unterbrechen.

Beispiele aus der Praxis:

• Ein Kunde aktualisiert die Kontaktdaten, während das Onboarding fortgesetzt wird.
• Ein Partnersystem sendet zusätzliche Metadaten.
• Eine Benachrichtigung löst eine Prüfungsprotokollierung aus.