Ein erster Blick auf jBPM 4

Lange hat es gedauert und teilweise gespannt wurde es erwartet: Die Version 4 der bekannten Open Source Business Process Engine jBPM aus dem Hause JBoss. Jetzt wurde die erste alpha Version veröffentlicht.

Daher habe ich gleich mal einen Beispielprozess mit jBPM 4 umgesetzt und die Version etwas genauer unter die Lupe genommen.

Die Prozessbeschreibungssprache jPDL (jBPM Process Definition Language) sowie die technische Grundlage der Prozessmaschine hat sich in Version 4 stark verändert. Dies ist einigen Neuerungen geschuldet: Der Einführung der Process Virtual Machine (PVM), die Anlehnung an die Business Process Modelling Notation (BPMN), die Einführung einer möglichst generischen API für Process Engines als natürlich auch zahlreiche Verbesserungen auf Grund der Erfahrungen mit jBPM 3.

Beispielprozess

Doch eins nach dem anderen, zu erst einmal möchte ich ein Beispielprozess aus einem unserer Trainings, einen einfachen Ticketprozess, kurz vorstellen. Dazu einmal der Prozess als BPD (BPMN-Diagramm):

Ein Kunde kann für ein Problem ein Ticket aufmachen. Ist für den Kunden noch kein Betreuer festgelegt wird dies nachgeholt. Dann bekommt der Betreuer die Aufgabe zugewiesen. Hat er sie abgeschlossen bekommt der Kunde eine E-Mail und muss bestätigen, dass sein Problem gelöst wurde. Andernfalls bekommt der Betreuer die Aufgabe erneut auf den Tisch.

Installation

Also frisch ans Werk mit jbpm 4. Die Installation beschränkt sich aktuell eigentlich auf die Integration in Eclipse, da Deployments für JBoss AS oder Tomcat noch nicht zur Verfügung stehen. Daher beschränkt sich auch das Testen noch auf JUnit… Dank mitgelieferter guter Doku ging die Installation trotz Eclipse (sorry, es ist einfach nicht mein Lieblingstool ;-)) gut von der Hand.

Der neuen Designer und BPMN

Der neue grafische Prozessdesigner (GPD) überrascht sofort mit einer grafisch ansprechenden BPMN-Darstellung der Prozesse. Allerdings sind in der aktuellen Version auch nur ein Bruchteil der existierenden BPMN-Elemente umgesetzt und manche sogar falsch verwendet, doch dazu später mehr. Viele fehlende Kleinigkeiten, wie beispielsweise die XML-Ansicht oder eine Möglichkeit Properties einzugeben, kennzeichnen den Designer noch deutlich als unfertig, aber das ist in einer alpha Version schließlich ok.

Ein erster Wurf des Ticketprozesses führt zu folgendem Ergebnis:

Das ist ja auch schon sehr ansehlich 🙂 Auch wenn einige Kleinigkeiten noch nicht perfekt sind, so z.B.:

• An den Gateways (Verzweigungen) wird keine Beschriftung angezeigt, auch die ausgehenden Kanten können aktuell nicht beschriftet werden,
• Zeilenumbruche in den Aktivitäten sind nicht möglich, was ein Modellieren von links nach rechts, wie in BPDs oft üblich, erschwert wird,
• Pools und Lanes sind nicht möglich.

Hier bleibt abzuwarten, was bis zum Release noch alles verbessert wird und wie die entgültige Version aussieht.

Schlimmer finde ich einige Verletzungen der BPMN-Spezifikation die in jBPM 4 versteckt sind. Leider ist es heute wohl etwas hip die grafischen BPMN-Symbole (BPMN-Shapes) zu verwenden es aber mit der Spezifikation nicht ganz so genau zu nehmen, da ist jBPM übrigens in guter Gesellschaft vieler andere Tools. Aus meiner Sicht ist dieses Vorgehen jedoch mehr als unschön, denn der Zweck der Spezifikation ist ja genau die exakte Definition hinter den Symbolen. Hier bin ich aktuell auch noch in der Diskussion mit dem jBPM-Team, auch hier werden wir sehen, wie es in der finalen Version aussieht.

