Zum Inhalt springen
SAP, DATEV und Dynamics Experten

APIs, Middleware & Architektur

Ob Punkt-zu-Punkt-Verbindung oder zentrale Middleware — die Architektur entscheidet darüber, wie teuer die zehnte Anbindung wird. Diese Kategorie ordnet die Möglichkeiten ein: direkte Schnittstellen, Warteschlangen und ereignisgetriebene Übertragung, geplante Abgleiche, Datenmapping und Transformation, Versionierung von Schnittstellen sowie Überwachung und Wiederholung fehlgeschlagener Übertragungen. Wir erklären, wann sich eine eigene Integrationsschicht lohnt, welche Anforderungen an Protokollierung und Nachvollziehbarkeit sinnvoll sind und wie sich Abhängigkeiten von einzelnen Dienstleistern begrenzen lassen. Auch die Dokumentation kommt vor: Ohne beschriebene Datenflüsse wird jede spätere Änderung zum Risiko — unabhängig davon, wie sauber die erste Umsetzung war. Ergänzend zeigen wir, welche Kennzahlen den Zustand einer Integration beschreiben — von der Zahl offener Warteschlangen bis zur Dauer eines vollständigen Abgleichs.

Event-Driven-Architektur mit Message QueueEreignis-QuellenShop: BestellungShop: ZahlungERP: BestandMessage Broker / Queueentkoppelt Quelle und Ziel1234Reihenfolge je Partition (FIFO)ACK / CommitRetry + BackoffVerbraucherERP-AuftragBuchhaltungLager-SyncpublishsubscribeBelastbarkeit der ZustellungAt-least-onceIdempotenz-SchlüsselReihenfolge erhaltenLastpufferFehler-PfadDead Letter Queuenach erschöpften VersuchenAlerting + Wiederaufnahmekein stiller DatenverlustMarktdynamik17,6%Wachstum Queue-Markt p.a.90%Großfirmen Echtzeit 202513%reife EDA-Adoption

Event-Driven-Architektur und Message Queues

Wie Events und Message Queues entkoppelte, ausfallsichere Shop-Integrationen ermöglichen: Retry, Reihenfolge per Partition, Idempotenz und DLQ erklärt.

14 Min. Lesezeit
Idempotenz und Retry-StrategienShopBestellung + KeyIdempotency-StoreKey bekannt?Dedup-PrüfungRetry-EngineBackoff + Jittermax 5 VersucheERP / SAPZielsystemSichere Wiederholung mit Exponential BackoffVersuch 1nach 1sVersuch 2nach 2s + JitterVersuch 3nach 4s + JitterVersuch 4nach 8s + JitterVersuch 5nach 16s + JitterErfolg: Key als verarbeitet markiertspätere Duplikate werden ignoriertDead-Letter-Queuenach max. Versuchenmanuelle KlärungAt-least-once ZustellungJede Nachricht kommt mindestens einmal an,möglicherweise mehrfach. Duplikate sinderlaubt und werden vom Empfänger entfernt.Idempotenz macht den Empfängerunempfindlich gegen Wiederholungen.Deduplizierung im StoreIdempotency-Key wird gespeichert, bevorder Auftrag ans ERP geht. Trifft derselbeKey erneut ein, wird das Ergebnis desersten Aufrufs zurückgegeben.Keine doppelten Bestellungen im ERP.

Idempotenz und Retry-Strategien für robuste Schnittstellen

Idempotency-Keys, Exponential Backoff mit Jitter und Dead-Letter-Queues: So werden Bestell- und Bestands-Syncs zwischen Shop und ERP sicher wiederholbar.

13 Min. Lesezeit
Webhooks vs. Polling im Shop-zu-ERP-DatenflussEvent-getrieben (Webhook)ShopEreignis: BestellungERP-EmpfängerHTTPS POST + HMACPush200 ACKAbfrage-basiert (Polling)ERP-Clientfragt im IntervallShop-APIGET seit ZeitstempelGETDelta-ListeZustellung absichernEmpfangsquittung (2xx)Retry + BackoffIdempotenz-KeyDead Letter QueueSicherheit der Webhook-RouteHMAC-SHA256 SignaturZeitstempel gegen ReplayAllowlist der IPsmTLS optionalSignatur in konstanter Zeit prüfenAuswahl nach DatenflussBestellung Shop zu ERP: Webhook (Sekunden)Bestand ERP zu Shop: Webhook + Delta-SyncStammdaten-Backfill: Polling im IntervallVergleich auf einen BlickLatenzSek.Webhook nahe EchtzeitAPI-LastgeringPush statt DauerabfragePolling-Intervall1-5Minuten als SicherheitsnetzRobusthybridPush plus Abgleich

Webhooks vs. Polling: Event-getriebene Shop-Integration

Webhooks oder Polling für die Shop-zu-ERP-Anbindung? Vergleich von Latenz, Zustellgarantie, HMAC-Sicherheit und Ausfallsicherheit mit Praxisempfehlungen.

13 Min. Lesezeit