Seminar Magnolia CMS – Java-Modulentwicklung und Erweiterungen

Das Seminar vermittelt die Entwicklung wartbarer Magnolia-Java-Module mit Build, Moduldescriptor, Dependency Injection, Konfiguration, Commands, Apps, REST-Erweiterungen, Tests und Paketierung. Der Schwerpunkt liegt auf einer reproduzierbaren Vorgehensweise mit klaren Ausgangswerten, kontrollierten Änderungen, Negativtests und dokumentierten Abnahmekriterien. Produktive Änderungen werden nicht vorausgesetzt; alle Arbeitsschritte lassen sich in einer Labor- oder Projektumgebung nachvollziehen.

Inhaltsübersicht

1. Projektstruktur und Modullebenszyklus
2. Komponenten, Konfiguration und Dependency Injection
3. Commands, Jobs und Geschäftslogik
4. Apps, Aktionen und Felder erweitern
5. REST und Drittsystemintegration
6. Tests, Paketierung und Kompatibilität
7. Zielgruppe und Voraussetzungen
8. Didaktik und Arbeitsweise

Projektstruktur und Modullebenszyklus

Inhaltsverzeichnis

• Maven-Projekt und Abhängigkeiten
• Moduldescriptor, Versionen und Startreihenfolge
• Installations-, Update- und Bootstrap-Aufgaben
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Maven-Projekt und Abhängigkeiten, Moduldescriptor, Versionen und Startreihenfolge und Installations-, Update- und Bootstrap-Aufgaben zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Maven-Projekt und Abhängigkeiten werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Moduldescriptor, Versionen und Startreihenfolge wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Installations-, Update- und Bootstrap-Aufgaben werden schrittweise konfiguriert oder implementiert. Ein neues Modul wird gebaut, installiert und mit reproduzierbarer Versionsstrategie versehen. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Modulgrundgerüst mit Build- und Updatekonzept.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Komponenten, Konfiguration und Dependency Injection

Inhaltsverzeichnis

• Komponentensichtbarkeit und Provider
• Konfigurationsdefinitionen und Parameter
• Services, Events und klare Schnittstellen
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Komponentensichtbarkeit und Provider, Konfigurationsdefinitionen und Parameter und Services, Events und klare Schnittstellen zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Komponentensichtbarkeit und Provider werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Konfigurationsdefinitionen und Parameter wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Services, Events und klare Schnittstellen werden schrittweise konfiguriert oder implementiert. Ein konfigurierbarer Service wird implementiert, injiziert und mit Austauschkomponenten getestet. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Servicearchitektur mit Konfigurationsvertrag.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Commands, Jobs und Geschäftslogik

Inhaltsverzeichnis

• Commands und Kataloge
• Transaktionen, Wiederholbarkeit und Fehlerpfade
• Jobs, Events und Hintergrundverarbeitung
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Commands und Kataloge, Transaktionen, Wiederholbarkeit und Fehlerpfade und Jobs, Events und Hintergrundverarbeitung zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Commands und Kataloge werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Transaktionen, Wiederholbarkeit und Fehlerpfade wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Jobs, Events und Hintergrundverarbeitung werden schrittweise konfiguriert oder implementiert. Ein idempotenter Verarbeitungsvorgang wird als Command mit Fehler- und Wiederanlaufpfad umgesetzt. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Command-Paket mit Protokollierungs- und Wiederholungsstandard.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Apps, Aktionen und Felder erweitern

Inhaltsverzeichnis

• App- und Subapp-Definitionen
• benutzerdefinierte Aktionen und Verfügbarkeit
• Felder, Validierung und Datenquellen
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet App- und Subapp-Definitionen, benutzerdefinierte Aktionen und Verfügbarkeit und Felder, Validierung und Datenquellen zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: App- und Subapp-Definitionen werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für benutzerdefinierte Aktionen und Verfügbarkeit wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Felder, Validierung und Datenquellen werden schrittweise konfiguriert oder implementiert. Eine kleine Administrationsoberfläche mit abgesicherter Aktion wird entwickelt. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: UI-Erweiterung mit Berechtigungs- und Bedienkonzept.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

REST und Drittsystemintegration

Inhaltsverzeichnis

• eigene REST-Ressourcen und Serialisierung
• Authentisierung, Rollen und Eingabevalidierung
• Clients, Timeouts und Fehlerbehandlung
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet eigene REST-Ressourcen und Serialisierung, Authentisierung, Rollen und Eingabevalidierung und Clients, Timeouts und Fehlerbehandlung zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: eigene REST-Ressourcen und Serialisierung werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Authentisierung, Rollen und Eingabevalidierung wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Clients, Timeouts und Fehlerbehandlung werden schrittweise konfiguriert oder implementiert. Eine geschützte API und ein ausgehender Client werden zu einem kontrollierten Integrationsfall verbunden. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: API-Modul mit Sicherheits- und Fehlervertrag.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Tests, Paketierung und Kompatibilität

Inhaltsverzeichnis

• Unit- und Integrationstests
• Testdaten, Mocks und Magnolia-Kontext
• Paketierung, Upgradefähigkeit und Release-Dokumentation
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Unit- und Integrationstests, Testdaten, Mocks und Magnolia-Kontext und Paketierung, Upgradefähigkeit und Release-Dokumentation zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Unit- und Integrationstests werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Testdaten, Mocks und Magnolia-Kontext wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Paketierung, Upgradefähigkeit und Release-Dokumentation werden schrittweise konfiguriert oder implementiert. Das Modul wird gegen Grenzfälle, Upgrade und Deployment geprüft. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Releasefähiges Modul mit Test- und Kompatibilitätsnachweis.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Zielgruppe und Voraussetzungen

Inhaltsverzeichnis

• Adressierte Rollen
• Fachliche und technische Vorkenntnisse
• Labor- und Arbeitsmittel

Zielgruppe: Java-Entwicklung, Magnolia-Entwicklung, Lösungsarchitektur, Integration Engineering und technische Lead-Verantwortung.

Voraussetzungen: Sichere Java-, Maven- und Git-Kenntnisse, Grundlagen in Dependency Injection, HTTP und Tests sowie Magnolia-Architekturkenntnisse.

Für die Praxisanteile wird eine getrennte Magnolia-Umgebung mit Beispieldaten verwendet. Administrations- und Entwicklungsübungen werden mit nicht produktiven Konten durchgeführt. Vor jedem Eingriff werden Ausgangszustand, erwartete Wirkung und Rückfallmöglichkeit festgehalten.

Didaktik und Arbeitsweise

Inhaltsverzeichnis

• Fachimpuls und Demonstration
• Geführte Umsetzung
• Kontrollierte Fehlerfälle
• Abnahme und Dokumentation

Kurze Fachimpulse werden unmittelbar durch Demonstrationen und geführte Arbeitsschritte vertieft. Jede Übung enthält einen definierten Ausgangszustand, konkrete Prüfpunkte, mindestens einen Negativfall und eine schriftliche Abnahme. Wiederholbare Checklisten und Runbooks stehen im Mittelpunkt; reine Funktionsvorführungen ohne Prüfung sind nicht Bestandteil des Vorgehens.