Lektion 07
Willkommen in der Königsklasse der Integration! Heute beschäftigen wir uns mit den anspruchsvollsten Szenarien: der Anbindung von Finanz-Tools mit komplexer Authentifizierung und der Verarbeitung von Echtzeit-Ereignissen aus der Logistik. Du lernst die Techniken, die für wirklich robuste und skalierbare Integrationen notwendig sind.
Platz für deine Notizen:
Checkliste: Was du heute erreichen wirst
Übung 1 (Konzept): Einen Batch-Prozess entwerfen
Ziel: Du sollst die logischen Schritte für einen nächtlichen Rechnungs-Export zu DATEV skizzieren. Dies ist eine reine Konzept-Übung, die dein Architektur-Verständnis schult.
Szenario:
Alle über den Tag in Xentral erstellten Rechnungen sollen nachts an die DATEV-API übertragen werden.
Die DATEV-API hat ein Limit von 60 Anfragen pro Minute.
Eine Rechnung wird einzeln per API-Call übertragen.
Deine Aufgabe: Skizziere die notwendigen Workflows und die wichtigsten Schritte. Denke an:
Wie werden die Rechnungen über den Tag gesammelt?
Wie wird der nächtliche Prozess gestartet?
Wie stellst du sicher, dass das Raten-Limit nicht überschritten wird?
Wie vermeidest du, dass Rechnungen doppelt übertragen werden?
Platz für deine Skizze oder Stichpunkte:
Nächtlicher Export
Trigger: Timer, jeden Tag um 2:00 Uhr.
Schritt 1: Lese die Liste "pending_invoices" aus dem Data Store.
Schritt 2: Starte eine "Loop over Items"-Schleife über die Rechnungs-IDs.
Schritt 3 (in der Schleife): Lese die vollständigen Rechnungsdaten aus Xentral (
invoice.get).Schritt 4 (in der Schleife): Sende die Daten an die DATEV-API.
Schritt 5 (in der Schleife): Füge einen "Wait"-Knoten von 1 Sekunde hinzu, um das Limit (60/min) einzuhalten.
Schritt 6 (in der Schleife): Nach erfolgreichem Senden, entferne die ID aus der "pending_invoices"-Liste im Data Store.
Fehlerfall: Bei transienten Fehlern retry mit Backoff; bei dauerhaften Fehlern in eine Fehler-Queue verschieben und Alarm auslösen.
Übung 2 (Konzept): Event-gesteuerte Status-Rückmeldung
Ziel: Du sollst den Prozess für eine Echtzeit-Rückmeldung des Lieferstatus an einen Webshop entwerfen.
Szenario:
In Xentral wird ein Auftrag manuell auf "versendet" gesetzt.
In diesem Moment soll der Webshop per API-Call darüber informiert werden, damit der Kunde eine E-Mail erhält.
Deine Aufgabe: Welchen Trigger würdest du für den Workflow verwenden? Begründe deine Entscheidung im Vergleich zu einem Timer-Trigger.
Platz für deine Antwort:
Cheat Sheet: Wichtige Begriffe aus Modul 7
OAuth2
Ein offener Standard für delegierte Autorisierung. Erlaubt einer Anwendung (Connect) den Zugriff auf eine andere (z.B. Exact Online) im Namen des Benutzers, ohne dessen Passwort zu kennen.
Access Token
Ein kurzlebiges "Ticket", das für die eigentlichen API-Aufrufe verwendet wird. Läuft typischerweise nach kurzer Zeit (z.B. 1 Stunde) ab.
Refresh Token
Ein langlebiges "Ticket", das nur dazu dient, ein neues, frisches Access Token zu erhalten, wenn das alte abgelaufen ist.
Batch-Verarbeitung
Die Strategie, viele kleine Aufgaben (z.B. API-Aufrufe) zu sammeln und sie gebündelt oder zeitversetzt abzuarbeiten, oft um API-Limits einzuhalten.
API-Raten-Limit
Eine von einem API-Anbieter festgelegte Obergrenze für die Anzahl der Anfragen, die ein Client in einem bestimmten Zeitraum stellen darf (z.B. 100 Anfragen pro Minute).
Event-Trigger (Kafka)
Ein Workflow-Trigger, der auf ein internes Ereignis im Xentral-System (z.B. "Rechnung erstellt") lauscht und den Workflow in Echtzeit startet.
Polling
Die Technik, bei der ein System in regelmäßigen Abständen (z.B. alle 5 Minuten) ein anderes System anfragt, ob es neue Daten gibt. Das Gegenteil von Event-gesteuert.
Entkopplung
Ein Architekturprinzip, bei dem ein komplexer Prozess in mehrere, unabhängige Workflows aufgeteilt wird. Dies erhöht die Wartbarkeit und Flexibilität.
Was this helpful?