📝 Einleitung: Präzises Orchestrieren komplexer B2B-Interaktionen

.

1. Überblick über das Diagramm

Dies ist einBPMN-2.0-Choreografie-Diagramm mit dem Titel„Feature-Anfrage senden“, das die Interaktion zwischen zwei Teilnehmern modelliert:

Teilnehmer	Rolle
Teilnehmer 1 – Kunde	Initiiert Feature-Anfragen, prüft Alternativen, gibt die finale Zustimmung
Teilnehmer 2 – Lieferant	Erhält Anfragen, führt Machbarkeitsprüfungen durch, schlägt Alternativen vor, genehmigt formell und plant

Das Diagramm verweist zudem auf einSub-Choreografie: „Überprüfung alternativer Funktionen (MI)” — ein Multi-Instance-Teilprozess, der verwendet wird, wenn alternative Funktionen vorgeschlagen werden.

Ein Choreografiediagramm enthält Choreografie-Aufgaben, wobei jede Aufgabe mindestens zwei Teilnehmer haben muss: einen auslösenden und einen nicht auslösenden Teilnehmer [[4]].

---

2. Schritt-für-Schritt-Prozessübersicht

Phase 1: Initiierung

[Startereignis] → [Funktionsanfrage senden]

• Der Kunde sendet eine formale Funktionsanfrage an den Anbieter.

• Dies wird als Choreografie-Aufgabe mit einem Symbol für eine Nachrichtenumhüllung dargestellt, das die Kommunikation zwischen Teilnehmern anzeigt.

Phase 2: Machbarkeitsprüfung (XOR-Gateway)

[XOR-Gateway: Machbarkeitsprüfung?]
   ├── Unmöglich (Neueinreichung) → kehrt zurück zu Funktionsanfrage senden
   ├── Ja → fährt fort
   └── Alternative angeboten → löst Überprüfung alternativer Funktionen (MI) aus

• Der Anbieter prüft, ob die angeforderte Funktion machbar ist.

• Es gibt drei mögliche Ergebnisse, aber pro Instanz wird nur ein Pfad gewählt – dies ist das definierende Merkmal eines XOR-Gateways [[13]].

• Wenn unmöglichkehrt der Fluss zur Neueinreichung zurück (ein klassisches Wiederholungs-Muster).

• Wenn machbar („Ja“)fährt der Prozess zur Genehmigung durch den Anbieter fort.

• Wenn eine Alternative angeboten wirdwird ein Multi-Instance-Teilprozess ausgelöst.

Phase 3A: Weitere Informationen anfordern (paralleler/optionaler Zweig)

[Anfrage Informationen] ↔ [Anfrage Antwort]

• Jederzeit vor der endgültigen Genehmigung kann eine der Parteien zusätzliche Informationen anfordern.

• Dies wird als bidirektionale Choreografie-Aufgabe zwischen Anbieter und Kunde modelliert.

Phase 3B: Überprüfung alternativer Funktionen (Multi-Instance-Teilprozess)

[Überprüfung alternative Funktion III] ← MI-Marker
         ↓
[Auf Antwort warten] ← MI-Marker

• Wenn Alternativen vorgeschlagen werden, treten beide Parteien in eine Multi-Instance-Schleife — was bedeutet, dass der Überprüfungs- und Wartungszyklus für jede alternative Option wiederholt wird.

• Eine Multi-Instance-Aktivität wird für jedes Element in einer Sammlung einmal ausgeführt, ähnlich wie eine for-eachSchleife in der Programmierung [[8]].

• Der gestrichelte Pfeil vom Teilprozess zur Nachrichtenhülle zeigt den asynchronen Nachrichtenaustausch während jeder Iteration an.

Phase 4: Endgültige Annahme durch den Anbieter (XOR-Gateway)

[XOR-Gateway: Endgültige Annahme durch den Anbieter?]
   ├── Nein → Neu bewertet → Schleife zurück in den MI-Teilprozess
   └── Ja → Formell genehmigen & planen

