Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

IT-Security

Produktentwicklung

Software-Modernisierung

Weitere Leistungen...

Leistungen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Events

Fachmedien

Softwerker

Webinare

Wissens-Hub

Deine Entwicklung

Jobs

Kultur & Karriere Podcast

Unsere Kultur

Karriere

Über uns

Aktuelles

Kontakt

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

IT Consultant & Developer

ComputerWeekly

Backups entscheidend für Datensicherheit und Geschäftsbetrieb

Stephan Köninger zeigt, warum Backups und Disaster-Recovery-Pläne unverzichtbar für Datensicherheit und Geschäftskontinuität sind.

Backups entscheidend für Datensicherheit & Geschäftsbetrieb

<p>Möchte man Sprachen wie bspw. YAML, SQL oder XML in JavaScript interpretieren, existiert eine Vielzahl an Bibliotheken, die hierfür herangezogen werden können. Doch was, wenn dies für eine Sprache noch nicht der Fall ist? Wie wird eine Sprache definiert und wie kann man diese von einer Maschine ausführen lassen?</p><p>Im Rahmen dieses zweiteiligen Blog-Beitrages werden diese Fragen anhand der Object Constraint Language (OCL) beispielhaft geklärt. Da die OCL ein sehr breites Funktionsspektrum aufweist, wird nur ein kleiner Teil aufgegriffen. Anhand dieses Ausschnittes werden die grundlegenden Werkzeuge und Begriffe zur Definition einer Sprache vorgestellt und erklärt. Im zweiten Teil des Blog-Beitrages wird dann eine konkrete Implementierung eines Parsers mit Hilfe des Parser-Generators Jison beschrieben.</p><h2>Die Object Constraint Language (OCL)</h2><p>Die OCL ist eine Sprache, die maßgeblich im Rahmen der UML Anwendung findet. Sie erlaubt es, textuell definierte Regeln (Constraints) festzulegen, welche die Semantik eines UML-Modells präzisiert. So ist es bspw. mit Hilfe eines UML-Klassendiagramms recht einfach möglich, eine Eltern-Kind-Beziehung zu definieren: eine Klasse <code>Person</code> hat eine zyklische Assoziation auf sich selbst mit dem Namen <code>childOf</code>. Soll nun der Umstand berücksichtigt werden, dass eine Person nicht sein/ihr eigenes Elternteil sein kann, ist es nahezu unmöglich dies nur über Konzepte der UML allein darzustellen. Mit Hilfe der OCL hingegen ist dies ein Kinderspiel und kann über folgende Invariante erreicht werden:</p>

```
context Person inv:
    self.children->forAll(c | c <> self)

```

<p>Diese Invariante zeigt an, dass für jedes Element (<code>forAll</code>) der Liste <code>children</code> gelten muss, dass dies nicht auf das Objekt zeigen darf, welches die Liste selbst hält, da sonst eine zyklische Referenz entsteht.</p><h2>Festlegen der Sprachfeatures</h2><p>Die OCL erlaubt es also Abfragen auf Objekten auszuführen. Hierzu ist es notwendig, dass über die Felder eines Objekts navigiert werden kann, was durch eine Punktnotation realisiert wird. Es kann also via <code>a.b</code> auf den Wert des Feldes <code>b</code> des Objekts <code>a</code> (in beliebiger Tiefe) zugegriffen werden. Stellt <code>a</code> eine Liste von Objekten dar, wird durch den Aufruf von <code>a.b</code> eine neue Liste mit allen Werten des Feldes <code>b</code> (sofern vorhanden) der Objekte der Liste aus a zurückgegeben. Auch existieren Funktionen, die auf dem Ergebnis einer Abfrage ausgeführt werden können. Hierfür wird der Pfeil-Operator <code>-></code> eingesetzt, gefolgt vom Namen der Funktion (bspw. <code>forAll</code>, <code>min</code>, <code>max</code>, <code>select</code>, u.v.m).</p><p>Folgendes Objekt dient als Beispiel zur Veranschaulichung der oben beschriebenen Abfrageregeln:</p>

```
{
  field: “value”,
  listField: [
    { value: “a” },
    { value: “b” },
    { value: “c” }
  ],
  objectField: {
    value: “d”
  }
}

```

<p>Werden die nun folgenden Abfragen (linke Spalte) auf dem obigen Objekt ausgeführt, ergeben sich die in der rechten Spalte angegebenen Ergebnisse:</p><table><thead><tr><th>Abfrage</th><th>Ergebnis</th></tr></thead><tbody><tr><td>

```
self.field

self.listField





self.objectField.value

self.listField.value

```

</td><td>

```
"value"

[
  { value: "a" },
  { value: "b" },
  { value: "c" }
]

"d"

["a","b","c"]

```

</td></tr></tbody></table><h2>Formale Definition der Sprache</h2><p>Kern dieses Blogartikels ist es, die oben skizzierten Features zur Abfrage von Objekten als Sprache zu implementieren. Hierfür ist eine formale Definition der Sprache unerlässlich. Die Definition untergliedert sich in die Bereiche Lexer und Parser, welche folgend näher beschrieben werden.</p><h3>Lexer</h3><p>Aufgabe eines Lexers (auch Tokenizer) ist es, den textuell vorliegenden Programmcode in einzelne Teile (sog. Token) zu zerlegen. Hierfür müssen dem Lexer Regeln mitgegeben werden, welche die jeweiligen Token definieren und als solche für den Lexer greifbar gemacht werden. Für die beiden Operatoren <code>.</code> und <code>-></code> ist dies simpel, da diese statische Konstrukte darstellen und analog unter den Token “.” bzw. “->” abgelegt werden. Auch die runden Klammern des Operationsaufrufs sind feste Konstrukte, die als solche jeweils ein Token darstellen.</p><p>Interessanter sind die Zugriffe auf Feld- oder Operationsnamen, da diese variabel sind. Die Namen unterliegen jedoch einem festen Muster und können daher mit Hilfe eines Regulären Ausdrucks erkannt und behandelt werden: <code>[a-zA-Z_][a-zA-Z0-9_]*</code>. Stößt der Lexer auf eine Zeichenkette die diesem Regulären Ausdruck entspricht, wird sie als Token “VARIABLE_NAME” erfasst.<br /> Zudem wird der Lexer so konfiguriert, dass mehrfach auftretende Leer- oder ähnliche Zeichen (Tab, Zeilenumbruch) ignoriert werden. Ein besonderes Token ist das EOF-Token (End-of-File). Dieses wird später dazu verwendet, dem Parser anzuzeigen, dass mit keinem weiteren Ausdruck zu rechnen ist. Für die in diesem Blog-Beitrag vorgestellte Abfragesprache sehen die Lexer-Regeln daher wie folgt aus:</p>

```

\s+                             { /* skip blanks, new line, etc. */ }
'.'                             { return '.'; }
'->'                            { return '->'; }
'('                             { return '('; }
')'                             { return ')'; }
[a-zA-Z_][a-zA-Z0-9_]*          { return 'VARIABLE_NAME'; }
<<EOF>>                         { return 'EOF'; }

```

<h3>Parser</h3><p>Konnte der Lexer eine Abfrage in Token zerteilen, wird das Ergebnis an den Parser übergeben, der anhand einer gegebenen Grammatik die Token transformiert. Eine Grammatik lässt sich mathematisch definieren als G = (N,T,P,S), wobei N die Menge nichtterminaler Symbole (hier: e), T die Menge terminaler Symbole (die Token aus den Lexer-Regeln), P die Regeln der Grammatik und S das Startsymbol definiert (hier: e).</p><p>Gemäß dieser Vorgabe ergibt sich für die OCL folgende Grammatik:</p>

```

N = {e}
T = {'.', '->', '(', ')', 'VARIABLE_NAME', 'EOF'}
P = e -> e 'EOF',
    e -> 'VARIABLE_NAME',
    e -> e '.' 'VARIABLE_NAME',
    e -> 'VARIABLE_NAME' '(' ')'
S = e

```

<p>An dieser Stelle sind sowohl die Lexerregeln als auch die Grammatik definiert, sodass die Sprachdefinition vollständig ist. Der letzte, fehlende Schritt die Sprache ausführbar zu gestalten, ist das Erstellen eines Parsers. Natürlich kann ein Parser grundsätzlich manuell implementiert werden, jedoch zeigt die Erfahrung, dass mit wachsender Komplexität der Sprache auch die Komplexität des Parsers steigt und es sich daher anbietet, einen Parsergenerator zu verwenden. Hierfür wird im zweiten Teil des Blog-Beitrages die konkrete Umsetzung eines Parsers in JavaScript mit Hilfe der Bibliothek <code>Jison</code> vorgenommen.</p>

Implementieren einer Sprache in JavaScript – Teil 1: Grundlagen

<p>Camunda bietet mit seiner <a href="https://docs.camunda.org/manual/latest/" target="_blank">Business Process Management Suite</a>  eine leichtgewichtige Open-Source-Plattform zur Modellierung und Automatisierung von Geschäftsprozessen. Hierfür bieten die Macher nicht nur ein rudimentäres, leicht und intuitiv zu bedienendes Modellierungswerkzeug an, sondern liefern gleich auch die entsprechende Workflow Engine mit. Unterstützt wird die weit verbreitete und bekannte Modellierungssprache <a href="https://docs.camunda.org/manual/latest/reference/bpmn20/" target="_blank">BPMN</a>  (Business Process Model and Notation). Diese zeichnet sich nicht nur durch eine konkrete Syntax, d.h. eine für Menschen lesbare Darstellungsform aus, sondern ist auch von Grund auf für die maschinelle Ausführbarkeit konzipiert worden. Die angebotenen Sprachfeatures erlauben die Definition von Prozessmodellen jeglicher Komplexität und lassen hinsichtlich der Ausgestaltung kaum Wünsche offen. Sollen innerhalb eines Prozesses komplexe Entscheidungen abgebildet werden, bietet Camunda auch hierfür eine Lösung: eine Decision Engine, die als Eingabe ein <a href="https://docs.camunda.org/manual/latest/reference/dmn11/" target="_blank">DMN</a> -Modell (Decision Model and Notation) erwartet. Hierbei handelt es sich um eine Entscheidungstabelle, über die sich auf Basis definierbarer Eingabe-Faktoren ein oder mehrere Ausgaben spezifizieren lassen. Die Definition der verschiedenen Faktoren ist auf Datentypen wie beispielsweise <em>String</em>, <em>Integer</em>, <em>Boolean</em> oder <em>Date</em> beschränkt. Obwohl für diese Datentypen eine Reihe an Vergleichsoperationen angeboten werden, kann es dennoch vorkommen, dass diese für den gegebenen Anwendungsfall nicht ausreichend sind.</p><p>Auch hierfür bietet Camunda eine Lösung: Innerhalb von DMN-Modellen kann mithilfe der Auszeichnungssprache <a href="https://docs.camunda.org/manual/latest/reference/dmn11/feel" target="_blank">FEEL</a>  (Friendly Enough Expression Language) eine Funktion vor der Evaluation einzelner Felder in einer Entscheidungstabelle ausgewertet werden. Neben den von Camunda angebotenen Funktionen existiert eine Schnittstelle, um weitere, eigene FEEL-Funktionen zu definieren. Ziel dieses Blogbeitrags ist es, eine eigene Funktion zur Evaluierung in einem DMN-Modell zu implementieren. Die notwendigen Schritte werden einzeln vorgestellt und mit Code-Auszügen veranschaulicht.</p><h2>Camunda BPM DMN: Initiales Projekt-Setup</h2><p>Zunächst benötigt man ein Projekt, das die Camunda-Umgebung enthält und konfiguriert. Im folgenden Beispiel wird als Basis ein Spring-Boot-Projekt mit Gradle und Kotlin über den <a href="https://start.spring.io/" target="_blank">Spring Initializr</a>  erstellt und als einzige Abhängigkeit die “H2 Database” angegeben, da Camunda den jeweiligen Workflow State in eine relationale Datenbank schreibt und ohne nicht lauffähig ist. Das Projekt und der in diesem Beitrag gezeigte Code sind auf <a href="https://github.com/SteKoe/camunda-dmn-feel" target="_blank">GitHub</a>  hinterlegt.</p><p>Wurde das Projekt erzeugt und heruntergeladen, müssen in der <em>build.gradle.kts</em>-Datei noch die für Camunda notwendigen Abhängigkeiten ergänzt werden:</p>

```
dependencies {
    [...]
    implementation("org.camunda.bpm.springboot:camunda-bpm-spring-boot-starter:3.3.3")
    implementation("org.camunda.bpm:camunda-engine-plugin-spin:7.11.0")
    implementation("org.camunda.bpm.extension.feel.scala:feel-engine-plugin:1.8.0")
}

```

<p>Die Vorbereitungen für die Implementierung eigener FEEL-Funktionen ist hiermit abgeschlossen und es kann mit der Implementierung begonnen werden.</p><h2>Implementieren einer Funktion</h2><p>Im Folgenden soll nun als Beispiel eine Funktion implementiert werden, die als Eingabe-Parameter einen String erwartet und dann <em>true</em> zurückgibt, wenn der String mit einem Vokal beginnt, andernfalls <em>false</em>. Die Camunda-FEEL-Erweiterung bietet hierfür die Klasse <em>JavaFunction</em> an, die als ersten Parameter eine Liste von Strings erwartet, welche die Eingangsparameter definiert. Der zweite Parameter ist die konkrete Implementierung der Funktion und enthält entsprechend die gewünschte Logik. Da wir das Projekt auf Kotlin aufgesetzt haben, die Camunda-FEEL-Erweiterung aber in Scala entwickelt wurde, müssen wir ein paar Besonderheiten beachten. Dies betrifft in erster Linie vor allem die Verwendung spezifischer Wrapper-Objekte for Datentypen wie <em>String</em>, <em>List </em>und <em>Boolean</em>. Doch schauen wir uns die Funktion einmal genauer an:</p>

```
import org.camunda.feel.interpreter.Val
import org.camunda.feel.interpreter.ValBoolean
import org.camunda.feel.interpreter.ValList
import org.camunda.feel.interpreter.ValString
import org.camunda.feel.spi.JavaFunction
import scala.collection.JavaConverters.collectionAsScalaIterable

val stringStartsWithVowel:JavaFunction = JavaFunction(listOf("input")) { args ->
    val inputString = args.get(0) as ValString
    val listOfVowels = listOf(
            ValString("a"),
            ValString("e"),
            ValString("i"),
            ValString("o"),
            ValString("u")
    )
    val feelList = ValList(collectionAsScalaIterable<Val>(listOfVowels).toList())
    ValBoolean(feelList.items().contains(ValString.apply(inputString.value().substring(0, 1).toLowerCase())))
}

```

<p>Im Falle der Beispielfunktion erwarten wir genau einen Eingangsparameter, den wir <em>input</em> benannt haben. Da wir die Funktion in Kotlin implementieren, ist die Liste von Eingabeparametern optional (sie muss nicht einmal disjunkt sein) und könnte leer sein. In Scala könnte man statt über einen Index-basierten Zugriff die einzelnen Parameter mit Namen abgreifen. Der Lesbarkeit und Dokumentation halber füllen wir die Liste jedoch mit sinnvollen Werten bzw. Namen. Auf den konkreten Wert dieses Parameters greifen wir nun in Zeile 1 zu und führen auch einen Typecast durch. In den folgenden Zeilen wird eine Liste von Vokalen definiert, gegen die wir den Eingabeparameter in Zeile 10 prüfen. Zeile 9 ist für die Konvertierung des List-Typs in den ValList-Typ erforderlich.</p><h2>Und was ist mit Unit-Tests?</h2><p>Natürlich soll die Funktion nicht erst im Produktivsystem getestet werden. Fangen wir also mit einem positiven Unit-Test-Fall an und gehen davon aus, dass unsere Funktion, wenn wir den String „Another one bites the dust“ eingeben, <em>true</em> zurückgibt:</p>

```
import org.junit.Assert.assertTrue
import org.junit.Assert.assertFalse
import org.camunda.feel.interpreter.ValBoolean
import org.camunda.feel.interpreter.ValString
import org.junit.Test

class CustomFeelFunctionTest {
    @Test
    fun `Postive case for stringStartsWithVowel`() {
        val stringThatStartsWithVowel = ValString("Another one bites the dust")
        var actual = stringStartsWithVowel.function.apply(listOf(stringThatStartsWithVowel)) as ValBoolean
        assertTrue(actual.value())
    }
}

```

