Integrationen (ERP, PIM, WMS, Zahlungen)

Der Shop ist nur eines von mehreren Systemen. Das Geschäft läuft daneben auf einem ERP für Bestand und Buchhaltung, einem PIM für Produktdaten, einem WMS für das Fulfillment, Zahlungsdienstleistern und einem CRM für das Marketing. Die meisten Produktionsstörungen beginnen nicht im Shop selbst, sondern in der Integrationsschicht dazwischen.

Systeme, an die wir anbinden

• ERP: SAP Business One, Microsoft Dynamics 365 Business Central, Pohoda, Money S5, Odoo, NetSuite
• PIM: Akeneo, Pimcore, Plytix und die internen Excel-Tabellen, die sich für ein PIM ausgeben
• WMS / 3PL / Fulfillment: Zásilkovna, Packeta, GLS, DPD, FedEx, hauseigene Lagersysteme
• Payments: Stripe, GoPay, ComGate, PayU, Adyen, Mollie, dazu Fraud-Detection und Recurring Billing
• CRM / Marketing: HubSpot, Klaviyo, Mailchimp, Salesforce
• Analytics / Daten: BigQuery, Snowflake, Segment, GA4

Wie wir sie bauen

• Idempotent. Jeder Webhook darf zweimal ausgelöst werden, ohne einen inkonsistenten Zustand zu erzeugen, denn im Produktionsbetrieb treten Retries auf.
• Beobachtbar: Jeder Aufruf zwischen zwei Systemen wird mit Correlation-ID geloggt. Wenn eine Bestellung nicht im WMS ankommt, zeigt das Log in einer Minute, wo sie steckt.
• Resilient. Fällt der Drittanbieter aus, überlebt die Integration das: Dead-Letter-Queues, Exponential Backoff und Werkzeuge für manuelles Replay.
• Versionierte Verträge. Der API-Vertrag liegt im Repo, eine schemabrechende Änderung des Anbieters fällt schon beim Deployment auf, nicht erst in der Produktion.
• Getestet, mit Contract-Tests gegen aufgezeichnete Responses und Smoke-Tests gegen die Sandbox bei jedem Deployment.

Woher diese Regeln kommen

Nichts davon ist Theorie. Jede dieser Regeln hat in einem Shop, an dem wir gearbeitet haben, einmal Lehrgeld gekostet:

• Ein Status-Sync stand wochenlang still, ohne je zu scheitern: Das ERP schickte immer wieder 300.000 Status für Bestellungen, die es im Shop nie gab. Das erschöpfte das Fehlerbudget des Import-Tools und brach jeden Lauf still ab, bevor die eigentlichen Daten verarbeitet wurden. Seitdem gilt: Fehlerbudgets werden überwacht, nicht nur konfiguriert.
• Ein frisch deployter Bestell-Sync überschrieb Felder, die dem Marktplatz-Connector gehörten, und die Sendungen eines ganzen Tages erreichten die Marktplätze nie. Seither hat jede synchronisierte Spalte genau einen deklarierten Eigentümer, und der Sync rührt fremde Zeilen nicht an.
• Eine Stored Procedure im ERP warf SQL-Exceptions und meldete trotzdem „Erfolg“. Aufgefallen ist das, weil wir vor dem Go-live 1.300 echte Bestellungen gegen die Integration abgespielt haben; das ist inzwischen die Standardprobe für bestellkritische Flows.
• Ein fehlerhafter Feed hätte beinahe Zehntausende Produkte in einem einzigen Lauf gelöscht. Lösch-Schwellenwerte mit Circuit Breaker gehören seitdem zu jedem Katalog-Sync, den wir bauen.
• Zahlungen fanden ihre Bestellungen nicht mehr, weil die Firewall des Hosters die Webhooks des Zahlungsdienstleisters drosselte. Der Fix war eine Whitelist; ihn zu finden hieß, HTTP-Logs zu lesen, die sich vorher niemand angesehen hatte.

B2B-Commerce

B2B ist ein anderes Geschäft als DTC: Käufer sind Angestellte von Firmen, Preise hängen von Verträgen ab, und Bestellungen laufen durch Genehmigungsprozesse. Auch diese Schicht bauen wir. Dazu gehören Firmenkonten mit Rollen und Hierarchien, kundenspezifische Kataloge und Vertragspreise, Quote-to-Order-Workflows, Zahlungsbedingungen (Net 30/60/90, Kreditlimits, Rechnungsanbindung an das ERP) sowie Procurement-Integration über Punchout (OCI, cXML, Ariba) und EDI für Kunden, die weiterhin klassische EDI-Bestellungen (850) senden.

Wie ein Projekt üblicherweise beginnt

Der Umfang von Integrationsarbeit ergibt sich aus dem Fehler, der schon sichtbar ist: die Bestellung, die nie im WMS ankam, die Bestandszahl, die jede Nacht ein Stück driftet, das CSV, das jemand jeden Morgen von Hand neu eintippt. Wir gehen diesen Ablauf von Ende zu Ende durch, halten Umfang und Festpreis schriftlich fest und bauen den Ersatz so, dass der nächste Fehler sofort im Monitoring auftaucht, statt tagelang unbemerkt zu bleiben. Der laufende Betrieb, Monitoring inklusive, kann als monatlicher Retainer bei uns bleiben.