5 Minuten Lesezeit

Geschäftsprozessautomatisierung mit Camunda: Fehlertolerante Implementierung von BPM-Schemata

BPMN

Business

Comunda

Spring Boot

In der heutigen digital geprägten Welt erfordert die Erhaltung eines Wettbewerbsvorteils schlanke und effiziente Geschäftsprozesse. Die Automatisierung ist eine der wichtigsten Lösungen, um dies zu erreichen. Nach Angaben von Statista wird der Markt für Geschäftsprozessmanagement (BPM) bis 2025 einу Größe von 14,4 Milliarden US-Dollar erreichen. Die steigende Beliebtheit und Nachfrage nach BPM-Tools wie Camunda, die für ihre Flexibilität und Skalierbarkeit bekannt sind, zeugen von diesem Trend. Da Unternehmen nach zuverlässigen Werkzeugen zur Optimierung ihrer Abläufe suchen, erweist sich Camunda als Vorreiter und ebnet den Weg für innovative, fehlertolerante Automatisierungslösungen in der Branche.

Was ist Camunda?

Einfach ausgedrückt ist Camunda eine Open-Source-Plattform für Workflow- und Entscheidungsautomatisierung, die Geschäftsanwender und Softwareentwickler zusammenbringt. Mit seinen robusten Werkzeugen und Funktionen bietet Camunda Möglichkeiten, BPMN-Workflows (Business Process Model and Notation) zu entwerfen, zu implementieren und zu optimieren, um Geschäftsabläufe reibungsloser und transparenter zu gestalten.

Camunda, Spring Boot & BPMN: Verständnis der Konzepte

Drei Hauptakteure haben die Landschaft des Geschäftsprozessmanagements umgestaltet: Camunda, Spring Boot und BPMN. Jeder von ihnen hat seine eigene Nische gefunden und bietet einzigartige Funktionen, die verschiedene Facetten des Prozessmanagements abdecken. Wenn sie jedoch kombiniert werden, bilden sie ein unvergleichliches Kraftpaket, das in der Lage ist, die Abläufe in digitalen Unternehmen zu revolutionieren.

Camunda: Camunda ist nicht nur ein weiteres Tool in der umfangreichen BPM-Toolbox, sondern ein herausragendes. Als robuste Open-Source-Plattform ist Camunda auf die Automatisierung von Arbeitsabläufen und Entscheidungen spezialisiert. Ihr Hauptziel? Die nahtlose Verschmelzung der Welten von Geschäftsstrategen und Softwareentwicklern. Auf diese Weise wird sichergestellt, dass die Konzeption, das Design und die Implementierung von Geschäftsprozessen effizient, transparent und kohärent sind.

Spring Stiefel: Spring Boot nimmt die Stärke des Spring-Frameworks und hebt sie an. Durch das Angebot einer optimierten Methode zum Erstellen eigenständiger Java ist es zur Anlaufstelle für Entwickler geworden, die Standardcode minimieren und direkt in das Herz projektspezifischer Funktionalitäten eintauchen möchten. Seine Stärke liegt in seiner Flexibilität und seinem Konvention-über-Konfiguration-Ansatz, der sich für die Idee intelligenter Standardeinstellungen einsetzt. Dieser Ansatz ermöglicht es Entwicklern, skalierbare Anwendungen schneller zu erstellen und eine zeitnahe Bereitstellung und konsistente Leistung sicherzustellen.

BPMN: Wenn wir die BPMN personifizieren sollten, wäre sie der eloquente Linguist der Geschäftswelt. Als weltweit anerkannter Standard bietet die BPMN ein visuelles Vokabular für den Entwurf von Geschäftsprozessen, das diese für eine Vielzahl von Beteiligten leicht verständlich macht. Diese universelle Sprache stellt sicher, dass die technischen Nuancen eines Prozesses sowohl von technisch versierten Programmierern als auch von Geschäftsstrategen entziffert werden können, was die Zusammenarbeit und eine fundiertere Entscheidungsfindung fördert.

Die Synergie der Automatisierungsmöglichkeiten von Camunda, der Entwicklungsfreundlichkeit von Spring Boot und der standardisierten BPMN-Notation bietet Unternehmen ein dynamisches Dreiergespann. Zusammen stellen sie sicher, dass BPM-Schemata von theoretischen Konstrukten auf dem Papier in umsetzbare, reale Implementierungen übergehen. Das Endziel? Geschäftsprozesse zu kultivieren, die agil und belastbar sind und perfekt auf die sich entwickelnden Anforderungen der modernen digitalen Unternehmenslandschaft abgestimmt sind.

