BPM meets APM: Systemübergreifendes Prozessmonitoring auf Basis von Open Source - der Prototyp

Geschäftsprozesse laufen nicht nur in der Process Engine ab und sind (leider) nicht immer voll automatisierbar. Häufig liegt ein Szenario wie in der nebenstehenden Abbildung vor: Es gibt eine Process Engine und ein oder mehrere Drittsysteme. Diese Drittsysteme werden, wie Holger Hagen schon im ersten Teil dieses Blog-Zweiteilers erklärt, ausgehend beispielsweise in Human Tasks von den Prozessbearbeitern aufgerufen, um dort Aktionen durchzuführen oder Hintergründe zu recherchieren.

Diese Vorgänge in Drittsystemen sind aus Prozesssicht nicht nachvollziehbar. In diesem Teil des Blogs beschreibe ich die Umsetzung eines Prototyps, der diese Lücke schließt. Er soll beweisen, dass mit dem entwickelten Konzept und der Verbindung von BPM und APM systemübergreifendes Monitoring möglich wird. Der Prototyp basiert dabei unter anderem auf Camunda BPM und dem Elastic-Stack. Dies sind gängige Technologien, die bei unseren Kunden weit verbreitet sind. Das Konzept ist aber analog auch auf andere Technologien anwendbar. Die Umsetzung erfolgte in mehreren Stufen, die ich hier nacheinander beschriebe.

Schritt 1: Anbindung der Process Engine an die Event-Infrastruktur und Visualisierung der KPIs im zugehörigen Dashboard

Das erste Ziel, um Prozessmonitoring mit bestehenden Open-Source-Technologien zu ermöglichen ist die Anbindung der Process Engine – in unserem Falle Camunda BPM – an die Monitoring-Infrastruktur. Als Basisinfrastruktur für das Monitoring habe ich mich, wie bereits erwähnt, für Teile des Elastic-Stacks entschieden.

Die Integration von Elasticsearch und Camunda BPM kann auf zwei unterschiedliche Weisen umgesetzt werden: (1) Durch ein Plugin für Camunda BPM, das durch einen History Event Handler die entsprechenden Daten nach Elasticsearch schreibt oder (2) durch das Pollen der gewünschten REST-API der Process Engine und das anschließende Schreiben nach Elastic. Ich habe mich für die erste Variante entschieden, da sich diese besser in eine ereignisbasierte Verarbeitung integriert. Um den Prozess zu Monitoren werden also Prozessevents über das Plugin nach Elasticsearch geschrieben.

Nachdem die Prozessevents in Elasticsearch vorliegen, ist eine Kennzahlendefinition mit Kibana möglich. Ziel ist es die Prozessdurchführungsdaten im selben Tool zu visualisieren, indem auch schon andere KPIs analysiert werden. Durch Kibana Abfragen werden Kennzahlen, wie die Anzahl der aktiven Prozessinstanzen oder abgeschlossene Aufgaben in Echtzeit analysierbar. Folglich ist eine laufende Überwachung und ein Soll-Ist-Abgleich möglich. Und das alles nur durch ein Plugin für Camunda BPM. 

Der PoC kann folgende Prozesskennzahlen in Kibana abbilden: Anzahl abgeschlossener, aktiver Prozessinstanzen, Anzahl abgeschlossener, aktiver Aufgaben. Diese Kennzahlen können außerdem noch in ihrem zeitlichen Verlauf abgebildet werden.

Schritt 2: Verarbeitung der Ereignisse mit Complex Event Processing

Das Zählen von Ereignissen aus einem Prozess reicht allerdings nicht aus, um alle interessanten Kennzahlen abzubilden. Die Prozessdurchlaufzeit beispielsweise kann durch das Zählen von Tasks in einem Prozess nicht ermittelt werden. Daher war es im nächsten Schritt notwendig, die Prozessereignisse zu verarbeiten. Als Methode zur Ereignisverarbeitung habe ich mich für Complex Event Processing (CEP) entschieden. Dazu nutze ich das Open-Source-Tool Siddhi, eine Alternative dazu wäre Esper.

CEP ist eine Methode zur Identifikation von Mustern in Ereignisströmen. Die Muster werden genutzt, um aus einer Menge an primitiven Events neue höherwertige, komplexere Events zu erzeugen. Vorteil dieser Methode ist die Flexibilität. Denn die verwendeten Muster zur Kennzahlenerfassung können ohne größeren Aufwand angepasst werden. Zudem können einfach weitere Kennzahlen und Drittsysteme ergänzt werden. Darüber hinaus wird für CEP häufig eine Hochsprache zur Formulierung der Abfragemuster genutzt. Durch die Nutzung einer Hochsprache wird der BPMN-Gedanke, dass sowohl ein Facharbeiter als auch ein Entwickler das Modell verstehen und erweitern kann, weitergeführt.

Die Durchlaufzeit beispielsweise wird über ein solches CEP-Muster berechnet. Primitive Prozessereignisse werden in die höherwertige Prozessdurchlaufzeit umgewandelt. Genauer wird durch das Muster die zeitliche Differenz zwischen dem Endereignis (B) eines Prozesses und dessen Startereignis (A) berechnet: A → B: Dann Durchlaufzeit = Endzeitpunkt(B) – Startzeitpunkt(A). Die höherwertigen Events werden wieder zurück nach Elasticsearch geschrieben.

Durch die Verarbeitung der Prozessereignisse ist die Basis für die nächste Ausbaustufe, die Verknüpfung mit Ereignissen aus dem APM, geschaffen.

Schritt 3: Verknüpfung des BPM mit dem APM

