Elena LucconeInnovation und Technologie

BPMN-Prozesse ändern im Betrieb

Wir fangen ein neues Projekt an. Darin modellieren wir mit der Fachseite die Prozesse mittels BPMN und wir gehen sogar einen Schritt weiter: Wir lassen die Prozesse durch eine BPMN-Engine ausführen. Wir versprechen uns viele Vorteile: Die Prozesse sind sichtbar und verständlich; Fachseite und IT haben den Gap überwunden und reden miteinander. Es ist wesentlich einfacher und schneller als früher, Fehler und Engpässe zu analysieren. Nun, wer kennt das nicht: Kaum ist ein Software-Release ausgerollt, schon stapeln sich die Wünsche nach neuen Funktionen, die Prozesse müssen optimiert werden und vielleicht passiert es auch, dass etwas im Betrieb suboptimal läuft oder dass ein Vorgang vorzeitig abgeschlossen wurde, obwohl er noch bearbeitet werden müsste.

Die Software auszutauschen und neue Instanzen mit der neuen Software laufen zu lassen, ist nicht das Problem. Aber was machen wir, wenn wir Vorgänge in Bearbeitung oder, technisch ausgedrückt, wenn wir laufende Prozessinstanzen haben und wollen, dass diese die Änderungen ab sofort berücksichtigen?

Relativ unspektakulär sind Änderungen an aufgerufenen Services ohne Schnittstellenänderungen. Interessant sind dagegen Änderungen am Prozessfluss. Ein Vorgang muss demnächst zum Beispiel vor dem Abschließen von einem Sachbearbeiter geprüft werden. Oder im Beispiel des versehentlich abgeschlossenen Vorgangs will man vielleicht einen Schritt zurückgehen und die Bearbeitung wiederholen und das ist im Modell nicht vorgesehen worden.

Die gute Nachricht ist: Die Hersteller kennen das Problem und machen sich auch Gedanken dazu. Sie bieten diverse Eingriffsmöglichkeiten an: automatische oder manuelle Migrationsmöglichkeiten, APIs zur Änderung der Daten oder zum Verschieben von Tokens, Konfigurationspläne für Migrationen, Dateien mit Beschreibungen, wie mit den so genannten verwaisten Tokens (sie treten bei laufenden Instanzen auf, die sich bei einem Prozessschritt befinden, der im neuen Prozessmodell nicht existiert) umgegangen werden soll usw.

Ich durfte IBM BPM 8.5 auf diese Aspekte untersuchen und konnte einige der angebotenen Funktionen testen. Auf mich macht die Software einen guten Eindruck. Ich konnte bis jetzt diverse teilweise sehr komplexe und konstruierte Migrationsszenarien lösen. Zwar gibt es eine „Einschränkungsliste“, aber auch die hier genannten Punkte konnte ich entweder nachvollziehen (Beispiel: Man darf kein Prozessdatenobjekt löschen, das noch verwendet wird.) bzw. ich konnte dafür einen Workaround finden.

Das Kennen des BPMN-Standards und das Verständnis darüber, wie die IBM BPM Engine funktioniert, hilft immens, wenn es darum geht, eine Lösung für ein „verbotenes“ Migrationsszenario zu finden. Manchmal muss man über die APIs Tokens verschieben oder Prozessdaten ändern und wenn das alles nicht in einem Schritt klappt, dann einen „Zwischenprozess“ ausrollen, der nur dafür gedacht ist, die Tokens abzufangen, damit sie an die richtige Stelle verschoben werden können. Anschließend kann dann die „echte“ neue Prozessversion problemlos in den Betrieb genommen werden.

Die schon angesprochenen APIs können einiges. Alle haben Vor- und Nachteile und bieten teilweise andere Funktionen. Leider kann man sich daher nicht auf die Nutzung einer API beschränken. Die JS-API scheint mir zum Beispiel sehr mächtig zu sein. Ich habe aber keine Möglichkeit gefunden, wie ich damit die aktuellen Token-IDs (also die aktuelle Aktivität oder Position) einer laufenden Instanz abfragen kann (wenn Sie eine kennen, bitte einfach mal hier als Kommentar posten). Diese Möglichkeit bietet die REST-API. Also wird man bei etwas komplexeren Änderungsszenarien mit mehreren APIs arbeiten müssen.

Ein weiteres Problem ist die Anzahl der zu ändernden Instanzen. Solange man nur eine Prozessinstanz ändern möchte, kann man relativ einfach die APIs aufrufen und die gewünschte Änderung durchführen. Meistens hat man aber mehrere Instanzen, die auf ein Problem laufen und daher geändert bzw. migriert werden müssen.

Eine Möglichkeit damit umzugehen, ist die Erstellung eines Migrationsprozesses (auch mittels BPMN), der die betroffenen Instanzen ermittelt und die gewünschte Änderung durchführt.

Die APIs können auf unterschiedliche Wege in einem BPMN-Prozess angebunden werden. Die JS-API kann in einer Script-Task aufgerufen werden. Dies ist ein schönes Beispiel dafür.

Mein Kollege Sebastian Kurth zeigt hier wie man die REST-API in einem BPMN-Prozess anbinden kann.

Wenn man etwas flexibel an das Problem geht und mehrere APIs nutzt, ist man in der Lage automatisiert problematische Instanzen und ihre aktuellen Tokens zu ermitteln, die Tokens zu verschieben und die Instanz-Daten zu ändern.

Fazit

IBM BPM 8.5 bietet gute Eingriffsmöglichkeiten bei laufenden Prozessinstanzen. Diese Erkenntnis dürfte uns aber keinen Anlass geben, alle Probleme über Instanz-Eingriffe zu lösen und man sollte keine Probleme erfinden, wenn es keine gibt. Mit anderen Worten: Man sollte trotzdem gute BPMN-Modelle erstellen und regelmäßige Problemsituationen berücksichtigen. Bei Migrationen sollte man, wenn es möglich ist, die „alten“ Prozessinstanzen auslaufen lassen. Eine komplexe Lösung sollte man erst anwenden, wenn diese tatsächlich benötigt wird.

Schlagwörter: ,