Zielgruppe EntwicklungVersion: GSB10.1Produktentwicklung

• Dokumentmodell
• Gradle und Gradle–Plugins
• GSB Editor Entwicklung
• Checks / Reports
• Git-Repositories
• Releaseerstellung
• GSB Produktkomponenten
• Installation / Deployment eines Release
• Skillprofil
• Benötigte Umgebungen

Grundsätzlich werden bei der Entwicklung des GSB und der einzelnen GSB Komponenten nach Möglichkeit etablierte Standards genutzt. Die Dokumentation der Kernentwicklung greift dies auf, indem diese zu den einzelnen Themenstellungen eine Erläuterung der GSB spezifischen Besonderheiten enthält und für weiterführende und vertiefende Informationen auf die vorhandene Dokumentation der jeweiligen Komponente verwiesen wird (bspw. Spring-Dokumentation).

Dokumentmodell

Das Dokumentmodell in dem die redaktionellen und konfigurativen Inhalte der GSB Mandanten gespeichert werden basiert auf einer Vererbungshierarchie von aufeinander aufbauenden Dokumenttypen.

Die Definition des Dokumentmodells im GSB 10 findet sich hier in der Datei repository/src/main/resources/required-doctypes.cnd. Die CND Datei beschreibt das Dokumentmodell als Compact Namespace and Node Type Definition (CND). Erweiterungen und Änderungen am Dokumentmodell müssen in der GSB 10 CND durchgeführt werden.

Die Änderungen an der CND müssen in den korrespondierenden Java Contentbeans unterhalb von

• contentbase/src/main/java/de/bund/gsb/site/contentbeans und
• /site/src/main/java/de/bund/gsb/site/contentbeans nachvollzogen werden.

Darüber hinaus liegt das Dokumentmodell auch als XML-Modell in der Datei /src/docs/cms_docmodel.zuml. Das Modell kann mit dem lizenzkostenpflichtigen Tool "Poseidon for UML Version 4.2" bearbeitet werden. Das XML-Modell wird genutzt, um hieraus eine HTML-Dokumentation des Dokumentmodells zu generieren. Die Erstellung der Dokumentation erfolgt automatisch bei der Generierung der Asciidoc-Dokumentation des GSB 10 Release.

Gradle und Gradle–Plugins

Der GSB wird mit Hilfe von Gradle gebaut.

Alle Schritte des Bauprozesses (Kompilierung, Assemblierung, Tests etc.) sind als Gradle-Tasks umgesetzt. Der GSB stützt sich hierbei auf Standard Gradle-Plugins, die z.T. GSB spezifisch erweitert worden sind.

Durch Nutzung von Gradle als Build-Tool für den GSB können stehen im GSB damit automatisch alle Tasks und Konventionen des Gradle Lifecycle genutzt im GSB Entwicklungs- und Bauprozess genutzt werden.

Eine detaillierte Erklärung aller Gradle-Plugins ist in der Javadoc-Dokumentation der Plugins zu finden.

Übersicht

Abbildung 1. Übersicht über alle Gradle Plugins

Legende:

Blau

In Gradle selbst enthaltene Standard-Plugins

Rot

Externe Open-Source Plugins von Drittanbietern

Grün

Im Rahmen des GSB/OS entwickelte und bereitgestellte Gradle-Plugins

Liste der im Rahmen des GSB bereitgestellten Gradle-Plugins

ID	Basiert auf	Beschreibung
de.bund.gsb.versions	io.spring.dependency-management	Versionsmanagement für Dependencies
de.bund.gsb.base	base	Basis-Konventionen für alle GSB-Projekte
de.bund.gsb.customer	de.bund.gsb.base	Für Mandanten-Projekte
de.bund.gsb.aggregate-javadoc		Aggregiertes Javadoc über einen kompletten Gradle-Build.
de.bund.gsb.java-base	java	Basis-Konventionen für alle Projekte mit Java-Code.
de.bund.gsb.java	java de.bund.gsb.java-base	Plugin für Projekte, welche JAR-Dateien produzieren.
de.bund.gsb.war	war io.freefair.war de.bund.gsb.java-base	Plugin für Projekte, welche WAR-Dateien produzieren.
de.bund.gsb.component	de.bund.gsb.distribution	Basis-Plugin für Projekte, welche GSB-Komponenten bauen.
de.bund.gsb.tomcat-component	de.bund.gsb.component	Für Projekte, welche GSB-Komponenten als catalina.base-Verzeichnis bauen.
de.bund.gsb.application-component	de.bund.gsb.component application	Für Projekte, welche GSB-Komponenten als Standalone-Anwendung bauen.
de.bund.gsb.liferay-component	de.bund.gsb.tomcat-component de.bund.gsb.war	Für Projekte, welche Liferay-basierte GSB-Komponenten bauen.
de.bund.gsb.distribution	distribution	GSB Konventionen für das distribution-Plugin.
de.bund.gsb.documentation	de.bund.gsb.asciidoctor	Für Projekte, welche AsciiDoc-Dokumentation beinhalten.
de.bund.gsb.release	de.bund.gsb.distribution	Für das Bauen, eines GSB-Releases
de.bund.gsb.content		Für Projekte, welche Content aus einem Content-Repository extrahieren.
de.bund.gsb.install		Ermöglicht die einfache lokale Installation von Komponenten in Mandanten-Projekten.
de.bund.gsb.checkstyle	checkstyle	GSB Checkstyle Konventionen auf Basis des checkstyle-Plugins.
de.bund.gsb.cpd	de.aaschmid.cpd	GSB CPD Konventionen auf Basis des de.aaschmid.cpd-Plugins.
de.bund.gsb.spotbugs	com.github.spotbugs	GSB SpotBugs Konventionen auf Basis des com.github.spotbugs-Plugins.
de.bund.gsb.jacoco	jacoco	GSB JaCoCo Konventionen auf Basis des jacoco-Plugins.
de.bund.gsb.asciidoctor-base		Basis-Plugin für Projekte welche Asciidoctor nutzen.
de.bund.gsb.asciidoctor	de.bund.gsb.asciidoctor-base	Für Projekte, welche Asciidoctor nutzen.
de.bund.gsb.xalan		Für Projekte, welche Xalan nutzen.
de.bund.gsb.export-nexus		Für Projekte, welche ein Maven-Repository aus einem Nexus-Server exportieren.
de.bund.gsb.integration-test		Für Integrationstests.
de.bund.gsb.selenium-test	de.bund.gsb.integration-test	Für Selenium-basierte Integrationstests.

Die meisten der Gradle Plugins basieren - soweit möglich - auf vorhandenen Standard-Plugins und konfigurieren diese nur gemäß der GSB-Konventionen, damit diese auch in Mandanten-Projekten einfacher genutzt werden können. Das de.bund.gsb.checkstyle-Plugin konfiguriert beispielsweise nur die GSB-Checkstyle Regeln für das Gradle-eigene checkstyle-Plugin.

GSB-spezifische Konfigurationen

gsb {
    coreVersion = '10.1.0-SNAPSHOT' (1)
    component {  (2)
        name = 'indexer' (3)
    }
    customer { (4)
        name = 'standardlsg' (5)
    }
    install { (6)
        gsbosDir = '/opt/gsbos'
        softwareDir = "$gsbosDir/software"
        runtimeDir = "$gsbosDir/runtime"
        localRuntimeDir = '~/gsbos/runtime'
        symlinkTemplates = true
    }
    documentation { (7)
        baseName = gsb.component.name (8)
    }
}

1	Die aktuelle GSB-Version (Default ist die Version des genutzen Gradle Plugins)
2	Konfiguration für das de.bund.gsb.component-Plugin
3	Name der GSB-Komponente (Default ist der Name des Projektes)
4	Konfiguration für das de.bund.gsb.customer-Plugin
5	Name des Mandanten (Default ist der Name des (Root-)Projektes)
6	Konfiguration des de.bund.gsb.install-Plugins. (Für Mandanten-Projekte)
7	Konfiguration für das de.bund.gsb.documentation-Plugin.
8	Basis-Verzeichnis für die Dokumentation.

GSB Editor Entwicklung

Der GSB Editor Client wird auf Grundlage des Google Web Toolkits entwickelt. An dieser Stelle werden insbesondere die Besonderheiten gegenüber einem Standard Java-Projekt skizziert.

Gradle Plugins

Zusätzlich zu den Gradle Plugins der Basis werden für den Editor weitere Plugins definiert.

Deploy Plugins

Die Deploy Plugins sorgen dafür, dass für den Client die Tasks deploySdmStatic, deployDevelopment und deployProduction und für die komplette Editor-Anwendung der Task deploy erzeugt werden. Die Deploy-Tasks des Clients sorgen dafür, dass der Client separat und entpackt neben die Anwendung gelegt wird. Über die Extension des Plugins kann der Pfad angegeben werden, in dem das Deployment stattfinden soll.