• Nachdem alle Alternativen überprüft wurden (oder wenn keine Alternativen erforderlich waren), wird eine endgültige Entscheidungsschwelle erreicht.

• Bei Ablehnung tritt der Prozess erneut in die Multi-Instance-Überprüfungsschleife ein — was eine iterative Verfeinerung ermöglicht.

• Bei Annahme wechselt der Prozess zur formellen Genehmigung.

Phase 5: Formelle Genehmigung & Abschluss

[Formell genehmigen & planen] → [Bestätigungsnachricht] → [Endereignis]

• Der Anbieter genehmigt die Funktion formell und erstellt einen Implementierungsplan.

• Eine Bestätigungsnachricht wird an den Kunden.

• Der Kreis mit dickem Rand markiert das Endereignis, was den erfolgreichen Abschluss des Prozesses signalisiert.

Ausnahmepfad: Abbrechen

[XOR-Gateway] → [Anbieter, Funktionsanfrage stornieren] → [Endereignis beenden]

• In der Machbarkeitsprüfungsphase kann der Anbieter die Anfrage einseitig vollständig stornieren und den Prozess sofort beenden.

---

3. Veranschaulichung zentraler BPMN-Konzepte

3.1 Choreografie-Aufgaben vs. Kollaborationsaufgaben

Konzept	Beschreibung
Choreografie-Aufgabe	Zeigt Nachrichtenaustauschzwischen Teilnehmern; jede Aufgabe hat einen Initiator und einen Respondenten, die als farbige Bänder auf dem Aufgabenrechteck dargestellt sind
Kollaborationsdiagramm	Verwendet separate Pools/Spuren pro Teilnehmer; konzentriert sich auf die interne Prozesslogik
Wann Choreografie verwendet werden sollte	Wenn die Hauptfrage ist, wer mit wem kommuniziertanstatt interner Schritte

In einem Choreografiediagramm muss jede Aufgabe mindestens zwei Teilnehmer haben – einen Initiator und einen Nicht-Initiator [[4]].

3.2 XOR (Exklusive) Gateways

• Dargestellt durch ein Diamant-Symbol mit einem „X“ im Inneren.

• Nur ein ausgehender Pfad wird basierend auf einer Bedingung oder Entscheidung gewählt [[16]].

• Hier an drei kritischen Entscheidungspunkten verwendet: Machbarkeitsprüfung, endgültige Annahme durch den Anbieter und der Stornierungszweig.

• Best Practice: Beschriften Sie ausgehende Sequenzflüsse stets mit klaren Bedingungen [[14]].

3.3 Multi-Instance (MI)-Marker

• Dargestellt durch drei vertikale Linien (|||) am unteren Rand einer Aufgaben-/Subprozess-Box.

• Zeigt an, dass die Aktivität ausgeführt wirdmehrmals parallel oder sequenziellfür jedes Element in einer Sammlung [[9]].

• In diesem Diagramm gilt dies sowohl für „Alternative Funktion prüfen“ als auch für „Auf Antwort warten“, was bedeutet, dass jede Alternative den vollständigen Prüfungs-Antwort-Zyklus unabhängig durchläuft.

• Stellen Sie es sich als eine geschäftsprozess-level-foreach-Schleife [[12]].

3.4 Nachrichtenereignisse & Umschläge

• Die Umschlag-Symbole auf den Sequenzflüssen zeigen anasynchrone Nachrichtenübermittlungzwischen den Teilnehmern.

• Nachrichten wie „Angebot“, „Anfrage“ und „Bestätigung“ sind explizite Artefakte, die Organisationsgrenzen überschreiten.

• Die Darstellung von Nachrichtenumschlägen macht den Kommunikationsvertrag sichtbar und überprüfbar [[2]].

3.5 Beendigungsereignis mit Abbruch

• Der ausgefüllte schwarze Kreis mit dickem Rand nach „Funktion beantragen stornieren“ ist einBeendigungsereignis mit Abbruch.

• Es beendet sofortalleaktiven Prozessinstanzen, nicht nur den aktuellen Token – nützlich für harte Stornierungen.

---