Aber was habe ich denn eigentlich zu meckern. Ich möchte drei konkrete Beispiele anführen:

Ausgehende Sequenzflüsse (Flows, Transitionen) in Activities. Die jBPM-Dokumentation sagt hier:

Dies bedeutet, dass jBPM sich zwischen den zwei ausgehenden Flows für genau einen entscheidet, also eine so genannte XOR-Semantik. Die BPMN-Spezifikation definiert allerdings eine AND-Sematik, also alle ausgehenden Flows werden feuern, außer sie enthalten Bedingungen die nicht erfüllt sind. Was jBPM umsetzt müsste eigentlich korrekterweise als Activity mit folgendem XOR modelliert werden, so wie es in meinem Beispiel oben gezeigt ist. Wird nach der jBPM-Empfehlung gearbeitet aber ohne Gateway nach “Problem bearbeiten” auskommen:

Letzteres ist ganz in bekannter jBPM-Manier und eigentlich sowohl intuitiv als auch in der jBPM-Gemeinde bekannt. Aber es entspricht eben nicht wirklich genau der Spec und ist damit schnell mißverständlich.

Ein weiteres, wenn auch nicht ganz so relevantes Problem, ist in folgender Abbildung visualisiert: jBPM kennt kein zusammenführendes exklusives Gateway (also quasi ein “OR-Join” ;-)). Bei einem exklusiven Gateway wird immer eine Entscheidung erwartet, welcher ausgehende Flow durchlaufen werden soll. Was logisch ist, wenn man weiß, dass dieses Gateway in jBPM die dort bisher so genannte Decision abgelöst hat. Es im Sinne der BPMN zu verwenden erfordert zumindest einen Workaround.

Ein dritter Kritikpunkt ist, dass das terminierende Ende-Ereignis (Der Endknoten mit dem ausgefüllten Punkt) sowohl eine gesammte Prozessinstanz terminieren kann (korrekt!) als auch einen einzelnen Ausführungspfad, beispielsweise in einem Fork (nicht korrekt! Dafür gibt es das “normale” Ende-Ereignis).

Insgesamt noch kein Weltuntergang, aber trotzdem hoffe ich, dass sich hier noch eine korrektere Abbildung der Spezifikation durchsetzt, ich werde es auf jeden Fall anregen. Und schließlich ist bis zur finalen Version auch noch ein bisschen Zeit.

jPDL – Neuerungen

Der modellierte Prozess wird im Hintergrund direkt als jPDL im XML-Format abgespeichert. Das XML ist prinzipiell noch mit dem aus jBPM 3 bekannten Format vergleichbar, jedoch gibt es einige Unterschiede:

• Veränderte Namensgebung, an der BPMN orientiert: Transitionen heißen jetzt “flow”, “decision” wird zu “gateway” usw…
• Die grafischen Layoutinformationen, in jBPM 3 im gpd.xml abgespeichert, sind jetzt direkt im gleichen XML zu finden,
• Es gibt speziell definierte Aktivitäten beispielsweise für die Ausführung von Java-Code. Ementsprechend gibt es dann ein “java”-Element.

Am einfachsten zeige ich hier den oben modellierten Prozess einmal als Quellcode, ein Beispiel sagt schließlich mehr als hundert Worte. Der Prozess ist dabei nur äußert rudimentär ausmodelliert (ich sollte dazusagen, dass ich gerade im Hotel sitze und der Pool ruft), aber bereits lauffähig (Test-Code folgt unten). Auch ist dort mein Workaround für das schließende exklusive Gateway eingebaut.

