In den bisherigen Unterkapiteln wurden alle Javaskripte in den jeweiligen Events abgelegt. Diese werden in der enaio® Datenbank gespeichert, von dort über REST vom enaio® webclient geladen und zur Ausführung gebracht. Für kurze und einfache Skripte funktioniert dieser Weg sehr gut. Für lange und komplexe Client-Skripte hingegen wird es schnell unübersichtlich und ist entsprechend fehleranfällig. Vor diesem Hintergrund möchten wir in diesem Kapitel ein alternatives Vorgehen aufzeigen.

Installationsvoraussetzungen

Folgende Voraussetzungen müssen mindestens erfüllt sein:

enaio® webclient 9.10 Final SR4
enaio® gateway 9.10 Final Hotfix 10
DMS service 9.10 Version 3.0.2 (oder neuer)
enaio® service-manager 9.10 (Hotfix)

1 Installationsvoraussetzungen
2 Weitere Vorbereitungen
3 Laden von Javaskript aus einem public-Ordner (ab 9.10 SR7)
4 Laden von anderen Ressourcen aus einem public-Ordner
5 Staging zwischen Test-, Abnahme- und Produktivsystem
6 Staging mit einem Versionsverwaltungssystem wie Git
7 Mehrere Service-Manager Instanzen

Weitere Vorbereitungen

Alle Microservices in enaio® teilen sich eine zentrale Stelle, wo alle Konfigurationsdateien abgelegt sind, die sie zum Betrieb benötigen. Im Zuge der Umstellung auf Microservices wird diese Stelle für die enaio® Gesamtsystem-Konfiguration immer wichtiger. Neben den Konfigurationen für die Microservices - die von außen nicht erreichbar sind - bietet diese Stelle auch einen öffentlichen Teil, dessen Ressourcen über das enaio® gateway und somit für Clients wie enaio® webclient erreichbar sind.

In der Grafik ist beispielhaft das config-Verzeichnis des enaio® service-manager dargestellt. Hier hervorzuheben ist der Ordner apps, welcher die Basis für eigene Ressourcen darstellt. Innerhalb des Ordners müssen weitere Unterordner für die einzelnen Projekte angelegt werden, um eine gewisse Basisstruktur sicherzustellen. In einem Projekt-Unterordner muss nun ein Unterordner namens public folgen, in welchem dann die öffentlich zur Verfügung stehenden Ressourcen abgelegt werden können. Dabei kann sich der public-Unterordner weiter nach Bedarf untergliedern. Nur Ressourcen die unterhalb des public-Unterordners liegen sind über enaio® gateway für Clients wie enaio® webclient abrufbar.

Die Ordnerstruktur ist nachfolgend noch einmal visuell dargestellt.

Laden von Javaskript aus einem public-Ordner (ab 9.10 SR7)

In einem Event-Skript, wie zum Beispiel das AfterWebClientLogin Skript, kann Javaskript aus public-Ordnern über die Methode includePublicScript geladen und automatisch ausgeführt werden:

// Queries inside service-maanger: config/apps/osweb/public/vertragsakte.js
formHelper.includePublicScript("osweb/public/vertragsakte.js").then(result => {
   // Continue here if you want to wait until the script is loaded and executed.
});

Das hier dargestellten Skript vertragsakte.js könnte dabei exemplarisch wie folgt aussehen:

var vertragsakte = {};
 
vertragsakte.config = {
    multiplier: 10
};
 
vertragsakte.calcWithMultiplier = function(value) {
    return value * vertragsakte.config.multiplier;
};
 
vertragsakte.init = function(formHelper, globals, scriptingStorage, userAction, done) {
    var nr = formHelper.getFieldByName("vertragsNr");
    // ...
	done();
};

scriptingStorage.vertragsakte = vertragsakte;

Das exemplarische Skript vertragsakte.js definiert für sich ein eigenes JavaScript Objekt und fügt diesem Funktionen, Variablen sowie weitere JavaScript Sprachbestandteile hinzu. Innerhalb eines Event-Skriptes - wie dem AfterLogin-Event zum Start des enaio® webclient - können dann mithilfe von includePublicScript öffentliche Skript-Ressourcen aus dem public-Verzeichnis geladen werden. Die hier aufgezeigte Beispielimplementierung fügt das nachgeladene Vertragsaktenskript dann dem globalen enaio® webclient-Skriptobjekt scriptingStorage hinzu, welches das Vertragsakte-Objekt dann über die gesamte Laufzeit des WebClient zur Verfügung stellt.