Client Instance Plugin

Das Client Instance Plugin konfiguriert die GWT-Tasks. Es werden die Module gesetzt, die Übersetzt werden sollen. Dazu wird die Variable instancePackages ausgewertet. Aus den angegebenen Namen werden automatisch die Module *Development und *Production erzeugt. Weiterhin wird die IP gesetzt, auf die der SuperDev Mode horcht. Neben der Konfiguration der GWT-Tasks wird der Task sdmWar angelegt, der die Ressourcen des Clients packt ohne einen gwtCompile durchzuführen.

Einrichten der Entwicklungsumgebung

Um die Umgebung für die Entwicklung vorzubereiten, wird die Datei editor/host.gradle.example nach editor/host.gradle kopiert. In der kopierten Datei wird in der Property ext.deployPath der Pfad eingetragen, an den die Anwendung kopiert werden soll. Normalerweise sollte der Wert /opt/gsbos/software/editor/ sein. Außerdem kann durch ext.bindAddress eine Adresse angegeben werden, auf die der SuperDev Mode horcht. Wird beispielsweise in einer VM entwickelt, kann hier die externe IP-Adresse angegeben werden, damit der SuperDev Mode ebenfalls im Host funktioniert.

Über den Gradle-Task :editor:installAll wird ein lokaler Apache und der Editor installiert. Weiterhin wird eine runtime-Konfiguration unter ~/gsbos/runtime/ für die Entwicklung erzeugt und nach /opt/gsbos/runtime verlinkt.

Für die Client-Entwicklung ist es notwendig, dass der Client entpackt ist. Die Deploy-Tasks des Clients legen die Ressourcen neben dem Editor, beispielsweise unter /opt/gsbos/software/editor/static/gsbeditor, ab. In den application.properties muss der Ort noch durch den Eintrag spring.resources.static-locations registriert werden.

Client

Der Client des GSB Editors wird mit dem Google Web Toolkit (GWT) entwickelt. Der Quellcode kann so in Java geschrieben werden und in JavaScript durch GWT übersetzt werden.

Annotation Processor

Der Client verfügt über zwei Annotation Processor. Diese erzeugen zum einen die Implementierungen der Label-Interfaces und zum anderen sammeln sie die Defaults der Label auf. Werden die Projekte durch Gradle übersetzt, werden die Annotation Processor automatisch ausgeführt. Falls der Quellcode durch eine IDE übersetzt werden soll, muss diese entsprechend konfiguriert werden.

SuperDev Mode

Die Entwicklung des Clients geschieht im SuperDev Mode. Dabei wird der Code übersetzt, wenn die Seite des Editors geladen wird. Der SuperDev Mode wird durch den Gradle-Task :editor:gsbeditor:gwtSuperDev gestartet. Optional kann der Task :editor:gsbeditor:deploySdm vorher ausgeführt werden, der dafür sorgt, dass die Ressourcen des War-Archivs aktuell sind. Der SuperDev Mode verfügt nicht über die Möglichkeit Annotation Processor auszuführen. Werden also Änderungen an den Label-Interfaces vorgenommen, muss zunächst ein recompile der entsprechenden Projekte vorgenommen werden.

Model View Presenter

Der Editor ist mit dem Model View Presenter (MVP) Entwurfsmuster entwickelt. Dieses Muster ist aus dem Model View Controller (MVC) entstanden. Bei diesem Muster gibt es eine Unterteilung in Model, View und Presenter. Das Model kennt weder Presenter noch View. Die View ist nur für die Darstellung und für Ein- und Ausgaben zuständig. Sie interagiert nicht mit dem Model. Der Presenter verbindet das Model mit der View und steuert die Abläufe.

Turducken

Durch das Prinzip Turducken (Turkey + Duck + Chicken) werden große Anwendungen in mehrere kleinere aufgeteilt. Dabei gibt es eine Basisanwendung, die für das Laden der weiteren enthaltenen Anwendungen verantwortlich ist. Die Kommunikation zwischen den Anwendungen erfolgt durch einen sogenannten InterAppEventBus.

Der GSB Editor (Client) besteht aktuell aus einem großen Kern (Basisanwendung) und der eingebundenen Preview-Anwendung (Nebenanwendung).

Struktur

Klassen die sowohl vom Rest-Interface, dem Backend des Editors, als auch vom Client genutzt werden befinden sich im Projekt :editor:model. Der Code des Clients liegt im Projekt :editor:gsbeditor und die statischen Ressourcen liegen im Projekt :editor:gsbeditor-resources. Der Client ist in die folgenden Module aufgeteilt:

• Widgets
• Core
• Base
• Benchmark
• Preview

Im Modul Widgets befinden sich die GWT-Widgets, die für ein einheitliches Design sorgen. Core stellt wichtige Interfaces und Implementierungen bereit, die in allen GWT-Modulen zur Verfügung stehen sollten. Beispielsweise findet sich hier der InterAppEventBus für die Kommunikation zwischen den GWT-Modulen. Der Hauptteil des Editors ist im Modul Base zu finden. Die verschiedenen Bereiche des Editors spiegeln sich hier in den Packages wieder. Die Klassen des DokumentEditors liegen beispielsweise im Package de.bund.gsb.webeditor.client.base.documenteditor. Das Optionale Modul Benchmark fügt ein Benchmark-Panel hinzu, wenn es mit kompiliert wird. Das GWT-Modul für das Preview-Fenster ist Preview. Es ist als optionale Erweiterung des Kerns gestaltet. Der Kern hat keinerlei Abhängigkeiten zu diesem Projekt.

Die Erstellung des Editor Clients wird ebenfalls mit entsprechenden Gradle-Tasks durchgeführt.

Checks / Reports

Die Beschreibung der Prüfung der GSB Sourcen gegen die GSB Code-Conventions und Erstellung von Reports werden in diesem Kapitel dokumentiert.

Tools

Im GSB werden die folgeden Tools genutzt um die verschiedene Aspekte des Codes zu testen und zu messen. Die Ausführung der Checks kann durch Aufruf der entsprechenden Gradle-Tasks bzw. bei Verwendung einer CI/CD-Pipeline im Rahmen der Entwicklung individuell auf Basis der jeweiligen Anforderungen gesteuert werden. Pauschale Vorgaben können an dierser Stelle nicht getroffen werden und sind individuell mit dem Auftraggeber der Entwicklung abzustimmen.

Checkstyle

Checkstyle führt eine statische Analyse des Quellcodes durch. Hierbei steht die Einhaltung von Code-Conventions im Vordergrund.

Die Einbindung von Checkstyle erfolgt durch das de.bund.gsb.checkstyle Gradle-Plugin. Dieses nutzt das Gradle-eigene checkstyle Plugin und konfiguriert die GSB-Regeln vor. Checkstyle kann über den Gradle-Task checkstyleMain gestartet werden.

SpotBugs

SpotBugs (der Nachfolger von FindBugs) führt eine statische Analyse des kompilierten Bytecodes durch. Hierbei steht das Auffinden von (potentiellen) Fehlern im Programmcode im Vordergrund.

Die Einbindung von SpotBugs erfolgt durch das de.bund.gsb.spotbugs Gradle-Plugin. Dieses nutzt das offizielle com.github.spotbugs Plugin und konfiguriert die GSB-Regeln vor. SpotBugs kann über den Gradle-Task checkstyleMain gestartet werden.

CPD

CPD führt eine statische Analyse des Quellcodes durch. Hierbei steht das Auffinden von identischen (kopierten) Code-Blöcken im Vordergrund.

Die Einbindung von CPD erfolgt durch das de.bund.gsb.cpd Gradle-Plugin. Dieses nutzt das de.aaschmid.cpd Plugin und konfiguriert die GSB-Regeln vor. CPD kann über den Gradle-Task cpdCheck gestartet werden.

Junit

Mit Hilfe von Junit wird eine dynamische Analyse des Codes (sog. Unit-Tests) durchgeführt.

Die Ausführung der Tests erfolgt durch Gradle. Die Tests können über die Gradle-Tasks test (für Unit-Tests) und integrationTest (für Integrations-Tests) gestartet werden. Unit-Tests sind in den jeweiligen Komponenten meist unter src/test/ zu finden, Integrations-Test liegen unterhalb von src/integrationTest, sofern vorhanden.

JaCoCo

JaCoCo misst, welche Teile des Quellcodes im Rahmen der Unit- und Integrationstests ausgeführt wurden und welche nicht.

