GPI Zusammenfassung KK

Nachteile External Tasks

- Asynchronizität ist nicht immer tolerierbar, wenn der Fortgang sehr zeitkritisch ist. - Architektur komplexer , da jeder weitere External Task Client (Microservice) eine weitere zu unterhaltende Komponente ist. - Steigung der Belastung des Netzwerks durch die Kommunikation zwischen External Task Clients und der Camunda REST API

5 Vorteile des External Task Patterns (Bei Camunda)

1. Einfache Skalierbarkeit 2. Flexible IT-Architekturen 3. Microservice-friendly 4. Kombination von Cloud-BPM und On-Premise-Services: 5. «Besseres» Retry-Handling

Wir können die typischen CRUD-Operationen auf unsere zwei Entities ohne SQL, rein objektorientiert durchführen

1. Neues Java-File «UserRepository.java» mit interface-Gerüst (keine class, da diese erst zur Laufzeit von Spring/JDK er-stellt wird basierend auf dieser Interface-Deklaration) -> Public interface UserRepository 2. Erbt von JpaRepository => extends -> Public interface UserRepository extends JpaRepository 3. Typisierte Parameter erforderlich (class name und Type der Id der Klasse von dem geerbt wird): User und String -> Public interface UserRepository extends JpaRepository <User, String> 4. Grob erläutern, weshalb diese Parameter erforderlich sind und was da eigentlich genau extended wird anhand «Goto Definition». -> Methoden der Spring frameworks JpaRepository werden extended

Annotation @InjectMocks

@InjectMocks ist die Mockito-Annotation. Sie ermöglicht es Ihnen, ein Feld zu markieren, für das eine Injektion durch-geführt werden soll. Injection ermöglicht es Ihnen, Mocks und Spy-Injections kurzzeitig zu aktivieren.

Spring-Framework

Bietet zahlreiche Out-of-the-Box-Funktionalitäten wie z.B. Datenvalidierung, Daten-bankzugriff, Web-Frameworks, E-Mail, usw., die man sonst selbst auf dem Core-Java entwickeln müsste

Annotation @Qualifier

Die @Qualifier-Annotation wird verwendet, um den Autowiring-Konflikt aufzulösen, wenn es mehrere Beans desselben Typs gibt. Die @Qualifier-Annotation kann auf jede mit @Component annotierte Klasse oder auf eine mit @Bean annotierte Methode angewendet werden. Diese Annotation kann auch auf Konstruktorargumente oder Methodenparameter angewendet werden.

Annotation @Test

Die Annotation @Test teilt JUnit mit, dass die public void method, an die sie angehängt ist, als Testfall ausgeführt wer-den kann. Um die Methode auszuführen, konstruiert JUnit zunächst eine neue Instanz der Klasse und ruft dann die an-notierte Methode auf. Alle vom Test ausgelösten Ausnahmen werden von JUnit als Fehler gemeldet. Wenn keine Ausnahmen ausgelöst werden, wird davon ausgegangen, dass der Test erfolgreich war.

Annotation @GenerateValue

Diese Annotation wird verwendet, um die zu verwendende Primärschlüsselgenerierungsstrategie anzugeben.

Annotation @Id

Jede JPA-Entität muss einen Primärschlüssel haben, der sie eindeutig identifiziert. Die @Id-Annotation definiert den Primärschlüssel. Wir können die Bezeichner auf verschiedene Arten erzeugen, die durch die @GeneratedValue-Annotation angegeben werden. Generiert technische IDs.

Build Automation Layer

Maven -> pom.xml (Steuerungsdatei) -> lädt z.B. die benötigten Java Dependencies ins .m2-Verzeichnis statt wie früher händisch alle benötigten jars oder einzelne Java-Klassen händisch am richtigen Ort abzulegen, usw.

Unterschied External Task und JAVA Delegate

Seitens Prozessapplikation läuft alles über DENSELBEN Thread im Unterschied zu ein Thread pro Prozessinstanz-Delegate-Implementation. Seitens des ExternalTaskClients läuft es bei unserer Konfiguration so, dass zwar drei Tasks gefetched werden können, aber nur einer aufs Mal erledigt wird

Annotation @RESTController

Verwendet um die Erstellung von RESTful Web Services zu vereinfachen. Es handelt sich dabei um eine praktische Annotation, die @Controller und @ResponseBody kombiniert, wodurch die Notwendigkeit entfällt, jede Methode zur Bearbeitung von Anfragen in der Controller-Klasse mit der Annotation @ResponseBody zu annotieren. Jede request handling method der Controller-Klasse serialisiert automatisch Rückgabeobjekte in HttpResponse.

Annotation @Async

Wenn eine Methode einer Bean mit @Async annotiert wird, wird sie in einem separaten Thread ausgeführt. Mit anderen Worten, der Aufrufer wartet nicht auf die Fertigstellung der aufgerufenen Methode.

Was sind die Parallelen & Unterschiede von User Tasks und External Tasks?

a. Ist ein Haltepunkt (Transaktionsgrenze), da in die Datenbank persistiert werden muss (siehe nächster Punkt) so-wie die Aufnahme und Erledigung des Tasks potentiell lange dauern kann (asynchron). b. Es existiert eine Tasklist, bei beiden als Datenbanktabelle persistiert, bei beiden über REST/Java API zugänglich, bei User Tasks zudem im Frontend sichtbar gemacht. c. User Tasks können zugewiesen werden, External Tasks nicht d. User Tasks kennen Candidate Groups, External Tasks analog dazu ein Topic e. Nur eine Person respektive ein External Task Client kann einen bestimmten User respektive External Task für sich beanspruchen (claim respektive lock), bearbeiten und completen. f. Ein Benutzer kann (je nach Einstellungen) einen User Task unclaimen und ein External Task Client kann analog dazu einen bereits gelockten External Task nicht erledigen und nach dem Timeout ist er wieder in der Tasklist (für andere) verfügbar. g. Die Workflow Engine weiss, welcher Benutzer (Username) respektive welcher External Task Client (workerid) eine Aufgabe erledigt hat.