<p>Wie bereits erwähnt, müssen wir hier einige Scala-spezifische Datentypen verwenden und können beispielsweise nicht <em>String</em> verwenden, sondern müssen auf <em>ValString</em> zurückgreifen. Analog ist die erwartete Antwort unserer Funktion nicht vom Typ <em>Boolean</em>, sondern ein <em>ValBoolean</em>. Wenn wir diesen Test ausführen, werden wir sehen, dass unsere Logik bereits funktioniert. Der Vollständigkeit halber wollen wir noch einen Negativ-Test hinzufügen:</p>

```
@Test
fun `Negative case for stringStartsWithVowel`() {
    val stringThatDoesNotStartWithVowel = ValString("The quick brown fox")
    val actual = stringStartsWithVowel.function.apply(listOf(stringThatDoesNotStartWithVowel)) as ValBoolean
    assertFalse(actual.value())
}

```

<p>Auch hier werden wir nach erneutem Ausführen der Tests sehen, dass die Funktion für den Eingabewert “The quick brown fox” das korrekte Resultat liefert. Um den Rahmen dieses Beitrags nicht mit einer Vielzahl an Testkonstellationen zu sprengen, zeige ich nun, wie die implementierte Funktion der Camunda-Engine bekannt gemacht werden kann, um sie letztlich auch in einem DMN-Modell verwenden zu können.</p><h2>Camunda FEEL mit Funktion bekannt machen</h2><p>Um die Funktion einsetzen zu können, muss neben der <em>JavaFunction</em> auch ein <em>CustomFeelFunctionProvider</em> implementiert werden. Hierfür leiten wir eine Klasse von der Camunda FEEL-Erweiterung angebotenen Klasse <em>org.camunda.feel.spi.JavaFunctionProvider</em> ab und implementieren die notwendigen Methoden:</p>

```
import org.camunda.feel.spi.JavaFunction
import org.camunda.feel.spi.JavaFunctionProvider
import java.util.Optional
import kotlin.collections.HashMap

class CustomFeelFunctionProvider : JavaFunctionProvider() {
    override fun resolveFunction(functionName: String): Optional<JavaFunction> {
        return Optional.ofNullable(functions.get(functionName))
    }

    companion object {
        private val functions = HashMap<String, JavaFunction>()

        init {
            functions.put("stringStartsWithVowel", stringStartsWithVowel)
        }
    }
}

```

<p>In dieser Klasse wird eine statische Map mit unserer Funktion gefüllt. Der Schlüssel der Map entspricht dem späteren Funktionsnamen, den man in DMN-Modellen verwenden kann.</p><p>Leider reicht dies noch nicht aus; es muss eine Datei mit dem vorgegebenen Namen <em>org.camunda.feel.spi.CustomFunctionProvider</em> unter <em>src/main/resources/META-INF/services</em> abgelegt werden. In diese Datei wird nun der FQCN jeder Klasse eingetragen, die als <em>FunctionProvider</em> der FEEL-Erweiterung fungieren sollen. Hier gilt: nur ein FQCN pro Zeile!</p><p>Als letzter Schritt muss nun noch die FEEL-Erweiterung als solche an der Camunda-Engine registriert werden. Dies ist über eine Spring-Bean einfach in nur zwei Zeilen möglich:</p>

```
@Bean
fun feelScalaPlugin(): ProcessEnginePlugin = CamundaFeelEnginePlugin()

```

<p>Nun ist die Integration in Camunda abgeschlossen und es können Integrationstests geschrieben werden!</p><h2>Integrationstests der FEEL-Funktion</h2><p>Da die von uns programmierte Funktion in einem DMN-Modell verwendet werden soll, erstellen wir für den Integrationstest eine einfache Entscheidungstabelle und legen diese im Ordner <em>src/test/resources/bpmn</em> ab. Dieser Speicherort ist von der Camunda-Engine vorgegeben, da alle in diesem Ordner befindlichen BPMN- und DMN-Modelle automatisch von der Engine beim Start eingelesen werden. Unsere Entscheidungstabelle erwartet als Eingabeparameter eine Variable mit dem Namen SENTENCE vom Typ <em>String</em>. Der Ausgabeparameter heißt <em>startsWithVowel</em> und ist vom Typ <em>Boolean</em>.</p>

```
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/DMN/20151101/dmn.xsd" xmlns:biodi="http://bpmn.io/schema/dmn/biodi/1.0" id="Definitions_01d1liz" name="DRD" namespace="http://camunda.org/schema/1.0/dmn" exporter="Camunda Modeler" exporterVersion="3.1.0">
 <decision id="DT_DMN" name="Decision">
   <extensionElements>
     <biodi:bounds x="157" y="81" width="180" height="80" />
   </extensionElements>
   <decisionTable id="decisionTable_1" hitPolicy="FIRST">
     <input id="input_1">
       <inputExpression id="inputExpression_1" typeRef="string">
         <text>SENTENCE</text>
       </inputExpression>
     </input>
     <output id="output_1" label="Starts With Vowel" name="startsWithVowel" typeRef="boolean" />
     <rule id="DecisionRule_09cwpik">
       <inputEntry id="UnaryTests_0byqx1i">
         <text>stringStartsWithVowel(cellInput)</text>
       </inputEntry>
       <outputEntry id="LiteralExpression_1230wy7">
         <text>true</text>
       </outputEntry>
     </rule>
     <rule id="DecisionRule_1ar4y7f">
       <inputEntry id="UnaryTests_1sf7gpl">
         <text></text>
       </inputEntry>
       <outputEntry id="LiteralExpression_0a595oz">
         <text>false</text>
       </outputEntry>
     </rule>
   </decisionTable>
 </decision>
</definitions>

```

<p>Um DMN-Modelle auswerten zu können, benötigen wir den <em>DecisionService</em>,der Teil der Camunda-Engine ist. Über diesen Service können DMN-Modelle unabhängig von BPMN-Modellen getestet werden. Praktischerweise ist der <em>DecisionService</em> eine Spring-Bean und lässt sich daher mit herkömmlichen Mitteln ganz einfach in die Test-Klasse einbinden.<br /> Auf der <em>DecisionService</em>-Instanz rufen wir die Methode <em>evaluateDecisionTableByKey</em> auf und übergeben dieser die ID des DMN-Modells (vgl. id Attribut im decision-Knoten in der XML) sowie einen Kontext. Der Kontext ist eine Map, die einen Variablennamen und dessen konkreten Inhalt verknüpft; in unserem Fall SENTENCE und als Wert beliebige Testdaten. Konkret sieht die der Integrationstest wie folgt aus:</p>

```
import org.junit.Assert.assertFalse
import org.junit.Assert.assertTrue
import org.camunda.bpm.engine.DecisionService
import org.camunda.bpm.engine.variable.impl.value.PrimitiveTypeValueImpl.BooleanValueImpl
import org.junit.Test
import org.junit.runner.RunWith
import org.springframework.beans.factory.annotation.Autowired
import org.springframework.boot.test.context.SpringBootTest
import org.springframework.test.context.junit4.SpringRunner

@RunWith(SpringRunner::class)
@SpringBootTest
class CustomFeelFunctionsIT {
    @Autowired
    lateinit var decisionService: DecisionService

    @Test
    fun `Postive case for stringStartsWithVowel`() {
        val context = HashMap<String, Any?>()
        context.set("SENTENCE", "Another one bites the dust")

        val decisionResult = decisionService.evaluateDecisionTableByKey("DT_DMN", context)
        assertTrue(decisionResult.getSingleEntryTyped<BooleanValueImpl>().value)
    }

    @Test
    fun `Negative case for stringStartsWithVowel`() {
        val context = HashMap<String, Any?>()
        context.set("SENTENCE", "The quick brown fox")

        val decisionResult = decisionService.evaluateDecisionTableByKey("DT_DMN", context)
        assertFalse(decisionResult.getSingleEntryTyped<BooleanValueImpl>().value)
    }
}

```

<p>Starten wir nun diesen Test, wird ein Spring-Kontext mit Camunda-Engine hochgefahren, die die FEEL-Erweiterung beinhaltet. Anschließend wird das DMN-Modell eingelesen und über die Verwendung des Decision-Services und den gegebenen Kontexten ausgewertet. Die Integrationstests laufen durch und zeigen damit, dass die Einbindung der Funktion in die DMN funktioniert hat.</p><h2>Ergebnis</h2><p>Ziel war es, eine neue Funktion der FEEL-Sprache hinzuzufügen und diese in einem DMN-Modell zu verwenden. Leider ist der Weg in Teilen holprig, da eine Kombination aus Spring-typischen Konfigurationsschritten und Datei-basierter Konfiguration nötig ist. Doch letztlich ist es gelungen, die neue Funktion in der Camunda-Engine nutzbar zu machen. Ein weiterer Faktor konnte ebenfalls abgedeckt werden: Die Testbarkeit der Funktion ist sowohl im Unit-, als auch im Integrationstest gegeben. Leider ist der Umweg über Wrapper-Klassen wie <em>ValString </em>oder <em>ValBoolean</em> nötig, da die FEEL-Eweiterung in Scala implementiert ist.</p>

Camunda Business Process Management: DMN extended!

<p>Mit „Actions“ versucht GitHub in den Markt der CI/CD-Provider einzusteigen und will sich hier ein Stück des Kuchens abgreifen. GitHub Actions sind der nächste logische und vielleicht auch überfällige Schritt des Unternehmens, nicht nur Versionsverwaltung as a Service anzubieten und Code zu hosten, sondern diesen auch direkt im gleichen Ökosystem testen, bauen und releasen lassen zu können. Andere Anbieter wie GitLab oder Bitbucket bieten diese Funktionalität bereits seit längerem an. GitHub-Nutzer mussten bisher auf externe Lösungen wie bspw. CircleCI oder Travis CI ausweichen. Mit den GitHub Actions wird das Rad nicht neu erfunden und daher ist es nicht verwunderlich, dass GitHub auf bereits etablierte Konzepte und Vorgehensweisen anderer Anbieter zurückgreift. So werden die CI/CD-Pipelines, welche bei GitHub als Workflow bezeichnet werden, zum Beispiel auch in YAML geschrieben und als Teil des Quellcodes im Repository abgelegt. Auch ist die Definition einer Laufzeitumgebung (Windows, macOS, Linux) möglich und die Angabe von (mehreren) Versionen einer Laufzeitumgebung kann definiert werden.</p><h2>Zentrale Konzepte</h2><p>GitHub verwendet zwar im Kern ähnliche Konzepte wie die bekannten CI/CD-Provider am Markt, jedoch gibt es im Detail kleine Abweichungen. Daher <a href="https://help.github.com/en/articles/about-github-actions#core-concepts-for-github-actions" target="_blank">definiert GitHub</a>  die gegebenen Konzepte wie folgt:</p><p><b>Workflow</b> – Ein Workflow ist das Aggregat einzelner Teilaufgaben, die für das Bauen, Testen, Packen, Release und/oder Deployen eines Projekts notwendig sind. Um einen Workflow auszuführen, können trigger (bspw. on push) oder cronjobs definiert werden. Die einzelnen Schritte werden bei GitHub „Job“ genannt.</p><p><b>Job</b> – Ein Job setzt sich aus einzelnen Schritten (Steps) zusammen. Jobs können parallel oder nacheinander ausgeführt werden und definieren die Umgebung, in welcher die zugeordneten Schritte ausgeführt werden sollen. Hierfür kann zwischen Linux (ubuntu), Windows oder macOS ausgewählt werden.</p><p><b>Step</b> – Ein Step definiert eine einzelne Aufgabe, die in der vom Job vorgegebenen Umgebung ausgeführt wird. Eine Aufgabe kann hierbei ein Command (bspw. npm install) oder eine Action sein.</p><p><b>Action</b> – Actions sind aggregierte (meist komplexe) Step-Implementierungen, die wiederverwendet werden können. Statt beispielsweise für den Checkout immer wieder „git clone“ als Command zu implementieren, kann die Action „actions/checkout@v1“ verwendet werden.</p><h2>Ein Beispiel anhand von Node.JS</h2><p>Um es frei nach Goethe zu sagen: Genug der Worte, Taten warten! – Folgende GitHub-Action-Definition zeigt, wie ein Node-Projekt in drei verschiedenen Node-Versionen gebaut werden kann. Der Workflow wird bei jedem „push“-Event getriggert und startet anschließend für jede angegebene Node-Version einen virtuellen Runner, welcher ein Ubuntu bereitstellt. Auf diesen Runner werden anschließend alle Steps ausgeführt: Auschecken der Sourcen, Installation der Node-Version, Logik, um das Node-Projekt zu bauen, testen und zu releasen. Eine genaue Beschreibung der einzelnen Syntaxelemente ist ebenfalls von GitHub dokumentiert und kann <a href="https://help.github.com/en/articles/workflow-syntax-for-github-actions" target="_blank">hier</a>  eingesehen werden.</p>

```
name: Node.JS CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [8.x, 10.x, 12.x]

    steps:
    - uses: actions/checkout@v1
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}
    - name: npm install, build, and test
      run: |
        npm install
        npm run prepare:release
      env:
        CI: true
        RUN_SLOW_TESTS: true
```

<p>Wird diese Workflow-Definition unter „.github/workflows/nodejs.yml“ im Repository abgelegt, kann unter dem Reiter „Actions“ eine Übersicht der einzelnen „Workflow runs“ (sofern bereits einer gestartet wurde) und Workflow-Definitionen abgerufen werden.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/lXTSgeW0Rdyvk6xwElsY"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/lXTSgeW0Rdyvk6xwElsY" alt="Actions-Übersichtsseite: Links sind die Verfügbaren Worfklows aufgelistet, rechts die bereits gelaufenen Workflow-Instanzen mit Status, Dauer und Branchnamen." width="700" height="550" /></a> <br /> Auch eine Detailansicht der einzelnen Runs wird, wie von anderen Providern gewohnt, angeboten und im folgenden Bild deutlich. Jeder Teilschritt wird hierbei als Kopfzeile dargestellt, hinter welcher initial die entsprechenden Logausgaben versteckt werden. Durch einen Klick auf einen Workflow-Schritt können entsprechend weitere Logausgaben abgerufen werden. Im linken Bereich der Seite werden – sofern konfiguriert – die verschiedenen parametrisierten Workflows angezeigt. In dem vorliegenden Beispiel sind es die drei Node-Versionen 8, 10 und 12.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LTb4W5YGRCSUza9Gs9A3"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LTb4W5YGRCSUza9Gs9A3" alt="Workflow-Detailsseite: Hier werden die einzelnen Logausgaben einer konkreten Workfow-Instanz ausgegeben." width="700" height="544" /></a> </p><h2>Einschränkungen</h2><p>In einigen Fällen können Workflows Ressourcen-hungrig oder komplex sein. Daher sieht GitHub ein paar wenige Einschränkungen für die Verwendung von GitHub Actions vor. Diese Limits gelten jeweils pro Repository und sind als „harte“ Limits zu berücksichtigen:</p><ul><li>Maximal 20 gleichzeitige Workflows</li><li>Maximal insgesamt 1000 API-Requests pro Stunde</li><li>Maximale Laufzeit eines Workflows: 6 Stunden</li><li>Maximal 20 parallele Jobs</li></ul><h2>Fazit</h2><p>Dieser Beitrag umreißt, welche neuen Möglichkeiten GitHub mit dem bald öffentlich verfügbaren Feature „Actions“ anbieten wird. Aktuell scheinen die Möglichkeiten noch recht rudimentär zu sein, doch der Vorteil eine CI/CD-Pipeline direkt beim Git-Provider selbst definieren zu können bietet zumindest für kleine und vor allem neue Projekte einen gewissen Mehrwert. Inwiefern sich GitHub Actions gegen die verbreiteten üblichen Verdächtigen im Bereich CI/CD durchsetzen kann, wird sich zeigen.</p>

GitHub Actions – CI/CD auf kurzem Wege