Die Einbindung von JaCoCo erfolgt durch das de.bund.gsb.jacoco Gradle-Plugin. Dieses nutzt das Gradle-eigene jacoco Plugin und Konfiguriert dieses GSB-spezifisch vor. Die JaCoCo Reports können über die Gradle-Tasks jacocoTestReport (für Unit-Tests) und jacocoIntegrationTestReport (für Integrations-Tests) generiert werden.

OWASP Dependency Check

Der OWASP Dependency Check durchsucht die Abhängigkeiten der Projekte nach bekannten Sicherheitslücken.

Die Einbindung des OWASP Dependency Checks erfolgt durch das org.owasp.dependencycheck Gradle-Plugin. Der Check kann über den Gradle-Task dependencyCheckAnalyze gestartet werden.

Der Gesamt-Report

Der Gesamt-Report, welcher die Ergebnisse der einzelnen Tools für die einzelnen Teil-Projekte aggregiert und aufbereitet, kann über die Gradle-Tasks reportsZip und qualityReport erstellt werden.

Git-Repositories

Der Aufbau der GSB GIT-Repositories und die der Entwicklung zugrundeliegenden GIT Workflows werden an dieser Stelle dokumentiert.

Der GSB besteht aus insgesamt 3 Git-Repositories, welche im *-git.zip Artefakt zusammengefasst sind und die einen Gradle-Build enthalten. Die Git-Repositories müssen beim initialen Aufsetzen einer Entwicklungsumgebung aus den Git Zip-Artefakten erstellt werden. Die Struktur und Organisation der Zip-Artefakte entspricht 1zu1 der benötigten Struktur des jeweiligen Git-Repositories, so dass dieses einfach auf Grundlage und Basis des Git-Artefakts erstellt werden kann:

Abbildung 2. Übersicht über die GSB Repositories/Projekte

Basis

Das Basis Repository enthält die Kern-Implementierung aller GSB-Komponenten, sowie die Hilfs-Mandanten https und service.

standardlsg

Das standardlsg Repository enthält den Mandanten standardlsg. Dieser ist als separates Projekt/Repository umgesetzt, damit er leichter als Vorlage für weitere Mandanten-Projekte genutzt werden kann.

Hinweis:

Der Mandant Standardlösung ist kein integraler Bestandteil des GSB Produktes. Die Standardlösung wird stattdessen unabhängig und eigenständig vom eigentlichen GSB Produkt entwickelt, um hier flexibler auf fachliche und funktionale Anforderungen reagieren zu können. Aus technischer Sicht wird die Standardlösung im Mandanten standardlsg entwickelt und bereitgestellt. An dieser Stelle wird der Mandant und das zugehörige Git-Repository standardlsg daher nur der Vollständigkeit halber erwähnt.

Release

Das Release Repository enthält selbst keinen Code, sondern nur einen Gradle-Build, welcher das GSB-Release bestehend aus den Basis-Komponenten und dem standardlsg Mandanten zusammenbaut.

Releaseerstellung

Der Prozess der Releaseerstellung wird hier dokumentiert. Das Release umfasst sowohl alle Komponenten des GSB-Produktes sowie der im Release enthaltenen GSB-Mandanten (bspw. standardlsg). Die Dokumentation berücksichtigt die Erstellung eines Gesamtrelease.

Die Installation auf den zentralen Servern der Entwicklungs- und Testumgebungen erfolgt im Anschluss durch Erstellung des Platform Bundle und dessen Installation auf den Servern der jeweiligen Umgebung.

Übersicht über das Gesamtrelease

Um ein GSB-Gesamtrelease zu erstellen müssen die Teilprojekte in ihren einzelnen Kapitel 6, “Git-Repositories” in der korrekten Reihenfolge released werden.

Im ersten Schritt muss das Basis Repository released werden.

Danach kann in der gradle.properties-Datei im standardlsg Repository die soeben releaste Basis Version refeziert werden. Nachdem das standardlsg Projekt nun gegen die fertige Basis Version baut, kann auch dieses released werden.

Im letzten Schritt können in der gradle.properties-Datei des Release-Projektes die Versionsnummern der releasten Basis und der releasten standardlsg eingetragen werden, um dann - durch das Release-Projekt das Gesamtrelease zu erstellen.

Release eines Teil-Projektes

Das Release eines der drei Kapitel 6, “Git-Repositories” läuft für alle Projekte jeweils identisch ab. Dieser Prozess wird im Folgenden beschrieben.

Bei Nutzung des Gitflow-Workflow wird empfohlen, dass aus dem develop-Branch ein release-Branch erstellt wird, in dem nur noch Bugfixes und für das Release wichtige Änderungen committed werden. Nach Fertigstellung des Releases sollte der Release-Stand in den master-Branch und der master- in den develop-Branch gemerged werden.

In GSB Projekten wird dieser Prozess mit Hilfe von zwei Gradle-Tasks unterstützt.

prepareRelease

Dieser Task erstellt - ausgehend vom develop-Branch - einen neuen release-*-Branch. Die Versionen für das Release und die weitere Entwicklung können dabei über Parameter angegeben werden.

prepareRelease für einen Release Candidate

./gradlew prepareRelease --release-version=42-rc1 --next-version=42

In diesem Beispiel wird während der Entwicklung der Version 42 ein release-*-Branch für den Release Candidate 42-rc1 erzeugt. Die Version für die weitere Entwicklung bleibt in diesem Fall 42.

prepareRelease für ein finales Release

./gradlew prepareRelease --release-version=42 --next-version=42.1

In diesem Beispiel wird am Ende der Entwicklung der Version 42 ein release-*-Branch für die Version 42 erzeugt. Die Version für die weitere Entwicklung wird auf 42.1 erhöht.

performRelease

Dieser Task finalisiert das mit Kapitel 7.2.1, “prepareRelease” vorbereitete Release, in dem es den release-*-Branch in den master-Branch merged, die Version mit einem entsprechenden tag versieht, und das Ganze dann wieder in den develop-Branch merged.

Der Task muss auf dem zu finalisierenden release-*-Branch gestartet werden.

./gradlew performRelease

Danach kann auf dem master-Branch das Release - wie im nächsten Kapitel beschrieben - gebaut werden.

Bau des Releases im Release Projekt

• Der Gradle-Task distZip erstellt das Release als Zip-Datei im Ordner build/distributions
• Der Gradle-Task installDist erstellt das Release in entpackter Form im Ordner build/install

Bei Nutzung des maven-publish Gradle-Plugins werden zudem automatisch zwei entsprechende Publications mit den Namen gsb und gsbReports erstellt. Diese erlauben es das Release über ensprechende publish* Tasks in einem Maven-Repository abzulegen.

GSB Produktkomponenten

Abschließend werden die einzelnen Komponenten des GSB Produktes vorgestellt. Die einzelnen Komponenten sind im zentralen GSB Git-Repository jeweils als Subprojekt definiert und abgelegt. An dieser Stelle wird insbesondere der fachliche Hintergrund der einzelnen Subprojekte beschrieben.

Adminportal

Das Adminportal fasst die Administration der GSB-Funktionen an zentraler Stelle und mit einem einheitlichen Look & Feel zusammen und stellt dem Nutzer einen Single-Point-Of-Administration bereit. Das Adminportal basiert auf dem Liferay-Portal, das an den erforderlichen Stellen erweitert / optimiert wird und das die Basis für den Mandanten-Bereich mit den Administrations-Portlets bildet.

Das Adminportal setzt sich aus folgenden Git-Modulen des Basis-Repositories zusammen:

• adminportal
• liferay
• liferay-jsf-spring-boot-starter
• liferay-spring-boot-starter

Das Git-Modul adminportal bündelt die einzelnen Administrations-Portlets des Adminportals. Das liferay-Modul bindet das aktuell genutzte Liferay-Portal als Abhängigkeit ein und enthält Anpassungen oder Optimierungen am Liferay selbst. Die beiden spring-boot-starter Module enthalten Spring-Boot-Konfigurationen zur Nutzung im Liferay-Kontext.

Die Portlets zur Administration der GSB-Funktionen befinden sich in einzelnen Modulen unterhalb des adminportal-Moduls (z.B. guestbook-admin). Ein Portlet ist eine Webapplikation, die nach dem Portlet-Standard (Java Portlet Specification 2.0 JSR-286 oder 3.0 JSR-362) entwicklet wird und die in einem Portal-Server (Portlet-Container) betrieben werden kann. Dabei können mehrere Portlets auf einer Seite des Portals unabhängig voneinander verwendet werden. Genauere Informationen zu Portlets im Liferay-Portal finden sich in der Liferay-Portlet-Dokumentation. Der gewählte Technologie-Stack zur Entwicklung von Portlets im Liferay-Portal kann dabei frei gewählt werden: z.B. Liferay’s MVCPortlet, Spring MVC, JavaServerFaces (JSF). Die Portlets im Adminportal werden als JSF-Portlets mit der JSF-UI-Biliothek PrimeFaces und mit dem Spring-Framework entwickelt.