Hauptnutzen einer digitalisierten Lösung gegenüber der bisherigen Lösung

• Melden eines Umzugs ist neu rund um die Uhr möglich • Keine Dokumente können «vergessen» werden, sprich physisch müsste man nach Hause und einen neuen Ter-min machen. Neu nicht nötig. • Alle Doks sind digital vorhanden und müssen nicht wie bisher eingescannt werden. • Personalien sind digital vorhanden (kein manuelles eintippen nötig). Daher sind die Infos bereits in den Systemen der Einwohnerkontrolle.

Systemarchitektur eUmzug (4 Hauptkomponente und ihr Zusammenspiel)

• Weiss/farblos: Die eigentliche Umzugsplattform mit dem Hauptprozess, welche als Camunda Spring Boot-Applika-tion implementiert ist. Service Tasks, welche nicht eingefärbt sind, werden über JavaDelegates implementiert, User Tasks über Embedded Forms, die in der Camunda Webapp Tasklist eingebettet sind. • Blau (Aufrufprozesse): Implementation als eigener Prozess innerhalb der Umzugsplattform, welcher über eine Call Activity aufgerufen wird. • Grün (Microservice): Implementation als Microservice-Applikation, welche lediglich simple Spring Boot-Applikatio-nen sind. Die Einbindung in den Hauptprozess geschieht über das External Task Pattern. • Rot und Orange (Umsysteme per REST/SOAP): Die rot und orange eingezeichneten Systeme sind in einer produktiven Umgebung komplett in einer anderen Verantwortung als beim Kanton Bern, sprich bei den Gemeinden, dem Bund etc. Sie könnten entsprechend in irgendeiner Technologie implementiert sein. Für die Umzugsplattform relevant ist lediglich, dass diese über definierte Schnittstellen erreichbar sind, konkret über SOAP-Schnittstellen (Rot) gemäss eCH-Standards oder über REST (Orange). Für Testzwecke sind diese Umsysteme gemocked, jeweils in einer eigenen Github-Repository verfügbar und dokumentiert.

5 Kategorien von komplexen Entscheidungen

1. Automatisierte Freigabe/Ablehnung eines Antrags, einer Rechnung, usw. 2. Risiko-/Betrugseinschätzung eines Kunden, Antrags, usw. 3. Automatisierte Aufgabenzuweisung zu einem Benutzer oder einer Rolle oder sogar zu einem System (z.B. Verrech-nung über Papierrechnung vs. Kreditkartenbelastung) 4. Berechnungen z.B. des zu offerierenden Produktpreises oder des Kunden mit grösster Erfolgswahrscheinlichkeit 5. Ermitteln der geeigneten Kommunikation, z.B. was auf eine Anfrage geantwortet wird.

Die Aufgabe «Benutzerinformationen auslesen» ist ein Service Task, der über ein JavaDelegate implementiert ist, welcher auf die persistierten LDAP-Informationen zugreift und den vollständigen Namen plus Heimorganisation für den User Task und die E-Mail-Adresse für den späteren MailVersand als Prozessvariablen zurückgibt. (Vorgehen)

1. BPMN: «Benutzerinformationen auslesen» -> Service Task, Implementation DelegateExpression, DelegateExpres-sion ${getUserInformationAdapter} 2. VSCode: Neues Java-File im Hauptbereich «GetUserInformationDelegate.java» 3. class-Gerüst einfügen implements JavaDelegate > Quick Fix -> add unimplemented methods 4. @Named mit getUserInformationAdapter hinzufügen, um Service Task mit VS Code zu verbinden 5. Neue lokale (!) String-Variable userName im VS Code, die auf Prozessvariable (!) «anfrageStellenderBenutzer» zu-greift. -> vgl. Camunda Startereignis -> Initiator 6. Für Datenbankinteraktion: Autowiring des UserRepository 7. Zwei lokale String-Variablen fullUserDescription und eMail deklarieren. 8. Zunächst suchen wir den User in der Datenbank: Optional <User> user = userRepository.findById(userName); Optional bedeutet, da kann etwas zurückkommen oder nicht (=empty). a. Wenn der Benutzer unbekannt ist, soll die volle Bezeichnung automatisch auf «Alien (Universe)» und die E-Mail-Adresse auf «[email protected]» gesetzt werden, ansonsten lesen wir diese Daten aus der Repository. lassen wir uns automatisch ein JSON-Objekt zusammenstellen aus dem User-Objekt (im Hintergrund werden einfach alle Getter-Methoden ausgeführt), welches wir dann in einen String serialisieren: 9. Zwei neue Prozessvariablen anlegen, die an Camunda zurückgegeben werden für den vollen Namen und für die E-Mail-Adresse: execution.setVariable("userMail", eMail); execution.setVariable("userFullDescription", fullUserDescription); 10. User Task um Formularfeld Label Antragsteller, ID userFullDescription und schreibgeschützt = Validation- add cons-traint. Name readonly, Config bleibt leer.

DMN Begriffe

1. Business Rules Task -> Der Task mit dem Tabellen-Symbol 2. Decision Engine -> Ist in unserem Processengine integriert 3. Decision -> Entscheidung, sind die Boxen in DMN. Können Tables sein oder Code (Literal Expression) 4. DMN: Decision Model and Notation -> Der Standard, wird mit xml genutzt 5. DMS: Decision Management Suite -> vollwertige Tools, um vollwertige Decisions zu verwalten 6. DRD: Decision Requirements Diagram -> Ist das ganze DMN Diagramm 7. Input Data und Output / Decision Table: 8. Literal Expression -> Code 9. FEEL -> für das Business einfach verständliche Sprache im Vergleich zu JavaScript