BPMN-Basiskomponenten

Für diejenigen, die mit der BPMN nicht vertraut sind, ist das Verständnis ihrer wesentlichen Komponenten entscheidend. Diese Komponenten bilden die Grundlage für jedes BPMN-Diagramm.

Veranstaltungen

Sie kennzeichnen etwas, das während eines Prozesses passiert. Ereignisse können einen Ablauf beginnen, unterbrechen oder beenden und werden oft als Kreise dargestellt.

Gateways

Gateways sind für die Entscheidungsfindung innerhalb des Prozesses zuständig. Auf der Grundlage von Bedingungen steuern sie den Ablauf des Prozesses und werden normalerweise als Rauten dargestellt.

Aktivitäten

Aktivitäten stellen die geleistete Arbeit dar. Sie können Aufgaben oder Teilprozesse sein und werden als abgerundete Rechtecke dargestellt.

Verbinden von Objekten

Diese Elemente, darunter Sequenzflüsse, Nachrichtenflüsse und Assoziationen, veranschaulichen die Abfolge von Prozessen und den Fluss von Nachrichten.

Swimlanes

Diese kategorisieren BPMN-Elemente entweder nach Rolle (z. B. Manager, Buchhalter) oder System (z. B. ein ERP-System).

Artefakte

Diese bieten zusätzliche Informationen über den Prozess. Zu den gängigen Artefakten gehören Datenobjekte, Gruppen und Anmerkungen.

Vor- und Nachteile von Camunda

Wie jede technologische Lösung bringt auch Camunda eine Reihe von Vorteilen und Herausforderungen mit sich. Hier ist ein umfassender Blick auf die Vor- und Nachteile.

Vorteile:

Flexible und einfache Integration mit Java-Anwendungen durch Spring Boot.
Eine intuitive Modellierungsoberfläche für BPMN 2.0.
Bietet detaillierte Analysen zu Prozessmetriken.

Nachteile:

Die Lernkurve für technisch nicht versierte Benutzer könnte steiler sein.
Es ist ein guter Ausgangspunkt, aber betrachten Sie es nur als Basis - obwohl Camunda eine leistungsstarke Workflow-Engine ist, benötigen Sie dennoch weitere Software-Entwicklung.

Rationalisierung überfrachteter BPMN-Diagramme

Harte Realität

Camunda soll dafür sorgen, dass Entwickler und Analysten die gleiche Sprache sprechen, aber oft kommt die Realität dazwischen.

Microservices fallen aus, Benutzer geben falsche Daten ein, alles kann passieren. In diesem Fall beginnt man, das schöne analytische Diagramm mit verschiedenen Fehlerbehandlungen, Loggern und alternativen Pfaden zu verschönern. Der Analytiker entwirft ein schönes, prägnantes und verständliches Schema. Es hat ein paar Delegierte und bietet logische Pfade für den Prozessfluss unter verschiedenen Umständen. So sieht ein vorläufiges Schema aus, wenn es in die Hände eines Entwicklers gelangt:

Allerdings gibt es auch Nachteile. Ein solches Schema könnte eine kurze Aufgabenbeschreibung enthalten, wie z. B. "Überprüfe den Kunden", die mehrere Schritte, eine Entscheidungsfindung auf der Grundlage jedes Ergebnisses und die Zusammenstellung der abgeleiteten Entscheidungen zu einem einzigen Ergebnis impliziert, möglicherweise mit anschließender Übertragung dieses Ergebnisses an externe Systeme.

Es ist klar, dass an diesem Punkt Fehlerbehandler, Logger und technische Dienstelemente im Diagramm oder im Code erscheinen. Auf diese Weise wird eine "analytische" Aufgabe in der Java-Implementierung umfangreich und komplex, oder die Anzahl der Schritte im Schema nimmt zu, wobei jeder von Handlern und alternativen Pfaden begleitet wird. Infolgedessen wird das Schema schnell unübersichtlich, schwierig zu unterstützen und zu ändern, und das Hinzufügen neuer Funktionen kann die Umstrukturierung eines großen Bereichs sowohl des Schemas als auch des Delegatencodes erfordern. Im Grunde genommen enthält es eine große Anzahl identischer Elemente.