Um ein JSF-Portlet für das Liferay-Portal zu entwickeln wird ein Rahmen aus Konfigurationsdateien benötigt, die unterhalb des src/main/webapp/WEB-INF-Verzeichnisses des Adminportals des Portlet-Git-Moduls abgelegt werden. Die folgende Tabelle listet die Dateien und deren Funktion auf:

Datei	Funktion
faces-config.xml	Konfiguration der JSF-Applikation (z.B. zur Definition von Ressource-Bundles)
liferay-display.xml	Beschreibt die Kategorie unter der das Portlet bei der Portlet-Auswahl angezeigt werden soll
liferay-plugin-package.properties	Definiert die Eigenschafen des Liferay-Plugins (alle Eigenschaften)
liferay-portlet.xml	Beschreibt die Liferay-spezifischen-Erweiterungen für Portlets, die im Liferay-Portal installiert werden
portlet.xml	Definition des Portlets (Name, Info, Einstiegspunkt, Portlet-Klasse etc.)

Zu Verwaltung der JSF-Beans (u.a. für Dependency Injection) wird das Spring-Framework mit Spring-Boot verwendet. In jedem Administration-Portlet ist eine @SpringBootApplication-Klasse vorhaden, die für die Initialisierung des Kontextes verantwortlich ist. Über den in der portlet.xml definierten Einstiegspunkt:

<init-param>
<name>javax.portlet.faces.defaultViewId.view</name>
<value>defaultSite.xhtml</value>
</init-param>

wird die Ansicht bei Aufruf des Portlets definiert.

Die folgende Tabelle listet die vorhandenen Git-Module unterhalb des adminportal-Basis-Moduls und dessen Funktion

Adminportal-Modul	Funktion
auto-login	Komponente zur Verwaltung der SSO-Login-Daten sowie den automatischen Import von Nutzern aus dem Userservice
custom-fields	Initialisierung der benötigten Liferay-Custom-Fields
datatable-admin	Portlet zur Verwaltung von Datentabellen
eventdispatcher-admin	Portlet zur Verwaltung der Eventdispatcher-Performer
guestbook-admin	Portlet zur Verwaltung der Gästebücher
liferay-theme	Erweiterungen am Liferay-Theme
member-admin	Portlet zur Verwaltung von Benutzern/Gruppen/Rollen
newsletter-admin	Portlet zur Verwaltung von Mailing-Listen und Newslettern
primefaces-theme	Erweiterungen am Primefaces-Theme
rating-admin	Portlet zur Verwaltung von kommentier- / bewertbaren Dokumenten
selenium-test-common	Basisprojekt für Selenium-Testfälle
solr-info	Portlet zur Verwaltung des Suchservers
spring-boot-starter	Von den Portlets gemeinsam genutzte Funktionalitäten
survey-admin	Portlet zur Verwaltung von Umfragen
test-common	Basisprojekt für Testfälle
workflow-admin	Portlet zur Verwaltung der Workflows

CAS

Der CAS ist die Single-Sign-On Lösung für den GSB.

Das cas Projekt enthält lediglich GSB-spezifische Anpassungen auf Basis des Apereo CAS. Dazu gehören hauptsächlich eine angepasste Benutzeroberfläche sowie die Fähigkeit zwischen Mandanten zu unterscheiden.

Der CAS nutzt die REST Authentication-Methode um den tatsächlichen Login an den Userservice zu delegieren.

Technische Umsetzung

Die GSB spezifische Erweiterung des CAS (Java-Package de.bund.gsb.cas) wird als War-Overlay über dem Standard Apereo CAS entwickelt, der als Abhängigkeit im CAS-Modul definiert ist. Alle Informationen zum CAS sind in der offiziellen Dokumentation zu finden.

Eventdispatcher

Der Eventdispatcher ist eine Spring Boot Applikation die mittels Content-API auf den Content im Repository zugreift. Dies geschieht in erster Linie indem eigene Event-Listener definiert werden, welche auf bestimmte Repository-Events reagieren.

Anhand der Konfiguration und der Implementierung aus den Mandantenerweiterungen wird bestimmt, welche Events relevant sind und weiterverarbeitet werden sollen.

Neben dieser Funktionalität dient der Eventdispatcher ebenso zur Synchronisierung des Content-Repositories mit dem Admin-/Serviceportal.

Eine detaillierte fachliche Beschreibung und Hinweise zur Konfiguration des Eventdispatchers finden sich in der Dokumentation zum Eventdispatcher.

Aufbau und Funktionsweise

Die zentralen Klassen zur Konfiguration des Eventdispatchers sind de.bund.gsb.eventdispatcher.EventDispatcher und de.bund.gsb.eventdispatcher.EventDispatcherControl. Hier werden durch Spring Annotationen die wesentlichen Beans initialisiert, die zum Betrieb des Eventdispatchers erforderlich sind.

Außerdem werden hier Funktionen aus dem Spring Boot Framework, wie asynchrone Request und das Scheduling, aktiviert und konfiguriert. Die Standard-Properties zur Konfiguration des Eventdispatcher sind in der src/main/resources/application.properties zu finden. Weitere XML-Konfiguration, z.B. von Mandantenerweiterungen, werden dynamisch eingelesen.

In der folgenden Übersicht sind die übrigen Komponenten sowie deren Funktion kurz zusammengefasst:

Komponente (Paketprefix 'de.bund.gsb.eventdispatcher')	Funktion
cache	Implementierung verschiedener Zugriffskontrollen mittels Spring Security
contentutils	Der Seitencache auf Basis des Ehcache mit den zugrhörigen Funktionen zur Invalidierung und zum Aufwärmen
controller	Basisfunktionaltiät zum Abruf und Zwischenspeichern von Content
healthcheck	Die Implementierungen der einzelnen Contentbeans
listening	Die Spring Web Controller zur Verarbeitung der Requests
performer	Hibernate-Funktionen zum Zugriff auf Datenbankinhalte
propertychecks	Die Klassen (Actions, Validatoren, etc.) für den Formularbaukasten
ratings	Basisimplementierung sowie Standardimplementierungen von Generischen JSPs
rest	Hilfklassen für den Newsletterversand per REST
service	Hilfklassen für die Anbindung ans Serviceportal
spring.boot	Klassen zur Konfiguration von Spring Boot

Indexer

Der Indexer ist eine Standalone Anwendung auf Basis von Spring Boot. Über die Content-API wird durch Suchanfragen oder über den Event-Listener der zu indexierende Content aus dem Repository abgefragt.

Aufbau und Funktionsweise

Als Einstiegspunkt zur Indexer Spring Boot Application dient die Klasse de.bund.gsb.indexer.Indexer. In dieser werden die übrigen Komponenten sowie zusätzliche Resourcen geladen. Die Standard-Properties zur Konfiguration des Indexers sind in der src/main/resources/application.properties zu finden. Weitere XML Konfiguration, z.B. für die Mandanten, werden dynamisch nachgeladen. Eine Aufstellung dieser Komponenten kann der folgenden Tabelle entnommen werden:

Komponente (Paketprefix 'de.bund.gsb.indexer')	Funktion
accesscontrol	Implementierung der Zugriffskontrolle im Indexer
app	Implementierung des Indexer Dispatchers der die eigentliche Event-Verarbeitung durchführt
content	Klassen zur Verarbeitung und Erweiterung des Contents
controller	Spring Controller zur Steuerung des Indexers über den Browser
healthcheck	Implementierung des Healthchecks für den Indexer
listener	Implementierung des Event Listeners des Indexers
mapper	Basisimplementierung des Content Mappers
spring.boot	Klassen zur Konfiguration von Spring Boot
writer	Klassen zum Entfernen oder Ergänzen von Informationen im Solr Index

MailDistributor

Der MailDistributor ist für den GSB-Newsletter-Versand verantwortlich. Er stellt REST-Schnittstellen (s.u.) bereit, über die die Daten einer Mailing-Liste über die Newsletter-Administration des Adminportals eingesehen und verwaltet werden können und über die die An-/Abmeldung von Abonnenten auf der Site erfolgt. Ein Versandvorgang wird mit den notwendigen Daten vom EventDispatcher angestoßen. Der MailDistributor berechnet die Empfänger und versendet die Newsletter-Mails über die konfigurierten SMTP-Server an die Empfänger. Bounce-Mails werden über den LMTP-Server angenommen, den der MailDistributor standardmäßig auf Port 1234 öffnet. Damit die Bounce-Mails vom SMTP-Server an den LMTP-Server weitergeben werden, ist eine entsprechende Konfiguration im STMP-Server notwendig.