Was testen wir?

1. Die Prozesslogik: Das ausführbare BPMN-Modell inkl. Script Tasks, Execution Listeners, der Aufruf von Delegates (Glue Code), das Setzen von User- und External Tasks und natürlich der Sequenzfluss inkl. XOR-Gateways. 2. Die DMN-Modelle. 3. Die JavaDelegates. 4. Ab Scope 2: Die in der Prozessapplikation enthaltenen Services (welche besser als Microservice in eigenen Applikatio-nen wären).

Was testen wir nicht?

1. Die Workflow Engine -> das hat hoffentlich Camunda ausreichend gemacht 2. Die genutzten Libraries -> das haben hoffentlich deren Hersteller gemacht 3. Im engeren Sinne: Die von unserer Prozessapplikation aufgerufenen Umsysteme oder die External Task Clients, welche unsere Prozessapplikation nach neuen Jobs abfragen. ABER: Bei Scope 3 (Integrationstests) prüfen wir sie insofern teilweise mit, dass wir die für unsere Prozessapplikation relevante nach aussen sichtbare Funktionalität auf ihr erwarte-tes Verhalten testen. Und natürlich sollten die verantwortlichen Teams diese Services testen.

Wieso sollte DMN genutzt werden?

1. Die derzeitigen Anforderungskonzepte gehen nicht auf die Entscheidungsfindung ein, die in Informationssystemen immer wichtiger wird. 2. Obwohl sie für alle Softwareentwicklungsprojekte wichtig sind, sind Entscheidungsanforderungen besonders wichtig für Projekte, die Geschäftsregeln und fortgeschrittene Analysetechnologien einsetzen. 3. Entscheidungen sind eine gemeinsame Sprache für Geschäfts-, IT- und Analyseorganisationen und verbessern die Zusammenarbeit, erhöhen die Wiederverwendung und erleichtern die Implementierung.

Was mocken wir in Scope 1?

1. Die in der Prozessapplikation enthaltenen Services (SendGridClient, TwilioClient, RestTemplate) inkl. der Return-Werte aufgerufener Methoden 2. Den Menschen (Formulare ausfüllen und absenden) 3. External Task Clients (External Tasks erledigen) 4. Den JobExecutor

Warum sind Workflow/Process Engines (bsp. Camunda) sinnvoll? (Punkte 1-5)

1. Duality of BPMN: BPMN-Modell ist sowohl von Biz, Dev und Ops verständlich → zeigt also fachlich, was passiert, ist aber auch ausführbar, also eine lebende Dokumentation. 2. Transparenz in Operation und Testing: Jederzeit im BPMN-Modell sichtbar, wo eine Prozessinstanz steckt und somit ist es auch unwahrscheinlicher, dass Instanzen vergessen gehen/liegen bleiben. 3. Generierung von Prozess-KPIs: In Camunda Cockpit sieht Biz und Ops verschiedenste KPIs, z.B. Anzahl laufende und abgeschlossene Instanzen sowie Heatmaps. 4. Versionierung: Jede Anpassung unseres Prozessmodells ist als separate Version deployed → Es könnten einerseits auch parallel Prozessinstanzen auf verschiedenen Modellen laufen 5. Unterstützung von Long-running processes: Durch State Handling hat die WE keine Mühe, dass Menschen nicht synchron antworten und damit für längere Zeit einen Thread blockieren würden → Bei Problem innerhalb des Service Tasks können wahlweise Incidents oder Business Errors ausgelöst werden.

Wieso kann es Sinn machen, Entscheidungen zu automatisieren (insbesondere mit DMS) und nicht durch den Menschen treffen zu lassen?

1. Effizienz steigern 2. Durchlaufzeiten senken 3. Fehlerquote senken 4. Transparenz erhöhen (inkl. leichtere Auditierbarkeit) 5. Missbrauch verhindern (bei User Task mit Entscheidungen kann der Mensch bewusst/unbewusst Missbrauch betrei-ben, z.B. durch Benachteiligung einer Ethnie).

Warum überhaupt noch Menschen?

1. Effizienz: Es ist oftmals teurer, jeden beliebigen Fall automatisieren zu wollen, anstatt diese eher seltenen Fälle durch Menschen lösen zu lassen (bei uns z.B. das Prüfen des Tasks, wobei hier eher 20/80 statt 80/20) 2. Kreativität: Das Erstellen und Überarbeiten von Tweets ist ein kreativer Akt 3. Agilität: Statt von Beginn an alles automatisieren zu wollen, kommt man schneller voran, wenn zu Beginn nur die Low-hanging fruits automatisiert werden, die übrigen Aktivitäten hingegen als User Task stehen bleiben. Sukzessive können dann bei entsprechenden Entwicklerresourcen User Tasks in automatisierte Tasks umgewandelt werden.

Daten aus Umsystemen als Prozessvariablen (zwei Extremvarianten und Abstufungen davon, wie mit Daten aus Umsystemen (z.B. ERP, CRM oder hier ein LDAP) umzugehen ist)

1. Id-Variante: Nur die Id einer Entität (z.B. username) wird als Prozessvariable persistiert. 2. All Data-Variante: Die Id und alle (relevanten) Attribute einer Entität (z.B. firstName, usw.) werden als Prozessvariable(n) persistiert.

3 Vorteile von Workflow Engines im Bezug auf REST-Services

