Case Management und CMMN für Entwickler

Inhaltsverzeichnis

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 verfügbar und lässt sich auf der quelloffenen BPM-Plattform 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:

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.

Auftritt CMMN

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:

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. Es gibt auch ein Poster, 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. Mit steigender Akzeptanz von CMMN sollte sich das allerdings schnell ändern. Camunda plant beispielsweise ein auf dem bpmn.io-Projekt aufsetzendes
Modellierungswerkzeug.

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

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:

• Kontext: Um den Menschen (im Case Management ist vom "Wissensarbeiter" die Rede) zu befähigen, gute Entscheidungen zu treffen, sollen ihm möglichst viele Informationen zum aktuellen Fall zugänglich sein. Das können Stammdaten, verlinkte Entitäten, Dokumente oder Notizen sein.
• Aktivitätsübersicht: Ein Herzstück von CMMN sind die Aktivitäten (zum Beispiel Human Tasks oder Process Tasks).Sie sind einem Lebenszyklus unterworfen, dergleich näher erläutert wird. Dies führt dazu, dass Aktivitäten entweder aktiv sind ("active", also gerade laufen) oder aber verfügbar ("enabled"). Verfügbare Aktivitäten lassen sich manuell vom Menschen starten, wodurch sie in den aktiven Zustand wechseln.
• Formular für Aufgaben: Wird eine Aufgabe ("Human Task") abgearbeitet, definiert man dafür typischerweise ein Formular, in dem sich zum Beispiel relevante Eingaben tätigen und die Aufgaben abschließen lassen.

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.