zurück zum Artikel

Case Management und CMMN für Entwickler

Bernd Rücker

Workflow-Engines sind im Werkzeugkasten der Entwickler angekommen, wobei typischerweise der Standard BPMN 2.0 Verwendung findet. Beim Automatisieren stößt man allerdings immer wieder auf Fälle, in denen der Mensch den Prozessablauf beeinflussen können muss.

Case Management und CMMN für Entwickler

Workflow-Engines sind im Werkzeugkasten der Entwickler angekommen, wobei typischerweise der Standard BPMN 2.0 Verwendung findet. Beim Automatisieren stößt man allerdings immer wieder auf Fälle, in denen der Mensch den Prozessablauf beeinflussen können muss.

Flexibilität ist in BPMN (Business Process Model and Notation) teilweise schwierig abbildbar. Deshalb hat die Object Management Group einen eigenen Standard CMMN 1.0 (Case Management Model and Notation) verabschiedet, der – wie BPMN auch – in Workflow-Engines ausführbar ist. Der vorliegende Artikel führt in CMMN ein und zeigt die Umsetzung beispielhaft am quelloffenen BPM-System vom Unternehmen des Autors.

Als konkretes fachliches Beispiel soll das Annehmen (oder Ablehnen) einer privaten Krankenversicherung dienen. Der vollständige Quellcode inklusive der zugehörigen BPMN- und CMMN-Modelle ist auf GitHub [1]verfügbar und lässt sich auf der quelloffenen BPM-Plattform [2] von Camunda direkt ausführen beziehungsweise ausprobieren.

Auf den ersten Blick wirkt der als "Underwriting" bezeichnete Prozess durchaus strukturiert und kann also mit BPMN abgebildet werden:

Der strukturierbare Teil des "Underwriting"-Prozesses lässt sich als Prozessdefinition in BPMN darstellen (Abb. 1).

Der strukturierbare Teil des "Underwriting"-Prozesses lässt sich als Prozessdefinition in BPMN darstellen (Abb. 1).

Das so entstandene Modell kann man direkt auf einer Process Engine ausführen. Die ersten Schwierigkeiten treten beim Freigeben der Police auf, was im Prozess durch eine sogenannte "Call Activity" dargestellt ist. Hier haben Sachbearbeiter mannigfaltige Möglichkeiten. Sie können beispielsweise den Hausarzt kontaktieren, um Vorerkrankungen zu erfragen, was wiederum eventuell die Nachfrage bei Fachärzten erfordert. Bei größeren Risiken müssen sie vielleicht einen Kollegen zu Rate ziehen und um seine Einschätzung bitten. Eventuell möchte er, dass der Kunde angerufen wird, um ein paar Informationen abzufragen, und so weiter. Diese Tätigkeiten lassen sich nicht in eine sinnvolle Reihenfolge bringen. Stattdessen soll der Sachbearbeiter Freiheiten bekommen, um selbst zu entscheiden. Das ist nur mit Workarounds in BPMN abbildbar, die spätestens bei komplexeren Szenarien, die beispielsweise Entscheidungsphasen oder Abhängigkeiten umfassen, dafür sorgen, dass das Modell explodiert.

An der Stelle kann CMMN helfen. Der Standard wurde im Mai 2014 bei der OMG in Version 1.0 verabschiedet und ist in Version 7.2 der Camunda BPM-Plattform umgesetzt. Folgende Abbildung zeigt die Case Definition für das Underwriting:

Der unstrukturierte Teil des Underwriting-Prozesses lässt sich als Case Definition in CMMN darstellen (Abb. 2).

Der unstrukturierte Teil des Underwriting-Prozesses lässt sich als Case Definition in CMMN darstellen (Abb. 2).

Teilweise ähneln die Symbole der BPMN. Neben dem Case als Ganzes gibt es Human Tasks (woraus Aufgaben für eine Aufgabenliste entstehen), Process Tasks (wenn BPMN-Prozesse in einem Case gestartet werden sollen), Meilensteine und weitere Eckpunkte und Aufgaben. Alle Notationselemente lassen sich online nachschlagen [3]. Es gibt auch ein Poster [4], das Details dazu auflistet.

Genau wie BPMN 2.0 wird auch das Modell der CMMN 1.0 als XML-Datei gespeichert und lässt sich dann direkt in der Engine ausführen. Bisher gibt es übrigens nur ein grafisches Modellierungswerkzeug das CMMN überhaupt beherrscht, den CMMN Web Modeler [5]. Mit steigender Akzeptanz von CMMN sollte sich das allerdings schnell ändern. Camunda plant beispielsweise ein auf dem bpmn.io [6]-Projekt aufsetzendes
Modellierungswerkzeug.