Hier sehen Sie, wie das vorherige Schema in einem realen Einsatz aussehen könnte:

Natürlich hat sich das Schema erweitert und ist schwerfälliger geworden. Aber es gibt auch Vorteile: Alle Aufgaben sind atomar geworden, und es haben sich Verhaltenszweige für den Fall von Fehlern herausgebildet.

Erkennen des Problems

Wenn wir versuchen, das Schema und die Geschäftslogik des Java-Codes zu trennen und zu kapseln, können wir Folgendes tun:

Vermeiden Sie die Duplizierung ähnlicher Elemente im Schema.
Verwenden Sie eine universelle und wiederverwendbare Implementierung von Delegaten im Java-Code.
Optimieren und beschleunigen Sie den Ablauf des Prozesses.
Vereinfachen Sie den Umgang mit technischen Fehlern und legen Sie eine Logik für das Prozessverhalten fest, wenn sie auftreten - fast ohne die Beteiligung von Java-Code. Dies wird die Fehlersuche und die manuelle Analyse von fehlgeschlagenen Prozessen, die sich in einem Vorfall befinden, erheblich vereinfachen.
Drastische Verringerung der Anzahl von Prozessen, die bei technischen Ausnahmen in Zwischenfälle "verfallen".
Legen Sie eine solide Grundlage für die weitere Entwicklung.

Um die Arbeit mit dem Produkt zu erleichtern, ist es besser, das Schema in atomare Aufgaben zu zerlegen, das Gesamtvolumen der Schemaelemente zu reduzieren, die Anzahl der Service-Handler zu verringern, das Volumen des Java-Codes jedes Delegaten zu reduzieren und universelle Delegaten wiederzuverwenden und bei Bedarf ein sofortiges Refactoring durchzuführen. All dies impliziert automatisch das Schreiben von Unit-Tests für alle Delegaten und die Hauptpfade des Prozesses.

Zersetzung und Zerstäubung

Wenn man sich die Prozessanwendung genau anschaut und ihre Knotenpunkte analysiert, kann man viele sich wiederholende Funktionen erkennen: Abfragen an externe Systeme, Protokollierung, Fehlerbehandlung, Senden von Rückrufen usw. Mit anderen Worten, man muss die Prozessanwendung kritisch bewerten und Objekte identifizieren, die leicht gekapselt werden können... Aber in was? In Java-Code? Nein, das wäre unlogisch, denn in diesem Fall wäre das Schema eng mit seiner Java-Implementierung verbunden. In dieser Situation ist es sinnvoll, Prozesspools in Betracht zu ziehen.

Ein Prozesspool ist ein Schema für einen separaten Prozess, der seinen eigenen Kontext hat. Es ist erwähnenswert, dass es bequem ist, atomare Teile der Funktionalität vom Hauptprozess in solche Pools zu extrahieren, ebenso wie alle sich wiederholenden Momente: Senden von Benachrichtigungen, Anfragen an externe Systeme usw.

Es kann viele Prozesspools geben, und es wäre logisch, sie thematisch zu gruppieren. Zum Beispiel Abfragen an einen bestimmten Microservice, Alerting, Senden verschiedener Benachrichtigungen. Die Interaktion zwischen solchen Pools lässt sich leicht mit Camunda Messaging einrichten. Jedes Mal, wenn ein solcher Pool in der Camunda-Engine aufgerufen wird, wird eine bestimmte Nachricht übergeben, die einen bedingten Header und die Nummer des übergeordneten Prozesses für die Rückgabe einer Antwort sowie eine Reihe von Daten enthält, die für den Betrieb dieses spezifischen kleinen Pools erforderlich sind.

Hier sehen wir, wie der Hauptprozess (unten) eine Nachricht sendet, die der Starter eines anderen Pools abonniert hat. Wenn das Ereignis eintritt, startet der zweite Pool eine neue Instanz des Prozesses, stellt eine Anfrage und sendet eine Antwort zurück an den Hauptprozess, der daraufhin erfolgreich abgeschlossen wird. Während dieser Zeit wartet der Hauptprozess auf das Antwort-Ereignis vom externen Pool, an den er eine Anforderung gesendet hat. Wenn die Nachricht eintrifft, wird der Prozess fortgesetzt. Erfolgt innerhalb des angegebenen Zeitintervalls keine Antwort, geht der Prozess davon aus, dass die externe Berechnung nicht verfügbar ist oder fehlgeschlagen ist, und bricht ab.

