Übung 07

Ziel: In diesem Lab liegt der Fokus nicht auf der Implementierung, sondern auf dem Entwurf und der Architektur. Du wirst zwei komplexe, reale Szenarien analysieren und die passenden Connect-Architekturen dafür entwerfen. Deine Aufgabe ist es, die richtigen Trigger, Knoten und Strategien auszuwählen und deine Entscheidung zu begründen.

Voraussetzungen:

• Dein Wissen aus den Modulen 1-7.

---

Szenario 1: Nächtlicher DATEV-Rechnungsexport

Anforderungen:

• Alle Rechnungen, die in Xentral im Laufe eines Tages erstellt werden, sollen gesammelt werden.

• Jede Nacht um 03:00 Uhr soll ein Prozess starten, der alle gesammelten Rechnungen an die DATEV-API überträgt.

• Die DATEV-API erlaubt maximal 100 API-Aufrufe pro Minute. Jede Rechnung erfordert einen einzelnen Aufruf.

• Der Prozess muss robust sein: Wenn er bei der 500. von 1000 Rechnungen abbricht, soll er beim nächsten Lauf nicht wieder bei Null anfangen.

• Die Authentifizierung an der DATEV-API erfolgt über OAuth2.

Deine Aufgabe:

Entwirf eine Architektur mit Xentral Connect, um diese Anforderungen zu erfüllen. Beschreibe die notwendigen Workflows, ihre Trigger und die Kernlogik. Erstelle ein Mermaid-Diagramm, das deine Architektur visualisiert.

Platz für deine Lösung:

Beschreibung der Architektur

Ich würde eine Architektur aus zwei Workflows verwenden, um die Sammlung der Rechnungen von deren Verarbeitung zu entkoppeln.

Workflow 1: Collect-Invoices

• Trigger: Event-Trigger. Er lauscht auf das Xentral-Event invoice.created.

• Aktion: Sobald eine Rechnung erstellt wird, nimmt der Workflow die Rechnungs-ID und speichert sie in einer dedizierten Liste im Data Store, z. B. unter dem Key datev_pending_invoices. Hier wird eine append/push-Operation auf ein Array verwendet.

Workflow 2: Process-DATEV-Export

• Trigger: Timer-Trigger. Konfiguriert auf täglichen Start um 03:00 Uhr.

• Credentials: Für den DATEV-API-Knoten werden OAuth2-Credentials eingerichtet, die Token-Refresh automatisch handhaben.

• Kernlogik:

1

Laden

Der Workflow liest die komplette Liste der Rechnungs-IDs aus dem Data Store (datev_pending_invoices).

2

Schleife

Loop over Items über die gelesenen Rechnungs-IDs starten.

3

Verarbeitung pro ID

• Hole die vollständigen Rechnungsdaten via Xentral > invoice.get mit der aktuellen ID.

• Sende die Daten an die DATEV-API (OAuth2-gesichert).

• Füge nach dem Senden einen Wait-Knoten von 1 Sekunde ein (max. 60 Rechnungen/min, innerhalb des Limits von 100/min).

• Entferne nach erfolgreichem Senden die verarbeitete Rechnungs-ID aus datev_pending_invoices im Data Store — dadurch ist der Fortschritt persistent und der Prozess robust gegenüber Abbrüchen.

4

Abschluss

Wenn die Schleife fertig ist, ist die Liste im Data Store leer und der Prozess beendet.

Mermaid-Diagramm

graph TD
    subgraph Tagsüber
        A[Event: Rechnung erstellt] --> B(Workflow 1: Collect-Invoices);
        B --> C{Data Store: Füge ID zu<br>
        'datev_pending_invoices' hinzu};
    end

    subgraph Nachts um 03:00 Uhr
        D[Timer-Trigger] --> E(Workflow 2: Process-DATEV-Export);
        E --> F{Lese alle IDs aus<br>
        'datev_pending_invoices'};
        F --> G{Loop over Items};
        G -- Jede ID --> H(Hole Rechnungsdaten);
        H --> I(Sende an DATEV API via OAuth2);
        I --> J(Wait 1 Sekunde);
        J --> K{Entferne ID aus<br>
        'datev_pending_invoices'};
        K --> G;
        G -- Schleife fertig --> L[Ende];
    end