1. Integration von Umsystemen: Mit JavaDelegate kann u.A. Umsysteme über APIs integriert werden → Je nach Anbieter viele lediglich zu konfigurierende Adapter oder werden über eigenen Glue Code integriert (z.B. bei Camunda). 2. Retry-Handling: Systeme oft nicht verfügbar weil API's geändert haben. Dank WE möglich, dass der Job (bei Camunda der Service Task) erst nach 15 Minuten maximal fünfmal ausgeführt wird. 3. Compensation Handling: Über sogenannte Compensation Events können wir pro Aktivität steuern, was zu tun ist bei Inkonsistenzen auf Datenbankebenen

Vorteile der Id-Variante (und damit Nachteile der All Data-Variante)

1. Konsistenz & Aktualität: Wir haben stets den aktuellsten Stand der (Stamm)daten, z.B. die aktuelle E-Mailadresse. Und damit auch Konsistenz, da es z.B. nicht passieren kann, dass in unserem Prozess der Benutzer a zu Beginn der Pro-zessinstanz noch in der Abteilung X arbeitet, einen Tag später (z.B. beim Anzeigen des Benutzerformulars) eigentlich in der Abteilung Y, wobei dann immer noch Abteilung X angezeigt wird. 2. Keine Redundanz & optimaler Datenschutz: Da nur die Id persistiert wird, müssen nicht die vollständigen Umsystem-Daten mitgeführt inkl. standardmässig auch historisiert werden. Falls ein Kunde seine personenbezogenen Daten lö-schen möchte, müssen wir entweder in unserer Prozessapplikation gar nichts löschen oder nur die Id, falls aus dieser ein Personenbezug abgeleitet werden kann. 3. Geringe Speicherkosten: Da nur die Id persistiert wird, wird nur wenig Speicherplatz für die Persistierung und Ba-ckups benötigt.

Wir haben je eine Klasse für User- und OrgUnit-Objekte, welche gleichzeitig die Angaben enthält, damit diese über ORM mit den entsprechenden Datenbank-Tabellen gemappt werden kann. (Vorgehensweise)

1. Neuer Ordner «ldap» und darin neues Java-File "OrgUnit java" mit class-Gerüst 2. Zunächst ein POJO erstellen mit String shortName und longName inkl. Getter und Setter 3. Nun die Angaben für ORM, um die Daten zu persistieren -> Bereits vorhandene Dependencies sind h2 und jdbc + pom.xml erweitern um benötigte JPA-Dependency: org.springframework.boot spring-boot-starter-data-jpa 4. @Id hinzufügen (ohne Autogenerate da String von Mensch vergeben) und speichern. 5. Weiterfahren mit neuer Klasse «User.java»: POJO erstellen mit String userName, firstName, officialName und eMail sowie mit OrgUnit homeOrganization. 6. @Entity, @Id und @ManyToOne (bei User Klasse many user in one org) hinzufügen und speichern 7. Damit JPA die Entities auch tatsächlich in einer bestehenden H2-Datenbank anlegt, müssen wir in application.pro-perties noch eine Eigenschaft hinzufügen: spring.jpa.hibernate.ddl-auto=update

Wieso sollten komplexere Entscheidungen nicht in BPMN (oder Quellcode), sondern z.B. in auf DMS-Tools modelliert werden?

1. Nicht alle Entscheidungen haben Einfluss auf den Sequenzfluss (XOR-/OR-Gateway). 2. Das Diagramm wird rasch unübersichtlich (zig verschachtelte XOR-Gateways) 3. Wissensquellen, Input-Daten und Entscheidungslogik werden sehr umfassend abbilden. 4. Wenn sich die Regeln häufig ändern (z.B. basierend auf Rechtsgrundlagen oder Geschäftswachstum) und allenfalls sogar parallel mehrere Regelwerke gültig sind, ist eine Versionierung erforderlich.

Vorteile der All Data-Variante (und damit Nachteile der Id-Variante:)

1. Performanz: Dadurch, dass die Daten gleich als Prozessvariablen verfügbar sind, müssen wir nicht bei jeder Nutzung wieder eine Abfrage machen. (Dieser Vorteil gilt aber nicht für DB!) 2. Unabhängigkeit: Aus dem gleichen Grund spielt es auch keine Rolle, wenn zu einem späteren Zeitpunkt nach der initialen Abfrage das Quell-System nicht verfügbar ist.

Wir wollen über unsere JavaDelegate-Klasse nun auf den neu erstellten LDAP-Service via REST zugreifen und zwar ein GET-Request auf eine User-Resource via /users/{username} Vorgehen: Instanziieren

1. RestTemplate (einer von mehreren REST-Client-Varianten des Spring-Frameworks) instanzieren. Wir könnten entwe-der mit new RestTemplate() bei jedem Aufruf des Delegates eine neue Instanz erstellen oder etwas effizienter mittels @Bean EINE Instanz von RestTemplate erstellen, auf die wir mit @Autowired zugreifen können. Da es in der Praxis nicht selten ist, dass wir auf mehr als einen REST-Service zugreifen müssen, kommt es vor, dass mehr als ein RestClient zu konfigurieren ist (z.B. mit anderer Authentifzierung), daher benennen wir unsere Bean 2. Um das RestTemplate nutzen zu können, verwenden wir @Autowired, müssen aber entweder der Variable denselben Namen geben wie unsere angelegte Bean oder wir müssten @Qualifier verwenden. In unserem Beispiel spielt es jedoch keine Rolle, da wir aktuell nur ein Template angelegt haben.

Wann testen wir?

1. Scope 1: Nach jeder Änderung von Prozessmodell oder Code, spätestens vor dem Commiten in die Code-Repository. 2. Scope 2: Spätestens vor dem Commiten in die Code-Repository 3. Scope 3: Vor einem neuen Release (aufwändig, da entweder mit Selenium oder RPA FrontendTests zu schreiben, usw. oder inklusive Menschen, welche Test-Drehbücher abarbeiten; zudem in jedem Fall eine ganze Testumgebung für all die Umsysteme erforderlich)