Was dies bietet:

Möglichkeit zur Wiederverwendung von Code. Wenn Sie denselben Code mehrmals unter verschiedenen Bedingungen während des Prozesses aufrufen müssen, können Sie einfach bestimmte Meldungen erstellen und die entsprechenden atomaren Prozesspools aufrufen;
Abkapselung des Software-Implementierungsschemas von seiner geschäftlichen Darstellung. Es spielt keine Rolle, wie das Hauptschema umgestaltet wird oder welche Wege der Prozess nehmen wird. Alle Interaktionen sind bereits in separate Nebenprozesse verlagert worden, was völlige Flexibilität ermöglicht: einfach eine Anfrage stellen und auf eine Antwort warten.
Die Anzahl und die Wahrscheinlichkeit von Abstürzen des Hauptprozesses werden erheblich reduziert. Vor einer solchen Aufteilung befand sich der Prozess in einer Unsicherheit von 4 Zuständen:
Die Antwort ist eingetroffen.
Die Antwort kam nicht, weil der externe Microservice abgestürzt ist.
Die Antwort kam nicht, weil der Hauptprozess beim Senden der Anfrage abstürzte.
Die Antwort kam nicht, weil ein Timeout überschritten wurde.

Bei dieser Aufteilung befindet sich der Prozess immer in einem einzigen Zustand: entweder kam die Antwort, oder der Prozess wartete und wurde beendet. Für die Wirtschaft ist es von Bedeutung, wie genau der Prozess endete: ob es ein Fehler war oder nicht. Dies ist jedoch ein ordnungsgemäßer Abschluss und kein Zwischenfall. Dies ist wichtig, weil ein Prozess, der nicht in einem Zwischenfall feststeckt, keine Ressourcen "verbraucht" und Fehler leicht protokolliert, Statistiken gesammelt, Warnungen eingerichtet und analysiert werden können.

Es spielt keine Rolle mehr, was mit den kleinen Prozessen passiert. Sie können tun, was sie wollen: abstürzen, laufen... Nur das Ergebnis ist wichtig: die Antwort der externen Ressource. Und selbst dann nicht immer, denn der Hauptprozess sollte die Funktionalität externer Systeme nicht garantieren. So könnte es zum Beispiel sinnlos sein, dass der Prozess auf eine Antwort des Benachrichtigungs-Microservice wartet, da es überhaupt keine Antwort geben könnte.
Die Komplexität des Hauptprozesses wird stark reduziert. Komplexe Logik kann auf separate kleine Pools verteilt werden, die leichter zu debuggen sind. Die Client-Verifizierung könnte zum Beispiel so aussehen:

Hier können wir sehen, dass im externen Pool mehrere Aufgaben gleichzeitig aufgerufen werden. Gehen wir näher auf diesen Punkt ein.

Parallelisierung von Prozessberechnungen

Camunda ermöglicht die gleichzeitige Ausführung von Zweigen von Prozessberechnungen. Zu diesem Zweck gibt es ein spezielles Gateway, das so genannte Parallel Gateway, mit dem der Fluss in Parallelen aufgeteilt oder mehrere parallele Berechnungen in einem Strom zusammengeführt werden können. Es liegt auf der Hand, dass es zur Beschleunigung des Prozessflusses von Vorteil ist, bestimmte Aufgaben an parallele Threads zu delegieren. Wenn die Logik unabhängig ist, kann sie parallel ausgeführt werden, z. B. indem gleichzeitig Anfragen an externe Systeme gestellt werden und auf Antworten von allen gleichzeitig gewartet wird:

Jedes Mal, wenn ein solcher Übergang erfolgt, fallen Gemeinkosten für die Erstellung neuer Threads für die Aufgabenteilung und die Zusammenführung der Ergebnisse an. Es kann zu verschiedenen Sperrausnahmen kommen, und natürlich ist es nicht immer notwendig oder gerechtfertigt, immer so zu handeln, insbesondere ohne Tests, aber die Vorteile sind offensichtlich.