---

Szenario 2: Echtzeit-Tracking-Update

Anforderungen:

• Ein externer Versanddienstleister (Carrier) ruft einen Webhook in Connect auf, sobald sich der Status eines Pakets ändert (z. B. "im Transit", "zugestellt").

• Die Information enthält eine tracking_number und den neuen status.

• Dieser neue Status soll in einem benutzerdefinierten Feld am Lieferschein in Xentral gespeichert werden.

• Sobald der Status in Xentral aktualisiert wurde, soll eine Benachrichtigung an die API des ursprünglichen Webshops gesendet werden, um den Kunden zu informieren.

• Der Prozess muss in Echtzeit (< 10 Sekunden) erfolgen.

Deine Aufgabe:

Entwirf eine Architektur, die diesen Prozess abbildet. Begründe, warum du dich für eine bestimmte Anzahl von Workflows entscheidest und wie diese miteinander interagieren. Erstelle auch hier ein Mermaid-Diagramm.

Platz für deine Lösung:

Beschreibung der Architektur

Für diesen Prozess wähle ich eine entkoppelte Architektur aus zwei Workflows, um Verantwortlichkeiten klar zu trennen und Wartbarkeit zu erhöhen.

Workflow 1: Ingest-Carrier-Status (Status-Annahme)

• Trigger: Webhook-Trigger — stellt die URL für den Carrier bereit.

• Verantwortlichkeit: Nur Datenannahme vom Carrier und Schreiben in Xentral.

• Kernlogik:

1

Daten empfangen

Der Webhook empfängt tracking_number und status.

2

Lieferschein finden

Suche in Xentral den Lieferschein mit der empfangenen tracking_number (z. B. deliverynote.list mit Filter).

3

Xentral aktualisieren

Verwende deliverynote.update, um den neuen Status in das benutzerdefinierte Feld des gefundenen Lieferscheins zu schreiben.

4

Sofort antworten

Antworte dem Carrier mit HTTP 200 OK, damit der Carrier schnell eine Bestätigung erhält.

Workflow 2: Notify-Shop-On-Update (Shop-Benachrichtigung)

• Trigger: Event-Trigger. Lauscht auf das Xentral-Event, das durch die Aktualisierung des Lieferscheins ausgelöst wird (z. B. deliverynote.customfield.updated).

• Verantwortlichkeit: Nur Benachrichtigung des Webshops.

• Kernlogik:

1

Event-Daten erhalten

Der Trigger erhält die Daten des aktualisierten Lieferscheins (inkl. Auftrags-ID und neuem Status).

2

Shop-API aufrufen

Rufe die API des Webshops auf und übermittle die Status-Aktualisierung für die entsprechende Bestellung.

Warum diese Entkopplung?

• Robustheit: Wenn die Shop-API nicht erreichbar ist, schlägt nur Workflow 2 fehl. Workflow 1 hat bereits die Carrier-Daten angenommen und Xentral aktualisiert. Die Benachrichtigung kann wiederholt werden, ohne Carrier-Aufrufe zu verlieren.

• Wartbarkeit: API-Änderungen beim Shop betreffen nur Workflow 2.

• Geschwindigkeit: Workflow 1 kann dem Carrier in < 10 Sekunden (typisch sofort) antworten, ohne auf externe Shop-API-Latenz zu warten.

Mermaid-Diagramm

graph TD
    A[Carrier ruft Webhook auf] --> B(Workflow 1: Ingest-Carrier-Status);
    B --> C{Finde Lieferschein in Xentral};
    C --> D(Aktualisiere Status in Xentral);
    D --> E[Antworte Carrier mit 200 OK];
    
    subgraph Xentral Event Bus
        F(Event: Lieferschein aktualisiert);
    end

    D -- löst aus --> F;

    F --> G(Workflow 2: Notify-Shop-On-Update);
    G --> H{Lese Auftrags-ID aus Event};
    H --> I(Rufe Shop-API auf);
    I --> J[Ende];

---