Verstehen, dass mindestens die folgenden teils zeit- und geldintensive Tätigkeiten erforderlich sind, wenn man mit einer Applikation wie dem eUmzug produktiv gehen will:

1. Weitergehende Dokumentation 2. Umfassende Fehlerbehandlung 3. Unit Tests, Integrations-Tests, Systemtests in Testumgebung, Abnahmetests 4. Integration in bestehende IT-Architektur / Aufsetzen der benötigten IT-Komponenten 5. Eventuell eigene Tasklist-Applikation erstellen 6. Festlegen von Verantwortlichkeiten sowie Schulung betroffener Business- und IT-Anwender 7. Implementation eines Monitorings und Controlling

Warum sind Workflow/Process Engines (bsp. Camunda) sinnvoll? (Punkte 6-10)

6. Automatische Zuweisung und automatischer Transport: Im Unterschied z.B. zu papierbezogenen oder E-Mail-bezogenen Freigabeprozessen weiss die WE, wem sie die Aufgabe zuweisen soll oder wer als Kanditat in Frage kommt → Automatische Zuweisung 7. Strukturierte Erfassung von Informationen: Kein spezifisches Feature der Engine, sondern der Frontend-Technologie, dass Eingaben strukturiert erfolgen und validiert werden können im Unterschied zum klassischen Papierformular oder einer E-Mail. 8. Integration von Decision Services: Mithilfe von Business Rules Tasks kann mit DMS aufgezeigt werden, in welcher Form Entscheidungen fällt oder vorbereitet 9. Reaktion auf Zeitereignisse: WE kann sehr einfach auf absolut oder relativ definierte Zeitereignisse reagieren, um einen neuen Prozess (periodisch) zu starten → Deadlines festzulegen oder zusätzliche Aktivitäten nach bestimmter Zeit auszuführen. 10. BPMN Error-Handling: WE erlaubt durch das gezielte Auslösen von BPMN Errors z.B. aus einem JavaDelegate oder einem External Task Client heraus ein umfassendes BPMN Error-Handling.

Annotation @RequestMapping

@RequestMapping ist die häufigste und am meisten verwendete Annotation in Spring MVC. Sie wird verwendet, um Webanfragen auf bestimmte Handler-Klassen und/oder Handler-Methoden abzubilden.

Annotation @ExternalTaskSubscription

Annotation, um den External Task Client bei einem Thema zu abonnieren.

Asynchronus AFTER

Asynchrone Fortsetzungen nach einer Aktivität sind nützlich, wenn Sie sicherstellen wollen, dass die von der Aktivität durchgeführten Zustandsänderungen gespeichert werden, bevor die Prozess-Engine die Prozessausführung fortsetzt. • Dies ist in der Regel sehr viel intuitiver, als die asynchrone Fortsetzung BEFORE der nächsten Aktivität zu platzie-ren. • Eine Aktivität kann mehrere ausgehende Sequenzflüsse haben. Ohne die Möglichkeit, eine asynchrone Fortset-zung nach der Aktivität zu platzieren, müssten Sie sie vor allen nächsten Aktivitäten platzieren.

Annotation @Autowired

Dependency Injection: Automatisches verdrahten von Bsp. XYRepository. Die eine, von SpringBoot erstellte Instanz des XYRepository, kann so in dieser Klasse verwendet werden. Erstellt eine Instanz zu Laufzeiten. Wird nach der Erledigung der main-Methode durchgeführt, weil erst dann alle von Spring verwalteten Beans (Instanzen einer Klasse) instanziert sind.

Decision Modeling mit DMN

Der DMN-Standard wurde als Ergänzung zur BPMN entwickelt und bietet einen Mechanismus zur Modellierung der Entscheidungsfindung, die in einer Aufgabe innerhalb eines Prozessmodells dargestellt wird. DMN muss nicht mit BPMN verwendet werden, ist aber in hohem Maße kompatibel.

Annotation @Before

Der mit @Before markierte Code wird vor jedem Test ausgeführt, während @BeforeClass einmal vor der gesamten Test-vorrichtung ausgeführt wird. Wenn Ihre Testklasse zehn Tests hat, wird der @Before-Code zehnmal ausgeführt, @Befo-reClass jedoch nur einmal.

Annotation @JsonIgnore

Die @JsonIgnore-Annotation markiert ein Feld eines POJO, das von Jackson während der Serialisierung und Deserialisie-rung ignoriert werden soll. Jackson ignoriert das Feld sowohl bei der JSON-Serialisierung als auch bei der Deserialisie-rung.

Annotation @JsonProperty

Die @JsonProperty-Annotation wird verwendet, um Eigenschaftsnamen mit JSON-Schlüsseln während der Serialisierung und Deserialisierung zu verknüpfen. Wenn Sie versuchen, ein POJO zu serialisieren, hat das generierte JSON standardmäßig Schlüssel, die den Feldern des POJO zugeordnet sind.

Annotation @Named

Die @Named-Annotation wird für die Angabe von Namen für Klassen verwendet, die die Interface implementieren und sie ist optional

Annotation @NotNull

Die @NotNull-Annotation ist eigentlich ein expliziter Vertrag, der Folgendes festlegt: Eine Methode darf nicht null zu-rückgeben. Eine Variable (wie Felder, lokale Variablen und Parameter) darf keinen Nullwert enthalten.

Prozess-Layer

Die Camunda Core-Elemente (Process Engine, Job Executor, REST-API & Co.) werden von Spring Boot durch die angegebenen Dependencies und durch @EnableProcessApplication automatisch in Apache Tomcat ausgeführt