Bei sequentieller Ausführung entspricht die Gesamtausführungszeit der Summe der Ausführungszeiten der einzelnen Vorgänge. Im Gegensatz dazu entspricht sie bei paralleler Ausführung der Ausführungszeit des längsten Vorgangs. Unter den Bedingungen von nicht sofortigen Antworten von externen Quellen, Wiederholungen und Fehlern ist dieser Unterschied alles andere als unbedeutend. Ein weiterer unbestreitbarer Vorteil ist die Form der "freien Wiederholungen", d. h. während die längste Anfrage ausgeführt wird, haben die anderen Aufgaben hypothetisch die Möglichkeit, mehrmals fehlzuschlagen und zu versuchen, ihre Aktionen zu wiederholen, ohne die Gesamtausführungszeit der Aufgabe zu beeinflussen.

Ausnahmen und Wiederholungsversuche

Pleite? Das kommt vor. Die Standardversion von Camunda hat die Fähigkeit, eine fehlgeschlagene Transaktion zu wiederholen. Mit "Transaktion" meinen wir Camundas internen Mechanismus zur Ausführung von Delegatencode. Der Start einer Transaktion kann z.B. der "async before" oder "async after" Marker auf einer Aufgabe im Modeler sein. Wenn die Engine auf diese Markierung stößt, überträgt sie ihre Informationen in die Datenbank und startet einen neuen asynchronen Thread. Dies ist sehr wichtig. Unter "Transaktion" verstehen wir den Ausführungsabschnitt zwischen den Aufrufen der Methode .complete() im TaskService, gefolgt von der Aufzeichnung der Informationen in der Datenbank. Diese Transaktionen sind, wie andere auch, atomar.

Wenn eine technische Ausnahme auftritt, d. h. ein nicht betriebswirtschaftlicher Fehler, z. B. Dividieren durch Null und Vergessen einer Nullprüfung, führt die Transaktion einen Rollback durch und versucht, neu zu beginnen. Standardmäßig tut sie dies dreimal hintereinander ohne Pause. Ein Wiederholungsversuch beginnt, wenn eine reguläre Ausnahme auftritt, die in der BPMN-Welt als technische Ausnahme und nicht als BpmnError bezeichnet wird. Ein auftretender BpmnError stoppt den Prozess ohne weitere Wiederholungsversuche. Stellen Sie sich vor, wie dies die Resilienz des Prozesses erhöht.

Es ist sinnvoll, diese Funktion zu maximieren. Daher werden bei jedem Delegaten, der ein externes System anfordert, diese Markierungen gesetzt, die die Anzahl der Wiederholungsversuche und die Pause dazwischen angeben, und im Code des Delegaten wird die Logik dafür getrennt, wann der Prozess beendet werden soll und wann nicht. Sie gibt die volle Kontrolle über die Ausnahmebehandlung und die Wiederholungsmechanismen. Infolgedessen versucht der Prozess, die fehlgeschlagene Aufgabe mehrmals zu wiederholen, und erst nach einer Reihe von Fehlschlägen gibt er einen Fehler aus.

Die vielleicht größte Herausforderung ist die Behandlung von technischen Ausnahmen und BPMN-bezogenen Fehlern sowie die Gestaltung der Logik ihrer Behandlung für einen kontinuierlichen Ablauf des Prozesses. Wir haben bereits einige Fehler im Zusammenhang mit der Behandlung von Antworten aus externen Quellen diskutiert, als wir über die Aufteilung in Prozesspools sprachen. Wir möchten Sie daran erinnern, dass der eigentliche Aufruf in einem separaten Miniprozess gekapselt war und der Hauptprozess entweder eine Antwort erhielt und weiterging oder aufgrund einer Zeitüberschreitung den Weg "Ich habe keine Antwort erhalten" ging.

Schauen wir uns nun diesen sehr kleinen Prozess an:

Siehst du den Rahmen? Das ist ein Unterprozess. Er enthält spezifische Aufgaben und erfasst Fehler, die von internen Aufgaben ausgelöst werden. Darüber hinaus kann der Job-Executor in solchen Frames einen Job für den Timer erstellen, der die Ausführungszeit für alles innerhalb des Unterprozesses festlegt.

