In dieser Dokumentation ist beschrieben, wie wir das Process der Apartment-Reservierung implementiert haben. Als Beispiel haben wir eigene Webseite (foliage Apartment) entwickelt, wo die Gastgeber Ihre Apartments anbieten. Bei der Implementierung des Processes wurden folgende Technologien verwendet:
- Apache WebServer https://httpd.apache.org/
- Tomcat WebServer http://tomcat.apache.org/
- CakePHP https://api.cakephp.org/3.7/
- MySQL Datenbank für Apartments und Benutzer
- Maven und Plugin shade https://github.com/apache/maven-shade-plugin
- Camunda https://github.com/camunda/camunda-bpm-platform
- Google Gson https://github.com/google/gson
- RestAPI für Feiertage https://feiertage-api.de
- J2EE, Java SE 1.8 https://www.oracle.com/technetwork/java/javaee/overview/
- Git als Version Control System https://github.com/
- Bootstrap, Fontawesome und GoogleFonts für das Design
- Date Range Picker - JavaScript http://www.daterangepicker.com/
Das Model wurde in Camunda Modeler gemacht. Dies besteht aus zwei Services (extern implementiert), einem DMN (extern implementiert), einem UserTask (wird durch API Aufruf erledigt) und einem SendTask (extern implementiert mit javax.mail).
Das Process soll die Preise für Apartments dynamisch berechnen. Die Berechnung geschieht basierend auf Grundpreis (ab [num] EUR) und auf den Tagen, auf die das Apartment reserviert wird. Je nach dem, ob es Wochenende oder Feiertage gibt, wird sich der Preis um ein Faktor erhöht. Dieser Faktor Wird in einem separatem Service mithilfe von DMN berechnet. Schliesslich bekommt man die Liste mit Tagen und jeweiligen Preisen pro Nacht.
Auf der Startseite befinden sich mehrere Apartments. Beim Klicken auf eins davon landet man auf /apartment/:id. Hier sind weitere Informationen angezeigt, wie z.B. Anbieter, Preis und weiteres. Unten links muss man einen Zeitraum auswählen, für welchen man das Apartment reservieren möchte.
Beim Klicken auf das Button Prüfen, wird eine API Anfrage
POST /engine-rest/process-definition/{definition_key}/start
an Camunda Engine gesendet und Process wird gestartet. Es wird als RequestBody ein JSON Objekt übergeben, welches ApartmentID und Von- und Bis-Datums enthält. Das DefinitionKey, welches in API-Anfrage übergeben wird, wird beim Deployen des Models generiert. Diese und alle weiteren API Anfragen werden aus Sicherheitsgründen ausschließlich im Backend durchgeführt und bearbeitet. Frontendseitig werden nur entsprechende Variablen gesendet, die im Backend validiert werden und dann entsprechende Funktionen aufrufen.
Nachdem das Process gestartet wurde, wird das erste Service mit der externen Implementiereung aufgerufen. Das kann entweder über das Starten von /service/start_1_foliageAvailability.bat oder über CMD Befehl:
java -cp foliage_availability/target/apartments-availability-0.0.1-SNAPSHOT.jar availability.CheckWorker
Wenn das Process gestartet ist, erscheint ein entsprechendes Label (in diesem Fall Verfügbarkeit wird geprüft) und eine Animation. In Camunda Cockpit sieht man, das sich das Token auf dem ersten Service befindet. Das AvailabilityCheckerService erstellt eine Variable Apartment, befüllt sie mit übergebenen Daten (from, to, id) und prüft, ob diese Apartment in dem angegebenen Zeitraum verfügbar ist. Als Antwort wird an Camunda Engine ein boolischer Wert übergeben.
Als Antwort von camunda-engine API beim Starten des Process bekommt die Applikationen alle notwendigen Daten inkl. Process ID und Definition Key. Diese Daten werden für den späteren Verbrauch in Cookies gespeichert. Wenn das Availability Checker Service ein false (d.h. Apartment ist nicht frei) zurückgeliefert hat, wird das Process gleich nach dem Gateway beendet. Das Gateway bekommt eine Variable ${available} und falls sie true ist, geht das Process weiter, ansonsten (default flow) wird es beendet und der Benutzer wird über die Nicht-Verfügbarkeit des Apartments benachrichtigt. Diese Daten bekommt die App durch den folgenden API Aufruf
GET /engine-rest/history/variable-instance?variableName=available&processInstanceIdIn={id}
Danach wird das zweite Service Day Checker (auch entweder über cmd oder bat-datei start_2_foliageDayChecker.bat) gestartet.
Dieses Service prüft den von Benutzer angegebenen Zeitraum auf zwei Eigenschaften: Feiertag und Wochenendetag. Für die erste Eigenschaft wird eine externe RestAPI verwendet:
GET https://feiertage-api.de/api/?jahr={year}
Alle Tage werden in einer for-Schleife geprüft. Die API liefert Datum und Beschreibung eines Feiertages wenn es solches am jeweiligen Tag gibt. Die Wochenendetage werden einfach mit Vergleich auf Calendar.Saturday und Calendar.Sunday geprüft. Schliesslich wird ein HashMap erstellt und es mit den Daten befühlt.
Das dritte Service enthält Business Rule Task. Das wurde mit DMN modelliert und als .xml gespeichert, um es für Java lesbar zu machen. Die Tabelle sieht so aus:
Das Process wird wieder über cmd oder durch Starten von start_3_foliageCalcFactor.bat gestartet. Weil wir auf diesem Schritt ein Map (HashMap<String, Map<String, Boolean>>) von Daten haben, welches folgendermaßen aussieht:
days: {
2018-01-01: {
holiday: true,
weekend: false
},
2018-01-02: {
holiday: false,
weekend: false
}
}
müssen wir die einzelnen Datensätze durch for-Schleife laufen lassen, in der das DMN ausgeführt wird. In jeder Iteration wird aus Holiday(boolean) und Weekend(boolean) ein Double-Wert berechnet. In der for-Schleife werden Daten in ein neues Map gespeichert (Map<String, Double>). Als Antwort von Service bekommt camunda-engine eine Variable, die folgendermaßen aussieht:
factors: {
2018-01-01: 1.25,
2018-01-02: 1.00
}
Nachdem das dritte Service durchgelaufen ist, bekommt die Applikation eine Liste von Faktoren. Das geschieht über den API Aufruf
GET /engine-rest/history/variable-instance?variableName=Faktor&processInstanceIdIn={id}
Auf diesem Schritt muss der Benutzer die Entscheidung treffen, ob er mit dem Preis einverstanden ist und das Apartment immer noch reservieren möchte. Danach muss er auf das entsprechende Button klicken. Das Button submitet die Form und es triggert noch ein API Aufruf
GET /engine-rest/task?processInstanceId={id}
das liefert uns eine Liste von allen Tasks mit eingegebener ID. Wir suchen hier das richtige User Task mit dem Namen Bestätigung von user und speicher die TaskID. Dann könen wir die nächste Anfrage senden:
POST http://localhost:8080/engine-rest/task/{id}/complete
Als RequestBody wird eine boolische Variable ${ok} übergeben. Die Variable entnimmt die Applikation aus dem Button, welches geklickt wurde. Danach entscheidet das Gateway, ob das Process weitergeht oder gleich beendet wird. Wenn ${ok == true} geht das Process an den letzten Schritt. Der Benutzer bekommt nach dem Klick eine entspechende Benachrichtigung.
Letztendlich wird das Letzte Service gestartet (wie immer, entweder über cmd oder durch Started von start_4_foliageNotifier.bat). Dieses Service macht nichts anderes als sendet eine E-Mail an Gastgeber. Die E-Mail enthält den Zeitraum und das Link zum Apartment.
Nachdem E-Mail versendet wurde, wird das Process erfolgreich beendet. Notifier Service enthält externe Bibiliotheken, die mithilfe von Maven Dependencies eingebunden werden. Mit diesen Bibliotheken wird die Verbindung mit Mail-Server über SMPT hergestellt und die E-Mail gesendet. Das ganze Process kann man mit und ohne Benutzeroberfläche steuern und ausführen.
foliage-Team im Rahmen der Veranstaltung Anpassung von IT-Diensten bei Frau Prof. Meister
Dokumentiert von Rodchenkov M.