<process xmlns="http://jbpm.org/4/jpdl" name="TicketProcess">
   <start name="Start" g="15,146,48,48">
      <flow to="Kundenbetreuer bekannt?"/>
   </start>
   <exclusive name="Kundenbetreuer bekannt?" g="84,144,48,48">
      <flow to="Kundenbetreuer festlegen" g="108,24">
      	<condition expr="#{false}"/>
      </flow>
      <flow to="join">
      	<condition expr="#{true}"/>
      </flow>
   </exclusive>
   <task name="Kundenbetreuer festlegen" g="168,0,153,51"
         assignee="bernd">
      <flow to="CRM aktualisieren"/>
   </task>
   <java name="CRM aktualisieren" g="168,72,157,52"
         class="com.camunda.ca002.jbpm.TicketService"
         method="updateCustomer">
      <flow to="join" g="347,97"/>
   </java>
   <exclusive name="join" g="324,144,48,48">
      <flow to="Problem bearbeiten">
      	<condition expr="#{true}"/>
      </flow>
   </exclusive>
   <task name="Problem bearbeiten" g="408,144,133,52"
         assignee="bernd">
      <flow to="Kunden informieren"/>
   </task>
   <java name="Kunden informieren" g="564,144,145,52"
         class="com.camunda.ca002.jbpm.TicketService"
         method="notifyCustomer">
      <flow to="Warten auf Feedback"/>
   </java>
   <state name="Warten auf Feedback" g="564,216,145,52">
      <flow to="Problem geloest"/>
   </state>
   <exclusive name="Problem geloest" g="612,300,48,48">
      <flow to="join" g="347,324">
      	<condition expr="#{false}"/>
      </flow>
      <flow name="yes" to="end">
      	<condition expr="#{true}"/>
      </flow>
   </exclusive>
   <end name="end" g="696,300,48,48"/>
</process>

Was hat sich an jPDL verändert: Einiges, aber doch ist auch viel gleich geblieben. Die Entscheidungen, früher “decision”, jetzt “exclusive” sind eigentlich unverändert. Die bisher bekannten ActionHandler um Java-Code an beliebige Events anzuhängen gibt es in der Form nicht mehr oder sie sind in der Alpha-Version noch nicht verfügbar. Dafür gibt es die “java” Aktivität, bei der eine Methode einer Klasse aufgerufen wird, wobei auch Injection, Parameterübergabe und die Verwertung des Rückgabewertes möglich sind. Auf jeden Fall nett, ersetzt aber die ActionHandler meiner Meinung nach noch nicht.

API

Die API hat sich sehr stark verändert. Die Motivation dahinter war nun aber nicht, den Entwicklern das Leben schwer zu machen, sondern die API möglichst unabhängig von der jBPM jPDL Version zu machen. Im Idealfall entsteht dabei eine API, die von der Implementierung der Engine dahinter unabhängig ist. Zugegeben ein heeres Ziel und auch nicht einfach, aber auch ein guter Ansatz. Übrigens ist diese API zu großen Teilen Schuld, dass jBPM 4 sich etwas mehr Zeit gelassen hat, so eine API aufstellen zu wollen und auszudiskutieren kostet einfach seine Zeit.

Prinzipiell gibt es in jBPM nun die “ProcessEngine” als zentrale Instanz, von der ich mir Services holen kann, wobei folgende eine zentrale Rolle spielen:

• ProcessService: Zugriff auf das Prozess-Repository (Prozessdefinitionen)
• ExecutionService: Laden, Signalisieren oder verändern von laufenden Prozessinstanzen
• TaskService: Zugriff auf Human Tasks
• ManagementService: Überwachung und Übersicht über den Status zum Monitoring und Betrieb
• (CommandService:) Mit diesem kann ich beliebige Kommandos an jBPM schicken, diese Commands können auch selbst implementiert werden und bieten einen flexiblen Erweiterungspunkt (wie auch bereits in jBPM 3).

Wen das ganze übrigens an das Referenzmodell der WfMC erinnert, das ist kein purer Zufall 😉