<p>Geschäftsprozessmodellierung und einhergehende Sprachen wie BPMN und DMN sind Begriffe, denen man normalerweise im beruflichen Umfeld begegnet und die im privaten Raum keine Rolle spielen. Natürlich kann man die Prozesse eines Haushalts (aka kleines, privates Familienunternehmen) auch mit Hilfe der BPMN abbilden, doch jeder würde mir beipflichten, dass dies ein wenig “drüber” wäre. Warum sollte man also mit Kanonen auf Spatzen schießen und BPMN im Smart Home verwenden? Für mich ist die Frage ganz klar zu beantworten: Weil es geht!</p><p>Es ergibt nach wie vor keinen wirklichen Sinn, eine Prozessautomatisierung bzw. -steuerung im privaten Rahmen zu implementieren, doch rein aus Interesse habe ich die Verknüpfung meines Smart Home-<a href="https://www.openhab.org/" target="_blank">openHAB</a> -Systems mit der <a href="https://camunda.com/de/products/bpmn-engine/" target="_blank">Camunda BPE</a>  (Camunda Business Process Engine) ausgetestet und muss sagen: Kann man machen! Anstatt Regeln über die in openHAB integrierte Rule-Engine zu definieren, modelliere ich sie nun als BPMN-Diagramm. Hierfür war es notwendig, einen MQTT-Broker aufzusetzen, über den die Integration von Camunda und openHAB realisiert werden konnte. Den entsprechenden Source-Code kann man im <a href="https://github.com/SteKoe/camunda-mqtt-openHAB" target="_blank">GitHub-Repository</a>  finden.</p><h2>OpenHAB und MQTT</h2><p>Für mein Proof-of-Concept habe ich auf <a href="https://mosquitto.org/" target="_blank">Eclipse Mosquitto</a>  als Message Broker zurückgegriffen, welches ich über Docker laufen lasse.</p><div>

```yaml
version: '3.5'
services:
  mosquitto:
    image: eclipse-mosquitto
    ports:
      - "1883:1883"
      - "9001:9001"
    volumes:
      - ./sh-mosquitto/mosquitto.conf:/mosquitto/config/mosquitto.conf
```