4. Wann dieser Diagrammtyp verwendet werden sollte

✅ Ideale Anwendungsfälle

Szenario	Warum Choreografie passt
B2B-Integrationsprozesse	Zeigt deutlich Nachrichtenverträge zwischen Organisationen
Onboarding-Workflows für Anbieter-Kunden	Modelliert Verhandlungs-, Angebots- und Genehmigungszyklen
SLA-gesteuerte Serviceanfragen	Macht Antwortpflichten und Eskalationspfade explizit
Regulatorische/Compliance-Dokumentation	Stellt überprüfbare Nachweise darüber bereit, wer was und wann kommuniziert hat
Design der API-/Service-Orchestrierung	Entspricht direkt nachrichtenbasierten Microservice-Interaktionen
Vertragliche Workflow-Definition	Jede Choreographie-Aufgabe stellt eine verbindliche Kommunikationspflicht dar

❌ Wann Choreographie NICHT verwendet werden sollte

Szenario	Bessere Alternative
Interne abteilungsinterne Prozesse	Standard-BPMN-Kollaborationsdiagramm mit Bahnen
Rein sequenzielle Ein-Partei-Workflows	Einfaches BPMN-Prozessdiagramm
Daten-Transformations-Pipelines	DMN-Entscheidungstabellen oder ETL-Diagramme
Echtzeit-Event-Streaming-Architekturen	CQRS/Event-Storming-Notation

---

5. Richtlinien & Best Practices

Modellierungsrichtlinien

1. Auf einer Seite halten — Streben Sie nach Top-Level-Diagrammen, die auf einer Seite Platz finden; verschieben Sie Details in kollabierte Teilprozesse [[6]].

2. Beschriften Sie jeden Gateway-Ausgang — Lassen Sie XOR-Gateway-Zweige niemals unbeschriftet; Mehrdeutigkeit führt zu Implementierungsfehlern [[14]].

3. Verwenden Sie eine konsistente Reihenfolge der Teilnehmer — Halten Sie denselben Teilnehmer an derselben Bandposition (oben/unten) über alle Aufgaben hinweg für bessere Lesbarkeit [[2]].

4. Benennen Sie Choreographie-Aufgaben als Verbphrasen — z. B. „Feature-Anfrage senden“ statt „Feature-Anfrage“; die Aktion gehört dem Initiator.

5. Zeigen Sie Nachrichtennamen explizit an — Jeder Nachrichtenfluss sollte ein benanntes Artefakt tragen, damit Implementierer den Payload-Vertrag kennen [[2]].

6. Vermeiden Sie das Überschneiden von Nachrichtenflüssen — Ordnen Sie Aufgaben neu an, um visuelle Unordnung zu minimieren; sich kreuzende Linien erhöhen die kognitive Belastung erheblich.

Tipps zu Multi-Instance-Aktivitäten

7. Definieren Sie die Sammlung klar — Geben Sie in der Dokumentation oder Modell-Annotationen an, was die Iteration antreibt (z. B. „Liste alternativer Funktionen“).

8. Entscheiden Sie zwischen parallel und sequenziell — Parallele MI führt alle Instanzen gleichzeitig aus; sequenzielle MI verarbeitet sie nacheinander. Wählen Sie basierend auf Ressourcenbeschränkungen und Abhängigkeitsanforderungen [[12]].

9. Verwenden Sie Aufrufaktivitäten für komplexe MI-Körper — Wenn der Multi-Instance-Körper komplex ist, extrahieren Sie ihn für die Wartbarkeit in einen separaten aufrufbaren Unterprozess [[11]].

Tipps zu Gateways

10. XOR-Aufteilungen benötigen sich gegenseitig ausschließende Bedingungen — Stellen Sie sicher, dass nicht zwei ausgehende Bedingungen gleichzeitig wahr sein können; andernfalls liegt ein Modellierungsfehler vor [[18]].

11. XOR-Verbindungen synchronisieren Token — Eine XOR-Verbindung wartet auf genau ein eingehendes Token; das Eintreffen mehrerer Token bedeutet einen Modellierungsfehler [[17]].

