Migration von Appway zu Camunda (mit CIB seven): Architektur und Integration

Einleitung
Willkommen zur dreiteiligen ONLU-Blogserie „Migration von Appway zu Camunda (mit CIB seven)“. Wir liefern wir Ihnen fundiertes Expertenwissen – von den Beweggründen über die technische Umsetzung bis hin zu praxiserprobten Best Practices.

Inhaltsverzeichnis

1. Teil 1: Einführung & Motivation
2. Teil 2: Architektur & Integration
3. Teil 3: Best Practices & Migrationsstrategien

Moderne Architektur: Kafka-Integration und ereignisgesteuerte Workflows

Camunda und Kafka erfüllen unterschiedliche, sich jedoch ideal ergänzende Rollen. Camunda fungiert als Orchestrator, der den Prozessfluss und die Entscheidungen steuert – was als Nächstes geschehen soll – während Kafka als hochskalierbare Event-Plattform dient, um diese Entscheidungen und Daten zwischen verteilten Systemen auszutauschen camunda.com. Mit anderen Worten: Camunda entscheidet auf Basis des Prozesskontexts über den nächsten Schritt, und Kafka transportiert die entsprechenden Nachrichten/Ereignisse zuverlässig zu den Microservices, die die Schritte ausführen sollen camunda.com. Diese Kombination aus prozessorientierter Orchestrierung und ereignisgetriebener Verarbeitung verbindet das Beste aus beiden Welten: Camunda behält den Überblick über langlaufende, komplexe Abläufe, Kafka entkoppelt die Services und erlaubt deren parallelen Betrieb.

In der praktischen Umsetzung gibt es mehrere Möglichkeiten der Integration:

• Service Tasks mit Kafka-Anbindung: Ein Service Task im Camunda-Prozess kann so implementiert werden, dass er beim Erreichen automatisch eine Nachricht an einen Kafka-Topic schickt (Producer). Ein konsumierender Microservice hört auf dieses Topic und führt die Aktion aus (z.B. eine Berechnung oder Datenbankoperation). Sobald der Microservice seine Arbeit erledigt hat, kann er wiederum ein Event auf Kafka senden, das Camunda über einen anstehenden Folgeschritt informiert. Camunda kann solche Events empfangen, indem z.B. ein externer Worker oder ein Kafka-Connector die Nachricht abfängt und dann per REST einen Message Catch Event oder eine entsprechende Prozessinstanz korreliert. Neuere Camunda-Versionen (8 / SaaS) bieten hierfür sogar out-of-the-box Kafka Connectoren an, die Eingangs- und Ausgangs-Ereignisse auf Kafka ohne viel Boilerplate-Code ermöglichen camunda.com. In Camunda 7/CIB seven kann man ähnliches mit External Task Workern oder custom Java Delegates erreichen.
• Komplette Event-Orchestrierung: Alternativ kann man Camunda auch stärker in eine Event-Driven-Architektur einbetten, indem man es als eine Art Supervising Service einsetzt. Ein Beispiel-Pattern ist das Event-driven Orchestration: Der Camunda-Prozess wartet an bestimmten Stellen auf Ereignisse (Message Intermediate Events), die von anderen Systemen via Kafka kommen, und entscheidet dann, wie es weitergeht. Im Prozessmodell wird also anstelle von synchronen Service Calls vermehrt mit Message Events gearbeitet. Die Modelle werden etwas komplexer, aber man erreicht damit eine sehr lose Kopplung. Ein Praxisbeispiel: Eine Camunda-Instanz (etwa in einem „Orchestrator“-Microservice) startet einen Geschäftsprozess und publiziert zunächst Events für die notwendigen Schritte (z.B. «Prüfung A gestartet»). Die konsumierenden Dienste führen ihre Aufgabe durch und senden bei Abschluss ein Event zurück («Prüfung A fertig»). Der Camunda-Prozess fängt dieses Event ab und geht zum nächsten Schritt weiter. Dieses Muster erfordert etwas mehr Implementierungsaufwand, bietet aber maximale Entkopplung und Skalierbarkeitmedium.com. Wichtig ist in jedem Fall, sauber zu definieren, welche Events vom Prozess erwartet werden und wie Fehlerfälle (z.B. Zeitüberschreitungen oder fehlende Antworten) gehandhabt werden.

Unabhängig vom Integrationsansatz sollte man bei der Migration auf eine eventgetriebene Architektur darauf achten, bestehende synchrone Aufrufe (wie SOAP oder REST) nicht unüberlegt 1:1 in Events zu giessen. Nicht jeder Prozessschritt eignet sich als asynchrones Event. Eine Hybrid-Architektur ist oft sinnvoll: Zeitkritische oder stark sequenzielle Schritte können weiterhin synchron per REST/HTTP angebunden sein, während entkoppelte Teile via Kafka orchestriert werden. Das Zielbild ist ein Microservice-basiertes Workflow-System, in dem Camunda als zentrales Brain agiert und Kafka als Nervensystem, das die Botschaften verteilt. Diese Architektur ermöglicht es, dass neue Services problemlos angebunden oder ausgetauscht werden können, ohne dass der Prozess geändert werden muss – es muss lediglich das entsprechende Event produziert oder konsumiert werden.

Im nächsten Beitrag steigen wir tiefer in die Best Practices und Migrationstrategien ein und zeigen, wie Camunda und CIB seven konkret in moderne Microservice-Landschaften integriert werden können für den sanften Umstieg.

• Appway Hintergrund und Übernahme durch FNZ fnz.com
• Herausforderungen monolithischer BPM-Plattformen (Vendor Lock-in) camunda.com
• BPMN-Standard verhindert Vendor Lock-in camunda.com
• Camunda vs. Appway – Funktionen im Vergleich softwaresuggest.com
• CIB seven und CIB flow – Beschreibung der Komponenten onlu.ch
• CIB seven Vorteile (Open Source, Kompatibilität) onlu.ch
• Camunda SOAP-Integration (Connector) docs.camunda.org
• Camunda & Kafka Zusammenspiel camunda.com
• Event-getriebene Orchestrierung mit Camunda (Beispiel) medium.com
• Migrationsstrategien Parallel vs. Big Bang camunda.com