</div><p>Läuft der Broker, müssen wir openHAB nur noch “beibringen”, sich mit diesem zu verbinden. Gewiefte openHAB-Nutzer werden erahnen, dass hierfür ein Binding installiert werden muss. Das MQTT-Binding (<a href="https://www.openhab.org/addons/bindings/mqtt/" target="_blank">https://www.openhab.org/addons/bindings/mqtt/</a> ) kann über die Paper-UI oder die <code>addons.cfg</code>-Datei wie gewohnt installiert werden. Anschließend muss der Mosquitto-Broker noch mit openHAB verheiratet werden, indem man ihn als Thing konfiguriert. Da ich mein openHAB-System über Dateien konfiguriere, folgt hier ein Auszug aus meiner Konfigurationsdatei:</p><div>

```openhab-things
Bridge mqtt:broker:broker [ host="mosquitto" ] {
    Thing topic wohnzimmer "MQTT Wohnzimmer" {
    Channels:
        Type switch : Lampe_Decke [ stateTopic="Haus/Wohnzimmer/Lampe/Decke", commandTopic="Haus/Wohnzimmer/Lampe/Decke", postCommand=true, on="ON", off="OFF"]
        Type switch : Lampe_Wuerfel [ stateTopic="Haus/Wohnzimmer/Lampe/Wuerfel", commandTopic="Haus/Wohnzimmer/Lampe/Wuerfel", postCommand=true, on="ON", off="OFF" ]
        Type switch : Lampe_Kamera [ stateTopic="Haus/Wohnzimmer/Lampe/Kamera", commandTopic="Haus/Wohnzimmer/Lampe/Kamera", postCommand=true, on="ON", off="OFF" ]
    }
}
```

</div><p>Hier passiert bereits die eine Hälfte der Magie die nötig ist, um Camunda und openHAB zusammen zu bringen: Innerhalb der Konfiguration der MQTT-Bridge werden für drei Lampen die Channels vom Typ “switch” (sic! Entgegen der Definition in den Items wird „switch“ hier klein geschrieben) definiert, welche einem State- bzw. Command-Topic zugeordnet werden. Möchte man später über das entsprechende Topic die Geräte schalten, muss unbedingt der Parameter <em>postCommand</em> auf <em>true</em> gesetzt werden, da sonst das Licht aus bleibt bzw. der Schalter nicht schaltet. Die Zuordnung von on auf ON bzw. off auf OFF ist für die spätere Nutzung in Camunda relevant, da hier sonst eine 1 statt ON bzw. eine 0 statt OFF ankommt. Je nach Gusto kann dies natürlich auch weggelassen und mit den jeweiligen Zahlenwerten weitergearbeitet werden.</p><p>Nach der Konfiguration des MQTT-Things, also der Verbindung zum Broker, müssen wir nun noch die Channel aus der Broker-Konfiguration mit den korrespondierenden Items verbinden.</p><div>

```openhab-items
Switch Wohnzimmer_Wuerfellampe
    "Würfellampe"
    { channel="hue:0100:1:wuerfellampe:brightness", channel="mqtt:topic:broker:wohnzimmer:Lampe_Wuerfel" }
 
Switch Wohnzimmer_Decke
    "Deckenlampe"
    { channel="homematic:HmIP-FSM:ccu:00089A49967AA7:2#STATE", channel="mqtt:topic:broker:wohnzimmer:Lampe_Decke" }
 
Switch Wohnzimmer_Kameralampe
    "Kameralampe"
    { channel="hue:0100:1:kameralampe:brightness", channel="mqtt:topic:broker:wohnzimmer:Lampe_Kamera" }
```

</div><p>Die gezeigte Konfiguration enthält neben der MQTT-Verknüpfung auch die Verknüpfung zu den eigentlichen Schaltzentralen der einzelnen Lampen. So werden bspw. die Würfel- und Kameralampe über Philips Hue gesteuert und die Deckenlampe über Homematic.<br /> Wird über die openHAB-Oberfläche die Würfellampe eingeschaltet, wird der Befehl “Einschalten” bzw. “ON” initiiert und von openHAB über das Hue-Binding an die Hue-Bridge weitergeleitet, welche letztlich das Licht schaltet. Analog geschieht dies bei Homematic-Geräten. Darüber hinaus wird der Befehl auch auf den MQTT-Broker gesendet und kann von allen Systemen, welche sich mit dem Broker verbunden haben, dort abgerufen werden.</p><p>Über MQTT sieht der Vorgang wie folgt aus: Sendet man eine Nachricht über Mosquitto an das Topic für die Deckenlampe mit dem Payload “ON”, wird openHAB diese Nachricht lesen, verarbeiten und die Deckenlampe schalten, indem der Befehl „ON“ über das Homematic-Binding an die Homematic CCU weitergeleitet wird, welche wiederum über eine 433Mhz Frequenz den eigentlichen Schalter ansteuert.</p><div>

```shell
mosquitto_pub -t "Haus/Wohnzimmer/Lampe/Decke" -m "ON"
```

</div><h2>BPMN im Smart Home: Mind the gap between openHAB and Camunda!</h2><p>OpenHAB und Mosquitto sind nun konfiguriert und funktionieren wie gewollt: Es werden Nachrichten bei Zustandsänderungen gesendet und Nachrichten können eine Zustandsänderung hervorrufen. Der nächste Schritt ist, eine Verbindung zwischen Mosquitto und Camunda herzustellen.</p><p>Um ein greifbares Szenario zu haben, sei folgender Use Case gegeben: Es sollen, wenn die Deckenlampe im Wohnzimmer eingeschaltet wird, sowohl die Würfel- als auch Kameralampe ebenfalls eingeschaltet werden. Wird die Deckenlampe ausgeschaltet, soll nichts weiter passieren.</p><p>Schauen wir einmal im Detail auf die von der BPMN angebotenen Konzepte, welche für die Umsetzung eingesetzt werden können: Die BPMN bietet sowohl Messages als auch Signals an. Rein technisch betrachtet existiert zwischen den beiden Konzepten kein Unterschied, semantisch jedoch ist ein Signal einem Broadcast gleichzusetzen und eine Message ein gezielter Versand einer Nachricht an einen externen Akteur. Geht man nun davon aus, dass das Schalten einer Lampe (hier der Deckenlampe) ein von openHAB gesendeter Broadcast über den Message-Broker ist, können wir als Startereignis ein “Signal Start Event” verwenden. Soll aus der BPMN heraus eine Lampe geschaltet werden, ist dies als gerichteter Aufruf zu verstehen und lässt sich daher als Message modellieren. Heißt also: eingehende Zustandsänderungen sind Signals, ausgehende Zustandsänderungen sind Messages.</p><p>Mit Hilfe der BPMN lässt sich der Use Case daher wie folgt abbilden:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/BPTf7WlpTVKRvzWjOVKu"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/BPTf7WlpTVKRvzWjOVKu" alt="BPMN-Prozess zur Steuerung der Würfel- und Kameralampe, wenn die Deckenlampe angeschaltet wird." width="700" height="275" /></a> </p><p>Wird die Deckenlampe im Wohnzimmer geschaltet, haben wir festgelegt, dass der entsprechende Zustand auf das MQTT-Topic <code>Haus/Wohnzimmer/Lampe/Decke</code> gelegt wird. Das “Signal Start Event” muss also auf dieses Topic horchen und wird daher im Feld “Signal Name” eingetragen.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/VQAxUY9SJOHrK7hRny8O"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/VQAxUY9SJOHrK7hRny8O" alt="Einstellungen des Signal Start Events zum Anstoßen des BPMN-Prozesses." width="700" height="383" /></a> </p><p>Nächster Schritt ist die Rückantwort von der BPMN an openHAB. Da es sich hier um das gezielte Senden von Nachrichten handelt, greifen wir auf “Intermediate Throw Events” zurück und geben als Message-Namen das Topic an, welches die entsprechende Lampe adressiert. Im vorliegenden Fall ist dies <code>Haus/Wohnzimmer/Lampe/Kamera</code> sowie <code>Haus/Wohnzimmer/Lampe/Wuerfel</code>. Was nun noch fehlt ist der Befehl, den wir an das korrespondierende Item übermitteln wollen. Dies wird am Message-Namen noch angefügt, sodass dieser letztlich wie folgt aussieht: <code>Haus/Wohnzimmer/Lampe/Kamera:command:ON</code> bzw. <code>Haus/Wohnzimmer/Lampe/Wuerfel:command:ON</code>.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/pCCwB474SeKMzZ3CixEg"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/pCCwB474SeKMzZ3CixEg" alt="Einstellungen des Intermediate Throw Events zum anschalten der Kameralampe." width="700" height="383" /></a> </p><h3>Camunda an MQTT: Kommunikation mit der Umwelt über ThrowEvents</h3><p>Ist die Ablauflogik in Camunda definiert, fehlt nun noch die ausführende Schicht, welche den Workflow und die Verbindung zum MQTT-Broker realisiert. Dies nehmen wir in Kotlin vor und verknüpfen unsere Implementierung durch das Camunda-Konzept “Delegate Expression” mit den modellierten “Intermediate Throw Events”.</p><p>Da wir Camunda als Spring-Boot-Applikation implementieren, können wir im “Delegate Expression”-Feld den Namen unserer auszuführenden Bean eintragen <code>${mqttThrowEvent}</code> und die Camunda BPE löst dies zur Laufzeit auf. Der Code sieht wie folgt aus:</p><div>

```java
package de.stekoe.camunda.mqtt.bpm
 
import de.stekoe.camunda.mqtt.logger
import de.stekoe.camunda.mqtt.service.MqttService
import org.camunda.bpm.engine.delegate.DelegateExecution
import org.camunda.bpm.engine.delegate.JavaDelegate
import org.camunda.bpm.model.bpmn.instance.Message
import org.camunda.bpm.model.bpmn.instance.MessageEventDefinition
import org.camunda.bpm.model.bpmn.instance.ThrowEvent
import org.springframework.stereotype.Component
 
@Component
class MqttThrowEvent(private val mqttService: MqttService) : JavaDelegate {
    override fun execute(execution: DelegateExecution) {
        val topic = getTopic(execution)
        if (topic == null) {
            logger().error("Not throwing any event in {}. Could not determine topic.", execution.currentActivityName)
            return
        }
 
        getMqttMessagePayload(execution)?.let { message ->
            logger().info("Throwing event topic {} with value {}", topic, message)
            mqttService.sendMessage(topic, message)
        }
    }
 
    private fun getTopic(execution: DelegateExecution): String? {
        return getBpmnMessageName(execution)?.split(":command:".toRegex())?.get(0)
    }
 
    private fun getMqttMessagePayload(execution: DelegateExecution): String? {
        return getBpmnMessageName(execution)?.split(":command:".toRegex())?.last()
    }
 
    private fun getBpmnMessage(execution: DelegateExecution): Message {
        val event = execution.bpmnModelElementInstance as ThrowEvent
        val definition = event.eventDefinitions.iterator().next() as MessageEventDefinition
        return definition.message
    }
 
    private fun getBpmnMessageName(execution: DelegateExecution): String? {
        return try {
            val bpmnMessage = getBpmnMessage(execution)
            bpmnMessage.name
        } catch (e: Exception) {
            logger().info("Cannot get the Message Name.", e)
            null
        }
    }
}
```

</div><p>Die obige Implementierung liest den Message-Namen des Events aus und zerlegt diesen anhand des Keywords „command“ in den Topic und den Befehl, welcher an das Topic gesendet wird. So wird bspw. aus <code>Haus/Wohnzimmer/Lampe/Kamera:command:ON</code> das Topic <code>Haus/Wohnzimmer/Lampe/Kamera</code> und der Befehl <code>ON</code> extrahiert. Die Anbindung an den MQTT-Broker ist in den <a href="https://github.com/SteKoe/camunda-mqtt-openHAB/blob/master/src/main/kotlin/de/stekoe/camunda/mqtt/service/MqttService.kt"><code>MqttService</code></a>  gekapselt.</p><h3>MQTT an Camunda: Vom Message-Broker zum BPMN-Signal</h3><p>Wie eingangs geschrieben, setzen wir für das Starten unseres BPMN-Prozesses auf das „Signal-Start-Event“. Hierfür stellt Camunda die Methode <code>signalEventReceived</code> im <code>RuntimeService</code> bereit, welche einen Signalnamen und optional weitere Parameter entgegennimmt, welche der Prozessinstanz übergeben werden können. In unserem PoC verwenden wir das MQTT-Topic als Signalnamen und geben zudem den Payload der MQTT-Message und Namen des MQTT-Topics als Variablen an den Prozess weiter.</p><div>

```java
override fun messageArrived(topic: String, message: MqttMessage) {
    logger().info("Message arrived at '{}' with payload {}", topic, message)
 
    val values: MutableMap<String, Any> = HashMap()
    values[String.format(PAYLOAD_NAME_PATTERN, topic.replace("/", "_"))] = String(message.payload)
    values[String.format(TOPIC_NAME_PATTERN, topic.replace("/", "_"))] = topic
 
    try {
        // Instruct Camunda BPE to trigger signal events
        runtimeService.signalEventReceived(topic, values)
    } catch (e: ProcessEngineException) {
        logger().warn("Signal processing failed due to: ${e.message}")
    }
 
    logger().info("Throwing BPMN signal '{}' width value {}", topic, values)
}
```

</div><p>Erhalten wir nun eine MQTT-Nachricht, wird in der Camunda-Engine ein BPMN-Signal mit demselben Namen angestoßen. Jedes Signal-Event, das auf dieses Signal lauscht, stößt dann die entsprechende Ablauflogik an, was in unserem Falle zum Start einer Prozessinstanz zur Steuerung der Lampen führt.</p><h2>Fazit</h2><p>Durch das Bindeglied Mosquitto ist es möglich, openHAB und Camunda zusammenzubringen und eine Steuerung über BPMN-Diagramme zu ermöglichen. Wie anfangs bereits erwähnt ist dies eher ein konstruiertes Problem, zeigt aber, wie flexibel verschiedene Systeme integriert werden können. Gerade im Hinblick auf die Heimautomatisierung ist die Verwendung von Camunda eine zwar technisch aufwändigere, aber auch autarke Alternative zu <a href="https://ifttt.com/">IFTTT</a> . Da ich meine Heimautomatisierung komplett unabhängig von externen Cloud-Anbietern halte, um bei Ausfällen des Internets immer noch alle Aktionen/Szenen und Geräte steuern zu können, werde ich diesem Ansatz jedoch eine Probezeit gewähren. Für visuell orientierte Menschen ist dieser Ansatz auch zu empfehlen, da man die Ablauflogik als Grafik präsentiert bekommt und keine abstrakten Code-Schnipsel eintippen muss.</p>

BPMN im Smart Home: Camunda und openHAB

<p><span>In dieser Blogserie, bestehend aus drei Teilen, soll es um meine digitalen Fotoverwaltung gehen und wie ich Fotogalerien erzeuge, die ich als statische Webseite veröffentlichen kann. Warum dieser Beitrag im Tech Blog der codecentric landet, liegt auf der Hand: In erster Linie bin ich Softwareentwickler und habe dank dieses Berufes die Möglichkeit, mir meine Werkzeuge selbst zu programmieren und genau auf meine Bedürfnisse anzupassen. Daher kann ich mein Hobby, die Fotografie, um meine beruflichen Erfahrungen erweitern und mir die Arbeit mit der Fotoverwaltung  und dem Bereitstellen von Galerien vereinfachen. Meine programmatische Lösung für die automatisierte bzw. vereinfachte Bereitstellung und Verwaltung meiner Fotos wird daher in dieser Serie Thema sein.</span></p><p><span>Warum ich dieses Thema in drei Teile schneide ist ebenso schnell erklärt: im ersten Teil soll es darum gehen, wo und wie ich meine Fotos speichere und verwalte, denn ich habe in den vergangenen Jahren diverse Tools kommen und gehen sehen, sowie einige Cloud-Dienste ausprobiert und war nie so wirklich glücklich mit den gegebenen Möglichkeiten.</span></p><p><span>Der zweite Teil handelt das Thema “Galerien” ab, welches für mich bis dato ein “pain point” war, da ich hier sehr viel Zeit und Energie investieren musste, um zu einem adäquaten Ergebnis zu gelangen. Außerdem fühlte sich das Erzeugen von Galerien aus Sicht eines Softwareentwicklers immer sehr unnatürlich an, da sich einzelne Schritte immer wiederholten. </span></p><p><span>Der dritte und letzte Teil führt die aufgeführten Punkte der vorhergegangen Beiträge zusammen: Dort wird beschrieben, wie ich mit Hilfe meines Verwaltungssystems automatisch generierte Fotogalerien erzeuge, die dann auf meinen Server deployed werden.</span></p><p><span>Genug der Vorgeschichte, tauchen wir direkt in den ersten Teil der Serie ab!</span></p><h2><span>Teil 1: Fotoverwaltung</span></h2><h3><span>Fotoverwaltung auf dem lokalen Rechner</span></h3><p><span>Zu Beginn meines “Fotografen”-Daseins hatte ich nicht groß darüber nachgedacht, wie und wo ich meine Bilder ablegen, geschweige denn wie ich sie strukturieren möchte. Vielmehr landeten sie unsortiert im Ordner “Meine Bilder”. Erst nach ein paar Jahren, als ich auf meine erstes MacBook umgestiegen bin und meine Daten migrieren musste, fing ich an über eine sinnvolle Struktur und einen Ablageort nachzudenken. Also begann ich damit, alle Fotos mit Apple iPhoto zu verwalten und in Alben zu sortieren. Dies kostete neben Zeit vor allem Nerven und auch die Namen der Alben wollten gut überlegt sein, denn ich hatte zu diesem Zeitpunkt bereits keine Lust mehr mir nochmals Gedanken über dieses Thema machen zu müssen. Recht schnell kam ich auf die nicht sehr innovative aber effektive Vorgehensweise, im Namen der Alben das Jahr und Monat der jeweiligen Aktivität als Präfix einzupflegen. Hierdurch wurde es möglich, Alben in chronologischer Reihenfolge zu sortieren.</span></p><p><span>Dies ging solange gut, bis die Weiterentwicklung von iPhoto eingestellt wurde und ich umdenken musste: Wohin also nun mit der iPhoto-Bibliothek? Was passiert mit der ganzen Arbeit die ich in die Strukturierung der Bilder gesteckt habe? Was wäre eine Alternative, die nicht weniger gut und vor allem auch kostenlos ist? Und auch: Ist es überhaupt sinnvoll weiterhin auf proprietäre Tools zu setzen?</span></p><p><span>Die Suche nach einer alternativen Software gestaltete sich schwierig, da viele in iPhoto vorhandenen Funktionen, wie beispielsweise die automatische Gesichts- und Personenerkennung, in keinem anderen Tool zu finden waren und sich die iPhoto-Metadaten auch nicht importieren ließen. Nach diversen Anlaufschwierigkeiten habe ich meine iPhoto-Bibliothek nach Picasa (ein Tool von Google) migriert und diese dort mit den gegebenen Mitteln weiter ausgebaut. Dies hatte zudem den Vorteil, dass Picasa auch für andere Plattformen erhältlich war. Auch diese Vorgehensweise verlief ein paar Jahre ohne Probleme, bis Google beschloss, Picasa aufzugeben. – So ging die Suche erneut von vorne los und der Frust war groß.</span></p><p><span>Zu diesem Zeitpunkt war ich der Tools bereits überdrüssig und beschloß, die Fotos nur noch über das Dateisystem zu verwalten, da dies in meinen Augen auch weiterhin ein fester Bestandteil der diversen Betriebssysteme bleiben wird. Die Alben aus Picasa wurden daher zu Ordnern und die enthaltenen Fotos habe ich mit Hilfe der EXIF-Daten ebenfalls einheitlich umbenannt, sodass sich die Dateinamen aus dem Aufnahmedatum und dem Zeitstempel zusammensetzen. Zumindest das Problem der Toolauswahl und Strukturierung meiner Fotos war damit vom Tisch.</span></p><h3><span>Migration in die Cloud</span></h3><p><span>Im Zuge der Abkehr von bestimmten Tools habe ich auch nach einer Möglichkeit gesucht, meine Fotos nicht mehr nur auf meinem MacBook zu speichern, sondern diese zwischen meinen Rechnern zu synchronisieren. Logische Konsequenz war daher die Suche nach adäquatem Cloud-Speicher. Doch der Gedanke, meine privaten Fotos in die Hände eines “Unbekannten” zu geben, war mir nicht sehr genehm, wodurch alle gängigen Cloud-Anbieter wie Dropbox, iCloud, Google Drive, Amazon oder Microsoft ausgeschlossen waren. Auch wenn mein Denken an dieser Stelle rückwärtsgewandt zu scheinen mag, so wollte ich dennoch wissen, an welchem geografischen Ort sich meine Daten befinden und möglichst sicher sein, dass diese auch nur dort sind.</span></p><p><span>Die Entscheidung fiel also auf eine private Cloud mit einer On-Premise-Installation einer Cloud-Software, die für alle Betriebssysteme eine Synchronisations-Software anbietet. Im Rahmen meiner Recherche bin ich auf </span><a href="https://nextcloud.com/" target="_blank">NextCloud</a> <span> (einem Fork von </span><a href="https://owncloud.org/" target="_blank"><span>OwnCloud</span></a> <span>) sowie </span><a href="https://www.seafile.com/" target="_blank"><span>Seafile</span></a> <span> gestoßen. Da ich erstere auf meinem bereits vorhandenen PHP- und MySQL-Stack laufen lassen konnte, habe ich mich für diese entschieden, mit dem Import meiner Fotos angefangen und alle Daten in “meine” Cloud auf meinen Server verschoben. Die Entscheidung fiel zudem aus monetären Gründen: Natürlich hätte ich auch ein NAS-System oder ähnliches bei mir aufstellen können, was jedoch zu Rüstkosten geführt hätte, die ich mit dem Einsatz von NextCloud nicht aufbringen musste.</span></p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/szH7D6QsGyAMTEgmfvwW"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/szH7D6QsGyAMTEgmfvwW" alt="NextCloud-Oberfläche mit Ordnerliste der Fotoalben im Browser" width="250" height="169" /></a> <p>NextCloud-Oberfläche mit Ordnerliste der Fotoalben im Browser</p></div><h3><span>Sicherheit hat seinen Preis</span></h3><p><span>Ein nicht zu unterschätzender Aspekt beim eigenständigen Verwalten einer Cloud-Instanz ist die Konfiguration der Software und des darunterliegenden Betriebssystems. Natürlich ist darauf zu achten, dass sowohl die NextCloud-Installation als auch das Betriebssystem selbst stets aktuell gehalten werden, um möglichen Angriffen aus dem Weg zu gehen. Dies ist Dank des eingebauten Updaters sehr einfach möglich, muss jedoch in regelmäßigen Abständen selbstständig kontrolliert werden. Zudem bieten die Entwickler von NextCloud auch ein </span><a href="https://scan.nextcloud.com/" target="_blank"><span>Security-Scan-Tool</span></a> <span> an, welches die Instanz von außen überprüfen kann. Natürlich ist es nicht sinnvoll, sich blind auf diese Angaben zu verlassen, da sie nur Anhaltspunkte für mögliche Schwachstellen offenbaren.</span></p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/3lrTv41tSCGJvAlXoPXY"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/3lrTv41tSCGJvAlXoPXY" alt="NextCloud Security Scan Übersicht mit A+ Bewertung" width="250" height="184" /></a> <p>NextCloud Security Scan Übersicht mit A+ Bewertung</p></div><p><span>Auch die Wahl des Passwortes ist ein wichtiger Faktor. Gerade für den Administrationszugang sollte dies kein triviales sein und folgender Daumenregel folgen: Es sollte mindestens 16 Zeichen lang sein, eine Zahl, einen Groß- sowie Kleinbuchstaben und ein Sonderzeichen enthalten (vgl. auch die </span><a href="https://www.bsi-fuer-buerger.de/BSIFB/DE/Empfehlungen/Passwoerter/passwoerter_node.html" target="_blank"><span>Empfehlung des BSI</span></a> <span>). </span></p><p><span>Darüber hinaus ist der Einsatz von SSL dringend zu empfehlen. Nicht zuletzt in Zeiten, in denen SSL-Zertifikate mit denkbar wenig Aufwand erzeugt und eingesetzt werden können (</span><a href="https://letsencrypt.org/" target="_blank"><span>Let’s Encrypt</span></a> <span> lässt grüßen).</span></p><h3><span>Fazit</span></h3><p><span>Mit diesem Setup arbeite ich nun seit über vier Jahren und bin sehr zufrieden; sowohl mit der Bedienbarkeit der Cloud, als auch dem Aufwand, diese zu verwalten. Da ich in regelmäßigen Abständen alle in der Cloud gespeicherten Daten auf einer Festplatte bei mir zu Hause sichere, habe ich auch keine Sorge, dass meine Daten plötzlich verschwinden. In den vergangenen Jahren habe ich neben meinen Fotos auch meine Kontakte und Kalender in die NextCloud migriert, kann über CalDav bzw. CardDav auf diese zugreifen und bin mir gewiss, dass diese nicht bei Google, Apple oder Microsoft liegen.</span></p><p><span>Im nächsten Teil über Fotoverwaltung geht es darum, wie ich aus meinen Fotos statische Fotogalerien als Webseite erstellt habe bzw. welche Odyssee ich auch hier hinter mich gebracht habe.</span></p>

Fotoverwaltung und Galerien – Teil 1: Fotoverwaltung

<p><span>Herzlich Willkommen zum zweiten Teil der Blogserie “Fotoverwaltung und Galerien”! Nachdem ich <a href="/wissens-hub/blog/fotoverwaltung-und-galerien-teil-1-fotoverwaltung">im ersten Teil</a>  meinen Weg hin zur Verwaltung meiner Fotos in einer NextCloud geschildert habe, möchte ich in diesem Teil darüber schreiben, wieso ich mich von den Fotogalerien großer Softwarehersteller abgewandt habe und zu einer Individuallösung gekommen bin.</span></p><h3><span>Einfach muss nicht schön heißen</span></h3><p><span>Wo man früher noch mit einer Tasse Kaffee bei Kuchen und Plätzchen im dunklen Wohnzimmer zusammen die Dias des letzten Urlaubs auf die Leinwand geworfen hat, sitzt man heute vor dem Fernseher oder PC. Um dies nicht zwingend zu einem zentralen Ereignis zu stilisieren, ist es dank des Internets einfach möglich, die Fotoalben als Link an Freunde und Verwandte zu schicken, um die Urlaubsimpressionen zu teilen. Tools wie Apple iPhoto, Google Picasa oder Adobe Photoshop bieten dem Anwender die Option zur Veröffentlichung von Fotoalben im Internet. Dies ist jedoch meist gepaart mit der Voraussetzung, dass die generierte Fotogalerie in eine entsprechende Cloud des Anbieters hochgeladen wird und von dort abgerufen werden kann. Wie bereits im ersten Teil geschrieben ist mir bei dem Gedanken grundsätzlich nicht wohl, da ich gerne wissen möchte wo genau meine Fotos liegen und wer darauf womöglich Zugriff hat. Der Gedanke “was habe ich schon zu verbergen” ist an dieser Stelle, und das nicht nur im Bezug auf private Bilder, in meinen Augen fehl am Platze.</span></p><p><span>Neben dem Unwohlsein bezüglich des Speicherorts meiner Fotos waren die Gestaltungsmöglichkeiten der Fotoalben in allen Fällen mehr schlecht als recht. Natürlich ließen sich ein paar Parameter wie Farben, Schriften oder das Layout anpassen, jedoch fehlte mir bei allen Anbietern das letzte Stück Individualität und die Gestaltungsfreiheit. Es liegt auf der Hand, dass es sich hier um Standardsoftware handelt und daher die Vorlagen nur in begrenztem Maße anpassbar sind. Doch da ich als Entwickler mit dem Schwerpunkt Webentwicklung wusste, welche Möglichkeiten existieren, war mir dies nicht ausreichend. Daher fing ich an, eigene Galerien zu implementieren und diese auf meine Bedürfnisse anzupassen und so zu gestalten, wie ich es wollte.</span></p><h3><span>Fotogalerien: Selbstgemacht bringt doppelt Spaß</span></h3><p><span>In Teil 1 erwähnte ich bereits, dass es sich für mich unnatürlich anfühlt, wenn ich Schritte immer wiederholen muss. Daher war für mich sofort klar, dass ich eine Lösung anstrebe, welche mir aus einem Set an Fotos automatisiert eine statische Webseite erzeugt, über die man sich die Bilder anschauen kann. Statt jedoch bei Null zu starten, habe ich mir im Netz aus diversen Vorlagen die Elemente herausgenommen, welche ich schön fand und die meinen Vorstellungen am nächsten kamen. Im zweiten Schritt habe ich die verschiedenen Elemente dann manuell zusammengesetzt und an meine Vorstellungen weiter angepasst.</span></p><p><span>Nun blieb der finale Schritt der Automatisierung offen: Ich suchte daher nach einer Template-Engine, welche auf Basis einer Vorlage und meiner Bilder eine statische Fotogalerie erzeugen kann. Nach diversen Gehversuchen mit eigenen Implementierungen, die auf </span><a href="https://handlebarsjs.com/" target="_blank">Handlebars-</a>  und <a href="/wissens-hub/blog/web-anwendungen-mit-node-express-typescript-entwickeln"><span>Node.js-</span></a> <span>Scripten fußten, habe ich diverse kostenlos verfügbare Seitengeneratoren ausprobiert (dies waren u.a. </span><a href="https://hexo.io/" target="_blank"><span>Hexo</span></a> <span>, </span><a href="https://middlemanapp.com/" target="_blank"><span>Middleman</span></a> <span>, </span><a href="https://nuxtjs.org/" target="_blank"><span>Nuxt</span></a> <span>, </span><a href="https://www.sphinx-doc.org/" target="_blank"><span>Sphinx</span></a> <span>, und weitere). Letztlich hängen geblieben bin ich bei </span><a href="https://jekyllrb.com/" target="_blank"><span>Jekyll</span></a> <span>, welches mich nicht zuletzt durch seine einfache Verwendung und Konfigurierbarkeit überzeugt hat.</span></p><p><span>Nachdem ich mich für Jekyll entschieden hatte, musste die zuvor erstellte Vorlage nun noch in das von Jekyll geforderte Templateformat gebracht und sinnvoll zerlegt werden. Dies war dank der Dokumentation und diversen Blogbeiträgen jedoch schnell gemacht und ich konnte damit beginnen, Fotos aus meinen Alben herauszusuchen, welche ich auf meiner Webseite präsentieren wollte. Waren die Fotos ausgewählt und ein Album erstellt, musste ich nur noch über die Jekyll-CLI den Seitengenerator anstoßen und konnte das Ergebnis auf meinen Server hochladen.</span></p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/miQIqnMgR1a59ScTGSGw"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/miQIqnMgR1a59ScTGSGw" alt="Jekyll Template für Fotogalerien" width="700" height="267" /></a> <p>Jekyll Template für Fotogalerien</p></div><p><span>Der zu diesem Zeitpunkt notwendige Arbeitsablauf sah also vor, dass ich zunächst aus den Fotoalben, die in meiner NextCloud lagen, jene Fotos raussuchte, welche ich veröffentlichen wollte. Diese wurden dann in das Jekyll-Projekt kopiert und mit </span><a href="https://imagemagick.org/" target="_blank"><span>ImageMagick</span></a> <span> für den Einsatz im Web präpariert, heißt, sie wurden auf maximal 1024 Pixel Seitenlänge verkleinert, Exif-Daten herausgenommen und für das Web optimiert gespeichert. Anschließend musste händisch eine Albumbeschreibung erstellt werden, die alle Bilder auflistet, welche letztlich in der generierten Ausgabe landen sollten. War dies getan konnte der Generierungsprozess gestartet werden und man war fertig.</span></p><h3><span>Fazit zu Fotogalerien</span></h3><p><span>Fürs Erste war dieser Ansatz hervorragend, da ich nur noch wenig Arbeit mit meinen Galerien hatte. Das Ergebnis war mehr als zufriedenstellend und ich hatte nun die einfache Möglichkeit geschaffen, meine Bilder zu teilen ohne auf mir unbekannte Anbieter und deren Infrastruktur zurückgreifen zu müssen.</span></p><p><span>Was mir bereits beim Erstellen der ersten Galerien auffiel war, dass sich die Schritte, Bilder zu kopieren und präparieren, sicherlich auch noch automatisieren lassen und auch ein Deployment auf meinen Server kein Hexenwerk darstellen würde. Also fing ich an, über eine Lösung nachzudenken, wie ich aus meiner NextCloud heraus die entsprechenden Bilder markieren konnte, die in meinen öffentlichen Galerien landen sollen.</span></p><p><span>Der Weg zur vollautomatisierten Lösung sowie die technische Verknüpfung meines Jekyll-Prozesses mit meiner NextCloud wird im letzten und abschließenden Teil dieser Blogserie behandelt.</span></p>

Fotoverwaltung und Galerien – Teil 2: Statische Fotogalerien

<p><span>In diesem letzten Teil meiner Blogserie zum Thema Fotoverwaltung und Galerien wird es endlich etwas technischer. Nachdem ich beschrieben habe, <a href="/wissens-hub/blog/fotoverwaltung-und-galerien-teil-1-fotoverwaltung">wie ich meine Fotos verwalte</a>  und <a href="/wissens-hub/blog/fotoverwaltung-und-galerien-teil-2-statische-fotogalerien">meine Fotogalerien manuell erzeuge</a> , fehlt noch der letzte logische Schritt: die Automatisierung des gesamten Prozesses. Ansatzpunkt der Automatisierung war der Ort, an dem ich auch den Inhalt meiner Galerien verwalte:</span><span> in meiner NextCloud.</span></p><h2>NextCloud als Bildquelle für die Galerien</h2><p>Zunächst habe ich überlegt, wie man die Fotos am besten markiert, die zusammen in einer Galerie landen sollen. Das Kopieren von Bildern in einen expliziten „Galerie“-Ordner kam von Anfang an aufgrund der redundanten Datenspeicherung für mich nicht in Frage und auch die Verwendung von Verknüpfungen fällt weg, da NextCloud diese nicht verarbeiten kann. Jedoch ist es dank der in NextCloud integrierten Tagging-Erweiterung möglich, Dateien und Ordner mit Schlagworten zu versehen und nach diesen zu Suchen. Mein Ansatz war es also, alle Bilder mit dem Schlagwort „galerie“ zu versehen, welche später veröffentlich werden sollen. Wie bereits <a href="/wissens-hub/blog/fotoverwaltung-und-galerien-teil-1-fotoverwaltung">im ersten Teil</a>  beschrieben, sind die Ordner jeweils mit dem entsprechenden Datum sowie einem Titel der Aktivität versehen, sodass diese als Galerieüberschrift herangezogen werden sollten. Was fehlte, war das Auslesen der einzelnen Ordner bzw. Bilder und das Generieren der Galerien.</p><h3>Auslesen der Bilder</h3><p>Um alle Bilder bzw. ganze Ordner für eine Galerie zu markieren, habe ich das Schlagwort „galerie“ angelegt und mir die entsprechende Id herausgesucht. Die ID ist in der URL zu finden, wenn man im Tag-Bereich der NextCloud das entsprechende Tag als Filter verwendet (siehe Screenshot; hier:  „?dir=9“, ergo ist die Id 9). Die ID wird für die programmatische Suche nach den markierten Elementen benötigt, da eine Suche über den Namen nicht möglich ist. <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/hkSJKG4cRvSC9wwdnYE2"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/hkSJKG4cRvSC9wwdnYE2" alt="Suchergebnisanzeige in NextCloud" width="700" height="509" /></a> </p><p>NextCloud bietet eine WebDAV-Schnittstelle an, über die man auf die gespeicherten Dateien und Ordner zugreifen kann. Das Filtern bzw. Suchen nach Tags ist mittels der WebDAV-API ebenfalls möglich, indem man folgende Anfrage an die NextCloud-Instanz schickt, die als <code>filter-rule</code> die Id enthält, nach der gesucht werden soll:</p>

```
REPORT /remote.php/dav/files/boromir

<?xml version="1.0"?>
<oc:filter-files xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns" xmlns:nc="http://nextcloud.org/ns" xmlns:ocs="http://open-collaboration-services.org/ns">
    <d:prop>
        <d:getcontenttype />
    </d:prop>
    <oc:filter-rules>
        <oc:systemtag>9</oc:systemtag>
    </oc:filter-rules>
</oc:filter-files>
```

<p>Als Antwort erhält man alle Dateien bzw. Ordner, welche der Tag-Id zugeordnet sind und es werden die im Bereich <code><d:prop></code> angegebenen Attribute in der Antwort zurückgegeben. Benötigt man also mehr als nur den <code>contenttype</code>, können in der Anfrage weitere Properties spezifiziert werden. Für unsere Zwecke ist der <code>contenttype</code> aber ausreichend, da wir anhand des <code>contenttype</code> bestimmen können, ob das Element eine Datei oder ein Ordner ist: Handelt es sich um eine Datei, ist der <code>contenttype</code> gesetzt, andernfalls nicht vorhanden bzw. leer:</p>

```
<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns" xmlns:nc="http://nextcloud.org/ns">
    <d:response>
        <d:status>HTTP/1.1 200 OK</d:status>
        <d:href>/remote.php/dav/files/boromir/Pictures/2019.07%20Minas%20Tirith/1.jpg</d:href>
        <d:propstat>
            <d:prop>
                <d:getcontenttype>image/jpeg</d:getcontenttype>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:status>HTTP/1.1 200 OK</d:status>
        <d:href>/remote.php/dav/files/boromir/Pictures/2019.06%20Minas%20Tirith</d:href>
        <d:propstat>
            <d:prop>
                <d:getcontenttype/>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
</d:multistatus>
```

<p>Sollten im Suchergebnis Ordner enthalten sein, möchte ich alle enthaltenen Bilder als Galerie exportieren. Folglich muss jeder Ordner gegen seinen Inhalt ersetzt werden, sodass letztlich eine Liste mit (Bild-)Dateien entsteht. Um den Inhalt der Ordner aufzulösen, wird pro Ordner nochmals eine Abfrage gesendet, die den Inhalt des jeweiligen Ordners abruft. Die Abfrage des Inhalts eines Ordners via WebDAV sieht wie folgt aus:</p>

```
PROPFIND /remote.php/dav/files/boromir/2019.06%20Minas%20Tirith

<?xml version="1.0"?>
<d:propfind  xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns" xmlns:nc="http://nextcloud.org/ns" xmlns:ocs="http://open-collaboration-services.org/ns">
    <d:prop>
        <d:getcontenttype />
    </d:prop>
</d:propfind>
```

<p>Auch hier fragen wir wieder den <code>contenttype</code> ab, da ein Ordner auch weitere Unterordner enthalten kann.</p><h3>Sicherheit und „Datenschutz“</h3><p>Das von mir implementierte Skript, das die Bilder und aus meiner NextCloud extrahiert, benötigt natürlich Zugangsdaten, da die von mir gespeicherten Daten in der NextCloud unter meinem Benutzerprofil hochgeladen wurden. Da mein Benutzer jedoch Zugriff auf sämtliche Daten hat, habe ich eigens für das Skript einen neuen Benutzer mit entsprechend sicherem Passwort angelegt und diesem Benutzer Zugriff auf die Bilder gegeben. Hierdurch kann das Skript zwar meine Bilder durchforsten und herunterladen, diese aber nicht verändern bzw. andere Daten lesen. Auch wenn dies etwas übervorsichtig erscheint, möchte ich an dieser Stelle darauf hinweisen, dass auch im Privaten das Thema Sicherheit nicht vernachlässigt werden sollte. Erneut sei gesagt, dass Phrasen wie „Was habe ich schon zu verbergen?“ oder „Macht nichts, wenn das veröffentlicht wird“ immer mit Vorsicht zu genießen sind.</p><h2>Automatisiert erzeugte Galerien</h2><h3>Herunterladen der Bilder</h3><p>Die Implementierung meines Galerie-Generators habe ich in Node.JS vorgenommen. Die Kommunikation zur NextCloud wird mithilfe einer <a href="https://www.npmjs.com/package/webdav" target="_blank">webdav-Bibliothek</a>  realisiert. Die erste Aufgabe des Skripts ist es, eine Liste der Bilder zu erzeugen, die in der NextCloud als für die Galerie relevant markiert wurden. Da sowohl einzelne Bilder als auch ganze Ordner für Galerien markiert werden können, muss die Liste der direkt markierten Bilder mit den Bildern vereinigt werden, die indirekt über ihren Ordner markiert sind. Anschließend kann diese Liste in ein <a href="https://de.wikipedia.org/wiki/Nested_Sets" target="_blank">Nested Set</a>  umgewandelt werden, die den Namen der Galerie als Schlüssel sowie alle in ihr enthaltenen Bilder als Liste führt:</p>

```
{
    "2019.06 Minas Tirith" => ["1.jpg", "2.jpg", "3.jpg", ...],
    "2017.02 Gondor" => ["faramir.jpg", "gandalf.jpg", ...],
    ...
}
```

<p>Die Zuordnung von Ordnernamen zu Bildern stellt die Grundlage für alle folgenden Operationen dar. Da die Bilder teils sehr groß sind (sowohl in ihrer Dimension als auch Dateigröße) und sich daher nur bedingt bzw. gar nicht für die Verwendung im Web eignen, werden die Bilder nicht nur stumpf heruntergeladen, sondern mithilfe von <a href="https://imagemagick.org/">ImageMagick</a>  auf verschiedene Anzeigegrößen heruntergerechnet (large: 1024x1024px, medium: 512x512px, small: 256x256px). Das Reduzieren der Dateigröße soll nicht nur die Ladezeit der Galerien verringern, sondern auch den <a href="https://www.websitecarbon.com/">CO2-Abdruck der Webseite</a>  reduzieren. Zwar steigt die Geschwindigkeit der Internetanschlüsse stetig und es ist nicht zwingend notwendig, auf ein oder zwei Kilobyte mehr zu achten, dennoch liegt es meiner Meinung nach in der Verantwortung eines jeden Entwicklers, Ressourcen bewusst einzusetzen und diese nicht einfach auszureizen, nur weil sie verfügbar sind.</p><h3>Behandlung von EXIF-Metainformationen</h3><p>Sind die Bilder heruntergeladen und auf kleinere Größen heruntergerechnet, kann der Blick erneut auf das Thema Sicherheit bzw. Datenschutz gelegt werden: Da die Bilder in meiner NextCloud teils direkt von der Kamera kommen, enthalten diese noch EXIF-Informationen, die mitunter Daten enthalten, die so nicht im Web landen sollen. Dies reicht von harmlosen Informationen wie dem Kameramodell bis hin zu Standortdaten. Um diese Meta-Informationen zu entfernen, verwende ich das <a href="https://exiftool.org/">ExifTool</a>  und entferne die Daten über den Befehl <code>exiftool -all= <pfad></code>. Natürlich handelt es sich hier nicht zwingend um „brisante“ oder „sehr persönliche“ Daten, dennoch denke ich, dass je weniger Informationen man im Internet verteilt, desto ruhiger lässt es sich schlafen.</p><h3>Galerien aus der eigenen Feder – ganz automatisch</h3><p>Bis hierher haben wir nun unsere Bilder sortiert, markiert, heruntergeladen und für die Anzeige im Web optimiert. Letztlich fehlt nur noch das Gewand für die Bilder: eine Webseite, die die Bilder präsentiert. Anstatt hier einen eigenen statischen Website-Generator zu implementieren, habe ich bereits früh auf einen bekannten Kandidaten gesetzt: <a href="https://jekyllrb.com/" target="_blank">Jekyll</a> ! Durch den hohen Verbreitungsgrad von Jekyll kann man aus einer Vielzahl an bereits vorgefertigten Templates wählen und diese an die eigenen Bedürfnisse anpassen. Da Jekyll „blog-aware“ ist, nutzen wir dieses Feature und betrachten jede Galerie als einen Blogpost, der ausschließlich aus Bildern besteht. Für den hier beschriebenen Anwendungsfall sieht die (gekürzte) Jekyll-Ordner-Struktur wie folgt aus:</p><ul><li>_layouts/<ul><li>default.html</li><li>galerie.html</li></ul></li><li>gallery/<ul><li>2017.02-gondor/<ul><li>faramir.jpg</li><li>gandalf.jpg</li><li>…</li><li>index.md</li></ul></li><li>2019.06-minas-tirith/<ul><li>1.jpg</li><li>2.jpg</li><li>…</li><li>index.md</li></ul></li></ul></li><li>index.html</li></ul><p>Im <em>_layouts</em>-Ordner befinden sich die wiederverwendbaren Templates für die Startseite sowie für die Galerien. Im <em>gallery</em>-Ordner findet sich für jede Galerie ein eigener Ordner, der sowohl die anzuzeigenden Bilder als auch eine Markdown-Datei enthält, die wiederum den Titel der Galerie enthält, das Header-Bild definiert und eine Liste von anzuzeigenden Bildern vorgibt:</p>

```
---
layout: galerie
title: "2017.02 Gondor"
header-img: "/gallery/2017.02-gondor/faramir.jpg"
images:
- image_path: /gallery/2017.02-gondor/faramir.jpg
  image_path_m: /gallery/2017.02-gondor/faramir_m.jpg
  image_path_s: /gallery/2017.02-gondor/faramir_s.jpg
- image_path: /gallery/2017.02-gondor/gandalf.jpg
  image_path_m: /gallery/2017.02-gondor/gandalf_m.jpg
  image_path_s: /gallery/2017.02-gondor/gandalf_s.jpg
---
```

<p>Durch diese Markdown-Datei weiß Jekyll, welches Layout zum Rendern verwendet werden soll und erzeugt basierend auf den gegebenen Informationen die statische HTML-Datei im konfigurierten Ausgabeordner (Standard: _site). Wird dieser Ordner nun auf einem Webserver platziert, kann die erzeugte Webseite im Browser aufgerufen werden.</p><h2>Fazit</h2><p>Mithilfe von NextCloud lassen sich Fotos ausreichend gut verwalten und organisieren. Dank der vorhandenen WebDAV-Schnittstelle ist es zudem möglich, auf die Daten zuzugreifen und diese im Rahmen automatisierter Prozesse zu verwenden. Im Rahmen dieser Blog-Beteitragsserie wollte ich zeigen, dass auch – oder vielleicht gerade – im privaten Bereich einige Erleichterungen möglich sind. Vor allem aber wollte ich zeigen, wie man sich mit etwas Aufwand und Geduld vorhandene Systeme zunutze machen kann, um daraus schöne Resultate zu generieren, die einem am Ende das Leben sogar einfacher machen. Durch das Markieren von Bildern und anschließend automatisierte Generieren von Galerien kann ich nun schneller und gezielter meine Bilder teilen und verbleibe dabei in meinem kleinen Ökosystem: Ich brauche keinen weiteren Dienstleister als einen Serverbetreiber (sofern dieser nicht bei mir daheim steht) sowie eine Domain, um mit meinen Daten nach Belieben Inhalte zu erzeugen.</p>

Fotoverwaltung und Galerien – Teil 3: Automatisch erzeugte Fotogalerien

<a href="https://astro.build/" target="_blank">Astro</a> stellt sich als „All-in-one Web Framework“ vor, das „designed for speed“ ist. Große Versprechen wie „Pull your content from anywhere“, „Deploy everywhere“ und „Use whatever frontend library you want“ prangen offensiv auf der Startseite. Eine eierlegende Wollmilchsau, die mal wieder durch das Dorf „JavaScript“ getrieben wird oder ein echter „paradigm shift“? Fragt man <a href="https://houston.astro.build/" target="_blank">HoustonAI</a>, eine KI auf GPT-3-Basis, die mit der gesamten Dokumentation zu Astro gefüttert wurde, welchem Zweck das Framework dient, kommt eine klare Aussage: „Content-focused sites such as blogs, marketing sites, portfolios, and more.“ 

Dieser Blogpost fasst die Erkenntnisse zusammen, die bei der Implementierung einer Astro-Seite herausgekommen sind. Das Projekt ist auf <a href="https://github.com/SteKoe/astro.build" target="_blank">GitHub</a> zu finden und wurde auf <a href="https://astro.stekoe.dev/" target="_blank">Vercel deployt</a>.

## Astro-Komponenten
Astro führt als Kernkonzept Astro-Komponenten ein, die die Basis eines jeden Projekts bilden. In Astro-Komponenten wird das HTML-Template der Seiten definiert und kann über Importe anderer Komponenten beliebig komplex verschachtelt werden. Dies ermöglicht bspw. die Wiederverwendung von UI-Elementen und ein Layouting. Die Syntax von Astro-Komponenten erinnert stark an <a href="https://mdxjs.com/" target="_blank">MDX</a> und erlaubt den Import von JavaScript-Bibliotheken sowie die Definition von Properties in der Kopfzeile der jeweiligen Komponente (siehe Beispiel unten). Durch Server-Side Generation (SSG) oder Server-Side Rendering (SSR), werden die Astro-Komponenten letztlich zu statischem HTML verarbeitet und an den Browser des Nutzenden geschickt. Hierbei wird jegliches JavaScript, sofern nicht anders gekennzeichnet, von Astro entfernt.

```mdx
---
import CounterVue from '../components/CounterVue.vue';
import Card from '../components/Card.tsx';

import LayoutWithNav from '../layouts/LayoutWithNav.astro';
---
<LayoutWithNav title="Astro | Dynamic Islands">
    <div class="m-4 mt-96 grid gap-4">
        <div class="text-center">
            Scroll down to reveal!
        </div>
        <div class="mt-96" client:only="vue">
            <Card>
                <CounterVue client:visible>
                    <h1>Hello from Vue! I am lazy loaded!</h1>
                </CounterVue>
            </Card>
        </div>
    </div>
</Layout>
```

### Your content, your way
Da Astro-Komponenten JavaScript-Bibliotheken importieren und diese im Markup verwendet werden können, sind der Fantasie eigenen Inhalt zu verarbeiten wenig Grenzen gesetzt: So kann über <a href="https://nodejs.org/dist/latest-v18.x/docs/api/globals.html#fetch" target="_blank">`fetch`</a> beliebiger Inhalt heruntergeladen werden. Dabei spielt es keine Rolle, ob ein Headless CMS, eine beliebige API oder Markdown herangezogen wird, da die abgerufene Antwort über weitere Bibliotheken verarbeitet und letztlich an das HTML-Template übergeben werden kann. Das folgende Beispiel zeigt dies anhand einer Markdown-Datei, welche von GitHub abgerufen und über die Bibliothek <a href="https://www.npmjs.com/package/marked" taget="_blank">`marked`</a> in HTML gewandelt wird.

```mdx
---
import LayoutWithNav from '../layouts/LayoutWithNav.astro';

import { marked } from 'marked';
const response = await fetch('https://raw.githubusercontent.com/wiki/adam-p/markdown-here/Markdown-Cheatsheet.md');
const markdown = await response.text();
const content = marked.parse(markdown);
---
<LayoutWithNav title="Remote markdown">
    <article set:html={content} style="margin: 1rem" class="prose" />
</LayoutWithNav>
```

### Eine Insellösung: designed for speed, fast-by-default
Das Laden und Rendern von Inhalten stellt jedoch noch kein Alleinstellungsmerkmal dar und Astro steht bekannten Static-Side Generatoren wie <a href="https://www.gatsbyjs.com/" target="_blank">Gatsby</a>, <a href="https://hexo.io/" target="_blank">Hexo</a> oder <a href="https://gohugo.io/" target="_blank">Hugo</a> in dieser Hinsicht in nichts nach. Was hingegen ein Novum ist, wird von Astro „Islands“ getauft: Astro Islands baut auf das Konzept der <a href="https://www.patterns.dev/posts/islands-architecture" target="_blank">„islands archichtecture“</a> auf und erlaubt es, UI-Komponenten jeglicher Art (<a href="https://react.dev/" target="_blank">React</a>, <a href="https://vuejs.org/" target="_blank">Vue</a>, <a href="https://svelte.dev/" target="_blank">Svelte</a>, ...) auf einer Seite zu verwenden. So können bspw. der Header, Footer, die Sidebar und der Hauptinhaltsbereich einer Seite als Inseln betrachtet, die jeweils statisch oder interaktiv gerendert werden. Damit die jeweilige Komponente „hydrated“ wird, also mit JavaScript angereichter und interaktiv gemacht wird, reicht in Astro das Setzen eines Attributs: Im Falle einer React-Komponente ist das `client:only="react"`, für Vue hingegen `client:only="vue"`. Soll eine Komponente erst geladen werden, wenn diese sichtbar wird, dann ist dies mit `client:visible` getan. 

Astro hat also eine „static-by-default“-Strategie und es wird die Annahme verfolgt, dass zunächst alle Komponenten statisch zu rendern sind. Erst durch das explizite Setzen der <a href="https://docs.astro.build/en/reference/directives-reference/#client-directives" target="_blank">client directives</a> werden Teile der Webseite (aka. Islands) zu dynamischen, interaktiven Elementen, die auf dem Client rendern.

```mdx
---
import CounterReact from '../components/Counter.jsx';
import CounterVue from '../components/CounterVue.vue';
---
<CounterReact client:only="react">
    <h1>Hello from React! I am interactive!</h1>
</CounterReact>
<CounterVue client:only="vue" client:visible>
    <h1>Hello from Vue! I am interactive!</h1>
</CounterVue>
```

## Deploy everywhere
Wir sind an dem Punkt angelangt, an dem wir verstanden haben, dass Astro dank seiner Komponenten sowie der Island-Architektur schnell und zuverlässig Inhalts-fokussierte Webseiten generieren kann, welche durch das „static-by-default“-Paradigma „blazing fast“ sind.

Als ein Framework, welches SSR erlaubt, stellt sich letztlich die Frage, wie und wo eine mit Astro entwickelte Seite deployt werden kann. Hierfür bietet Astro eine Vielzahl an <a href="https://docs.astro.build/en/guides/deploy/" target="_blank">Guides</a>. Im Falle von <a href="https://vercel.com" target="_blank">Vercel</a> reicht die Installation des `@astrojs/vercel`-Adapters sowie eine kleine Anpassung in der Astro-Konfiguration, um SSR mit Vercel zu ermöglichen.

> **Learning**: Auch wenn GitHub Pages kein SSR unterstützen, kann eine rein statische Astro-Seite dort gehostet werden. Die <a href="https://docs.astro.build/en/guides/deploy/github/" target="_blank">Anleitung hierzu</a> ist zwar gewohnt detailliert, dennoch sind wir über einen Aspekt gestolpert: Wenn die GitHub Pages als „Deploy from a branch“ konfiguriert sind, werden beim Push auf `gh-pages` alle Resourcen mit Jekyll geparst. Da Astro einen Ordner `_astro` erzeugt und Jekyll-Dateien und Order mit `_` als erstes Zeichen im Namen ignoriert, kann die Seite nicht erfolgreich aufgerufen werden. Hierfür muss im root-Ordner des `gh-pages`-Branches eine leere Datei mit dem Namen `.nojekyll` angelegt werden, um das Bauen mit Jekyll zu unterbinden.

## Fazit
Astro verspricht auf seiner Webseite eine Menge Dinge, die es zu prüfen galt. Durch die hohe Flexibilität durch die Astro-Komponenten sowie einer build-in Island-Architektur können diese Versprechen jedoch gehalten werden. Ein Blick auf den Netzwerk-Traffic im Browser zeigt, dass Astro einiges richtig macht und Entwickler:innen dabei hilft, den Fußabdruck einer Webseite stark zu reduzieren. Dadurch, dass jede Interaktivität explizit gekennzeichnet werden muss, wird man gezwungen sich konkret mit dem Sinn und Ziel einer Island zu beschäftigen und kommt nicht selten zu dem Schluss, dass eine rein statische Implementierung absolut zweckdienlich ist. Mit der Insellösung erreicht Astro also Lichtgeschwindigkeit. Zumindest fast.

Astro – Mit der Insellösung zur Lichtgeschwindigkeit

Gefühlt war es lange still rund um das Frontend-Framework Angular. Echte Innovationen blieben aus und man konnte das Gefühl nicht loswerden, dass Vue.js und React mit all ihren Derivaten den Vorsprung zu Angular uneinholbar weit ausbauen. Doch mit Version 17 hat das Angular-Team im Rahmen einer Keynote die Renaissance des Frameworks öffentlichkeitswirksam ausgerufen. Kein Wunder, denn der einstige Platzhirsch muss sich gegen Frameworks wie Remix oder Next.js durchsetzen. Diese haben sich stark am Markt positioniert und überzeugen durch ihre hohe Feature-Dichte sowie „Developer Experience“; und nicht zuletzt durch den Hype, der nicht selten in wellenartiger Form durch die JavaScript-Community schwappt. Mit „the next big thing“ wurde zuletzt seitens Next.js die Grenze zwischen Server- und Clientseite noch stärker verwässert. In den sozialen Medien ist von der Wiederbelebung der Skriptsprache PHP die Rede (die nie weg war und immer noch gut 75 % der Webseiten betreibt) und von SQL-Queries im Frontend. „Anarchie!“, oder „Back to the roots!“, möchte man schreien, doch soll dies nicht Thema dieses Artikels sein.\nAngular hat einiges aufzuholen. Damals™, als die inhärenten Performance-Probleme von AngularJS so gravierend wurden, hat man sich bei Google dazu entschieden, das Framework von Grund auf neu zu denken und zu implementieren. Dank der starken Strukturierung mittels Konzepten wie Komponenten, Pipes, Modulen, Services, etc. sowie dem Aufsatz von TypeScript als Basis fühlte sich das Entwickeln von Webanwendungen nicht mehr „hacky“ an. Angular hatte es geschafft, dass Webanwendungen “enterprisy” wurden und gleichzeitig die „Developer Experience“ signifikant verbessert wurde.\nWas damals „fancy“ und „awesome“ war, wird heute jedoch vermehrt als einengend und behäbig wahrgenommen. Viele Schritte, die bei der Implementierung von Angular-Applikationen notwendig sind, fühlen sich zu starr an und hinken im Vergleich zu React und Vue.js weit hinterher. Und vom Server-Side Rendering (SSR) wollen wir an dieser Stelle gar nicht sprechen.\nDoch mit Angular 17 wird alles anders, ja, besser als es jemals war! Das Team rund um das Framework hat versprochen, wieder mehr Traktion in die Weiterentwicklung bekommen zu haben und dies in Form einer Keynote präsentiert, welche im Folgenden einmal (inklusive Einwürfen aus dem Chat) kommentiert wird.\nAlles neu macht der November\nDie Zeitenwende unterstreicht das Angular-Team mit dem Redesign der Marke „Angular“. Sie kommt ab sofort in peppigen Farben daher und wirkt fast wie die Corporate Identity von Adobes Creative Cloud. Das neue Corporate Design von Angular trifft den aktuellen Zeit- und Designgeist und steht somit den konkurrierenden Frameworks in nichts nach. Passend zum Redesign wurde unter der URL \nhttps://angular.dev\n ein komplett neu gestalteter Auftritt gelauncht, der nicht nur eine von Grund auf neu geschriebene Dokumentation mit neuen Tutorials, Essentials sowie einem Angular Playground beinhaltet, sondern auch einen Dark Mode vorweisen kann. Abgesehen davon, dass in der Vorstellung reichlich viel Aufmerksamkeit auf den Dark Mode gelegt wurde, wirkt der Auftritt leichtgewichtig und frisch. Das Team rund um Angular wirft also nicht nur mit Worthülsen um sich, sondern tischt richtig auf, bekennt sich zum Open Source-Gedanken („We love open source“) und betont den Fokus auf Performance sowie Developer Experience, was sie unter anderem in den folgenden Punkten unter Beweis stellen.\nSSR & Hydration\nMit Version 17 holt Angular die Funktionalitäten rund um Server-Side Rendering sowie Hydration in die native Angular CLI, sodass kein Umweg mehr über Angular Universal Pakete mehr notwendig ist. Man hat erkannt, dass SSR mittlerweile einen \nwesentlichen Aspekt\n bei der Auswahl eines Frameworks darstellt. Mit dem Flag --ssr lassen sich nun Apps erstellen, die von Hause aus bereits Server-Side Rendering aktiviert haben, außerdem ist Hydration grundsätzlich immer mit an Board. Mit der neuen Angular Version sind SSR und Hydration als „production-ready“ ausgerufen worden. Dies ist ein überfälliger Schritt, da Next.js oder Nuxt hier bereits die Nase vorn haben. Dennoch verspricht auch hier das Team hinter Angular erneut, dass ein Hauptaugenmerk auf Performance gelegt wurde, sodass die Build-Zeit für Server-Bundles reduziert sowie der SSR-Dev-Server schneller läuft.\nNeben den bereits implementierten Features wurden jedoch auch weitere Punkte genannt, an denen noch gearbeitet wird und die in folgenden Versionen zu erwarten sind. So nimmt sich das Team eine erweiterte Kompatibilität zu Nicht-Node.js-Umgebungen vor. Progressive Hydration sowie HTTP-Streaming stehen ebenso auf der Agenda wie die Verbesserung der Developer Experience rund um parametrisierte Routen.\nNew control flow syntax\nAls Randnotiz ist die fortschreitende Integration von Signals in Angular zu vermerken. Hier wird aktuell die API „glatt gezogen“ und an der „zoneless experience“ gearbeitet. Eine totale Abkehr von Observables und Rxjs wird es jedoch so bald nicht geben. Die Empfehlung lautet weiterhin, dass für einen Stream von Events (bspw. Websockets) Observables die richtige Wahl sind und Komponent-State über Signals abgebildet werden sollte, da letztere eine feingranulare Kontrolle des States erlauben und gleichzeitig leichtgewichtiger daher kommen.\nDurch Einflussnahme der Angular-Community („The star-syntax is not well understood and quirky“ oder auch „imports of NgIf and NgFor are annoying“) sowie der Umstellung auf Signals wurde die Kontrollflusssyntax umgekrempelt. Zwar funktionieren die altbekannten Direktiven ngIf oder ngFor weiterhin wie gewohnt, jedoch wird eine neue, alternative Syntax angeboten, die wesentliche Verbesserungen in Darstellung, Fehlerhandling sowie Performance umsetzt. Letzteres wird durch die Implementierung der Syntax in Angular-Core erreicht, sodass diese nicht mehr wie ngFor oder ngIf über die Angular public API funktionieren, sondern auf low-level-APIs zurückgreifen können und somit den Call-Stack erheblich reduzieren. Gerade for-loops können laut Aussage des Teams bis zu 90 % schneller sein.\nngIf wird zu @if\nNeben einem \nelse\n-Zweig wurde der neuen Kontrollflusssyntax auch ein\n else if \nspendiert:\n<section>
    @if (user.loggedIn) {
        <app-dashboard />
    } 
    @else if(user.role === ‘admin’) {
        <app-dashboard />
        <app-admin-controls />
    } 
    @else {
        <app-login />
    }	
</section>\nngFor wird zu @for\nWas bisher als best-practice bei ngFor galt, ist nun Pflicht: die Angabe von track. Allein hierüber ist es Angulars Change Detection möglich, einiges an Performance-Boost herauszuholen. Zwischen den Zeilen hört man die marketing-wirksame Zahl von 90 % Geschwindigkeitszuwachs. Jedoch wird im direkten Interview bei „control flow heavy components“ eher von 30 % schnellem Rendering gesprochen.\n<section>
    @for (user of userList; track user) {
        <app-card [data]="user" />
    } 
    @empy {
        <p>There were no items in the list</p>
    }
</section>\nngSwitch wird @switch\nAuch NgSwitch kann durch die neue Syntax ersetzt werden. Viel geändert hat sich hier jedoch nicht. Es gibt weiterhin kein „fall-through“, sodass ein break oder return nicht notwendig ist.\n<section>
	@switch (condition) {
	   @case (caseA) {
	     <app-component-a />
	   }
	   @case (caseB) {
	     <app-component-b />
	   }
	   @default {
	     <app-component-c />
	   }
	}
</section>\nDeferred loading\nDeferred loading (oder auch lazy loading, aber das Angular-Team sagt „we prefer \ndefer\n“) ist ein alter Hut und wird spätestens seit Version 15 unterstützt. Mit Version 17 wurde jedoch auch hier einiges neu gedacht und neu gemacht: Dank der neuen Control-Flow-Syntax ist es nun möglich, im Template einen Block mit dem Namen \n@defer\n zu definieren, der je nach übergebener Konfiguration den Inhalt nachlädt. In Kombination mit \n@placeholder, @loading \nund \n@error \n(siehe Code weiter unten) lassen sich tatsächlich gut lesbare Template-Strukturen abbilden. Jeder dieser Blöcke, so wird stets betont, läuft non-blocking. Heißt also, dass alle Komponenten, die nicht in einem \n@defer-\nBlock enthalten sind, sofort gerendert werden. Spannend an dieser Stelle ist zu erwähnen, dass gerade das Thema Testing hervorgehoben wurde und man über TestBed geeignete APIs aufrufen kann, die das Abtesten der einzelnen \n@defer-\nBlöcke zulassen.\n<section>
	…
	@defer (on viewport)  {
		<large-component />
	}
	<huge-component />
	<enormous-component />
	…
</section>\nCustom Triggers\nLade Komponenten entweder, wenn sie in den sichtbaren Bereich gescrollt werden oder aber, wenn ein expliziter Trigger gesetzt wird. \n<section>
	<button #trigger (click)=”load=true”>
		Load Component
	</button>

	@defer (on viewport(trigger); when load == true) {
	 <large-component />
	}
</section>\nPrefetch\nLade die Komponente asynchron im Hintergrund: \n<section>
	…
	@defer (prefetch on immediate; 
  prefetch when val === true)  {
		<large-component />
	}
	…
</section>\nPlaceholder, Loading and Error\nDie Verwendung von \n@defer\n erlaubt die Kombination mit \n@placeholder\n für die Anzeige einer leichtgewichtigen Komponente, die als Platzhalter gerendert wird. \n@loading \nwiederum erlaubt das Einbinden einer Komponente,die während des Ladevorgangs gerendert wird. Sollte die in\n @defer \neingebundene Komponente nicht ohne Fehler geladen werden, kann über \n@error\n ein Fehler angezeigt werden.\n<section>
	<button #trigger>...</button>

	@defer (on interaction(trigger)) {
		<recommended-movies />
	} 
	@placeholder (minimum 500ms) {
		<img src=”placeholder.png”/>
	} 
	@loading (after 500ms; minimum 1s) {
		<spinner />
	} 
	@error {
		<p>Oops, something went wrong.</p>
	}
</section>\nEasier to use: Standalone components\nDas bisherige Manko einer kleineren Angular-Applikation war das Management des App Modules und das Anreichern um neue Komponenten oder Pipes. Seit Version 17 ist dies nicht mehr zwingend erforderlich, da sie Standalone by default sind. Das mag zwar auf den ersten Blick nicht gravierend erscheinen, ist aber in Kombination mit den Self-Closing Tags aus Version 16 ein echter Gewinner und hilft dabei, schöne und wartbare Komponenten zu erstellen. Mit dem nächsten Schritt, der Öffnung für Esbuild und Vite, werden weitere Konstanten des Angular-Systems (Webpack) angezählt. Nicht zuletzt durch SSR, sondern auch die generell langsame Build-Zeit wurden bereits in der vergangenen Version Vorbereitungen getroffen, Vite und Esbuild in der CLI-Build-Pipeline einzusetzen. Mit Version 17 sind diese auch nicht mehr Bestandteil der Developer Preview, sondern Standard im Toolset. Im Zuge der Umstellung erzeugt die Build-Pipeline nun ESM-Module und aktiviert die Hydration von Haus aus. Dennoch wurde auch Wert darauf gelegt, dass Webpack und somit bestehende Umgebungen weiterhin funktionieren, wobei klar kommuniziert wird, dass dies nicht mehr empfohlen wird.\nSumma summarum\nAngular 17 ist ein spannendes und wegweisendes Release des Frameworks, das zeigen kann und muss, ob die angekündigten Änderungen signifikanten Einfluss auf die Developer Experience haben und die Lücke zu anderen Frameworks schließen oder zumindest verkleinern kann. Sollte auch nur ansatzweise die Build-Zeit erheblich beschleunigt werden (bis zu 90 % wird vielfach genannt), ist eine wesentliche Verbesserung in Kombination mit schnellerer (testgetriebener) Entwicklung von Komponenten zu erwarten. Was durch die Keynote definitiv erreicht wurde, ist Fokus und eine Reihe von großen Versprechen in die Runde aller Webentwickelnden. Davon abgesehen wurde auch ein nicht zu vernachlässigender Hype erzeugt, der sich in Form von Diskussionen, Beiträgen, positiven wie negativen Kommentaren und weiteren Äußerungen manifestiert. Kurzum: Angular hat es geschafft, wieder von sich reden zu machen und die Roadmap für die Zukunft auszurollen.\n

Angular 17 – Eine echte Renaissance?

Usability (UX) und Accessibility (A11y) spielen im Rahmen der E-Mobilität eine ebenso wichtige Rolle wie die Verfügbarkeit von Ladestationen, die Preisgestaltung der E-Autos sowie die Stromkosten für einzelne Ladevorgänge. Studien zeigen [^1], dass die Tendenz, in Deutschland ein E-Auto zu erwerben aufgrund weiterhin vorherrschender Vorbehalte, sinkt. Neben den dort genannten Punkten ist eine auch in anderen Ländern präsente Problematik relevant: das Laden von Elektroautos bzw. die Bedienung der Ladestationen. Dies ist in vielen Fällen kompliziert und fehlerbehaftet[^2],[^3]. Wie Rufo in seinem Artikel [^4] schreibt, sind der “einfachere Zugang” sowie das “fehlerfreie, reibungslose Ladeerlebnis zwei wesentliche Schlüssel zur Akzeptanz von Elektrofahrzeugen”, die es zu adressieren gilt. Auch wenn die codecentric AG nicht im Bereich des Produktdesigns und der Produktentwicklung angesiedelt ist, so steht sie für die Beratung und Entwicklung qualitativ hochwertiger Software. Dabei wird der Fokus auf die Lösung des gegebenen Use Case gelegt [^5] und der Endnutzer nicht aus den Augen verloren.

## Usability und Softwarequalität – ein Game-Changer

In Zusammenarbeit mit unserem ausgegründeten Unternehmen UX\&I [^6] werden nutzungszentrierte Lösungen in Form von Bedienelementen und Oberflächen erarbeitet, die sich nicht an künstlichen Use Cases abarbeiten sondern reale “User Flows” aufnehmen und digital abbilden. Durch die Anwendung etablierter UX-Praktiken werden hierbei bereits viele Einstiegshürden für Nutzende genommen. Neben Usability-Vorgaben und der Fragen ergeben sich oftmals technische Herausforderungen, die auf einer anderen Ebene abgehandelt und geklärt werden müssen. Ladestationen kommunizieren mit einem CSM-System (Charging Station Management System) über das Internet und nutzen hierfür nicht selten Mobilfunk-Systeme. Das heißt, dass als mögliche Fehlerquellen auch technische Aspekte berücksichtigt werden müssen, wie beispielsweise Verbindungsprobleme oder Kommunikationsfehler zwischen Station und CSMS – und das möglichst transparent für die Anwendenden. Die sichert das Ziel, ein E-Auto beschwerdefrei zu laden. Hier ist neben einem obligatorischen Usertest mit einer real existierenden Ladestation auch das Testen der Software auf den bekannten Ebenen der Testpyramide relevant. Gerade an diesem Punkt ist Softwarequalität entscheidend wichtig. Der Umgang mit erwarteten, aber auch unerwarteten Fehlern, die bei der Benutzung auftreten können, hat entscheidenden Einfluss auf das Ladeerlebnis der Nutzenden. So sollte die Station in der Lage sein, Fehler selbständig zu beheben oder Lösungen implementieren, die nicht auf den Nutzenden zurückfallen. Sollte dennoch eine Interaktion notwendig sein, müssen die Fehlermeldungen so gut sein, dass die nutzende Person diese selbstständig lösen kann.

## Robuste EV-Software durch automatische Tests

Im Software-Engineering allgemein, aber auch in den Projekten der codecentric AG hat sich gezeigt, dass eine solide Test-Basis auf verschiedenen Ebenen grundlegend positive Auswirkungen auf die Qualität der implementierten Software hat. Durch die Anwendung der bekannten Testebenen wie Unit-, Integration- und System-Tests wird auf verschiedenen Flughöhen sichergestellt, dass einzelne Aspekte des Gesamtsystems in sich funktional sind und unter den im Test gegebenen Annahmen die erwarteten Ergebnisse liefern. Doch genau an dieser Stelle tut sich eine Lücke auf: Wie testet man das Zusammenspiel zwischen der existierenden Software und einer Ladestation? Es erscheint nicht zuletzt aus finanziellen Gesichtspunkten unpraktikabel, für integrative Tests eine dedizierte Ladestation aufzubauen. Zudem muss die Station für bestimmte Fehler-Konstellationen (fern-)gesteuert werden und der Zustand angepasst werden können. Hier bietet sich der Einsatz von simulierten Ladestationen an. Eine simulierte Umgebung bietet viele Vorteile, da sie skalierbar ist, diverse Fehlerfälle abbildet und bei Bedarf schnell wieder entfernt werden kann. Überdies kann eine simulierte Ladestation bereits neuere Standards des offenen Protokolls “OCPP” (Open Charge Point Protocol) implementieren und die Funktionsfähigkeit bzw. Kompatibilität der Softwarelösung zum gegebenen Standard überprüfen. Das Warten auf Software-Updates der einzelnen Hersteller von Ladesäulen entfällt und man kann frühzeitig anfangen, gegen das neue Protokoll zu entwickeln. Durch die Möglichkeit, in Integrationstests die simulierte Station nach Belieben zu steuern, können außerdem diverse Szenarien fest implementiert und automatisiert abgetestet werden. Regressionen sind hierdurch nahezu ausgeschlossen.

Neben der automatisierten Ansteuerung der Ladestationen kann der Simulator auch verwendet werden, um Demo-Systeme (bspw. für Lade-Apps, CSM-Systeme) oder interne Entwicklungsszenarien darzustellen, ohne auf real existierende Stationen angewiesen zu sein. So simuliert die virtuelle Ladestation in diesem Fall nicht nur deren Existenz, sondern kann auch Ladevorgänge starten, stoppen und Zählerstände eines fiktiven Stromzählers senden und vieles mehr. Hierdurch wird auch die Möglichkeit geschaffen, Rechnungslegungprozesse anzustoßen und zu testen.

## Der codecentric-Ansatz

Der Electric Vehicle Charging System Simulator (EVCSS) der codecentric AG, bietet genau für diesen Fall einen passenden Ansatzpunkt: Ein System, das Ladestations-Verhalten simulieren kann und über eine API fernsteuerbar ist. Hierdurch ist es möglich, für automatisierte Integrationstests eine vorkonfigurierte Ladestation anzulegen, Interaktionen an der Station zu simulieren und den Zustand der Ladestation abzufragen. Durch dieses Zusammenspiel kann in Tests von CSM-Systemen oder CSMS-nutzenden Applikationen verifiziert werden, dass Fehlerkonstellationen korrekt abgefangen und so behandelt werden, dass dem letztlich Nutzenden eine sinnvolle Verwendung des gesamten Systems ermöglicht wird.

## Fazit

Der Einsatz von simulierten Ladestationen kann einen wesentlichen Baustein in der Entwicklung robuster und nutzerzentrierter Ladeinfrastruktur darstellen, ohne dabei hohe Anschaffungskosten echter Hardware in Kauf nehmen zu müssen. Natürlich ist simuliertes Verhalten nur ein Teil des Gesamtbildes und sollte nicht als Allheilmittel verstanden werden, da der Test unter echten Bedingungen weiterhin im Fokus bleiben muss. Dennoch können auftretende Probleme über den Simulator nachgebildet und automatisiert abgetestet werden, sodass diese zukünftig nicht mehr auftreten können oder eine entsprechende Fehlerbehandlung existiert. Durch den Einsatz simulierter Ladestationen in Kombination mit der Durchführung automatischer Testszenarien kann die Akzeptanz im Bereich E-Mobilität durch robuste Software und einfache Bedienkonzepte erhöht werden. Nicht nur die E-Autos müssen überzeugen, sondern auch ein durchweg positives Erlebnis durch hervorragende Software ermöglicht werden.  

[^1]: [https://www.zdf.de/nachrichten/wirtschaft/e-autos-kauf-beliebtheit-umfrage-100.html](https://www.zdf.de/nachrichten/wirtschaft/e-autos-kauf-beliebtheit-umfrage-100.html)
[^2]: [https://www.greencarreports.com/news/1140533\_study-1-in-5-ev-charging-attempts-fails](https://www.greencarreports.com/news/1140533_study-1-in-5-ev-charging-attempts-fails)
[^3]: [https://umu.diva-portal.org/smash/get/diva2:1783054/FULLTEXT01.pdf](https://umu.diva-portal.org/smash/get/diva2:1783054/FULLTEXT01.pdf)
[^4]: [https://uxdesign.cc/the-future-of-ev-charging-2bc6d4a800cd](https://uxdesign.cc/the-future-of-ev-charging-2bc6d4a800cd)
[^5]: [https://www.codecentric.de/referenzen](https://www.codecentric.de/referenzen)
[^6]: [https://www.uxi.de/](https://www.uxi.de/)	

Simulation von Elektro-Ladestationen

# Spring Boot Admin - Wrap Up
Nach über 10 Jahren seiner Existenz möchten wir in diesem Blogpost die Geschichte des Spring Boot Admin beleuchten und Hintergründe über die aktuelle Entwicklung geben. Wie hat alles angefangen? Was war die Motivation? Wo kommt das Werkzeug her? Wie sieht die Entwicklung aus? Was ist der aktuelle Stand? Und: Warum tun wir das Ganze überhaupt?
## Wo kommen wir her?
Wie im Blog-Artikel "Spring Boot Admin"[^1] zu lesen, hat im Jahre 2014 die Geschichte des Spring Boot Admin angefangen. Im Zuge eines Kundenprojekts entstand die Notwendigkeit, die neu entwickelten Micro Services, basierend auf Spring Boot, zu administrieren und teilweise zu überwachen. Die damals implementierten Funktionen sind bis heute relevant, beispielsweise die Möglichkeit, das Log-Level von Anwendungen zu ändern, welche weiterhin ein integraler Bestandteil des Tools ist. Die anfängliche Übersicht aller installierten Anwendungen mit Versionsnummern, Status, JVM-Details, Log-Dateien und Log-Leveln[^1][^2] hat sich mittlerweile zu einer nahezu vollständigen Unterstützung der von Spring Boot angebotenen Actuator-Endpunkte weiterentwickelt. Mit Ende des Jahres 2014 und dem Release der Version 1.1.0[^3], welches Spring Boot 1.2.0 unterstützte (lang, lang ist's her), wurde das Jahr der Grundsteinlegung beschlossen.
## Der Aufstieg
In den folgenden Jahren verzeichnete das Projekt einen starken Gewinn an Popularität, was sich in der steigenden Anzahl von Stars und Forks auf GitHub widerspiegelte. Insbesondere die kontinuierliche Weiterentwicklung durch regelmäßige Releases, sowie die Einführung neuer Funktionen und Verbesserungen haben zu dieser Popularität beigetragen. Heute findet das Tool weltweit Anwendung, beispielsweise bei der Post in Brasilien, Banken in Norwegen, Fluggesellschaften in der Türkei, diversen Unternehmen in Deutschland und vielen anderen. 
Durch die Zusammenarbeit von Josh Long und Johannes Edmeier vor Ort im Hauptquartier der codecentric AG in Solingen, ist das Tool seit 2018 im Spring Initializer ([start.spring.io](https://start.spring.io/#!dependencies=codecentric-spring-boot-admin-server)) gelistet, wodurch es nicht selten schon während des Setups eines Spring Boot-Projekts berücksichtigt wird.

Im März 2018 und dem Release von Spring Boot 2 wurde die Architektur des Spring Boot Admin neu gedacht und das Frontend auf eine moderne Plattform mit Vue.js gehoben. Wir haben veraltete Features im Backend ersetzt oder entfernt, neue Features integriert und die Benutzeroberfläche modernisiert. Bis zu diesem Zeitpunkt verzeichnete das Repository bereits knapp 5700 Stars mit über 200 gemeldeten Issues, an denen wir regelmäßig arbeiteten. Durch die Nutzung des Spring Cloud DiscoveryClient wurde die Flexibilität des Spring Boot Admin zusätzlich erhöht. Dieser ermöglicht die Integration unterschiedlicher Plattformen (wie bspw. Kubernetes, Eureka, Zookeeper und weitere), wodurch das Tool noch vielseitiger und anpassungsfähiger für verschiedene Systemlandschaften wird.
## Die Fortentwicklung
Am Ende des Jahres 2020 stellte sich das Team rund um Spring Boot Admin neu auf, da die Kolleginnen und Kollegen, die bis dato das Werkzeug entwickelt hatten, das Unternehmen verlassen haben und eine Weiterentwicklung sonst nicht gewährleistet werden konnte. Durch die Restrukturierung ist es uns gelungen, auch nach 2020 weiterhin regelmäßig Updates mit neuen Features liefern zu können und sogar die Produktivität bezüglich der Abarbeitung von Issues zu steigern. Dies zeigt sich durch einen Anstieg der Stars, nachdem diese Kurve vorher stark abgeflacht war. Unsere Bemühungen trugen auch dahingehend Früchte, dass Microsoft mit seinem Cloud Dienst Azure Spring Boot Admin als Werkzeug in sein Repertoire aufgenommen hat[^4].

Zwischenzeitlich, nämlich am 24. November 2022, wurde Spring Boot in Version 3 veröffentlicht. Bereits frühzeitig haben wir als Team mit Vorab-Versionen des Frameworks, an der Kompatibilität des Werkzeugs gearbeitet und konnten am Anfang des kommenden Jahres eine kompatible Version freigeben. Wie auch bei der Veröffentlichung von Spring Boot Admin 2 haben wir nicht nur im Backend notwendige Updates und Anpassungen vorgenommen, sondern auch wieder der UI ein neues Aussehen verpasst und verwendete Upgrades von Frameworks umgesetzt.
## Motivation
Als Idee zur Überwachung und Steuerung von Spring Boot Applikation gestartet, ist Spring Boot Admin mittlerweile ein herausstechendes Open Source-Projekt bei der codecentric AG geworden. Bei vielen unserer Kunden setzen wir Spring Boot als Framework ein und haben uns somit selbst die Möglichkeit geschaffen, die von uns implementierten Services zu überwachen. Aus dem anfänglichen Gedanken der 'Hilfe zur Selbsthilfe' entstand der Idealismus, der Community etwas zurückzugeben. Durch unsere langjährige Erfahrung in der Entwicklung mit Spring Boot in diversen Kontexten, können wir dieses Werkzeug selbstbewusst frei zur Verfügung stellen. Natürlich steht diesem Idealismus auch ein praktischer Nutzen gegenüber: Wir beschäftigen uns frühzeitig mit neuen Spring Boot-Versionen und können so Migrationspfade, Hindernisse, Herausforderungen und Best Practices identifizieren, die wir später an unsere Kunden weitergeben können.
## Wie geht es weiter?
Die Adoptionsrate des Tools und die Möglichkeit, stets am Zahn der Zeit zu bleiben, motivieren uns, dieses Tool weiterzuentwickeln. Aktuell sind wir weiterhin bemüht, ein stabiles Werkzeug anzubieten und gleichzeitig mit neueren Versionen von Spring Boot weitere Funktionen einzubauen. Auch wenn es noch kein Releasedatum oder gar eine Ankündigung von Spring Boot 4 gibt, werden wir wie gewohnt in regelmäßigen Abständen Releases des Tools zur Verfügung stellen und die aktuellen Spring Boot Versionen unterstützen.
## Ein Dankeschön!
An dieser Stelle möchten wir uns bei Thomas Bosch, Dennis Schulte und Johannes Edmeier bedanken, die die initiale Idee für dieses Werkzeug hatten und es als Open Source-Projekt innerhalb der codecentric AG etabliert haben. Natürlich geht das Dankeschön auch an die Community, also an euch, die dieses Werkzeug aktiv benutzen, denn ohne euch gäbe es keine Grundlage für die Fortentwicklung des Tools.
Wir, das sind Erik Petzold, Ulrich Schulte, Andreas Fritz, Timo Kockert und Stephan Köninger, freuen uns darauf, euch weiterhin mit Releases versorgen zu dürfen und die Open Source-Welt mitgestalten zu können. 

[^1]: [Spring Boot Admin](https://www.codecentric.de/wissens-hub/blog/spring-boot-admin-2)  

[^2]: [Spring Boot Admin - First official release1](https://www.codecentric.de/wissens-hub/blog/spring-boot-admin-first-official-release)

[^3]: [Spring Boot Admin 1.1.0 - New Release is out](https://www.codecentric.de/wissens-hub/blog/spring-boot-admin-1-1-0-new-release-amazing-new-features)

[^4]: [Azure und Spring Boot Admin](https://learn.microsoft.com/de-de/azure/container-apps/java-admin?tabs=azure-cli)


Spring Boot Admin - 10 Jahre Wrap Up

Server Side Rendering (SSR) und Static Side Generation (SSG) sind Begriffe, die in der Webentwicklung aktuell immer wieder auftauchen. Aber was bedeuten sie eigentlich und warum werden sie gerade jetzt wieder relevant, obwohl wir sie in Zeiten von Single Page Applications (SPA) nicht brauchen? Zudem fühlt es sich an, als würde eine altbekannte Technik in neuem Gewand durch das Dorf getrieben werden. PHP, ich hör dir trapsen!

## Die Ära der statischen Webseiten (bis ca. 2005\)

Damals™, in den Anfangstagen des Internets, waren Webseiten statische, unveränderliche Dokumente. Das bedeutete, dass jede Seite als HTML-Datei auf einem Server abgelegt, von einem Browser abgerufen, interpretiert und angezeigt wurde. Zu jener Zeit war die semantische Bedeutung der HTML-Tags auch noch dem Gros der Entwickelnden bekannt (Spoiler: semantisches HTML ist und war schon immer relevant\!). Gegen Ende der 90er, mit dem Aufkommen von DHTML (Dynamic HTML: CSS und JavaScript), wurden Webseiten zunehmend dynamischer und grafisch aufwändiger. Diese Ära war geprägt von HTML-Seiten, die oft mit Tabellen als Layout-Elemente und CSS für das Styling erstellt wurden. Die Interaktivität war noch minimal und wurde hauptsächlich durch serverseitige Skripte wie PHP oder Perl realisiert.

## Der Aufstieg von AJAX und dynamischen Webanwendungen (2005-2010)

Ein Wendepunkt war das Jahr 2005, als Google Maps veröffentlicht wurde und die Transition hin zu Web 2.0 manifestierte. Google Maps demonstrierte eindrucksvoll, wie AJAX (Asynchronous JavaScript and XML) genutzt werden konnte, um dynamische Inhalte zu laden, ohne die gesamte Webseite neu aufbauen zu müssen. Das war der Beginn einer neuen Ära in der Webentwicklung, in der Benutzererfahrung und Interaktivität im Vordergrund standen. In den folgenden Jahren wurde AJAX immer populärer und ermöglichte die Entwicklung von dynamischen Webanwendungen. Frameworks wie jQuery erleichterten die Arbeit mit AJAX erheblich und trugen zur Verbreitung dieser Technik bei. Erst mit dem Aufkommen von Single-Page-Frameworks verlor u.a. jQuery an Bedeutung und eine professionalisierte Entwicklung von Webanwendungen nahm Fahrt auf.

## Die Ära der Single-Page-Applications (SPAs) (ab 2010\)

Der Aufstieg von SPAs begann etwa ab dem Jahr 2010\. Mit dem Aufkommen leistungsfähiger JavaScript-Frameworks wie AngularJS (2010), React (2013) und Vue.js (2014) wurde es möglich, komplexe Anwendungen zu entwickeln. Spätestens jetzt wurde deutlich, dass der Web 2.0 Ansatz, das Internet als Plattform zu betrachten, eingeschlagen war.  
SPAs laden einmal die Grundstruktur der Anwendung und aktualisieren dann dynamisch den Inhalt (genauer: das DOM) über AJAX-Anfragen. Das führte zu einer deutlich geänderten Benutzererfahrung, da Seitenwechsel schneller, flüssiger und vor allem ohne sichtbarem Neuaufbau realisiert wurden. In den letzten 15 Jahren hat sich die SPA-Entwicklung naturgemäß erheblich weiterentwickelt, und moderne Frameworks bieten neuere und ausgefeiltere Funktionen wie serverseitiges Rendering (SSR) und statische Seitengenerierung (SSG), um die Leistung und SEO weiter bzw. wieder zu verbessern. Doch warum geht man nun einen Schritt zurück? SPAs laufen ausschließlich auf dem Client (im Browser) und entlasten somit Server, warum also dieser Turn-Around? Mit SPA war doch alles schön und gut oder etwa nicht?

## Was ist SSR und SSG?

Beim Server Side Rendering (SSR) wird der Inhalt einer Webseite nicht im Browser des Benutzers, sondern bereits auf dem Server generiert. Der Browser erhält dann eine fertig (vor-)gerenderte HTML-Seite. Das war früher die gängige Methode, bevor JavaScript-basierte Single-Page-Applications (SPAs) populär wurden und wird auch heute noch von vielen CM-Systemen wie Wordpress oder Typo3 implementiert.

Sowohl SSR als auch SSG generieren Inhalte statisch vor und reduzieren somit die initiale Ladezeit, da hier klassische Caching-Machanismen auf dem Server greifen können. Der wesentliche Unterschied zwischen SSR und SSG liegt im Zeitpunkt der Generierung: Bei SSR wird die HTML-Seite bei jeder Anfrage dynamisch auf dem Server generiert. Das bedeutet, dass der Server jedes Mal, wenn ein Benutzer eine Seite anfordert, die Daten abruft und das HTML-Dokument neu zusammenstellt. SSG hingegen generiert die HTML-Seiten während des Build-Prozesses, also einmalig. Die statischen HTML-Dateien werden dann auf einem Server gespeichert und bei jeder Anfrage unverändert ausgeliefert. SSG eignet sich besonders gut für Webseiten mit Inhalten, die sich selten ändern (Blogs, Wiki, Zeitungsartikel,…). SSR hingegen ist ideal für dynamische Inhalte mit hoher Benutzerinteraktion und vom Nutzenden erstellen Inhalten bzw. Inhalten, die sich im zeitlichen Verlauf sekündlich ändern können. Nimmt man es genau, sind PHP-basierte Webseiten dem SSR zuzuordnen, da hier bei jedem Aufruf das PHP-Skript erneut ausgeführt wird und die Daten an den Client schickt.

## Die Renaissance von SSR

Dass SSR ein wiederaufgelebtes Thema in der Webentwicklung ist, lässt sich auf mehrere Schlüsselfaktoren zurückführen: Unter anderem ist die Performance von SSR-basierten Anwendungen besser gegenüber den Applikationen, die mit SPA-Frameworks erstellt werden. Moderne SSR-Frameworks nutzen etablierte Caching-Strategien und Edge-Computing, um schnelle Ladezeiten zu gewährleisten. Das bedeutet, dass Benutzer Webseiteninhalte schneller sehen (First Contentful Paint (FCP)) und interagieren können. Außerdem ist SSR ideal für Suchmaschinenoptimierung (SEO), da der Inhalt direkt als HTML ausgeliefert wird. Suchmaschinen-Crawler können den Inhalt leicht lesen und indexieren, was zu einer besseren Sichtbarkeit und einem höheren Ranking in den Suchergebnissen führen kann. Schließlich trägt die schnellere Ladezeit von SSR-Anwendungen auch zu einer besseren Benutzererfahrung bei. Benutzer schätzen schnelle Webseiten, was zu geringeren Absprungraten und einer höheren Benutzerzufriedenheit führt und bei Shopsystemen nicht selten zu mehr Abschlüssen.

Doch was macht SSR aktuell so besonders, wenn bspw. PHP dies seit jeher “von Haus aus” macht? Ein wesentlicher Aspekt ist, dass kein Framework- oder Technologie-Bruch stattfinden muss: Verwendet man Next.js, Nuxt.js oder Angular in einer aktuellen Version, kann mit den vom jeweiligen Framework angebotenen Feature-Set für beide Seiten, Client- und Server, entwickelt werden. Überspitzt gesagt reicht es aus, Grundlagen der Webentwicklung, Typescript und eins der großen Frameworks zu kennen statt zusätzlich noch die weiteren rein Server-seitigen Sprachen wie PHP oder ASP.NET. Zudem ist durch den Einsatz der Ursprünglich für den SPA-Fokus entwickelten Frameworks ein hybrider Betrieb möglich: Die Webapplikation wird zunächst ohne weitere Notwendigkeit für JavaScript an den Browser ausgespielt und anschließend über “hydration” mit Hilfe von JavaScript-Funktionen um Interaktive Elemente angereichert.

## Fazit

Auch wenn es den Anschein hat, ist SSR kein alter Trend im neuen Gewand, sondern ein topaktuelles Thema mit wesentlichen Weiterentwicklungen. Wer eine performante, SEO-freundliche und benutzerfreundliche Website entwickeln möchte, sollte sich mit SSR auseinandersetzen und über bekannte Muster aus PHP oder .NET-Zeiten hinaus blicken. Seit der Einführung dieser Technologien hat sich die Internetarchitektur maßgeblich weiterentwickelt und die neuen Webframeworks machen sich dies zu Nutzen und ermöglichen es, die Konzepte wie CDNs, Caching, Edge-Computing einfacher und für den Entwickelnden transparenter zu nutzen.

Server Side Rendering - Ein alter Trend im neuen Gewand?

Lass uns austauschen!

Möchtest du dich über Backups austauschen?

LEISTUNGEN

IT-Security: Hacks für deine IT-Sicherheit

WISSENS-HUB

Testing

Infrastructure as Code

Der Softwerker Vol. 22

Hier gibt's noch mehr spannende Infos von uns für euch

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Backups entscheidend für Datensicherheit und Geschäftsbetrieb

Hier gibt's noch mehr spannende Infos von uns für euch

IT-Security: Hacks für deine IT-Sicherheit

Der Softwerker Vol. 22

Jetzt für unseren Newsletter anmelden