12. Berücksichtigen Sie Standardflüsse — Bei aufspaltenden XOR-Gateways markieren Sie einen ausgehenden Fluss als Standard, um Fälle zu behandeln, in denen keine Bedingung zutrifft [[15]].

Allgemeine Tipps & Tricks

13. Validieren Sie mit Stakeholdern von beiden Seiten — Da Choreografien organisationsübergreifend sind, holen Sie die Freigabe von beiden — den Kunden- und Anbieter-Teams vor der Implementierung ein.

14. Mappen Sie frühzeitig auf konkrete Nachrichtenformate — Jede Nachrichten-Hülle sollte einem echten API-Aufruf, einer E-Mail-Vorlage oder einer EDI-Transaktion entsprechen.

15. Versionieren Sie Ihre Choreografie-Diagramme — B2B-Verträge entwickeln sich weiter; verfolgen Sie Diagrammversionen zusammen mit SLA-Dokumenten.

16. Verwenden Sie Choreografie-Konformitätsprüfungen — Es gibt Tools, um zu überprüfen, ob tatsächliche Implementierungen der modellierten Choreografie entsprechen [[5]].

17. Testen Sie Ausnahmepfade gründlich — Die Pfade „Unzulässig → Neu einreichen“ und „Neu bewertet → Zurück zum Loop“ sind dort, wo die meisten realen Fehler auftreten; stellen Sie sicher, dass sie ebenso rigoros getestet werden wie der Happy-Path.

18. Dokumentieren Sie Timeout-/Eskalationsregeln — Die MI-Aufgabe „Auf Antwort warten“ sollte definierte SLAs haben; dokumentieren Sie, was passiert, wenn niemals eine Antwort eintrifft.

---

6. Implementierungs-Mapping

BPMN-Element	Typische technische Implementierung
Feature-Anfrage senden	REST API POST / SOAP-Aufruf / E-Mail-Trigger
Prüfung der Machbarkeit XOR	Business-Regel-Engine / DMN-Entscheidungstabelle
Weitere Informationen anfordern	Bidirektionale Nachrichtenwarteschlange / Chat-Integration
Alternative Funktion prüfen (MI)	For-each-Schleife über das Array der Alternativen mit asynchronen Callbacks
Auf Antwort warten (MI)	Nachrichtenkorrelation mit Timeout-Handler pro Instanz
Endgültige Lieferantenakzeptanz XOR	Genehmigungs-Workflow-Engine / Menschliche Aufgaben-System
Formell genehmigen und planen	ERP/WMS-Integration + Benachrichtigungsversand
Bestätigungsnachricht	Webhook / E-Mail / Push-Benachrichtigung
Abbrechen (beenden)	Prozessabbruch-API + Kompensationslogik

---

7. Häufige Fallstricke, die vermieden werden sollten

Fallstrick	Folge	Vermeidung
Fehlender Standardfluss bei XOR	Prozess hängt, wenn keine Bedingung zutrifft	Immer einen Standard-Ausgangssequenzfluss definieren [[15]]
Unbeschriftete MI-Sammlung	Entwickler wissen nicht, was die Iteration antreibt	Die Quellensammlung in den Modelleigenschaften annotieren
Asymmetrische Teilnehmerbänder	Verwirrung darüber, wer jede Aufgabe initiiert	Durchgängige konsistente Bandreihenfolge über [[2]] hinweg sicherstellen
Übermäßiger Einsatz von Choreografie für interne Logik	Das Diagramm wird unleserlich	Choreografie ausschließlich für grenzüberschreitende Kommunikation reservieren
Terminierungssignatur ignorieren	Teilweise Bereinigung bei Abbruch	Kompensationsaktionen für den Terminierungspfad dokumentieren
Kein Timeout bei „Auf Antwort warten“	Zombie-Prozessinstanzen	SLA-basierte Timer auf jedem Wartezustand definieren

---

✅ Zusammenfassung & Tooling-Empfehlung: Modellierung beschleunigen mit Visual Paradigm BPMN + KI