Einführung
Wenn Ihr Geschäftsprozesse mit Camunda 8 digitalisieren werdet Ihr euch, nach der fachlichen Definition der Prozesse um direkte Umsatzung der Services und Konnektoren kümmern müssen.
Ich stelle euch ein Strategie, ein Tool, vor mit der wir Camunda 8 Services und Konnektoren entwickeln, die sowohl den Projectowner, Stakeholder, Scrum Master, Tester und vor allem den Entwickler auf effektive und effiziente Weise gleichermassen ermöglicht dieses Projekt zu rocken.
Die Fragestellung ist : Können wir alle Vorteile von BPMN nicht auch in diesen Services nutzen ohne auf qualitativ hochwertigen Code zu verzichten.
Tatsächlich erreichen wir mehr : Wir machen den Code sogar besser. Das Projektziel wird früher erreicht, der Code ist dokumentiert, der Code ist getestet, die Tester verstehen die automatischen Tests, die Stakeholder wissen auch bei der Implementierung wo, wer, warum und wie lange an etwas arbeitet.
Als Nebeneffekt ist jeder Service in anderen Projekten wiederverwendbar.
Wichtig für Stakeholder, ProductOwner
- Wir verwenden im Projekt eine Sprache.
- Die Definition der UsersStorys wird verbessert.
- Die Notwendigkeit für Programmcode-Refactoring wird stark reduziert.
Ziel dieses Artikels
Wir wollen in diesem Artikel die Vorgehensweise zeigen, wie man mit Kogito effiziente Services baut. An dieser Stelle wollen wir nicht Java-Programmierung, Camunda und Kogito Modellierung, Security usw. zeigen.
Camunda 8 Prozess
Lasst uns mit einem einfachen Camunda 8 Prozess starten , der einen einzigen Service Task enthält.
Diesen Prozess konfigurieren wir, so dass er Type “kogito” hat und konfigurieren zwei Variablen die wir an den externen Task übergeben.
Kogito JobWorker
Um einen Camunda 8 Service Task zu bedienen, müssen wir Camunda “fragen”, ob irgendwelche Service Task abgearbeitet werden sollen. Das macht unser JobWorker. An dieser Stelle ist nur der “Short Poll” implementiert um einfacher das Prinzip zu zeigen.
Kogito JobHandler
Die abgeholten Jobs werden im Jobhandler weiter bearbeitet. Dieser JobHandler bearbeitet die Camunda Daten auf, ruft den eigentlichen Service auf und nach dem Beenden des Services schliesst der JobHandler den Camunda Service Task ab und übergibt die Resultate.
Kogito Service
Unser Beispiel Service generiert aus den gegeben Daten einen Satz und übergibt diesen zurück an den JobHandler.
Vorteile
Lasst uns mit den grössten Vorteilen anfangen :
- Services werden modelliert!Im Refinement werden die Funktionalitäten und der Ablauf genau modelliert. Dadurch können direkt im Refinement nicht nur den Ablauf des Services und die Teilaufgaben eines Services sondern auch die Daten und Umsysteme modelliert werden. Nach dem Refinement ist der Service komplett beschrieben.
- Services werden von allen Projektbeteiligten tiefer verstanden!
- Bei komplexen Prozessen ist Kapseln viel einfacher.
- Jeder Service Schritt ist wiederverwendbar.
- Jeder Service Schritt wird einzeln getestet.
Ok aber …
Lasst uns an dieser Stelle die wichtigsten Fragen, die Projektbeteiligten in Ihrer Funktion fragen, beantworten.
Entwickler
F: Wir haben mit Camunda 8 ein BPMN System, brauchen wir noch eines?
A: Das was wir mit Kogito produzieren ist Programmcode in Java. Dieser Code kann mit GraalVM nativ kompiliert werden. Das gewählte Beispiel läuft vollständig im Memory.
Kogito sollte man in diesem Kontext mehr mit Lombok vergleichen und nicht mit Camunda.
F: Wenn ich meine Services selber schreibe kann ich sie vollständig testen. Geht das mit Kogito auch?
A: Ja, sowohl UnitTest als auch IntegrationsTest sind möglich und sollten in keinem Service fehlen.
F: Wir haben uns auf Api-First im Team geeinigt. Unterstützt das Kogito auch?
A: Ja überall. Hier ein Beispiel unseres Demo-Services.
Unter den Prozesseigenschaften eines Prozesses werden die Prozessdaten definiert.
Lasst uns an dieser Stelle die Input-Variabeln des ComplexServiceExample-Prozesses anschauen. Wir sehen hier die verschiedenen Prozessvariablen, wobei wir “inputVariables” definiert haben als Java Map. Und “activatedJob” ist eine komplexe Variable vom Typ io.camunda.zeebe.client.api.response.ActivatedJob.
Startet mal das Beispiel (Readme lesen) und startet es mit “mvn quarkus:dev” und drückt nach dem Start “d”. In der Quarkus Dev UI wählt ihr SwaggerUI.
F: Aber die Scripte im Prozess sind …?!
A: Java!
F: Kann ich alle Java Dependencies benutzen?
A: Ja, allerdings wenn wir es nativ kompilieren möchten müssen wir darauf achten, dass alle “Java-Refelection” zur Übersetzungszeit bekannt sind.
F: Können wir TestDriven entwickeln?
A: Da der Ablauf und die Input/Output Parameter des Service zum Refinement schon definiert sind, kann man vor und während der Entwicklung die Test schreiben. Perfektes TestDriven Development.
F: Ist es schnell?
A: Oh ja!
Projektverantwortliche
F: Müssen wir etwas lizenzieren?
A: Kogito ist OpenSource, und ist unter der Apache Lizenz veröffentlicht.
F: Ist die Entwicklung kostengünstiger zu realisieren?
A: Ja, vor allem wegen 3 Faktoren.
- Die Definition der Services (damit der Storys) ist genauer und damit viel weniger fehleranfällig, Refactoring wird stark reduziert.
- Die Integration von Umsystemen kann viel früher definiert und getestet werden.
- Der Programmcode ist, zu jedem Zeitpunkt, perfekt dokumentiert.
Schreibe einen Kommentar