Datenbank-Layer: H2 (MySQL-Klon).

Die Dependency wird von Maven heruntergeladen. Spring Boot kümmert sich darum, dass eine solche Datenbank angelegt wird, wenn sie noch nicht existiert, default-mässig in-memory, aber weil wir noch die JDBC-Dependency hinzugefügt haben, automatisch file-basiert. Im application-properties haben wir noch Abweichungen vom Default vorgenommen

Exclusive Gateways & unverständliche IDs in Camunda

Die Maschine weiss nicht, wo es bei XOr Gateway weiter muss. Da noch keine Daten -> work-around: bei «ja» Pfad den Default Flow nehmen. Bei «nein» muss Condition Type auf Expression gesetzt werden und Expression auf ${false}. In Realität nimmt man kein Default Flow. Daher müssen sinnvollere Bezeichnung her -> Default Flow entfernen und neue Expressions eingeben wie bsp. ${checkResult=='rejected'}.

Annotation @Bean

Die Spring @Bean Annotation wird auf eine Methode angewendet, um anzugeben, dass sie eine Bean zurückgibt, die vom Spring-Kontext verwaltet werden soll. Die Spring-Bean-Annotation wird normalerweise in den Methoden der Konfigurationsklassen deklariert. In diesem Fall können Bean-Methoden auf andere @Bean-Methoden in derselben Klasse verweisen, indem sie diese direkt aufrufen.

Script Tasks

Eignet sich dafür, um einfache Rechnungen zu machen anstelle eine neue Java Klasse. Nun wandeln wir eine Activtiy zu einem Script Task um

SOAP (Funktionsweise)

Ein SOAP-Client sendet das XML-Dokument an einen SOAP-Server. Diese SOAP-Anfrage wird über http an einen SOAP Request Handler gesendet. Eine Antwort des Dienstes wird an das SOAP Request Handler und dann an den Aufrufer im standardmäßigen SOAP-XML-Nutzdatenformat zurückgegeben

SOAP (Inhalte)

Eine SOAP-Nachricht ist ein gewöhnliches XML-Dokument, das die folgenden Elemente enthält: -Envelope - Definiert den Anfang und das Ende der Nachricht. Es ist ein obligatorisches Element. -Header - Enthält alle optionalen Attribute der Nachricht, die bei der Verarbeitung der Nachricht, entweder an einem Zwischenpunkt oder am endgültigen Endpunkt, verwendet werden.

Asynchronus BEFORE

Eine asynchrone Fortsetzung VOR einer Aktivität unterbricht den Ausführungsfluss zwischen dem Aufruf der TAKE-Liste-ner des eingehenden Sequenzflusses und der Ausführung der START-Listener der Aktivität

H2-Konsole nutzen -User hinzufügen

Einen User für den Super-Admin einfügen über: INSERT INTO USER (USER_NAME, FIRST_NAME, OFFICIAL_NAME, E_MAIL, HOME_ORGANIZATION_SHORT_NAME) VALUES ('a', 'Max', 'Muster', '[email protected]', 'gl2');

Annotationn @Entity

Entitäten in JPA sind nichts anderes als POJOs, die Daten darstellen, die in der Datenbank persistiert werden können. Eine Entität repräsentiert eine Tabelle, die in einer Datenbank gespeichert ist. Jede Instanz einer Entität stellt eine Zeile in der Tabelle dar.

Externe Task Worker

Entkoppeln die Ausführung von Tasks von der Prozessorchestrierung durch die Process Engine mittels eines Pull-Mechanismus. Bei der Automatisierung von Prozessen mit Camunda werden Service Tasks in der Regel direkt von der Process Engine über explizite Custom Java Methoden ausgeführt. Eine Alternative dazu bietet das External Task Worker Pattern, bei dem eine separate Anwendung eigenständig Aufgaben aus einer Liste holt, diese abarbeitet und das Ausführungsergeb-nis an die Engine zurückgibt. Bei diesem Muster führt die Prozess-Engine die Aufgaben nicht selbst über einen Delegaten aus, sondern schreibt sie in eine Liste, zusammen mit allen für ihre Ausführung erforderlichen Informationen. Ein External Task Worker ist eine von der Engine unabhängige Anwendung, die die Aufgaben aus dieser Liste über die REST-API der Engine abruft, sie ausführt und dann abschließt, d. h. ihre Ergebnisse an die Engine zurückgibt, wie in der folgenden Animation gezeigt.

Annotationn @Override

Es handelt sich um eine Markierung, die nur für Methoden verwendet werden kann. Eine mit @Override gekennzeichnete Methode muss eine Methode einer Oberklasse außer Kraft setzen. Ist dies nicht der Fall, kommt es zu einem Kompilierfehler. Mit @Override wird sichergestellt, dass eine Methode einer Oberklasse tatsächlich überschrieben und nicht nur überladen wird.

Annotation @RestResource

Gibt einem die Möglichkeit, den URL-Pfad, der einer Repository-Methode zugeordnet ist, und die Link-ID in dem von der HATEOAS-Ressourcenerkennung zurückgegebenen JSON anzupassen. Dazu verwenden wir die optionalen Parameter der Annotation: path für den URL-Pfad rel für die Link-ID

Asynchronus Continuation

Haltepunkte in der Prozessausführung, die als Transaktionsgrenzen dienen und ermöglichen es einem anderen Thread als dem gerade aktiven, die Ausführung fortzusetzen. Aus der Perspektive eines Anwendungsfalls • Async wird verwendet, um einen sicheren Punkt vor eine Aktivität zu setzen, so dass der Ausführungszustand festgeschrieben wird. Wenn die Aktivität dann nicht ausgeführt werden kann, wird die Transaktion nur bis zum sicheren Punkt zurückgerollt. • Async ist auch nützlich, wenn Sie länger laufende Berechnungen haben und den aufrufenden Thread (z. B. HTTP-Thread) nicht blockieren, sondern die schwere Arbeit an einen Hintergrund-Thread delegieren wollen.

