Seminar sovity Kompaktseminar – Umsetzung vom Connector bis zum Datentransfer

Inhaltsverzeichnis

1. Zielsetzung
2. Zielgruppe
3. Voraussetzungen
4. Seminarinhalte
   1. Modul 1: Rollen, Zielbild und Austauschbeziehungen
   2. Modul 2: Community Edition und Zwei-Connector-Labor
   3. Modul 3: Assets, Identifikatoren und technische Datenadressen
   4. Modul 4: Access Policies und Contract Policies
   5. Modul 5: Contract Definition und Veröffentlichung
   6. Modul 6: Push-, Pull- und speicherbasierte Transfers
   7. Modul 7: Health Checks, Metriken und strukturierte Logs
5. Praxisübungen
6. Methodik

Zielsetzung

Das Kompaktseminar vermittelt in drei Tagen einen vollständigen, bewusst fokussierten Umsetzungsweg. Aus Zielbild und Use Case entstehen eine lokale Zwei-Connector-Umgebung, ein abgesichertes Datenangebot, eine Vertragsverhandlung, ein Datentransfer, ein grundlegendes Identity- und Betriebskonzept sowie ein priorisierter Plan für die produktive Weiterentwicklung.

Zielgruppe

Architekten, Connector-Administratoren, Integration Engineers, Data Product Owner und technische Projektverantwortliche.

Voraussetzungen

Grundkenntnisse von Datenräumen, APIs und Containerbetrieb; keine vertieften EDC-Kenntnisse erforderlich.

Seminarinhalte

Die Themen werden in der angegebenen Reihenfolge aufgebaut. Jeder Schritt setzt auf dem zuvor geprüften Systemzustand auf.

Modul 1: Rollen, Zielbild und Austauschbeziehungen

Die organisatorische Ausgangslage wird in ein eindeutiges Rollen- und Architekturmodell überführt.

1. Schritt 1: Datenanbieter, Datenkonsument, Data Space Authority, Betreiber und Servicepartner voneinander abgrenzen.
2. Schritt 2: Datenobjekte, Gegenstellen, Austauschhäufigkeit und geschäftlichen Nutzen in einer Use-Case-Matrix erfassen.
3. Schritt 3: Connector, Portal, Katalog, Identity Provider und Registry den verantwortlichen Rollen zuordnen.
4. Schritt 4: Offene Architektur- und Governance-Entscheidungen priorisieren und als Freigabepunkte dokumentieren.

Modul 2: Community Edition und Zwei-Connector-Labor

Eine reproduzierbare Arbeitsumgebung bildet die Grundlage für alle weiteren Übungen.

1. Schritt 1: Container-Laufzeit, Java-, Node- und Buildwerkzeuge sowie freie Ports und Systemressourcen prüfen.
2. Schritt 2: PostgreSQL und zwei voneinander getrennte Connectorinstanzen starten.
3. Schritt 3: Startprotokolle, Datenbankmigrationen und Health-Endpunkte auf einen fehlerfreien Grundzustand prüfen.
4. Schritt 4: Anbieter- und Konsumentenrolle mit einem ersten technischen Ende-zu-Ende-Test bestätigen.

Modul 3: Assets, Identifikatoren und technische Datenadressen

Fachliches Datenprodukt und technische Bereitstellung werden unabhängig modelliert.

1. Schritt 1: Stabile Asset-ID, Version, Domäne und Lebenszyklusstatus nach einer Namenskonvention festlegen.
2. Schritt 2: Granularität so wählen, dass Policies und Transfers ohne unnötige Kopplung möglich bleiben.
3. Schritt 3: Quelltyp, Endpunkt, Methode, Format und statische beziehungsweise dynamische Parameter konfigurieren.
4. Schritt 4: Zugangsdaten nur als Secret- oder Vault-Referenz hinterlegen und Quelle mit Positiv- und Negativfall prüfen.

Modul 4: Access Policies und Contract Policies

Katalogsichtbarkeit und vertragliche Nutzungsbedingungen werden getrennt und testbar modelliert.

1. Schritt 1: Fachliche Regel in Operand, Operator, Wert, Datentyp und Namensraum übersetzen.
2. Schritt 2: Access Policy für Sichtbarkeit und Contract Policy für Vertragsberechtigung separat anlegen.
3. Schritt 3: Teilnehmer-, Gruppen-, Zeit- und Zweckbedingungen mit AND, OR oder XONE kombinieren.
4. Schritt 4: Erlaubte, abgelehnte und unvollständige Identitäten über eine Wahrheitstabelle und technische Tests prüfen.

Modul 5: Contract Definition und Veröffentlichung

Asset und Policies werden zu einem kontrollierten Datenangebot verbunden.

1. Schritt 1: Asset-Selektor oder explizite Asset-Zuordnung mit eindeutigem Geltungsbereich festlegen.
2. Schritt 2: Access- und Contract-Policy korrekt referenzieren und Contract Definition anlegen.
3. Schritt 3: Angebot aus externer Katalogsicht abrufen und unerwartete Assets oder fehlende Metadaten korrigieren.
4. Schritt 4: Probeverhandlung, Testtransfer und Freigabecheckliste als Veröffentlichungsnachweis durchführen.

Modul 6: Push-, Pull- und speicherbasierte Transfers

Transferart und Datenfluss werden nach Quelle, Ziel, Volumen und Integrationsmuster ausgewählt.

1. Schritt 1: HttpData-PUSH, parametrisiertes HttpData-PULL und speicherbasierte Verfahren vergleichen.
2. Schritt 2: Zieladresse, Zieltyp, Datenebenenparameter und Vertragsvereinbarung korrekt zuordnen.
3. Schritt 3: Transfer starten und Zustände, Data-Plane-Auswahl, Nutzdaten und Header prüfen.
4. Schritt 4: Abbruch, Wiederholung, Vertragsbeendigung und Verhalten bei vorhandenem Zielobjekt testen.

Modul 7: Health Checks, Metriken und strukturierte Logs

Dienststatus und Prozesszustände werden über messbare Signale und Korrelationskennungen beobachtbar.

1. Schritt 1: Start-, Readiness-, Liveness- und Dependency-Prüfungen den Betriebsentscheidungen zuordnen.
2. Schritt 2: Metriken für Anfragen, Fehler, Laufzeiten, Verhandlungen, Transfers und Datenbankverbindungen auswählen.
3. Schritt 3: Logs mit Zeitstempel, Dienst, Umgebung, Gegenstelle, Prozesskennung und Zustand strukturieren.
4. Schritt 4: Dashboards und Alarmregeln für Ausfall, Fehlerquote, hängende Prozesse und Zertifikatsablauf aufbauen.

Praxisübungen

Die Übungen verbinden die einzelnen Konfigurations- und Integrationsschritte zu prüfbaren Arbeitsergebnissen.

• Übung 1: Zwei-Connector-Labor aufbauen und technisch prüfen.
• Übung 2: API-basiertes Datenangebot mit getrennten Policies veröffentlichen.
• Übung 3: Vertragsverhandlung und Push- oder Pull-Transfer mit Nutzdatenkontrolle ausführen.
• Übung 4: Ende-zu-Ende-Abnahme und Produktivsetzungsplan erstellen.

Methodik

Das Format konzentriert sich auf einen vollständigen Ende-zu-Ende-Pfad mit klar begrenztem Funktionsumfang. Kurze Theorieblöcke wechseln mit geführter Konfiguration, eigenständigen Kontrollschritten und einer gemeinsamen Abnahme. Vertiefungen werden als priorisierte Folgebausteine in den Umsetzungsplan aufgenommen.