Die Funktionsweise von CMMN kann man sich am besten verdeutlichen, wenn man die resultierende Oberfläche eines Systems anschaut:

Beispielhafte Oberfläche für eine auf CMMN basierende Case-Management-Anwendung (Abb. 3)

Beispielhafte Oberfläche für eine auf CMMN basierende Case-Management-Anwendung (Abb. 3)

Obige Abbildung zeigt eine mit JavaServer Faces implementierte GUI (der Quellcode ist ebenfalls im GitHub-Projekt enthalten), die aus dem Piloten eines realen Projekts extrahiert wurde. Sie gliedert sich in mehrere Bereiche:

Eine Ausnahme bilden Aktivitäten mit einem sogenannten Wächter ("Sentry"). Sie sind durch eine kleine Raute an der Aufgabe markiert. Der Wächter entscheidet, ob eine Aktivität überhaupt verfügbar gemacht wird – ansonsten bleibt sie "available" und erscheint erst gar nicht in der Benutzeroberfläche. Der Statusname "available" ist an der Stelle leider unglücklich und missverständlich: Es ist wirklich so, dass ein "available" Task erst auf "enabled" oder "active" zu schalten ist, bevor er sich abarbeiten lässt. Für den Wissensarbeiter ist er also nicht verfügbar, außer der Wächter gibt ihn frei.

Es gibt zwei mögliche Bedingungstypen für die Wächter: Die Verfügbarkeit der Aktivität kann davon abhängen, dass eine andere Aufgabe beendet wurde, was visuell durch eine gestrichelte Linie dargestellt wird. Wichtig: Dies ist kein Sequenzfluss wie in BPMN, sondern visualisiert lediglich die kausale Abhängigkeit. Der Wächter kann aber auch beliebige Bedingungen prüfen und dabei Daten des Kontexts verwenden. Im Beispiel steuert die Information, ob der Kunde ein Raucher ist oder nicht, ob die Option, sein Risikoprofil anzupassen, verfügbar wird. Die Information hängt am Antragsobjekt im Kontext des Cases. In der Oberfläche sind daher die Aufgaben "review interview result" sowie "adjust risk profile for smoker" standardmäßig nicht zu sehen.

Das ermöglicht es nun relativ einfach, eine Art Speisekarte mit Aufgaben für den Wissensarbeiter zu definieren. Wichtige Regeln lassen sich im Modell hinterlegen, um dem Wissensarbeiter seine Tätigkeit so einfach wie möglich zu machen. Zur Laufzeit hat der Mensch dann die Kontrolle – in den durch CMMN gesetzten Grenzen. Wenn man jetzt noch Phasen (Stages) und Meilensteine (Milestones) verwendet, kann man sehr umfassende Cases definieren.

Typische Szenarien für CMMN sind in Versicherungen neben den Anträgen die Schadensabwicklungsprozesse. Ein weiteres Einsatzgebiet sind medizinische Anwendungen wie ie Behandlung eines Patienten im Krankenhaus oder in einer Reha-Einrichtung. Ansonsten lässt sich CMMN auch verwenden, um Ausnahmebehandlung abzubilden. In den Fällen kann der eventuell vollautomatisierte Prozessfluss unterbrochen werden, um einen Problemfall durch den Menschen zu klären. Beispiele dafür sind Zuordnungsprobleme bei automatisierten Dokumenteneingangsprozessen, Leseprobleme bei Scanstrecken, Ausnahmebehandlung in Callcentern und so weiter.

CMMN kann des Weiteren auch als ein Schritt auf dem Weg zu einem BPMN-Modell gesehen werden, denn eventuell stößt die direkte Vollautomatisierung eines bisher manuell durchgeführten Prozesses auf Ablehnung bei den Sachbearbeitern. In dem Fall lassen sich dem Bearbeiter über CMMN mehr Eingriffsmöglichkeiten bieten, um die Akzeptanz zu erhöhen. Den Grad der Automatisierung kann man dann schrittweise mit wachsendem Prozessverständnis bei den Mitarbeitern erhöhen. Dabei kann auch die Auswertung der bereits gesammelten Audit-Daten der CMMN-Engine helfen.

Für ein besseres Verständnis soll als konkretes Beispiel Camunda BPM dienen. Camunda hat sich, in Abgrenzung zu sogenannten Zero Code Suites, Entwicklerfreundlichkeit auf die Fahne geschrieben. Dementsprechend kann man eine Process Engine mit Standardkonfiguration und In-Memory-Datenbank mit einer Zeile Java hochfahren:

ProcessEngine engine = new
StandaloneInMemProcessEngineConfiguration().buildProcessEngine();

Danach lässt sich mit der Java API der Camunda Engine arbeiten, was im Artikel anhand eines JUnit-Testcases gezeigt wird. Die in JSF entwickelte Oberfläche benutzt die gleiche API, um Informationen zu lesen oder Änderungen an der Case-Instanz anzustoßen. Die Engine lässt sich genauso gut per REST-API steuern, sodass die Verwendung auch in anderen Szenarien möglich wird, zum Beispiel in JavaScript-, .NET- oder PHP-Anwendungen.

Der folgende Quelltextauszug zeigt einen Ausschnitt eines Testcases, der eine neue Case-Instanz startet. Wer Camunda kennt, wird die Parallelen zu BPMN-Prozessinstanzen erkennen. Tatsächlich wurde CMMN in die bestehende Engine integriert und lässt sich eng mit BPMN verzahnen.

// HashMap containing variables to be added to case instance

VariableMap variables =
Variables.createVariables().putValue("application",
new Application());

// create the case instance, this persists it in the database too
CaseInstance caseInstance =
processEngine.getCaseService().createCaseInstanceByKey(
"underwriting", variables);

// load tasks via Query API and assert that we have one task
// created (corresponding to one active Activity)
List<Task> tasks = processEngine.getTaskService().
createTaskQuery().list();
assertEquals(1, tasks.size());
// use camunda assertions to check we created the right task:
assertThat(tasks.get(0)).hasDefinitionKey("PI_humanTaskDecide");

// load all so called "executions" of a Case Instance, basically
//corresponding to Activities in our case
List<CaseExecution> caseExecutions =
processEngine.getCaseService().createCaseExecutionQuery().list();
for (CaseExecution caseExecution : caseExecutions) {
if (caseExecution.isEnabled()) {
System.out.println("Possible to start ('enabled'): " +
caseExecution.getActivityName() + " [" +
caseExecution.getActivityType() + "]");
} // else...
}

// complete task - changes the state of the case instance
processEngine.getTaskService().complete(tasks.get(0).getId());

// we could check completed activities now:
processEngine.getHistoryService().
createHistoricCaseActivityInstanceQuery()
.caseInstanceId(caseInstance.getId()).list();

Einer Case-Instanz lassen sich Daten übergeben, die auch in den Wächtern verwendet werden, um Bedingungen zu formulieren. Camunda verwendet dafür JUEL (Java Unified Expression Language), sodass die erwähnte Prüfung, ob es sich um einen Raucher handelt, vergleichsweise einfach ausfällt (sofern man annehmen kann, dass es ein entsprechendes Attribut in der Klasse Application gibt).

Ein Blick in das unten gezeigte CMMN-XML zeigt, wie eine Aktivität mit Sentry definiert wird. Wie man erkennen kann, ist das XML-Format nicht weiter kompliziert. Außerdem lassen sich alle Aktivitäten in CMMN an unterschiedlichen Stellen im Modell wiederverwenden. Deswegen ist der Human Task separat definiert und als sogenanntes Plan Item in den Case eingebunden.

<cmmn:planItem id="PI_humanTaskSmoker" definitionRef="humanTaskSmoker"
entryCriteriaRefs="sentrySmoker" />

<cmmn:sentry id="sentrySmoker">
<cmmn:ifPart>
<cmmn:condition>
<cmmn:body>${application.smoker}</cmmn:body>
</cmmn:condition>
</cmmn:ifPart>
</cmmn:sentry>
<cmmn:humanTask id="humanTaskSmoker" name="adjust risk profile for
smoker" isBlocking="true" camunda:assignee="demo"
camunda:formKey="app:adjust-smoker-risk-profile.jsf" />

Lässt man den Unit-Test laufen, kann man sich den Status der Aktivitäten im Case nach dem Start auf der Konsole anschauen oder grafisch über ein CMMN-Monitoring-Plug-in für Camunda Cockpit [7], das im Browser laufende Monitoring-Tool der Plattform.

Übersicht der Status
Aktivitätsname Aktivitätstyp Status Bemerkungen
review interview result Human Task Available kann erst nach 'tele-interview' gestartet werden
adjust risk profile for smoker Human Task Available kann nur bei Rauchern gestartet werden
approved Milestone Available kann erst erreicht werden, wenn 'decide on application' mit 'approve' abgeschlossen wird
rejected Milestone Available kann erst erreicht werden, wenn 'decide on application' mit 'reject' abgeschlossen wird
comment from co-underwriter Human Task Enabled kann manuell gestartet werden
tele-Interview with applicant Human Task Enabled kann manuell gestartet werden
doctor information request Process Task Enabled kann manuell gestartet werden
decide on application Human Task Active läuft
Underwriting Case Active gesamte Case Instance läuft ebenfalls