Folgende Sub-Module sind im maildistributor-Basis-Modul vorhanden:

Modul	Funktion
bounce-info-extraction	Bibliothek zur Extraktion der Verursacher und des Fehlercodes einer Bounce-Mail
client	Client-Bibliothek zur vereinfachten Kommunikation mit den REST-Schnittstellen des MailDistributors
model	Das externe Datenmodell des MailDistributors zur Verwendung in Kombination mit dem Client

Technische Umsetzung

Der MailDistributor ist eine Spring Boot Anwendung. Die REST-Schnittstelle wird mit Spring Web MVC und einem embedded Tomcat umgesetzt.

Die Definition und die Logik der bereits erwähnten REST-Endpunkte zur Verwaltung befinden sich im Paket de.bund.gsb.maildistributor.rest. Dort werden die Endpunkte in Form von Spring RestControllern definiert. Je nach aufgerufener Funktionalität wird zusätzlich zur auszuführenden Logik noch ein Mapping des Datenmodells vom externen Datenmodell zum internen Datenmodell durchgeführt.

Ein Versandauftrag wird von einzelnen Komponenten schrittweise verarbeitet und während der Verarbeitung in einer Queue gehalten. Die erste Komponente ist dabei der de.bund.gsb.maildistributor.input.TriggerController, der einen neuen Versandauftrag entgegen nimmt, diesen validiert (passen die übergebenen Attribut-Werte zur Mailing-Liste) und den Auftrag in Form eines Triggers in der Queue speichert. Das Trigger-Objekt erhält in der Queue einen Verarbeitungsstatus, anhand dessen die einzelnen Komponenten die vorhandenen Trigger-Objekte aus der Queue laden können. Die weiteren Verarbeitungskomponenten und ihre Funktion sind nachfolgend aufgelistet:

Komponente (Paketprefix 'de.bund.gsb.maildistributor')	Funktion
rest	RestController für die REST-Schnittstelle zur Verwaltung der Daten einer Mailing-Liste
processing.activecomponent.SendingJobCreator	Berechnet die Empfänger, erstellt und speichert die SendingJob- & Transport-Data-Objekte
processing.activecomponent.Archiver	Archiviert das Trigger-Objekt
processing.activecomponent.SendingJobPartitioner	Partitioniert die SendingJob-Objekte für einen performanten Versand
processing.activecomponent.QueueCleaner	Löscht Queue-Objekte
processing.activecomponent.BounceHandler	Behandelt die Bounce-Mails, erhöht den Bounce-Score eine Abonnenten oder deaktiviert diesen, falls notwendig
output.activecomponent.MailSenderAdmin	Verwaltet die MailSender-Komponenten und weist ihnen beim Versand eine SendingJob-Partition zu
output.activecomponent.MailSender	Erstellt die zu versendene Newsletter-Mail und verschickt sie über dem SMTP-Server and die Empfänger der SendingJob-Partition
output.activecomponent.TransportDataRefresher	Aktualisiert die Transport-Daten der Empfänger im Versandvorgang
service.ProcessingChainManager	Steuert den Ablauf der Verarbeitung

Bounce-Mails werden über den LMTP Server entgegengenommen und es erfolgt eine Prüfung, ob die Mailing-Liste existiert und ob keine Schlagworte enthalten sind, die auf automatische Antwort-E-Mails schließen lassen. Ist beides nicht der Fall, wird die Bounce-Mail in ihrer Queue gespeichert und vom BounceHandler verarbeitet.

Repository

Das Repository ist für das Speichern, Verarbeiten und Bereitstellen des Contents zuständig. Hierfür wird ein Content-Repository auf Basis von Apache Jackrabbit Oak verwendet. Dies implementiert die Java Content Repository (JCR) API. Über diese werden die Basis-Operationen zur Verarbeitung des Contents bereitgestellt. Dazu gehören das hierarchische Ablegen und Auslesen von Content, die Zugriffskontrolle und die Versionierung von Content. Außerdem stellt es einfache Ansätze zur Verwaltung von Benutzer, Gruppen und Rechten zur Verfügung, welche für die Anforderungen des GSB erweitert wurden.

Im Jackrabbit Oak wird der Content direkt auf dem Dateisystem in Form von Tar-Dateien abgelegt (Default). Darüber hinaus bietet Oak prinzipiell noch die Möglichkeit der Anbindung alternativer Storage-Interfaces. So können die Repository-Inhalte auch in relationalen Datenbank oder in einer NoSQL-Datenbank (MongoDB) gespeichert werden. Die alternativen Storage-Interfaces werden vom GSB allerdings nicht supported. Die binären Inhalte aus den Blob-Properties können in separaten File- oder Datastores ausgelagert werden. Zum Durchsuchen des Contents wird intern Lucene eingesetzt.

Das Repository ist als Spring Boot Application umgesetzt. Das heißt es ist eine Standalone Anwendung die ihren eigenen Servlet Container (Apache Tomcat) bereitstellt. Über das Spring Web Framework werden eine Reihe von Schnittstellen bereitgestellt.

Neben der eigentlichen Speicherung und Verwaltung redaktioneller Inhalte im Content-Repository beinhaltet die Applikation noch einige zusätzliche Funktionen:

• Publikation (Übertragung der zu publizierenden Inhalte in das Master-Repository in der Live-Umgebung)
• Replikation (Synchronisation der Inhalte vom Master-Repository in die Replication-Repository der Live-Umgebung)
• Transaktionen (Durchführung der Übertragung von Inhalten zwischen den verschiedenen Repositories)
• Papierkorb (Bereitstellung der Papierkorb-Funktionalität)
• Workflows (Untestützungsfunktionen für redaktionelle Freigabeprozesse)

Publikation

Die Publikationsfunktionalität ermöglich es einen definierten Contentstand auf das Master-Repository übertragen. Das Master-Repository enthält alle publizierten Inhalte und stellt diese in der Live-Umgebung den angebundenen Site-Applikationen für die Erzeugung der Webseiten zur Verfügung.

Dazu wird der Content in ein von Jackrabbit bereitgestelltes XML-Format überführt und an die Transaktionsschnittstellen (s.u.) übertragen.

Replikation

Die Replikation dient der Übertragung des Contents aus einem Master-Repositorys auf einen oder mehrere Replication-Repositories. Das Master-Repository ist das zentrale Repository in welches der zu publizierende Inhalt initial vom Content-Repository publiziert wird. Replication-Repositories können für den Aufbau einer ausfallsicheren und skalierbaren Infrastruktur genutzt werden. Die Replication-Repositories sind als "Spiegel" des Master-Repositories zu verstehen, enthalten also dieselben publizierten Inhalte. Die Replikation kümmert sich darum die Replication-Repositories bei Publikationen zu aktualisieren. Die Aktualisierung wird über die Transaktionsschnittstelle durchgeführt.

Transaktion

Bei einer Publikation werden neben den zu publizierenden redaktionellen Inhalten und ggf. enthaltenen Binärfiles (bspw. Bilder, PDF-Dokumente) auch die entsprechenden Content-Events (Publikation, Aktualisierung der einzelnen Dokumente) mit übertragen. Die Transaktionsschnittstellen werden verwendet, um das durch die Publikation oder die Replikation bereitgestellte XML einzuspielen. Die darin enthalten Events werden zum Nachspielen der Änderungen am Content verwendet.

Papierkorb

Der Papierkorb ist eine Erweiterung des Content Repositorys in einem Preview Repository. Hierüber kann gewährleistet werden, dass gelöschte Dokument und Ordner nicht endgültig entfernt werden sondern später noch wiederhergestellt werden können.

Workflows

Das Repository stellt eine Reihe von Funktionen für die Workflows bereit. Unter anderen werden die Changesets für die Publikationsworkflow hier verwaltet. Die eigentliche Workflow-Funktionalität erfolgt in der Camunda basierten Workflow-Komponente.

Aufbau und Funktionsweise

Im Aufbau des Repository lassen sich zwei Bestandteile des Repositorys unterscheiden. Zum einen sind unter dem Package org.apache.jackrabbit.oak.security die Erweiterungen des Jackrabbit Oak Repository zu finden. Dies sind insbesondere Erweiterungen an der Zugriffskontrolle sowie an der Verwaltung von Benutzern und Gruppen. In der folgenden Auflistung sind die einzelnen Komponenten sowie deren Funktion zu diesem Package zu finden:

Komponente (Paketprefix 'org.apache.jackrabbit.oak.security')	Funktion
authentication	Implementierung alternativen Login-Mechanismen
authorization	Erweiterungen an der Zugriffskontrolle wie zusätzliche Einschränkungen anhand des Dokumenttyps
internal	Basisklasse zum Einbinden der Erweiterten Sicherheitsfunktionen für den GSB
principal	Konfiguration zur Bestimmung von Principals auf Basis der erweiterten Benutzer- und Gruppenfunktionen
user	Implementierung alternativer Benutzer- und Gruppenverwaltungen für den GSB

