Ausgangslage

In jeder BPE, wie etwa der  Bonita BPM-Suite, können Prozessinstanzen eine Laufzeit von Stunden, Tagen oder sogar Wochen haben. Die zugehörigen Prozess-Payload-Informationen werden in einem Bonita-spezifischen Datenformat gespeichert und sind an die Prozessversion gebunden. Durch Messaging ist es möglich, dass unterschiedliche fachliche Prozessinstanzen miteinander – lose gekoppelt – kommunizieren. Zu jeder Softwarelösung werden früher oder später in ihrem Lebenszyklus Aktualisierungen eingespielt werden. Es gilt sicherzustellen, dass durch diese Updates keine Informationen verloren gehen und dass kein aktiver Prozess vorzeitig terminiert wird.

Vorbedingungen

Es sind zwei unterschiedliche Prozesse mit voneinander unabhängigen Pools vorhanden.

1. Der Prozess Sender (send_message) schickt eine Message an den Prozess Empfänger (message_receiver). Der Sender wartet auf eine externe Nachricht.
2. Der Empfänger verarbeitet die empfangene Nachricht und schickt im nächsten Schritt eine neue Message an den Sender zurück.
3. Der Sender empfängt diese neue Message und kann seine wartende Prozessinstanz fortführen.

Verwalten von parallelen Prozessversionen in Bonita

Jede BPM-Suite sollte parallele Prozessversionen unterstützen. Bei Bonita muss ein neuer Prozess im lexikografischen Sinn eine höhere Versionsnummer als sein Vorgänger vorweisen. Buchstaben sind technisch zulässig, man sollte aber bei einer numerischen Major-Minor Notation bleiben. Bonita weist hierbei den Prozessdesigner auf Versionskonflikte hin.

Währung der Installation der Version 2.0 werden in der Bonita User XP im Administrationsmodus die bestehenden Prozesse deaktiviert (Disable). Die Prozessinstanzen (Cases) der vorherigen 1.0-Versionen laufen weiter, neue können aber nicht mehr gestartet werden.

Folgende Szenarien sind durch diese Vorgehensweise abgedeckt:

Szenario 1

Prozess send_message in Version 1.0 schickt eine Nachricht an den Pool message_receiver mit dem Task receiver. Der Prozess message_receiver  empfängt die Nachricht und schickt im Prozessverlauf eine andere Nachricht an den Pool send_message und den Task receive_answer.

Szenario 2

Beginn wie Szenario 1. Zur Laufzeit wird vom Prozess message_receiver die Version 2.0 installiert und die Version 1.0 deaktiviert. Alle neuen Messages aus dem Prozess send_message starten nur noch Prozessinstanzen von dieser Version 2.0 . Noch laufende message_receiver-Instanzen der Version 1.0 sind weiterhin in der Bonita BPM-Suite aktiv und sollen regulär bearbeitet werden.

Szenario 3

Beginn wie Szenario 2. Mindestens eine Instanz von send_message wartet im Task receive_answer noch auf die Rückantwort. Zur Laufzeit wird vom Prozess send_message eine Version 2.0 installiert und die Version 1.0 wird deaktiviert. Es sind nun vier unterschiedliche Prozesse aktiv. Bei dieser Vielzahl an Prozessversionen ist die Verwendung einer Matching condition zum Empfang der passenden Messages notwendig. Entweder überträgt man einen eindeutigen fachlichen Schlüssel als Teil der Nachricht oder es wird als eindeutiger technischer Schlüssel die UUID der Prozessinstanz übermittelt.  Bonita bietet hier folgendes an: Matching Condition = processInstance.getUUID().getValue().equals return_id

Fazit

Lang laufende Prozessinstanzen dürfen ein Update der Prozesslogik nicht verhindern. BPM-Suiten müssen Konzepte für parallele Prozesse anbieten, um den Software-Lebenszyklus auch auf Prozessebene zu unterstützen. Mit ein wenig Governance-Aufwand ist dies mit Bonita oder auch mit der Activiti-BPM-Plattform gut zu bewerkstelligen.