Projekte zur Geschäftsprojektoptimierung und -automatisierung nutzen oft eine BPM-Engine zur Ausführung der Prozess-Instanzen. BPM-Engine sind Softwareprodukte, die unterschiedlichen Funktionsumfang, aber auch verschiedene Qualität haben. Aufgrund der Last- und Durchsatzanforderungen des Kunden kann es sogar passieren, dass ein Wechsel einer BPM-Engine notwendig ist.

Im Rahmen eines Kundenprojekts wurde eine Migration von Prozessen von Bonita BPM Open Solution zu Camunda BPM durchgeführt. Als erstes wurde auf Basis von Camunda BPM die Lösung entwickelt, die den gleichen Funktionsumfang hat wie die Bonita-Lösung. Dabei war es empfehlenswert, während der Migration eine Eins-zu-eins-Lösung zu implementieren, ohne gleichzeitig weitere CRs oder Modifikationen an der Software durchzuführen. So ließ sich die Migration einfacher realisieren: die Ergebnisse der Prozess-Ausführungen auf beiden BPM-Engines blieben vergleichbar.

Nach der Fertigung der Lösung und einem ausführlichen Test standen uns nun zwei Systeme mit nahezu äquivalentem Funktionsumfang zur Verfügung. Die Aufgabe bestand dann darin, etwa 800 Prozessinstanzen, die auf Basis von Bonita BPM noch liefen, auf die Camunda BPM-Lösung zu migrieren. Dieser Artikel beschreibt das Vorgehen.

Bevor die eigentliche Migrationsstrategie ausgewählt werden konnte, erstellten wir ein Prozesshistogramm, das darstellte, wie viele Prozessinstanzen im welchem Prozessschritt stehen und das uns ermöglichte zu entscheiden, welche Instanzen migriert und welche zunächst in andere Zustände überführt werden. Ein weiteres Prozesshistogramm, das wir später erstellten, entschlüsselte uns auch die Dynamik im System – so konnten wir sichergehen, dass wir nicht aufgrund einer Zufallsmessung einen außergewöhnlichen Zustand erwischt hatten.

Migration

Nach der Analyse der Daten im Quell- und Zielsystem haben wir uns für die Migration durch die geführte Steuerung der Camunda BPM Engine entschieden. Dabei wird für jede Prozessinstanz im Altsystem eine Instanz im neuen System via Camunda API gestartet und zum gewünschten Zielzustand geführt, der mit dem Zustand im Altsystem korrespondiert und in dem die Instanz im Bonita BPM steht. Dabei ist es wichtig, nicht nur die Zielzustände abzubilden, sondern auch die Prozesse mit den Nutzdaten zu versorgen. Die Migration vollzieht sich in mehreren Schritten, so dass der Migrationsprozess selbst auch innerhalb der BPM-Engine implementiert werden kann:

Die Identifikation von einzelnen Prozessinstanzen bildet den ersten Schritt bei der Migration der Instanz aus Bonita. Dazu stellt Bonita BPM eine REST-API zur Verfügung, die wir jedoch nicht wie gewünscht konfigurieren konnten, um darauf per Bonita REST-Client zuzugreifen, weil wir in der Lösung selbst Bonita EJB-Client verwendet haben. Trotzdem gelang es uns, die Daten via simplem HTTP-REST-Client aus der Bonita BP-Engine abzuziehen und lokal als XML-Dateien zu speichern. Als Ergebnis entstand dabei stets eine XML-Datei mit allen Informationen zu einer Prozessinstanz.
Danach wurde die XML-Datei eingelesen und in eine Java-Struktur überführt, die die entscheidenden Informationen über die Prozessinstanz enthielt, wobei vor allem die Informationen über die Aktivität oder Ereignis, in dem die Instanz wartet, aber auch die Werte der Prozessvariablen wichtig waren.

Für jede Prozessinstanz wurde nun per Camunda API eine Prozessinstanz in Camunda BPM gestartet. Dabei ergänzten wir das ursprüngliche Prozessmodell um weitere Nachrichten-Start-Ereignisse, so dass für jeden relevanten Zustand ein entsprechendes Startereignis existiert, das unmittelbar zum Zielzustand führt. Beim Starten von Prozessen ermöglicht es Camunda API, die Prozessvariablen zu übergeben, so dass diese direkt angegeben werden können. Für die Werte der Variablen und die Zuordnung von Zuständen war selbstverständlich etwas Programmierarbeit erforderlich.

Besonders interessant war der Start von Prozessinstanzen, die sich gerade in Sub-Prozessen oder in Call-Activities befanden. Da in diesem Fall nicht nur die Prozessinstanz selbst, sondern auch die der Subprozesse migriert werden mussten, haben wir die Subprozesse etwas präpariert und es ermöglicht, mittels einer Payload-Variablen im Prozess zu einer Zielaktivität zu springen.

Fazit

Dank REST-APIs von Bonita ließen sich alle Prozesse samt Daten aus Bonita BPM als XML exportieren. Die Verwendung von zusätzlichen Start-Ereignissen und Sequenzflüssen in Sub-Prozessen ermöglichen eine einfache Navigation im Zielsystem Camunda BPM. Wenn die Migration selbst als ein BPMN-Prozess modelliert wird, vereinfacht es den Zugang zur Engine selbst und gewährleistet einfache Wiederholbarkeit. Die Migration wird dann nicht mehr vom Menschen durchgeführt, sondern lediglich überwacht – Automatisierung durch und durch.