Seminar Magnolia CMS – Integration, REST und Drittsysteme

Das Seminar verbindet Magnolia kontrolliert mit Produktdaten, CRM, Suche, Medien-, Übersetzungs- und Fachsystemen und behandelt Verträge, Authentisierung, Fehlerbehandlung und Betrieb. 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. Integrationsarchitektur und Datenverträge
2. Ausgehende Aufrufe und REST Client
3. Eingehende APIs und Aktionen
4. Mapping, Fehlerbehandlung und Wiederholung
5. Test, Monitoring und Betrieb
6. Zielgruppe und Voraussetzungen
7. Didaktik und Arbeitsweise

Integrationsarchitektur und Datenverträge

Inhaltsverzeichnis

• Systemgrenzen und Verantwortungen
• synchron, asynchron und Batch
• Schema, Versionierung und Datenhoheit
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Systemgrenzen und Verantwortungen, synchron, asynchron und Batch und Schema, Versionierung und Datenhoheit 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: Systemgrenzen und Verantwortungen 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 synchron, asynchron und Batch 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: Schema, Versionierung und Datenhoheit werden schrittweise konfiguriert oder implementiert. Ein Integrationsportfolio wird nach Kopplung, Kritikalität und Änderungsrisiko strukturiert. 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: Schnittstellenlandkarte mit Datenhoheit und SLOs.

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

Ausgehende Aufrufe und REST Client

Inhaltsverzeichnis

• Client-Definitionen und Endpunkte
• Header, Parameter und Payload-Mapping
• Timeouts, Zertifikate und Authentisierung
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Client-Definitionen und Endpunkte, Header, Parameter und Payload-Mapping und Timeouts, Zertifikate und Authentisierung 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: Client-Definitionen und Endpunkte 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 Header, Parameter und Payload-Mapping 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: Timeouts, Zertifikate und Authentisierung werden schrittweise konfiguriert oder implementiert. Ein externer Dienst wird über eine kontrollierte Client-Konfiguration angebunden. 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: Client-Konfiguration mit Sicherheits- und Timeoutvorgaben.

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

Eingehende APIs und Aktionen

Inhaltsverzeichnis

• Delivery API für Ausgabe
• Management-APIs und kontrollierte Schreibpfade
• Commands, Webhooks und Entkopplung
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Delivery API für Ausgabe, Management-APIs und kontrollierte Schreibpfade und Commands, Webhooks und Entkopplung 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: Delivery API für Ausgabe 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 Management-APIs und kontrollierte Schreibpfade 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: Commands, Webhooks und Entkopplung werden schrittweise konfiguriert oder implementiert. Für einen Schreib- und einen Leseanwendungsfall wird der jeweils geeignete API-Typ gewählt und implementiert. 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-Entscheidung mit Berechtigungs- und Datenflussmodell.

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

Mapping, Fehlerbehandlung und Wiederholung

Inhaltsverzeichnis

• Transformation und Validierung
• idempotente Verarbeitung und Duplikatschutz
• Retries, Dead Letter und fachliche Fehler
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Transformation und Validierung, idempotente Verarbeitung und Duplikatschutz und Retries, Dead Letter und fachliche Fehler 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: Transformation und Validierung 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 idempotente Verarbeitung und Duplikatschutz 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: Retries, Dead Letter und fachliche Fehler werden schrittweise konfiguriert oder implementiert. Fehlerhafte, doppelte und verspätete Nachrichten werden kontrolliert verarbeitet. 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: Fehlerkatalog mit Wiederholungs- und Eskalationsregeln.

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

Test, Monitoring und Betrieb

Inhaltsverzeichnis

• Vertragstests und Testdoubles
• Metriken, Tracing und Korrelation
• SLA, Supportgrenzen und Änderungsmanagement
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Vertragstests und Testdoubles, Metriken, Tracing und Korrelation und SLA, Supportgrenzen und Änderungsmanagement 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: Vertragstests und Testdoubles 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 Metriken, Tracing und Korrelation 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: SLA, Supportgrenzen und Änderungsmanagement werden schrittweise konfiguriert oder implementiert. Ein Integrationsrelease wird mit Vertragsprüfung, Störungstest und Betriebsübergabe abgenommen. 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: Betriebspaket für Schnittstellen und Abhängigkeiten.

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: Integration Engineering, Lösungsarchitektur, Magnolia- und Backend-Entwicklung, API Management, Security Engineering und technische Projektleitung.

Voraussetzungen: Magnolia-Grundkenntnisse sowie sichere HTTP-, REST-, JSON- und Authentisierungskenntnisse; Java- oder Skriptingkenntnisse sind für Erweiterungsübungen hilfreich.

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.