Die übrigen Komponenten des Repository sind in den Packages de.bund.gsb.replication und de.bund.gsb.repository zu finden. Im Package de.bund.gsb.replication ist die Funktionalität zur Replikation implementiert. In dem anderen Package sind die weiteren Funktionen des GSB Repository implementiert. Details hierzu kann der folgenden Tabelle entnommen werden:

Komponente (Paketprefix 'de.bund.gsb.repository')	Funktion
content	Implementierung des XML Import und Export von Content
healthcheck	Implementierung von Healthchecks
oak	Klassen zur Konfiguration des Jackrabbit Oak Repository
publication	Implementierung der Publikationsfunktionalität im GSB
rest	Implementierung der REST-Schnittstellen
security	Funktionen zum Import/Export der im Repository gespeicherten Berechtigungen
session	Erweiterungen zur Sessionverwaltung
site	Klassen zur Bereitstellung der Contentbeans für Site
transaction	Implementierung der Transaktionssteuerung für die Publikation und Replikation
trash	Implementierung der Papierkorb Funktion
util	Sammlung von Hilfsklassen
version	Erweiterungen zur Arbeit mit Versionen im Repository, u.a. die Implementierung des VersionCleaners
workflow	Implementierung verschiedener Funktion für den Workflow Server

Die Konfiguration der Repository Spring Boot Applikation erfolgt in den Klassen

• de.bund.gsb.repository.RepositoryApplication,
• de.bund.gsb.repository.RepositoryConfiguration und
• de.bund.gsb.repository.RepositoryProperties.

Hier werden die zum Betrieb des Repository benötigten Spring Beans initialisiert.

In der Klasse de.bund.gsb.repository.RepositoryFactory wird das Jackrabbit Oak Repository konfiguriert. Die Klasse de.bund.gsb.repository.RepositoryStartup spielt für den Betrieb benötigte Daten ins Repository ein und startet wesentliche Kompenten, wie den internen Event-Listener.

Die Klassen de.bund.gsb.repository.RepositoryUserManager und de.bund.gsb.repository.RepositoryUserService stellen die Schnittstelle zur Userservice Applikation bereit.

Die zentralen GSB spezifischen Funktionen des Repository werden über REST-Schnittstellen bereit gestellt. Die REST-Controlen finden sich in dem Java Package de.bund.gsb.repository.rest.service und Service-Klassen im Package de.bund.gsb.repository.rest.service.

Weitere relevanten Packages sind:

• Access Management (Java Package: de.bund.gsb.repository.security)
• Contentbeans Bereitstellung (Java Package: de.bund.gsb.repository.site)
• Content Import/Export (Java Package: de.bund.gsb.repository.content)
• Ordner- und Dokumentverarbeitung (Java Package: de.bund.gsb.repository.rest.service.content)
• Transaktionen (Java Package: de.bund.gsb.repository.transaction)
• Publikationen (Java Package: de.bund.gsb.repository.publication)
• Workflows (Java Package: de.bund.gsb.repository.workflow)

Access Management

Mittels der Access Management Schnittstellen können die Berechtigungen zum Zugriff auf den Content von Benutzers und Gruppen erweitert oder reduziert werden. Außerdem können die bestehenden Berechtigungen für einzelne Benutzer, Gruppen und Teile des Contents abgefragt werden.

Contentbeans Bereitstellung

Zur Darstellung des GSB Contents in der Site wird dieser vom Repository als GSB Contentbeans in Form von Plain Old Java Objects (POJOs) bereitgestellt. Diese sind für die Site dadurch nicht änderbar und bilden die Java Repräsentation der eigentlichen Dokumente im GSB Content-Repository. Hierbei wird immer die aktuelle Version eines Dokuments ausgeliefert. Diese Schnittstelle wird sowohl von den Preview als auch den Live Sites verwendet und unterscheidet sich in ihrer Funktionalität hierbei nicht.

Content Import/Export

Über die Export Schnittstellen können Ausschnitte oder der gesamte Content in Form von XML Dateien bereitgestellt werden. Hierbei wird zwischen dem pfadbasierten Content-Export und dem Contentpatch-Export unterschieden. Bei ersteren werden alle Dokumente unterhalb eines festgelegten Pfads, optionalerweise rekursiv, exportiert. Bei letzteren werden üblicherweise die verlinkten Dokumente in einem ConfigLinkList-Dokument exportiert. Die beim Export erstellten XML-Dateien sowie die zugehörigen binären Anhänge werden in der Ordnerstruktur aus dem Content abgelegt und als Zip-Archiv zusammengefügt. Die Importschnittstelle kann den zuvor exportierten Content in ein Content Repository einspielen.

Ordner- und Dokumentverarbeitung

Die Schnittstellen zur Ordner- und Dokumentverarbeitung liefern den Content für den Indexer, Eventdispatcher, Editor und sonstige Anwendungen. Über diese Schnittstellen lassen sich zusätzlich neue Ordner und Dokumente erzeugen sowie bestehende ändern oder löschen.

Transaktionen

Die Schnittstellen für die Transaktionen stellen die Funktionen bereit um die durch eine Publikation oder Replikation erzeugten Daten einzuspielen.

Publikation

Die Publikationsschnittstellen erlauben die Freigabe und Publikation von Content. Dieser wird über die Transaktionsschnittstelle an ein Live-System übertragen.

Workflows

Die Workflow-Schnittstellen liefern die Funktionen für die Standard-Workflows. Dazu zählen die Verarbeitung für die Changesets für die Publikationsworkflows. Außerdem zusätzliche Funktionen für die Publikation und den Mailversand.

Serviceportal

Das Serviceportal bildet das Service-Backend für verschiedene GSB-Features:

• Nachrichten (Announcements)
• Datentabellen und Umfragen
• Gästebücher
• Bewertungen

Bei den Daten und Inhalten der oben skizzierten Features handelt es sich in der Regel um nutzergenerierte Inhalte (bspw. Gästebucheinträge), die zentral in einer Datenbank gespeichert werden. Das Serviceportal bietet Zugriffspunkte für die Speicherung und Verwaltung dieser Daten und stellt diese über eine REST-Schnittstelle den anderen GSB Komponenten zur Verfügung.

Technische Umsetzung

Das Serviceportal ist eine Spring Boot Anwendung.

Die REST-Schnittstelle wird mit Spring Web MVC und einem embedded Tomcat umgesetzt. Die Definition der REST-Endpunkte erfolgt im Java-Package de.bund.gsb.serviceportal.rest.controller als Spring RestController. Die Signatur und das Mapping des Requests der REST-Endpunkte wird im zugehörigen REST-Model im Package de.bund.gsb.restmodel in den Request-Objekten definiert.

Für die Speicherung der Daten (User Generated Content) werden Spring Data JPA und Hibernate eingsetzt. Durch die Nutzung von Spring Data JPA und Hibernate ergibt sich keine direkte Abhängigkeit zu den zugrundeliegenden und genutzten Datenbanken, so dass alle von GSB supporteten Datenbanken für die Persistierung der Daten des Userservice genutzt werden können. Die Umsetzung der Authentisierungfunktionen basiert auf Spring Security.

Site

Die Site ist für die Darstellung des Contents verantwortlich. Sie wird als Spring Boot Applikation bereitgestellt. Daher kann sie sowohl als eigenständige Java Applikation mit einem eigenen Servlet Container betrieben werden, also auch in einem bestehenden Tomcat.

Aufbau und Funktionsweise

Zur Darstellung des Contents stellt die Site Funktionen zum Abruf des Contents aus dem Repository bereit. Dieser wird als Plain Old Java Objects (POJOs) übertragen und in internen Caches vorgehalten. Über die Contentbeans werden die Inhalte der POJOs mit zusätzlichen Funktionen angereichert.

In der Site ist der Formularbaukasten umgesetzt. Mit diesem lassen sich über den Content Formulare zusammenstellen. Dazu sind in der Site Actions und Validatoren implementiert. Diese können durch die Mandanten erweitert werden.

Weiterhin ist in der Site die Funktionalität für Generische JSPs umgesetzt. Diese ermöglicht es über eigene JSPs und Java-Klassen komplexe Funktionen umzusetzen.

Darüber hinaus enthält die Site Funktionen, um auf Datenbanken und -inhalte zuzugreifen. Die Site speichert nur einige wenige technische Informationen/Token in der Site-Datenbank. Hierzu zählt z.B. der CSRF-Zugriffsschutz in Formularen verwendet, da die CSRF-Token in allen Site-Instanzen zur Verfügung stehen müssen, um eine zentrale Auswertung zu ermöglichen. Zusätzlich können Mandanten auch eigene mandantenspezifische Inhalte in einer Datenbank ablegen und verwalten.