Wird anschließend beispielsweise das "tele-interview" mit dem Kunden durchgeführt und die entsprechende Aufgabe abgeschlossen, ist die Aktivität "review interview result" verfügbar. Sind alle relevanten Aufgaben (es gibt dafür weitere Attribute, die in diesem Artikel nicht weiter betrachtet werden) erledigt, beendet der Prozess die Case-Instanz.

Dies soll als kurzer Einblick in CMMN genügen, bei Interesse lässt sich das gesamte Beispiel herunterladen [8]. Um es benutzen zu können, sollte eine aktuelle JBoss-Distribution von camunda [9] verwendet werden (JBoss wegen der JSF-Oberfläche). Alternativ lässt sich ein CMMN-Modell von der Pike auf selbst erstellen. Dazu steht ein Online-Tutorial [10] zur Verfügung.

Es gibt Fälle, in denen Geschäftsprozesse als Ganzes in CMMN behandelt werden sollten. Die Erfahrung zeigt jedoch, dass es häufig sinnvoll ist, BPMN und CMMN zu kombinieren. Die folgende Abbildung zeigt den Fall für das Fachbeispiel, in dem übergreifende Prozes strukturiert, die Entscheidungsphase unstrukturiert, einzelne Aktivitäten wie das Abfragen der Informationen beim Hausarzt aber wieder strukturiert ablaufen.

BPMN und CMMN lassen sich kombinieren, um stets das richtige Werkzeug für eine Aufgabe nutzen zu können (Abb. 4).

BPMN und CMMN lassen sich kombinieren, um stets das richtige Werkzeug für eine Aufgabe nutzen zu können (Abb. 4).


Aktuell erlauben die Standards nur eine Verzahnung von CMMN zu BPMN, aber nicht andersherum. Der Grund dafür ist, dass BPMN standardisiert wurde bevor es CMMN gab. Es ist zu erwarten, dass aber auch der Weg von BPMN zu CMMN standardisiert wird. Derzeit kann man die Zusammenarbeit in umgekehrter Richtung mit Workarounds oder Herstellererweiterungen realisieren.

Die Kombination der beiden Standards ist deswegen so wichtig, da man so wirklich das richtige Werkzeug für die aktuelle Aufgabe verwenden kann. Es gibt strukturierte und unstrukturierte Prozesse oder Prozessteile, bei denen man sich mit dem falschen Werkzeug schwer tut. In Camunda beispielsweise wurden aus dem Grund beide Standards in einer Engine kombiniert. Für die Zukunft ist es nicht unrealistisch, dass die Standards zusammenwachsen.

CMMN ist eine gute Ergänzung zu BPMN für Prozesse, die ein hohes Maß an Flexibilität benötigen. Die Spezifikation hat die Praxiserfahrung vieler Hersteller und Berater vereint und ist brauchbar. Da der Standard noch jung ist, existieren noch wenig verfügbare Beispiele und nutzbare Werkzeuge. Das wird sich aber sicherlich in diesem Jahr ändern. Die Ähnlichkeit der Symbole zu denen aus BPMN lässt vermuten, dass sie schnell auf Akzeptanz stoßen werden. Für jemanden, der ein neues Projekt mit unstrukturierten Prozessteilen startet, kann ein Blick auf CMMN lohnen.

Bernd Rücker
ist Mitgründer der Firma camunda. Als erfahrener Softwareentwickler, Trainer und Berater hat er sowohl an Process-Engines direkt mitgearbeitet als auch zahlreiche BPM-Projekte begleitet.
(jul [11])


URL dieses Artikels:
https://www.heise.de/-2569883

Links in diesem Artikel:
[1] https://github.com/camunda/camunda-consulting/tree/master/showcases/underwriting
[2] http://camunda.org
[3] http://docs.camunda.org/latest/api-references/cmmn10/
[4] http://www.opitz-consulting.com/fileadmin/redaktion/pdf/sonstiges/acm-in-practice_poster-a3_sicher.pdf
[5] http://cmmnwebmodeler.com/
[6] http://bpmn.io/
[7] https://github.com/camunda/camunda-acm-plugin/tree/master/
[8] https://github.com/camunda/camunda-consulting/tree/master/showcases/underwriting
[9] http://camunda.org/download/
[10] http://docs.camunda.org/latest/guides/getting-started-guides/cmmn/
[11] mailto:jul@heise.de