Wir verstehen grob, wann und wie die Camunda Process Engine Prozessvariablen persistiert.

Immer dann, wenn eine Transaktionsgrenze erreicht wird, werden Daten in die DB gespeichert.

H2 Konsole

In Testumgebungen können wir analog zu phpMyAdmin für MySQL mit der H2-Konsole auf H2- Datenbanken zugreifen. In application.properties haben wir alle erforderlichen Angaben für die Verbindung. Wenn man das nicht machen würde, hätte man nur eine in memory Datenbank, sprich, wenn springboot beendet wird, ist die Datenbank auch weg/wird gelöscht. Zusätzlich im pom.xml ist dependency für h2database drin.

Annotation @PathVariable

Kann verwendet werden, um Template-Variablen in der request-URI-Mapping zu behandeln und sie als Methodenparameter zu setzen.

Annotation @GeneratedValue (3 SubTypen)

Mit dem Element strategy können wir aus vier Strategien zur Erzeugung von Bezeichnern wählen. Der Wert kann AUTO, TABLE, SEQUENCE oder IDENTITY sein. Hibernate generiert primary key. o GenerationType.AUTO: Ist der default generation type und lässt den persistence provider die generation strategy wählen. o GenerationType.IDENTITY: Ist am einfachsten zu verwenden, aber aus Sicht der Leistung nicht der beste Typ. Sie stützt sich auf eine automatisch inkrementierte Datenbankspalte und lässt die Datenbank bei jedem Einfügevorgang einen neuen Wert erzeugen. Aus Sicht der Datenbank ist dies sehr effizient, da die auto-increment-Spalten hoch optimiert sind und keine zusätzlichen Anweisungen erforderlich sind. o GenerationType.SEQUENCE: Es erfordert zusätzliche Select-Anweisungen, um den nächsten Wert aus einer Datenbanksequenz zu erhalten. Für die meisten Anwendungen hat dies jedoch keine Auswirkun-gen auf die Leistung. Und wenn Ihre Anwendung eine große Anzahl neuer Entitäten persistieren muss, können Sie einige Hibernate-spezifische Optimierungen verwenden, um die Anzahl der Anweisungen zu reduzieren.

Process ID und Process Name in Camunda

Process Id ist eine technische Id, die wir im Visual Code sehen. Process Name ist für den menschen gemachte Id, die sehen wir in der Tasklist.

Annotation @SchemaValidation

Schaltet die SchemaValidierung für Nachrichten ein. Standardmäßig validiert CXF aus Leistungsgründen keine Nachrichten gegen das Schema. Durch die Aktivierung der Validierung lassen sich Probleme mit Nachrichten, die nicht mit dem Schema übereinstimmen, leichter feststellen.

Annotation @EnableProcessApplication

Standardmäßig ist der camunda-spring-boot-starter so konfiguriert, dass er die SpringProcessEngineConfiguration-Funktion zur automatischen Bereitstellung verwendet. Man hat auch die Möglichkeit, dies über SpringBootProcessApplica-tion zu tun. Dies deaktiviert die SpringProcessEngineConfiguration-Auto-Deploy-Funktion und verwendet stattdessen die erforderliche META-INF/processes.xml als Indikator für das Scannen von Ressourcen.

Wieso greifen wir nicht direkt auf die Datenbanktabelle mit SQL-Befehlen zu aus unserem Java Delegate?

Tabelle müssten wir selbst anlegen; keine separation of concerns => Wartbarkeit und Ausbaubarkeit sehr schwer und wir könnten Datenbank nicht einfach austauschen (z.B. von relational zu dokumentenbasiert); statt mit den uns «bekannten» Java-Objekten zu arbeiten, müssten wir SQLBefehle absetzen; usw.

Annotation @Query

Um die auszuführende SQL für eine Spring Data Repository-Methode zu definieren, können wir die Methode mit der @Query-Annotation annotieren - ihr value-Attribut enthält die auszuführende JPQL oder SQL.

Vor- und Nachteile External Task

Vorteile: Process Engine ist komplett getrennt von der Service-Abwicklung i. => Prozessapplikation konzentriert sich auf ihre Stärke des Orchestrierens, statt selbst auch noch Services ab-zuwickeln ii. => Process Engine könnte z.B. in einem Netzwerk laufen (z.B. Cloud), der Worker (External Task Client) in ei-nem anderen (wo z.B. ein ERP-System läuft). Übertragen werden je nach Konfiguration nur sehr wenig (heikle) Daten als Teil der Prozessvariablen. iii. => Unabhängige Wartung möglich der zwei Komponenten und entsprechend auch problemlos zwei völlig ver-schiedene Teams verantwortlich (Stichwort Microservice-friendly). Nachteile: Wenn der Worker ausfällt, gibt es zwar keinen Incident bei der Process Engine, aber die Instanz bleibt einfach hängen. Und zudem steigt die Latenz, da asynchrone Erledigung.

Annotation @BeforeClass

Wenn eine öffentliche, statische, nicht-arg-Methode mit @BeforeClass kommentiert wird, wird sie einmal vor allen Testmethoden der Klasse ausgeführt.

Der erste Request soll uns den User zurückgeben, der zweite Request die zum User zugehörige OrgUnit