In einem beispielhaften OnShow-Event des Objekttypen Vertragsakte könnte nun nur noch eine einzige Zeile stehen, und der gesamte Skriptablauf sowie dessen Logik erfolgt im nachgeladenen Skript:

scriptingStorage.vertragsakte.init(formHelper, globals, scriptingStorage, userAction, done);

Jede Skript-Ressource erfordert eine eigene HTTP(S)-Anfrage. Aus diesem Grund sollten Skript-Ressourcen nicht zu fein-granular sein.

Laden von anderen Ressourcen aus einem public-Ordner

Möchten Sie auf andere Ressourcen als Javaskript aus einem public-Ordner zugegriffen, so nutzen Sie dazu die Methode getPublicResource:

// Queries inside service-maanger: config/apps/osweb/public/vertragsakte.js
formHelper.getPublicResource("osweb/public/data.json").then(result => {
   // result contains the loaded data from data.json
});

Staging zwischen Test-, Abnahme- und Produktivsystem

Bei Kunden existieren in der Regel verschiedene Installationen:

Testsystem - für die Entwicklung neuer Lösungen
Abnahmesystem - für eine finale Abnahme der neu entwickelten Lösungen
Produktivsystem - auf dem beim Kunden produktiv mit realen Daten gearbeitet wird

Skripte, die auf dem Testsystem funktionieren, werden händisch in die einzelnen Events des Abnahmesystems transportiert. Dort müssen sie dann noch einmal aufwändig getestet werden, da bei dem händischen Transport Fehler passieren können. Selbiges dann vom Abnahmesystem zum Produktivsystem. Dieser auf dem Dateisystem basierende Ansatz macht die Sache bereits um einiges einfacher. In den Event-Skripten existiert oftmals lediglich ein einzelner Aufruf zum globals-Objekt wie im nachfolgenden Beispiel dargestellt:

scriptingStorage.vertragsakte.init(formHelper, globals, scriptingStorage, userAction, done);

Einmal entwickelt ändert sich hier nichts mehr, denn die gesamte Logik findet im Vertragsaktenskript statt, dem über arguments alle Argumente der OnShow-Eventhandlerfunktion durchgereicht werden. In zukünftigen Versionen müssen die Event-Skripte somit in der Regel nicht mehr angefasst werden. Das spart Zeit und es entstehen keine Fehler. Lediglich das händische Kopieren der Ressourcen in den public-Ordnern bleibt übrig, das jedoch sehr schnell und fehlerfrei durchführbar ist. Weitere Unterstützung und Sicherheit beim Kopieren bieten hier zusätzlich Versionsverwaltungssystem wie Git an.

Staging mit einem Versionsverwaltungssystem wie Git

Der gesamte Inhalt des config-Verzeichnisses in enaio® service-manager kann in ein Git-Repository ausgelagert werden. Darunter fallen auch die öffentlichen Skripte in den public-Verzeichnissen. Für die Konstellation Test-, Abnahme- und Produktivsystem werden seperate Git-Zweige erstellt und die jeweilige enaio® service-manager-Installation wird an einen der Zweige angebunden. Dadurch können auch verteilte enaio® service-manager-Installationen ohne Kopierarbeiten automatisch mit Konfigurationen und natürlich öffentlichen Skript-Ressourcen versorgt werden. Ist die Entwicklung abgeschlossen und erfolgreich getestet, wird der Entwicklungszweig im Git in den Develop-Zweig gemerged und schon sind alle Änderungen im Abnahmesystem verfügbar. Gleiches passiert nach erfolgter Abnahme. Ein Merge in den Master-Zweig und alles steht im Produktivsystem zur Verfügung. Ein Kopieren ist nicht mehr notwendig.
>> Mehr zum Staging mittels Git im enaio® service-manager finden Sie in der Online-Hilfe zu enaio® service-manager.

Mehrere Service-Manager Instanzen

Besteht die enaio® Installation aus mehreren enaio® service-manager Instanzen, so müssen die Public-Ressourcen auf jeder enaio® service-manager Instanz verfügbar sein, da zwischen allen enaio® service-manager Instanzen ein Loadbalancing existiert. Die Public-Ressourcen werden dem entsprechend wahllos von irgend einer Instanz bezogen und nicht immer von ein und derselben. Am besten erreichen Sie die zentrale Verfügbarkeit, indem Sie ein Staging mit einem Versionsverwaltungssystem wie Git einführen.

enaio® webclient

1.8 Laden externer Ressourcen