Über Velocity werden in der Site dynamische Inhalte umgesetzt werden, die im Content des Mandanten gepflegt und erst zur Laufzeit interpretiert werden. Die Velocity-Templates liegen wie skizziert im Content der GSB Mandanten, das Produkt enthält die Logik für den Zugriff, das Parsing und Ausführung der Velocity-Templates. Weiterhin stellt das Produkt Hilfsfunktionen für die Nutzung in den Velocity-Templates zur Verfügung, um bspw. Richtextinhalte lesen und formatiert ausgeben zu können.

Einen großen Teil der Funktionalität zur Darstellung des Contents wird über die JSP Templates umgesetzt.

Hier eine Übersicht über die Inhalte der einzelnen Package:

Komponente (Paketprefix 'de.bund.gsb')	Funktion
security	Implementierung verschiedener Zugriffskontrollen mittels Spring Security
site.cache	Der Seitencache auf Basis des Ehcache mit den zugehörigen Funktionen zur Invalidierung und zum Aufwärmen
site.content	Basisfunktionaltiät zum Abruf und Zwischenspeichern von Content
site.contentbeans	Die Implementierungen der einzelnen Contentbeans
site.controllers	Die Spring Web Controller zur Verarbeitung der Requests
site.database	Hibernate-Funktionen zum Zugriff auf Datenbankinhalte
site.forms	Die Klassen (Actions, Validatoren, etc.) für den Formularbaukasten
site.genericjsp	Basisimplementierung sowie Standardimplementierungen von Generischen JSPs
site.genericresultset	Hilfsklassen um mit dynamischen Ergebnislisten (z.B. Hibernate oder Solr) zu arbeiten
site.helperbeans	Hilfklassen für Sonderfunktionen in Contentbeans
site.indexer	Erweiterungen um z.B. Datenbankinhalte in den Solr Index zu schreiben
site.itext	Erweiterungen um mittels iText-Libary PDF Dokumente zu erzeugen
site.jcaptcha	JCaptcha Implementierung für den GSB
site.linkschemes	Klassen um die Linkerzeugung im GSB zu steuern
site.maildistributor	Hilfsklassen für die Arbeit mit dem Maildistributor
site.pbe	Implementierungen zum Preview Based Editing (PBE)
site.pluginbeans	Implementierung der Plugin Bean Funktionalität
site.rest	Rest-Klassen zur Arbeit mit Datentabellen, Gästebüchern und Bewertungen
site.search	Implementierung von Suchfunktionen mittels Solr
site.security	Erweiterungen zur Umsetzung von Zugriffskontrollen, z.B. über die CAS-Anbindnung
site.servlet	Erweiterungen zum Spring Dispatcher Servlet
site.spring	Klassen zur Spring-Konfiguration
site.taglib	Implementierung der Tag-Lib Funktionen
site.text	Klassen zur (Rich-)Text Verarbeitung mittels Richtextenhancer
site.tokenGeneration	Implementierung der Funktion zur Erzeugung von Tokens
site.util	Verschiede Hilfsklassen für Standard GSB Funktionen, welche per Spring Konfiguriert werden
site.velocity	Hilfsklassen zur Verarbeitung von Velocity
site.view	Erweiterungen zum View-Resolver von Spring

Userservice

Der Userservice bildet das Service-Backend für die Benutzer und Rollen im GSB.

Über die REST-Schnittstelle des Userservice können Benutzer und Rollen verwaltet werden. Außerdem ist der Userservice für die Prüfung eines Login-Versuches zuständig.

Die Schnittstellen des Userservice werden hauptsächlich vom Adminportal (für die Benutzer- und Gruppen-Verwaltung) und vom CAS (für den Login) genutzt.

Technische Umsetzung

Das Userservice ist eine Spring Boot Anwendung.

Die REST-Schnittstelle wird mit Spring Web MVC und einem embedded Tomcat umgesetzt. Die Definition der REST-Endpunkte erfolgt im Java-Package de.bund.gsb.userservice.impl.rest als Spring RestController. Die Signatur und das Mapping des Requests der REST-Endpunkte erfolgt direkt in den jeweiligen Methoden des REST-Endpunktes.

Für die Speicherung der Daten werden Spring Data JPA und Hibernate eingsetzt. Durch die Nutzung von Spring Data JPA und Hibernate ergibt sich keine direkte Abhängigkeit zu den zugrundeliegenden und genutzten Datenbanken, so dass alle vom GSB supporteten Datenbanken für die Persistierung der Daten des Userservice genutzt werden können. Die Umsetzung der Authentisierungfunktionen basiert auf Spring Security.

userservice-client

Das userservice-client Git-Modul erleichtert die Einbindung des Userservice in Spring Security basierte Anwendungen. Es enthält Spring-Konfigurationen, welche einer Anwendung den Login über den Userservice (bzw. CAS und Userservice) ermöglichen.

Installation / Deployment eines Release

Nachdem ein Release erstellt worden ist, kann dieses mit den vorhandenen Skripten zur Erstellung eines Platform-Bundle und dem Installationsskript auf beliebigen Umgebungen bspw. Test- oder Integrationsumgebungen installiert werden.

Das Ziel ist es das erstellte Release so früh wie möglich mit den Tools und Mechanismen des GSB 10 auf Installationsfähigkeit zu prüfen, so dass hierfür dieselben Tools genutzt werden sollen, die auch in produktiven Infrastrukturen genutzt werden.

Skillprofil

An dieser Stelle werden die zentralen Skills für die Entwicklung des GSB 10 tabellarisch zusammen mit einer kurzen Erläuterung aufgelistet.