Wir bauen den eigentlichen Request, bestehend aus vier Komponenten: a. Was wir erwarten: ResponseEntity< UserRepresentation> userResponse b. Die generische und sehr flexible exchange-Methode, welche wir nutzen wollen: restTemplate.exchange und zwar mit derjenigen Variante, welche folgende Parameter erwartet: i. url: "http://localhost:8070/api/users/{username}" ii. http-Methode: HttpMethod.GET iii. Request-Body: wir haben keinen => null iv. Typ des Body der Response: UserRepresentation.class v. url parameters: lokale Variable userName

Annotation @JsonUnwrapped

Wird verwendet, um Werte von Objekten während der Serialisierung oder De-Serialisierung zu entpacken.

Annotation @Rule

Wird verwendet, um etwas einzurichten, das für jede Testmethode neu erstellt oder zurückgesetzt werden muss.

Annotation @Mock

Wird verwendet, um mocked Instanzen zu erstellen und zu injizieren. Wir erstellen keine echten Objekte, sondern bitten mockito, eine Attrappe für die Klasse zu erstellen. Ermöglicht die kurze Erstellung von Objekten, die für Tests benötigt werden. Minimiert den sich wiederholenden Code zur Erstellung von Mocks.

Call Stack

Zeigt Thread, in dem wir gerade drin sind & wo wir überall «durch» sind aber auch andere parallel laufende Threads von der Java Runtime Engine. Diese Threads sind teilweise von Visual Studio, Spring Framework oder Tomcat Server.

Annotation @Component

Zeigt an, dass eine annotierte Klasse eine "Komponente" ist. Solche Klassen werden als Kandidaten für die automatische Erkennung bei der Verwendung von annotationsbasierter Konfiguration und Klassenpfad-Scanning betrachtet.

Annotation @Controller

Zeigt an, dass eine bestimmte Klasse die Rolle eines Controllers übernimmt. Die Spring Controller-Annotation wird in der Regel in Kombination mit annotierten Handler-Methoden verwendet, die auf der @RequestMapping-Annotation basieren. Sie kann nur auf Klassen angewendet werden. Sie wird verwendet, um eine Klasse als Web-Request-Handler zu kennzeichnen.

Wir kennen die unterschiedlichen Persistierungs-Komponenten-/Schichten und ihre Rollen (Datenbank und ORM).

a. In unserem Fall DB war h2. Könnte aber auch SQL benutzen b. ORM ist Object Relational Mapping ermöglicht, dass wir auf Java seite objekt-orientiert operieren kön-nen. D.h. wir können mit üblichen Objekten und Methoden arbeiten und stellt Verbindung von Java zu relationalen Datenbankmodell her.

External Task Client in NodeJS (Vorteile)

a. Java und NodeJS-Client können separat laufen => Skalierung möglich -> Wir können sogar mit einer anderen WorkerId über ein index2.js simuliert eine zweite NodeJS-Instanz laufen lassen (z.B. auf einem anderen Server). b. «Zufällig» wird mal der eine Client, mal der andere Tasks übernehmen. c. «Besseres» Retry-Handling: Wenn ein Worker ausfällt, übernehmen die anderen, selbst wenn der ausfallende Worker bereits begonnen hat, einen Task abzuarbeiten. Das eigentliche Retry-Handling ist dadurch nicht mehr allein bei der Pro-zessapplikation, sondern stärker bei den External Task Clients. d. Der Java-Client, welcher so langsam war, bremst nun nicht mehr den Prozess aus. e. Unterstützung polyglotter (=vielsprachige) Unternehmens-IT-Architekturen (NodeJS und Java in unserem Beispiel) und damit auch verschiedener Teams.

Wir wollen über unsere JavaDelegate-Klasse nun auf den neu erstellten LDAP-Service via REST zugreifen und zwar ein GET-Request auf eine User-Resource via /users/{username} Vorgehen: Methodenwahl

a. Wir nutzen eine Methode des RestTemplates, welche im Hintergrund über zig Schichten tatsächlich mit dem REST-Service kommuniziert. b. Diese Methode kann einen Request-Body erwarten (z.B. bei POST) oder auch nicht (z.B. bei GET). c. Ein Header wird zwingend vorhanden sein, aber nicht immer müssen wir diesen manuell konfigurieren (bei nor-malem GET ist der Standard in Ordnung). d. Die Methode wird eine Response zurückgeben oder eine Exception werfen, wobei die Response aus einem http-Status und einem Body besteht. e. Für die Serialisierung, respektive Deserialisierung, von/zu einem Body (in JSON) können wir entweder die Funkti-onalität des RestTemplate nutzen oder uns selbst darum kümmern, wobei ich im Folgenden beide Varianten zeige

Spring Boot

bietet die Möglichkeit, mit einer minimalen Zahl an Zeilen eine vollständige, umfassende Server-Applikation zu erstellen. So wird z.B. im Hintergrund ein Apache Tomcat-Server (Webserver und Applikationsserver) hochgefahren, ohne dass wir dies explizit konfigurieren mussten

SOAP (Definition)

ein leichtgewichtiges XML-basiertes Protokoll, das für den Austausch von Informationen in dezentralen, verteilten Anwendungsumgebungen verwendet wird. Sie können SOAP-Nachrichten auf jede beliebige Art und Weise übertragen, die die Anwendungen erfordern, solange sowohl der Client als auch der Server die gleiche Methode verwenden. Läuft mit http Protokoll.

http Status:

• 102 PROCESSING. • 200 OK. • 201 CREATED. • 202 ACCEPTED. • 204 NO CONTENT • 205 RESET CONTENT. • 400 BAD REQUEST. • 401 UNAUTHORIZED. • 404 NOT FOUND. • 500 INTERNAL SERVER ERROR • 501 NOT IMPLEMENTED. • 502 BAD GATEWAY. • 503 SERVICE UNAVAILABLE. • 505 http VERSION NOT SUPPORTED.