Ziel des Projekts war es nicht nur Standardprozesskennzahlen mit Open-Source-Tools abzubilden, sondern über den Tellerrand hinauszublicken und Vorgänge in anderen Systemen, beispielsweise während eines Human Tasks, transparent zu machen.

Die ausführende BPM-Engine hat keinerlei Kenntnis darüber, was während eines Human Task gemacht wird. Die vom Benutzer verwendeten Systemen werden aber bereits häufig überwacht. Dafür nutzt man das Application Performance Management. Es liegen somit bereits viele Daten vor, welche „lediglich“ noch mit den Prozessdaten verknüpft werden müssen.

Das APM erfasst mit dem Open Source inspectIT Ocelot Agent unter anderem Traces. Ein Trace beschreibt einen Ablaufpfad, beispielsweise von einem eingehenden HTTP-Request bis zum Laden der Daten aus der Datenbank. Diese Traces werden dann in einem Event Store, wie Elasticsearch oder auch Kafka, abgelegt. Ausgangsbasis für die Verknüpfung der beiden Welten des BPM und APM ist also das gleiche Open Source Speichermedium, Elasticsearch. Darüber hinaus können auch APM KPIs mit Kibana dargestellt werden: Ocelot meets Elastic – Better Java Instrumentation for Elastic APM via Jaeger.

Die Verknüpfung der Events der beiden Quellen wird wiederum mit CEP umgesetzt. Die Ereignisse aus dem Prozess werden mit den passenden Traces aus den Drittsystemen korreliert. Dabei ist es notwendig eine ereignisgenaue Korrelation zu erreichen, sodass die Vorgänge in externen Systemen richtig korreliert werden können. Durch die Verknüpfung der Daten aus dem BPM und APM wird es möglich nachzuvollziehen, was beispielsweise in einem Human Task in einem anderen System passiert, indem die Traces der HTTP-Requests aus dem APM-Umfeld mit den Events aus dem Human Task verknüpft werden.

Durch CEP können diese technischen Daten fachlich weiterverarbeitet werden. So wird beispielsweise in dem Prototyp eine Kennzahl erzeugt, welche die Anzahl an Suchvorgängen bei der Erfassung eines Kunden in einem externen System zählt. Somit kann die Navigation eines Benutzers durch eine Anwendung mit der zugehörigen Prozessinstanz ausgewertet werden. Es entsteht so eine viel größere Datenbasis, die für eine Analyse von Schwachstellen und Verbesserungspotenzialen im Prozess genutzt werden kann.

Schritt 4: Systemübergreifende Ablaufvisualisierung

Die verknüpften Daten (Prozessevents und Traces) können jedoch nicht nur dafür genutzt werden, um Kennzahlen zu definieren. Denn diese allein reichen beispielsweise nicht aus, um eine Ursachenanalyse durchzuführen. Aus diesem Grund wurde zusätzlich zu dem Kibana Dashboard eine Process-Mining-artige Visualisierung entwickelt. Sie hat die Aufgabe den Prozessverlauf mit allen externen Ereignissen darzustellen.

Die grafische Analyse wurde mit Angular umgesetzt. Sie ermöglicht es, die tatsächlich durchlaufenen Prozesspfade nachzuvollziehen. Zudem können zusätzlich zu dem Prozessverlauf auch die Vorgänge in externen Systemen visualisiert werden. Die externen Ereignisse können dabei als Ablaufpfade oder abstrahierte fachliche Ereignisse dargestellt werden.

Diese Darstellungsform soll die Möglichkeit bieten, beispielsweise zeitliche Treiber eines Prozesses zu erkennen – ähnlich des Process Minings. Zudem erlaubt eine solche Visualisierung die detaillierte Analyse von Ausnahmefällen, welche im Monitoring häufig von großer Bedeutung sind.

Es ist jedoch zu beachten, dass es sich bei der Illustration nur um einen Prototyp handelt, welcher die grundlegende Idee und Vorstellung abbilden soll. Wir arbeiten aktuell an anderen Visualisierungsideen und möglichen vorhandenen Open-Source-Tools zu deren Umsetzung, um herauszufinden, welche am besten geeignet sind.

Zusammenfassung

Ziel des Projekts war die Erhöhung der Transparenz eines Geschäftsprozesses durch erweiterte Monitoring-Möglichkeiten unter der Verwendung von bestehenden Open-Source-Tools. Genauer sollen Aktionen in einem Drittsystem während eines Prozesses transparenter werden. Dazu wurden Ereignisse aus dem Prozess mit Ereignissen aus den verwendeten Drittsystemen verknüpft und die beiden Welten des BPM und des APM zusammengebracht.

Die prototypische Umsetzung zeigt, dass eine solche Verbindung machbar und sinnvoll ist, um mehr Transparenz im Prozessmonitoring zu schaffen.  Das entworfene Konzept ist durch die lose Kopplung der Komponenten, die Nutzung einer Instrumentierung anstelle einer Anpassung der Drittsysteme und die quellenunabhängige Verarbeitung durch CEP, auf andere Anwendungsfälle übertragbar. Auch sind die eingesetzten Open-Source-Tools im Sinne eines best-of-breed-Ansatzes austauschbar. Hier bietet sich ein Blick auf die OpenAPM-Initiative an. Für eine Instrumentierung mit dem inspectIT Ocelot Agent müssen die Systeme lediglich in einer JVM betrieben werden.

Wir sind ganz begeistert in Anbetracht der vielfältigen Möglichkeiten, die dieser Ansatz bietet. Von daher sind wir schon sehr neugierig, was die Zukunft hier bringen wird. Gerne diskutieren wir das Konzept auch einmal mit Ihnen in Ihrem konkreten Kontext. Kommen Sie einfach auf uns zu!