Wie funktioniert das? Der Ausführungsfluss erreicht den Unterprozess, erzeugt eine parallele Zeitverarbeitung und wartet entweder auf den Abschluss des darin enthaltenen Vorgangs oder, wenn der Timer zuerst abläuft, folgt er der Timer-Route. Wenn während des Prozesses eine Ausnahme ausgelöst wird, die der Unterprozessrahmen erfasst, stoppt der Prozess seine Ausführung im aktuellen Zweig an und folgt dem Fehlerzweig.

Es ist auch offensichtlich, dass es eine Option zur Erstellung von Antwort-Dispatches für kritische Anfragen gibt. Beachten Sie, dass die Fehlererfassung nur für BpmnError mit einem bestimmten Code funktioniert. Daher ist es technisch gesehen wichtig, jede Ausnahme abzufangen und einen BpmnError mit dem erforderlichen Code zu werfen, der für das ErrorBoundaryEvent funktioniert.

Die Fehlerbehandlung im Hauptprozess funktioniert auf ähnliche Weise. Aus mehreren Tasks werden logische Einheiten herausgefiltert, die in einem Unterprozessrahmen platziert werden können, wobei ein Listener für einen bestimmten Fehlercode eingerichtet wird. Allerdings gibt es hier zwei Nuancen. Der erste ist, dass es unpraktisch ist, mehrere identische Zweige mit Fehlerbehandlung zu erstellen, die sich nur im Code unterscheiden. Wenn sich die Fehlerbehandlungsstrategie ändert oder z. B. die Protokollierung, müssten viele Delegierte des Schemas neu entworfen werden, was nicht wünschenswert ist. Daher könnte man in Erwägung ziehen, ereignisbasierte Unterprozesse zu verwenden.

Im Kern handelt es sich dabei um einen separaten Unterprozess des Prozesspools, der nur dann gestartet wird, wenn ein bestimmtes Ereignis eintritt, das er abonniert hat. Wenn Sie beispielsweise einen solchen Unterprozess für das Ereignis BpmnError mit einem Code wie MyCustomBusinessError abonnieren, wird der Handler bei Eintreten dieses Ereignisses ausgelöst, und nach dessen Beendigung wird der Prozess korrekt beendet. Ja, er wurde nicht erfolgreich, aber korrekt beendet. In diesen Unterprozessen können Sie auch eine unterschiedliche Verarbeitungslogik für dasselbe Ereignis in Abhängigkeit von externen Bedingungen implementieren, z. B. die optionale Benachrichtigung über einen Anwendungsfehler, wenn der Prozess einen bedingten Punkt passiert.

Die zweite Nuance ist viel komplizierter. Im wirklichen Leben ist der Lebenszyklus eines jeden Prozesses wahrscheinlich in zwei Geschäftsphasen unterteilt: vor der Lead-Generierung und danach. Wenn ein Fehler auftritt, bevor die Daten zu einem Lead formatiert werden, kann der Prozess wahrscheinlich einfach beendet werden, wobei die aufgetretenen Schwierigkeiten mitgeteilt werden. Sobald der Lead generiert ist, ist dies nicht mehr möglich.

Wir empfehlen auch nicht, Prozesse zu beenden, wenn während des Prozesses rechtliche Verpflichtungen entstehen, z. B. wenn ein Vertrag unterzeichnet wird. Wie gehen wir mit solchen Fehlern um? Einige technische Fehler, z. B. im Zusammenhang mit der Nichtverfügbarkeit externer Dienste, werden durch automatische Wiederholungsversuche innerhalb einer vorher vereinbarten Zeitspanne behandelt. Was aber, wenn der Prozess abgestürzt ist, die Wiederholungsversuche verstrichen sind, aber der hypothetische externe Mikroservice immer noch nicht verfügbar ist?

Manuelle Optimierung

Wir kommen zum Konzept der manuellen Auflösung oder, wie es auch heißt, zum Ausgleich.

Wie funktioniert das? Alle Fehler werden abgefangen, die Delegierten erhalten die Möglichkeit, es gegebenenfalls erneut zu versuchen, und wenn ihnen das Glück dann immer noch nicht hold ist, geht der Prozess in einen Fehlerzustand über, allerdings mit dem entsprechenden Code, z. B. COMPENSATION_ERROR. Dieser Code wird von einem anderen ereignisbasierten Unterprozess abgefangen, der verarbeitet, protokolliert, benachrichtigt und vor allem nicht unerwartet fehlschlagen kann. Nur dort, wo er dafür vorgesehen ist, löst er eine nicht abfangbare technische Ausnahme aus und stürzt in einen Vorfall ab.