Nun aber auch der versprochene JUnit-Test um den Prozess zu testen:

public void testTicket() {
  deployJpdlResource("TicketProcess.jpdl.xml");

  Execution execution = executionService.startExecutionByKey("TicketProcess");
  String executionId = execution.getId();

  execution = executionService.findExecution(executionId);
  assertEquals("Problem bearbeiten", execution.getNodeName());

  List<Task> taskList = taskService.getPersonalTaskList("bernd", 0, 10);
  assertEquals(1, taskList.size());
  Task task = taskList.get(0);
  assertEquals("Problem bearbeiten", task.getName());
  assertEquals("bernd", task.getAssignee());

  taskService.submitTask(task.getId());

  execution = executionService.findExecution(executionId);
  assertEquals("Warten auf Feedback", execution.getNodeName());

  execution = executionService.signalExecutionById(executionId);

  assertEquals("end", execution.getNodeName());
  assertTrue(execution.isEnded());
  assertFalse(execution.isActive());
}

Deployment

Die aktuellen Deployment-Optionen sind schnell beschrieben: Es gibt sie noch nicht 🙂 Wobei das auch nicht die Intension der alpha-Version war. Natürlich wird jBPM 4 auch wieder auf bekannten Tomcats oder JBossen laufen werden…

PVM

Last but not least möchte ich zumindest noch auf die unsichtbare, aber sehr wichtige, Änderung hinweisen: Die Einführung der Process Virtual Machine, oder kurz PVM. jBPM hat eingesehen, dass es nicht die eine perfekte Sprache zur Automatisierung von Geschäftsprozessen gibt, sondern für jedes Problem eigene Lösungen bereit stehen. Daher ist Grundlage von jBPM jetzt die PVM, welche nur die notwendigen Kernabstraktionen für einen Zustandsautomaten implementiert. Die jBPM Process Definition Language (jPDL), welche man meist meint, wenn man über jBPM spricht, baut dann auf der PVM auf und implementiert nur die Besonderheiten der Sprache. Man kann es sich so vorstellen, dass die PVM den abstrakten Zustandsautomat beschreibt und jPDL dann die Knotentypen. Infos dazu sind auch in meinem JavaSpektrum-Artikel zu finden. Interessant hierbei auch, dass die OSS-XPDL-Process Engine von Bull (“Nova Bonita”) in der neusten Version auch bereits auf der jBPM PVM basiert.

Fazit

Ich könnte gerade noch viel, viel mehr schreiben, wenn nicht der Tag bald vorbei wäre und der Pool bald zumachte. Auch in Sachen Web-Console, Reporting und BAM tut sich einiges. Viele Innereien im neuen jBPM sind sehr durchdacht und auf jeden Fall mehr als eine Weiterentwicklung. Der Editor macht bereits jetzt einen netten Eindruck und die Unterstützung der BPMN ist prinzipiell begrüßenswert.

Dennoch gibt es auch Wehrmutstropfen: Die Verletzungen der BPMN-Spec oder auch, dass jBPM 4 noch Zeit brauchen wird, bis die Reife und der Funktionsumfang von jBPM 3 erreicht sein wird. Die ApiDoc ist wesentlich besser als in der alten Version, aber auch immer noch lückenhaft. Einige Exceptions beim Herumspielen mit der alpha Version waren nicht unbedingt sofort selbsterklärend. Durch die vielen Änderungen an Klassennamen oder API’s müssen auch jBPM 3 Cracks auf jeden Fall einiges neu lernen.

Aber ich denke es lohnt sich auf jeden Fall, man muss eben noch ein bisschen Geduld haben. Und das sage ich jetzt nicht nur als Liebhaber und Committer des jBPM-Projektes 🙂

Über Feedback & Anregungen bin ich sehr dankbar, gerne hier im Blog, per Email oder auch im jBPM-Forum. Noch kann Einfluss an jBPM 4 genommen werden!