Business Process Model and Notation (BPMN) 2.0 bietet eine standardisierte Sprache zur Beschreibung von Workflows. Während interne Prozessschritte einfach zu handhaben sind, erfordert die Integration von Entitäten außerhalb der Organisation spezifische Modellierungstechniken. Externe Teilnehmer umfassen Kunden, Partner, Drittsysteme oder behördliche Stellen. Die korrekte Darstellung dieser Interaktionen gewährleistet eine genaue Prozessausführung und klare Kommunikation. Dieser Leitfaden erläutert die Mechanismen zur Verbindung externer Teilnehmer innerhalb der BPMN 2.0-Spezifikation.
Verständnis der Grenzen 🛑
Die grundlegende Herausforderung bei der Modellierung externer Interaktionen liegt in der Definition der Prozessgrenze. In BPMN stellt ein Pooleinen Teilnehmer dar. Ein Prozess verfügt typischerweise über einen einzigen Pool, der die Organisation darstellt, die den Workflow ausführt. Alle Entitäten außerhalb dieses Pools gelten als extern.
- Interne Pools:Enthalten die Aktivitäten, die der Organisation gehören.
- Externe Pools:Stellen Teilnehmer dar, die mit dem Prozess interagieren, aber nicht die interne Logik steuern.
Wenn Sie einen Prozess mit externen Partnern modellieren, müssen Sie zwischen dem, was innerhalb der Organisation geschieht, und dem, was in der Außenwelt geschieht, unterscheiden. Diese Unterscheidung bestimmt die Art des Flows, der zur Verbindung von Aktivitäten verwendet wird.
Nachrichtenflüsse im Vergleich zu Ablaufflüssen 💬
Eine der entscheidenden Unterscheidungen in BPMN ist der Unterschied zwischen Ablaufflüssen und Nachrichtenflüssen. Die Verwechslung dieser beiden kann zu Modellen führen, die technisch ungültig oder logisch mehrdeutig sind.
- Ablaufflüsse:Stellen die Ausführungsreihenfolge innerhalbeines einzelnen Teilnehmers (innerhalb eines Pools) dar. Es handelt sich um durchgezogene Pfeile.
- Nachrichtenflüsse:Stellen den Austausch von Informationen zwischenzwei Teilnehmern (zwischen zwei Pools) dar. Es handelt sich um gestrichelte Pfeile.
Bei der Verbindung externer Teilnehmer müssen Sie Nachrichtenflüsse verwenden. Die Verwendung eines Ablaufflusses zwischen zwei Pools ist ein Modellierungsfehler. Ein Ablauffluss impliziert Kontrolle, was bedeutet, dass die vorhergehende Aktivität die nachfolgende direkt auslöst. Ein Nachrichtenfluss impliziert Kommunikation, bei der eine Partei eine Nachricht sendet und auf eine Antwort oder Bestätigung wartet.
Visuelle Darstellung
| Flussart | Richtung | Linienstil | Verwendungszweck |
|---|---|---|---|
| Ablauffluss | Intern | Durchgezogene Linie | Aktivität zu Aktivität innerhalb eines Pools |
| Nachrichtenfluss | Extern | Punktierte Linie | Pool zu Pool (Teilnehmer zu Teilnehmer) |
| Assoziation | Intern/Extern | Punktierte Linie | Verknüpfen von Datenobjekten oder Anmerkungen |
Ereignistypen für externe Kommunikation 📨
Ereignisse sind die primäre Methode zur Initiierung oder Beendigung der Interaktion mit externen Teilnehmern. Sie können diese Interaktionen basierend auf Zeitpunkt und Absicht kategorisieren.
Startereignisse
Ein Startereignis markiert den Beginn eines Prozesses. Wenn ein externer Teilnehmer einen Prozess auslöst, ist das Startereignis in der Regel einNachrichten-Startereignis.
- Dieses Ereignis zeigt an, dass der Prozess auf eine eingehende Nachricht wartet, bevor er fortfährt.
- Es befindet sich am Anfang des Pools.
- Der eingehende Nachrichtenfluss ist direkt mit diesem Ereignis verbunden.
Zum Beispiel löst eine von einem Kunden gesendete Auftragsbestätigung einen Erfüllungsprozess aus. Der Prozess existiert erst, wenn die Nachricht eintrifft.
Mittlere Ereignisse
Mittlere Ereignisse treten während des Lebenszyklus des Prozesses auf. Sie sind nützlich, um Nachrichten zu erfassen, während der Prozess aktiv ist.
- Mittleres empfangendes Nachrichtenereignis: Der Prozess pausiert hier, bis eine bestimmte Nachricht empfangen wird. Dies ist üblich für asynchrone Aktualisierungen, wie beispielsweise eine Zahlungsbestätigung von einem Bankensystem.
- Mittleres sendendes Nachrichtenereignis: Der Prozess sendet hier eine Nachricht. Dies wird verwendet, wenn der Prozess eine externe Partei über eine Statusänderung informieren muss.
Randereignisse
Randereignisse sind an der Grenze einer Aktivität angebracht. Sie ermöglichen es, Ausnahmen oder Zeitüberschreitungen zu behandeln, ohne die Hauptablaufstruktur sofort zu stoppen.
- Nachrichtenrandereignis: Wenn eine externe Partei eine Stornierungsanfrage sendet, während der Prozess läuft, erfasst dieses Ereignis diese.
- Dies ermöglicht es dem Prozess, auf externe Störungen zu reagieren, ohne die aktuelle Aktivität aufzugeben.
Gateways und Entscheidungsfindung 🔀
Externe Teilnehmer bringen oft Komplexität durch Entscheidungspunkte mit sich. Ein Prozess könnte aufgrund einer Antwort von einer externen Quelle verzweigen müssen. Gateways verwalten diese Pfade.
XOR-Gateways
Ein Exklusiver Gateway (XOR) wählt einen Pfad aus mehreren Optionen aus. Im Kontext externer Interaktionen wird dies oft nach Erhalt einer Antwort verwendet.
- Wenn das externe System eine „Erfolg“-Nachricht zurückgibt, folgt der Prozess einem Pfad.
- Wenn die Nachricht „Fehler“ anzeigt, folgt der Prozess einem anderen Pfad.
- Der eingehende Nachrichtenfluss muss mit einem Gateway oder Ereignis verbunden sein, das der Entscheidung vorangeht.
UND-Gateways
Ein Inklusiver Gateway ermöglicht es, mehrere Pfade gleichzeitig zu nehmen, wenn die Bedingungen erfüllt sind. Bei Nachrichtenflüssen ist jedoch die Synchronisation entscheidend.
- Ein Verbindungs-Gateway wartet, bis alle eingehenden Pfade abgeschlossen sind.
- Bei der Kommunikation mit externen Partnern sind Verzögerungen üblich. Sie müssen sicherstellen, dass das Gateway auf die notwendigen Nachrichten wartet, bevor es fortfährt.
Umgang mit Asynchronität ⏳
Externe Interaktionen sind selten sofortig. Systeme können offline sein oder Antworten können Zeit in Anspruch nehmen. BPMN 2.0 behandelt dies über asynchrone Verhaltensweisen.
- Nicht-blockierend: Wenn ein Prozess eine Nachricht sendet, wartet er nicht auf eine sofortige Antwort, es sei denn, dies ist ausdrücklich modelliert.
- Nachrichtenbeibehaltung: Die Prozessmaschine speichert die Nachricht, bis sie empfangen wurde.
- Zeitüberschreitungen: Wenn innerhalb einer festgelegten Zeit keine Antwort empfangen wird, kann ein Zeitverzögerungs-Mittelpunkt-Ereignis eine Eskalation auslösen.
Dies ist entscheidend für langlaufende Prozesse. Wenn ein Prozess synchron auf jeden externen Aufruf wartete, würde er Ressourcen ineffizient verbrauchen. Asynchrone Nachrichtenübertragung ermöglicht es dem Prozess, zu anderen Aufgaben überzugehen, während er wartet.
Datenaustausch und Payloads 📦
Nachrichten sind nicht nur Signale; sie tragen Daten. In BPMN wird Daten durchDatenobjekte und Daten-Eingaben/Ausgaben.
- Datenobjekte:Visuelle Symbole, die Informationen darstellen, die von Aktivitäten verwendet oder erzeugt werden.
- Daten-Eingabe:Informationen, die benötigt werden, um eine Aktivität zu starten.
- Daten-Ausgabe: Information, die durch eine Aktivität erzeugt wird.
Beim Verbinden mit externen Partnern ist der Inhalt der Nachricht entscheidend. Sie sollten den erwarteten Datenpayload in der Nachrichtenspezifikation dokumentieren.
| Komponente | Funktion | Externe Relevanz |
|---|---|---|
| Nachricht | Behälter für Daten | Definiert den Schnittstellenvertrag |
| Datenobjekt | Spezifischer Datenbestandteil | Zeigt an, was übertragen wird |
| Assoziation | Verbindet Objekt mit Element | Klärt die Richtung des Datenflusses |
Häufige Fehler, die vermieden werden sollten ⚠️
Die Modellierung externer Partner bringt spezifische Risiken mit sich. Häufige Fehler können ein Prozessmodell ungültig oder schwer ausführbar machen.
- Verbindung von Pools mit Sequenzflüssen: Wie erwähnt, ist dies ungültig. Verwenden Sie immer Nachrichtenflüsse für die Kommunikation zwischen Pools.
- Fehlende Nachrichten-Startereignisse: Wenn ein Prozess über externe Eingabe startet, muss er ein Nachrichten-Startereignis verwenden. Ein allgemeines Startereignis bedeutet, dass der Prozess intern startet.
- Unerreichbare Pfade: Stellen Sie sicher, dass jeder Pfad mit externer Eingabe eine entsprechende Antwort hat. Deadlocks treten auf, wenn ein Prozess auf eine Nachricht wartet, die niemals eingeht.
- Ignorieren der Fehlerbehandlung: Externe Systeme fallen aus. Modellieren Sie immer Fehlerpfade mit Grenzereignissen oder Fehlerendereignissen.
- Überkomplizierung von Lanes: Erstellen Sie keine Lane für jedes externe Element. Behalten Sie den Pool für das externe Element bei und verwenden Sie Lanes nur für interne Rollen innerhalb dieses Elements, falls erforderlich.
Best Practices für Klarheit ✅
Um ein Modell aufrechtzuerhalten, das sowohl für technische Teams als auch für Geschäftssachverhalte verständlich ist, befolgen Sie diese Richtlinien.
- Beschreiben Sie eindeutig: Benennen Sie Message Flows explizit (z. B. „Bestätigungsbestätigung“, „Statusaktualisierung“).
- Verwenden Sie Zusammenarbeitsschemata: Bei komplexen Interaktionen zwischen mehreren Parteien ist ein Zusammenarbeitsschema oft übersichtlicher als ein einzelner großer Pool.
- Trennen Sie Anliegen: Modellieren Sie die interne Prozesslogik getrennt von der externen Schnittstellenlogik, wo immer möglich.
- Dokumentieren Sie Schnittstellen: Hängen Sie Anmerkungen oder separate technische Spezifikationen für das Datenbankschema an, das in Nachrichten verwendet wird.
- Konsistente Gestaltung: Verwenden Sie für alle Message Flows dieselbe Linienart und Farbcodierung, damit sie sich von Sequence Flows abheben.
Der Lebenszyklus einer externen Interaktion 🔁
Das Verständnis des Lebenszyklus hilft dabei, die richtigen Elemente zu platzieren. Eine typische Interaktion verläuft wie folgt:
- Initiierung: Eine externe Partei sendet eine Nachricht. Dies löst ein Message Start Event aus.
- Verarbeitung: Interne Aktivitäten verarbeiten die Daten. Zwischenereignisse können auftreten, wenn weitere externe Daten benötigt werden.
- Antwort: Der Prozess sendet eine Nachricht zurück an die externe Partei.
- Abschluss: Ein End-Ereignis markiert die erfolgreiche Beendigung des Prozesses.
Wenn der Prozess abläuft oder einen Fehler erhält, endet der Lebenszyklus anders, oft erfordert dies einen Kompensations- oder Stornofluss.
Fazit zur externen Anbindung 🎯
Die Modellierung externer Teilnehmer erfordert Präzision. Die Unterscheidung zwischen interner Steuerung und externer Kommunikation ist die Grundlage gültiger BPMN 2.0-Diagramme. Durch die korrekte Anwendung von Message Flows, geeigneten Ereignissen und klaren Grenzdefinitionen erstellen Sie eine Bauplan, der die Geschäftsrealität genau widerspiegelt.
Sorgfalt in diesen Bereichen verhindert Ausführungsfehler und stellt sicher, dass alle Stakeholder verstehen, wie das System mit der weiten Welt interagiert. Ziel ist ein Modell, das nicht nur visuell korrekt ist, sondern auch semantisch robust.