Warum auf diese Weise? Für die Überwachung können Sie EXCAMAD verwenden - ein externes Admin-Panel für Camunda, ein Analogon zu Cockpit, mit leistungsstarken Funktionen. Es hebt Prozesse in Vorfällen rot hervor. Diese Prozesse können an der gewünschten Stelle verändert oder neu gestartet werden. Sie können zum Beispiel den erforderlichen Variablenwert in den Kontext setzen und den Prozess von dem Punkt aus neu starten, der direkt nach dem problematischen Punkt liegt. Dies ist bequem und einfach und ermöglicht eine manuelle Problemlösung mit minimalem Aufwand.

Geschäftsprozessautomatisierung mit Camunda: Beispiele aus der Praxis

Camunda ist bekannt für seine Open-Source-Plattform und seine benutzerfreundliche Oberfläche und hat bereits zahlreichen Unternehmen geholfen, ihre Arbeitsabläufe zu optimieren. Lassen Sie uns ein paar Beispiele aus der Praxis betrachten.

Bankwesen und Finanzen

Münchener Hypothekenbank eG, eine unabhängige Immobilienbank, hat auf die Camunda Workflow Engine umgestellt, um die internen Prozesse zu verbessern und zu automatisieren, insbesondere die Postbearbeitung und die Koordination der Kreditanträge. Zuvor war das System starr, unflexibel und führte zu komplexen Abläufen, die die Fehlerquote erhöhten.

Bei der Umstellung auf eine Java-basierte Microservice-Architektur entschied sich das Unternehmen auf der Grundlage interner Empfehlungen für Camunda und arbeitete eng mit der WDW Consulting Group zusammen. Einige der Vorteile, die sie von Camunda erhielten, waren Standardfunktionen, während andere mehr Entwicklung benötigten. Diese Umstellung führte zu einer zentralisierten Aufgabenliste, die von allen Mitarbeitern genutzt wird und die Flexibilität bietet, einzelne Prozesse beizubehalten, ohne andere zu beeinträchtigen.

Das bemerkenswerteste Ergebnis war eine deutliche Verbesserung der Bearbeitungsgeschwindigkeit von Kreditanträgen. Davon profitieren sowohl die Mitarbeiter als auch die Endkunden. Als Beweis für den Erfolg wollen nun auch andere Abteilungen Camunda einführen, und die Bank hat sogar weitere Entwickler eingestellt, um die Implementierung weiter zu unterstützen.

Versicherung

SV Informatik, eine Tochtergesellschaft der SV SparkassenVersicherung, spezialisiert sich auf individuelle IT-Lösungen für Versicherungsunternehmen. Sie haben Camunda integriert, um verschiedene Prozesse abteilungsübergreifend zu automatisieren, was zu erheblichen Zeiteinsparungen und verbesserten Kundenreaktionszeiten geführt hat. Das Unternehmen entschied sich 2018 für Camunda als Lösung für die Suche nach einem effektiven Werkzeug zur Modellierung von Geschäftsprozessen, mit dem Fokus auf die Verbesserung von Prozessen und die Verbesserung der Zusammenarbeit zwischen der IT und anderen Abteilungen.

Seit seiner Einführung hat Camunda Aufgaben wie die Stornierung von Kfz-Versicherungspolicen und die Anforderung von Versicherungsdokumenten automatisiert. Eine bemerkenswerte Errungenschaft war die 80% automatisierte Verarbeitung von Online-Sturmschadenmeldungen. Dies erwies sich als besonders wertvoll während der Überschwemmungen und Stürme in Deutschland im Jahr 2021. Tools wie Camunda Optimize und Camunda Cockpit erleichtern die Prozessüberwachung und -optimierung.

Gastfreundschaft