• Asciidoc, PlantUML: Die interne Dokumentation basiert auf Asciidoc, für die Erstellung von Diagrammen wird PlantUML genutzt. Die Aktualisierung der Dokumentation erfordert gute Kenntnisse in der Erstellung und Definition entsprechender Dokumentation und Diagramme.
• CAS: Der GSB 10 stellt ein Single Sign On auf Basis von CAS zur Verfügung. Die Entwicklung erfordert gute Kenntnisse des Produktes sowie des Templating zur Anpassung der CAS-Oberflächen.
• Checkstyle, Findbugs: Die statische Analyse stützt sich auf die beiden Tools Checkstyle und Findbugs. Für die Entwicklung werden gute Kenntnisse in der Konfiguration der zugrundeliegenden Regelsätze sowie der Interpretation der erstellten Reports benötigt.
• CI/CD-Pipeline: Für eine Automatisierung des Builds des GSB 10 Release bietet sich die Nutzung einer Continuous Integration-Lösung an. Die Nutzung entsprechender Lösungen ist optional.
• Datenbanken (Hibernate, SQL): Applikationen wie der Userservice oder die Site setzen Datenbanken ein. Zur Einrichtung, Konfiguration und Migration sind gute Kenntnisse in Hibernate und SQL erforderlich.
• Google Web Toolkit: Der GSB Editor Client wird auf Basis von GWT entwickelt. Für die Entwicklung sind sehr gute GWT Kenntnisse und der zugrundeliegenden Architekturen und Konzepte erforderlich.
• Gradle: Als Buildtechnologie wird im GSB 10 Gradle eingesetzt. Die Entwicklung des GSB erfordert gute Kenntnisse über Gradle, Gradle-Konventionen, -Lifecycle sowie der Standard Plugins und deren Konfigurationsmöglichkeiten. GSB spezifische Tasks sind in entsprechenden Gradle Plugins gekapselt, deren Weiterentwicklung sehr gute Kenntnisse der Pluginentwicklung und entsprechende Groovy-Kenntnisse erfordert.
• Httpd Webserver: Die zentrale Komponente für die eigentliche Auslieferung der generierten Inhalte ist der Httpd-Webserver. Die Entwicklung der GSB 10 Httpd-Konfiguration erfordert sehr gute Kenntnisse des Httpd und der genutzten Httpd-Module.
• Jackrabbit / Jackrabbit Oak: Das Content Repository des Jackrabbit Oak ist die Kernkomponente des GSB Repositorys. Daher sind für die Erweiterung, Migration und Wartung dieser Komponente sehr tiefgehende Kenntnisse von Jackrabbit Oak erforderlich.
• JCR: Die Java Content Repository API wird für alle Zugriffe auf das Content Repository verwendet. Die Entwicklung von Schnittstellen zum Repository erfordert sehr tiefgehende Kenntnisse der API sowie der implementierungsabhängigen Besonderheiten.
• Java: Alle Komponenten des GSB 10 sind als Java Applikationen umgesetzt, so dass für die Entwicklung des GSB 10 umfassende Kenntnisse sowohl des Java JDKs, Design-Pattern als auch der eingesetzten Bibliotheken erforderlich sind
• Javascript: Der GSB Editor Client läuft als Javascript Anwendung im Browser. Die Entwicklung erfordert sehr gute Javascript Kenntnisse insbesondere bei der Analyse des Laufzeitverhaltens oder Fehlern des Editors. Gute Kenntnisse der entsprechenden Browsertools werden ebenfalls benötigt.
• Java Server Faces, Primefaces: Die Portlets des Adminportals sind auf Basis von JSF/Primefaces umgesetzt. Die Entwicklung von Adminportal Portlets erfordert gute Kenntnisse in den beiden Technologien.
• Java Server Pages: Die Seitengenerierung wird mit JSP-Templates umgesetzt, d.h. die Entwicklung erfordert sehr gute Kenntnisse im Umfeld JSP, Taglibs und der JSP Standard Tag Library.
• Liferay: Das Admiportal basiert auf dem Portalserver Liferay. Für die Entwicklung und Integration der Portlet in den Portalserver und die Einbindung der Portlets in die Seiten werden gut Kenntnisse des Portalservers benötigt.
• OWASP Dependency Check: Der Dependency Check wird genutzt, um bekannte Sicherheitslücken in den genutzten Java-Bibliotheken zu ermitteln. Die Nutzung und Interpretation der erzeugten Berichte ist für eine effektive Beurteilung der Reports erforderlich.
• Solr: Apache Solr wird als Such-Server in der Site verwendet. Für die Erstellung von Suchanfragen und Erweiterung der Indexierung werden gute Kenntnisse der Query-Syntax und der Java API (SolrJ) vorrausgesetzt.
• Spring / Spring Boot: Die GSB Komponenten basieren auf Spring und Spring Boot, so dass ein sehr gutes Verständnis der zugrundeliegenden Konzepte, Konventionen und insbesondere der Konfigurationen erforderlich sind.
• TinyMCE, ACE-Editor: Die Bearbeitung von Richtext im GSB Editor erfolgt mit dem Javascript basierten Editor TinyMCE. Die Entwicklung erfordert seht gute Kenntnisse der entsprechenden Konfigurationsmöglichkeiten sowie Plugins. Der ACE-Editor wird für die Pflege von eher technischen Dokumenten genutzt, so dass auch hier entsprechende Kenntnisse benötigt werden. Darüber hinaus werden sehr gute Kenntnisse der Einbindung und Integration der beiden Editoren in eine GWT Applikation benötigt.
• Tomcat Servlet Container: Die Site- und das Adminportal des GSB laufen als Webapplikation in einem Tomcat-Server. Die Site ist die zentrale Komponente für die Seitengenerierung, so dass für die Entwicklung sehr gute Kenntnisse der Tomcat-Konfiguration erforderlich sind.
• Velocity: Ausgabetemplates werden mit Hilfe von Velocity-Skripten im redaktionellen Content eines Mandanten definiert. Die Unterstützung von Velocity durch die Seitengenerierung erfordert gute Kenntnisse der Nutzung und Einbindung von Velocity in Java-Programmen
• XML/XSD/XSL: XML wird für den Export von Content verwendet und stellt die Basis für das Markup der Site dar. Daher erfordert die Arbeit mit diesen gute Kenntnisse über dieses Format, die Schema-Beschreibung und die Möglichkeiten der Transformation.

Benötigte Umgebungen

Entwicklungsumgebung (Arbeitsplatz Entwickler)

Der Arbeitsplatz des Entwicklers sollte weitestgehend der produktiven Infrastruktur entsprechen, d.h. es sollte ein Linux basierte Umgebung sein, um möglichst einfach ein lokales Deployment von GSB Komponenten durchführen zu können.

An dieser Stelle bietet sich die Verwendung von CentOS an, welches neben Redhat ein vom GSB 10 supportetes Betriebssystem ist.

Folgende Eckdaten sind eine gute Ausgangsbasis für eine lokale Entwicklungsumgebung:

• 4 CPU-Cores
• >= 16 GB RAM
• >= 100 GB Storage

Für die Entwicklung werden folgende SW-Komponenten benötigt

• Gradle Build Tool Lizenz
• Integrierte Entwicklungsumgebung: Es empfiehlt sich der Einsatz von IntelliJ IDEA, andere Entwicklungsumgebungen wie Eclipse können aber ebenfalls eingesetzt werden.
• Softwarevoraussetzungen: Darüber hinaus sind auf den lokalen Arbeitsplätzen die Beistellungen des GSB 10 (s.a. Installationsanleitung) zu installieren.
• Poseidon for UML in der Version 4.2 zur Bearbeitung des GSB Dokumentmodells (UML). Das UML-Modell des GSB Dokumentmodells ist aus dem GSB 7 übernommen worden. Die initiale Erstellung und Bearbeitung ist mit dem skizzierten kommerziellen UML-Editor durchgeführt worden. Inwiefern andere UML-Editoren für eine Bearbeitung des UML-Modells und anschließende Generierung der HTML-Dokumentation des Dokumentmodells ist nicht bekannt und müsste bei Bedarf geprüft werden.

Hinweis:
Da der Build des GSB auf Basis von Gradle und mit Hilfe von Gradle-Plugins durchgeführt wird, werden alle für den Build benötigten Komponenten automatisch (ggf. aus dem Internet) geladen. Eine explizite Installation von (Build-)Tools neben den oben skizzierten SW-Komponenten ist daher nicht erforderlich.

Zentrale Server

Neben den lokalen Arbeitsplätzen der Entwickler bietet sich der Einsatz eines zentralen Servers an. Auf diesem Server können die für eine Entwicklung übergreifend benötigten Komponenten wie Repository, Editor, Workflowserver, Adminportal installiert werden. Je nach Anforderung an die zentralen GSB Komponenten kann Art und Umfang der auf dem zentralen Server installierten Komponenten variieren. Wenn bspw. kein CAS basiertes SSO genutzt werden soll, dann muss auf dem zentralen Server auch kein GSB Servicetyp CAS installiert und betrieben werden.

An dieser Stelle bietet sich die Verwendung von CentOS an, welches neben Redhat ein vom GSB 10 supportetes Betriebssystem ist.

Folgende Eckdaten sind eine gute Ausgangsbasis für eine zentralen GSB 10 Server:

• 4 CPU-Cores
• >= 32 GB RAM
• >= 256 GB Storage

Für den zentralen Server werden folgende SW-Komponenten benötigt:

• Softwarevoraussetzungen: Darüber hinaus sind auf den lokalen Arbeitsplätzen die Beistellungen des GSB 10 (s.a. Installationsanleitung) zu installieren.
• GSB 10 Installation: Die Installation des GSB 10 auf dem Server erfolgt mit den im GSB 10 enthaltenen Tools zur Erstellung eines Platform Bundle und der anschließenden Installation.

Build Umgebung

Die Erstellung eines Release kann wie oben vorgestellt manuell mit Hilfe von Gradle und der GSB spezifischen Gradle-Tasks durchgeführt werden.

Für eine Automatisierung des Builds und der Releaseerstellung bietet sich der Einsatz eine CI/CD Lösung an. Hier können die präferierten Tools wie

• Jenkins
• Bamboo
• Travis
• Gitlab
• etc.

eingesetzt werden.

Es handelt sich hier um eine optionale Komponente für die an dieser Stelle keine pauschalen Empfehlungen ausgesprochen werden können, da die verschiedenen Tools unterschiedliche Anforderungen an Hard/Software stellen.

Die GSB Sourcen stellen ein exemplarisches Jenkinsfile zur Verfügung welches als Grundlage und Ausgangspunkt für eine individuelle Definition einer Jenkins basierten CI/CD-Pipeline genutzt werden kann.

Testumgebung

Die Testumgebung kann als Spiegel des zentralen Servers für die Entwicklung (ausschließlich Redaktionsumgebung) angesehen werden, d.h. die Testumgebung kann damit von ihrer Dimensionierung her entsprechend dem zentralen Server aufgesetzt werden. Der Server für die Testumgebung kann somit entsprechen zum zentralen Server aufgesetzt werden.

Sollen auf der Testumgebung auch Contentreplikationen vom Master- auf einen bzw. mehrere Replication-Server geprüft werden und sollen Netzwertrennungen bspw. zwischen Redaktion- und Live-Umgebung simuliert werden, dann bietet sich der Einsatz von mehreren Servern an.

Eine gute Wahl wäre an dieser Stelle:

• Redaktionssystem: Dimensionierung wie zentraler Server
• Master-Live-Server: Dimensionierung wie zentraler Server
• Replication-Live-Server: Dimensionierung wie zentraler Server