Im Jahr 2020 startete die SV-Fraktion, die in Deutschland, der Schweiz und Österreich tätig ist, mit Unterstützung von Camunda eine disruptive digitale Plattform namens "likeMagic". Diese Plattform sorgte für ein nahtloses Gästeerlebnis, von der Buchung bis zum Check-out mit Ergebnissen wie einer 95%-Self-Check-in/-out-Rate und einer 9 von 10 Punkten für die Zufriedenheit der Gäste. Die Innovation reduzierte den Personalbedarf und integrierte Plattformen wie Airbnb nahtlos. Die SV Group erkannte das Potenzial und bot "likeMagic" anderen Anbietern im Gastgewerbe an. Bis 2023 wuchs die Zahl der Kunden in der DACH-Region von 2 auf über 30. Die SV Group plant eine größere Reichweite in Europa und strebt bis Ende des Jahres 15.000 Zimmer an.

Fazit

Das transformative Potenzial von Camunda liegt nicht nur in seinen Kernfunktionalitäten, sondern auch in seiner Fähigkeit, Geschäftsabläufe auf einer grundlegenden Ebene neu zu definieren. In Kombination mit Spring Boot öffnet es die Tür zu nahtlosen Integrationen und verbesserter Skalierbarkeit. Um das volle Potenzial von Camunda ausschöpfen zu können, ist es unerlässlich, die Grundlagen von BPMN zu verstehen. Da sich Unternehmen in diesem digitalen Zeitalter weiterentwickeln, zeichnen sich Werkzeuge wie Camunda dadurch aus, dass sie dynamische Lösungen anbieten, die sich an die sich ständig ändernden Anforderungen anpassen können. Es geht nicht nur darum, Prozesse zu automatisieren, sondern auch darum, Arbeitsabläufe zu erneuern, die Effizienz zu steigern und greifbare Ergebnisse zu erzielen, die einen Unterschied machen. Nutzen Sie die Leistungsfähigkeit von Camunda und lassen Sie Ihr Unternehmen zu neuen Horizonten aufsteigen.

Dmitry Nazarevich CTO

Datum: 17. Januar 2024

Inhaltsübersicht

Bewerten Sie diesen Artikel:

★★★★★ 4/5

4.8/5 (37 bewertungen)

Ähnliches zum Lesen

Blog

Looker vs Power BI - Revolutionierung der Industrie für kleine Abdeckungen

Vergleich zwischen Looker und Power BI: Enthüllung des BI-Tools

Blog

Warum sollten Sie Junior-Softwareentwickler für Ihre Projekte einstellen?

Blog

Die Wahl des richtigen Nearshoring-Partners: Tipps für IT-Berater in Europa

Blog

Warum Ihr Projekt ohne BA wahrscheinlich scheitern wird

Weshalb Ihr Vorhaben ohne einen BA-Experten zum Scheitern verurteilt ist

Blog

Warum IT-Projekte scheitern

Kontaktieren Sie uns

Name

Unternehmen

E-Mail

Telefon

Nachricht Bitte fügen Sie Projektdetails, Dauer, Technologie-Stack, benötigte IT-Experten und andere Infos bei.

Bitte fügen Sie Projektdetails, Dauer, Technologie-Stack, benötigte IT-Experten
und andere Infos bei.

Hängen Sie nach Bedarf zusätzliche Dokumente an.

Datei hochladen

Sie können bis zu 1 Datei von insgesamt 2 MB anhängen. Gültige Dateien: pdf, jpg, jpeg, png

Bitte beachten Sie, dass Innowise mit dem Anklicken der Schaltfläche 'Senden' Ihre persönlichen Daten nach der Datenschutzrichtlinie verarbeiten wird, um Ihnen die gewünschten Informationen zukommen zu lassen.

Wie geht es weiter?

Sobald wir Ihre Anfrage erhalten und bearbeitet haben, werden wir uns mit Ihnen in Verbindung setzen, um Ihre Projektanforderungen zu besprechen und eine NDA für die Vertraulichkeit der Informationen zu unterzeichnen.

Nach der Prüfung der Anforderungen erstellen unsere Analysten und Entwickler einen Projektvorschlag, der Arbeitsumfang, Teamgröße, Zeit- und Kostenschätzung enthält.

Wir vereinbaren einen Termin mit Ihnen, um das Angebot zu besprechen und eine Vereinbarung zu treffen.

Wir unterzeichnen einen Vertrag und beginnen umgehend mit der Arbeit an Ihrem Projekt.

Geschäftsprozessautomatisierung mit Camunda: Fehlertolerante Implementierung von BPM-Schemata

Was ist Camunda?

Camunda, Spring Boot & BPMN: Verständnis der Konzepte