Effektive Shopware Infor SX.e Integration: Aufwand, Kosten, Risiken

Montagmorgen, 9:15 Uhr. Dein Shopware-Shop läuft seit drei Monaten live, die ersten Bestellungen trudeln ein – aber im Backoffice häufen sich die Tickets: „Warum zeigt der Shop 50 Stück verfügbar, wenn das ERP nur 12 auf Lager meldet?" „Kunde hat bestellt, aber die Order ist nicht in SX.e angekommen." „Preis im Checkout weicht vom ERP ab, wer hat recht?" Willkommen in der Realität der ERP-Shop-Integration – und wenn du dafür eine erfahrene Shopware Agentur suchst, lohnt sich ein nüchterner Blick auf Aufwand und Verantwortlichkeiten. Was im Konzept elegant klang – „Daten fließen automatisch zwischen Infor SX.e und Shopware" – entpuppt sich in der Praxis als Datenprojekt mit klaren Verantwortlichkeiten, Architekturentscheidungen und vielen Stolpersteinen. Dieser Artikel zeigt dir, wie du die Integration von Infor SX.e und Shopware von Anfang an richtig angehst, welche Daten wirklich fließen müssen, wo die typischen Fallstricke lauern und wie du Overselling, Preisabweichungen und Order-Fails vermeidest.

Für wen ist dieser Artikel relevant? Prüfe in 30 Sekunden, ob das dein Projekt ist

Nicht jedes Shopware-Projekt braucht eine vollwertige ERP-Integration – und nicht jedes ERP-System ist Infor SX.e. Dieser Artikel ist für dich relevant, wenn mindestens drei dieser Aussagen zutreffen:

• Dein Unternehmen nutzt bereits Infor SX.e (ehemals SyteLine) als ERP – typischerweise im Großhandel, Distribution, technischen Handel oder produzierenden Gewerbe.
• Du planst einen B2B-Shop mit Shopware, der auf echte Lager-, Preis- und Kundendaten aus dem ERP zugreifen muss.
• Du hast bereits ein Shopware-Projekt am Laufen, aber die Anbindung ans ERP ist noch offen oder läuft unbefriedigend (Datenqualität, Performance, Fehler).
• Du bist Entscheider, Projektleiter oder Agentur und brauchst eine realistische Einschätzung von Aufwand, Risiken und Kosten.
• Dir ist klar, dass „Standard-Connector" nicht automatisch „plug & play" bedeutet – und du willst wissen, worauf es wirklich ankommt.

Wenn du ein anderes ERP nutzt (z. B. SAP, Microsoft Dynamics, Sage), sind viele Prinzipien übertragbar – aber technische Details (APIs, Datenmodell, Verfügbarkeitslogik) unterscheiden sich erheblich. Für SX.e-Nutzer ist dieser Artikel die konkreteste Hilfe, die du finden wirst.

Was Shopware out-of-the-box kann – und wo die ERP-Integration beginnt

Shopware 6 ist ein mächtiges Shopsystem mit vielen B2B-Features an Bord. Bevor du in die Integration einsteigst, solltest du verstehen, was Shopware selbst mitbringt – und wo du zwingend auf externe Daten angewiesen bist.

Shopware out-of-the-box: Diese Features brauchst du nicht zu bauen

• Produktkatalog: Shopware verwaltet Produkte, Varianten, Kategorien, Bilder, Beschreibungen – aber die Daten müssen irgendwo herkommen. Wenn SX.e dein führendes System für Artikelstamm ist, brauchst du einen Import.
• Kundengruppen und Preise: Shopware kann kundenspezifische Preise anzeigen – aber nur, wenn du sie vorher importierst oder per API abrufst.
• Warenkorb und Checkout: Funktioniert sofort – aber ohne Verfügbarkeitsprüfung aus dem ERP riskierst du Overselling.
• B2B-Suite (optional, kostenpflichtig): Bietet Rollen, Rechte, Quick-Order, kundenspezifische Sortimente – reduziert Custom-Development erheblich, wenn du B2B machst.
• Rule Builder und Flow Builder: Ermöglichen Automatisierung (z. B. „Bei Bestellung über 1000 € E-Mail an Vertrieb") – aber keine Verbindung zum ERP ohne Integration.

Was du zwingend integrieren musst, wenn SX.e dein ERP ist

• Produktdaten: Artikelnummern, Beschreibungen, Kategorien, Varianten – aus SX.e in Shopware (typisch: Batch-Import nachts).
• Preise: Listenpreise, kundenspezifische Preise, Staffelpreise – entweder per Import oder Realtime-API (je nach Anforderung).
• Verfügbarkeit: Lagerbestände, damit der Shop nur verkauft, was lieferbar ist – idealerweise Realtime oder mit kurzem Cache.
• Kunden: Im B2B-Kontext oft komplex: Bill-To, Ship-To, Kundengruppen, Sales-Rep-Zuordnung – typisch: Batch-Import oder manuelles Anlegen mit Sync.
• Bestellungen: Orders aus Shopware müssen sicher und vollständig in SX.e ankommen – kritischster Prozess, braucht Retry-Logik und Monitoring.
• Status und Historien: Auftrags- und Rechnungsstatus zurück in Shopware, damit Kunden Self-Service nutzen können – typisch: Batch ein bis zwei Mal täglich.

Shopware ist kein ERP-Ersatz. Wenn SX.e deine Wahrheit für Lager, Preise, Kunden hält, brauchst du eine belastbare Integration – keine Insellösung.

Infor SX.e Shopware: Welche Daten wirklich fließen müssen – und welche Fehler du vermeiden solltest

Bevor du in technische Details einsteigst, solltest du verstehen, welche Datenobjekte und Prozesse im Zentrum jeder Infor SX.e Shopware Integration stehen. Anders als bei reinen Content-Projekten geht es hier um geschäftskritische Transaktionen: Preise müssen stimmen, Verfügbarkeiten aktuell sein, Bestellungen zuverlässig ins ERP gelangen.

Produkte: Die Basis deines Katalogs

Dein Shopware-Shop lebt von guten Produktdaten. Aus Infor SX.e kommen typischerweise Artikelnummern (SKU), Bezeichnungen, Beschreibungen, Kategorien und Sortimente, Varianten (Farben, Größen, Verpackungseinheiten), Maßeinheiten, Gewichte, Abmessungen sowie Bilder, falls im ERP verwaltet.

Stolperfalle: In SX.e gibt es verschiedene Item-Typen (Standard, Kits, Non-Stock) – nicht alle sollten eins zu eins in den Shop fließen. Definiere früh im Projekt, welche Artikel-Typen du überhaupt im E-Commerce anbieten willst.

Kunden: B2B braucht mehr als eine E-Mail-Adresse

Im B2B-Kontext – und Infor SX.e ist klassischerweise ein Großhandels-ERP – reicht ein simples Kundenkonto nicht aus. Du brauchst Bill-To / Ship-To-Strukturen (Rechnungsempfänger versus Lieferadressen), Kundengruppen und kundenspezifische Konditionen, Ansprechpartner und Rollen (Einkäufer, Genehmiger) sowie die Zuordnung zu Außendienstmitarbeitern (Sales Reps), falls Shopware als Portal für betreute Kunden dienen soll.

Praxis-Tipp: Kläre früh, ob Kunden völlig autonom agieren oder ob Sales-Reps sich im Shop anmelden und „ihre" Kunden sehen sollen. Das beeinflusst die Architektur erheblich.

Preise: Wer führt, wer überschreibt?

Preislogik ist der häufigste Grund für Integrationsprobleme. In Infor SX.e gibt es Listenpreise, kundenspezifische Preise und Vertragspreise, Staffelpreise (Mengenrabatte) sowie Währungs- und Länderanpassungen. Gleichzeitig bietet Shopware eigene Preis-Mechaniken: Kundengruppen-Preise, Promotions, Rule Builder. Die Frage lautet: Wer darf den finalen Preis bestimmen? Wenn du im Shop Rabatte vergibst, aber SX.e diese nicht akzeptiert, scheitert der Order-Submit oder der Kunde erhält eine Rechnung, die nicht zum Checkout passt.

Empfehlung: Definiere eine klare Pricing-Ownership. Entweder berechnet das ERP alle Preise (auch Promotions werden dort abgebildet) und der Shop zeigt sie nur an – oder der Shop berechnet und das ERP akzeptiert Overrides. Letzteres erfordert spezielle Einstellungen in SX.e.

Verfügbarkeit: Die Kunst, „lieferbar" richtig zu definieren

Nichts frustriert Kunden mehr als falsche Bestandsanzeigen. In Infor SX.e gibt es mehrere Kennzahlen, die auf den ersten Blick ähnlich klingen, aber unterschiedliche Bedeutungen haben:

Ziel: Definiere präzise, welche Kennzahl du im Shop als „verfügbar" anzeigst. Total Available Now ist meist die richtige Wahl für „sofort lieferbar". Wenn du Multi-Warehouse nutzt, brauchst du zusätzlich eine Rollup-Logik oder ein Default-Warehouse.

Praxis-Szenario: Dein Shop zeigt „50 Stück lieferbar", weil die Integration nur On Hand abruft. Tatsächlich sind aber 38 Stück bereits Committed für andere Aufträge. Ein Kunde bestellt 20 Stück – im ERP entsteht ein Backorder, weil nur 12 wirklich frei sind. Der Kunde ist verärgert, der Support überlastet. Lösung: Nutze die korrekte Verfügbarkeitsformel und aktualisiere sie regelmäßig.

Bestellungen: Der kritischste Prozess

Wenn ein Kunde im Shopware-Checkout auf „Jetzt kaufen" klickt, muss die Bestellung sicher und vollständig in Infor SX.e ankommen. Das umfasst Positionen (Artikel, Mengen, Einheiten, Preise), Versandadresse (Ship-To), Rechnungsadresse (Bill-To), Steuern (entweder vom Shop berechnet oder per SX.e-API simuliert), Rabatte und Promotions (mit klarer Regelung, wer sie anwenden darf), Zahlungsreferenzen (Transaktions-ID aus Payment-Gateway) sowie die Web-Order-Number (eindeutige Shop-Referenz).

Fehlerquellen: API ist nicht erreichbar oder antwortet zu langsam (Timeout im Checkout), Preise oder Steuern weichen ab (ERP lehnt Order ab oder korrigiert sie), Artikel nicht mehr lieferbar (Backorder oder Fehlschlag), fehlende Pflichtfelder oder ungültige Adressen (Submit scheitert).

Lösung: Implementiere ein robustes Retry- und Queue-Konzept. Wenn der Submit im Checkout fehlschlägt, darf die Bestellung nicht verloren gehen – sie muss in einer Warteschlange landen, aus der sie manuell oder automatisch erneut versendet werden kann. Monitoring und Alerting sind hier Pflicht.

Status und Historien: Self-Service statt Supportanfragen

Nach dem Kauf wollen Kunden wissen: Wurde die Bestellung bestätigt? Wann wird geliefert? Ist die Rechnung verfügbar? In Infor SX.e durchläuft jeder Auftrag verschiedene Status (Order Entry, Pick, Pack, Ship, Invoice). Diese Statusänderungen sollten zurück in Shopware fließen, damit Kunden sie im Account sehen können.

Standard-Ansatz: Die Integration holt Order- und Invoice-History per Batch aus SX.e. Du kannst die Lookback-Days anpassen, um nur relevante Zeiträume abzurufen. Best Practice: Starte mit einem Backfill (z. B. letzte 12 Monate), aktiviere dann Delta-Updates.

Drei realistische Szenarien: Vom MVP bis zur Hochleistungs-Integration – und was sie kosten

Nicht jede Infor SX.e Shopware Integration ist gleich. Je nach Geschäftsmodell, Kundenbasis und Prozessanforderungen unterscheiden sich Aufwand, Architektur und Risiko erheblich. Hier drei realistische Szenarien mit groben Aufwands- und Kostenspannen:

Szenario A: MVP / Standardnah (Aufwand: 4–8 Wochen, Budget: 15.000–35.000 Euro)

Ziel: Produkte, Kunden, ausreichend aktuelle Preise und Verfügbarkeit, Bestellübertragung – ohne Sonderlogik. Typisch für B2C oder einfache B2B-Setups mit wenigen Kundengruppen, Standardsortiment, keine kundenspezifischen Preise.

Architektur: Produkte per Nightly Batch (z. B. 2 Uhr nachts), Kunden per Batch alle vier Stunden oder bei Änderung, Preise und Verfügbarkeit mit Kurzzeit-Cache (15 Minuten) plus Realtime-Fallback, Bestellungen per Submit via API mit Retry-Queue bei Fehler, Status und Historien per Batch einmal täglich.

Tools: Standard-Connector (falls verfügbar) oder Low-Code-Integrationsplattform. Risiken: Begrenzte Flexibilität bei Sonderanforderungen, Overselling-Risiko bei längeren Cache-Zeiten.

Szenario B: B2B-Portal / Prozessstark (Aufwand: 3–6 Monate, Budget: 50.000–120.000 Euro)

Ziel: Kundenspezifische Preise, Rollen und Rechte, Sortimente, gegebenenfalls Freigabeprozesse (Approvals), belastbarer Status-Rückkanal für Self-Service. Typisch für Großhandel, Distribution, technischen Handel mit festen Kundenbeziehungen und komplexen Vertragsstrukturen.

Architektur: Produkte per Batch nachts, ergänzt um kundenspezifische Sortimente, Kunden per Batch mit Bill-To/Ship-To-Logik, Sales-Rep-Zuordnung, Preise per Realtime-API (kundenspezifisch, Staffel, Vertragspreise), Cache nur für anonyme Nutzer, Verfügbarkeit Realtime, gegebenenfalls Multi-Warehouse-Rollup, Bestellungen per Submit mit erweiterten Validierungen, Payment-Integration, Freigabe-Workflow falls nötig, Status und Historien per Batch mehrmals täglich.

Tools: Individuelle Middleware (z. B. Mulesoft, Boomi, Azure Integration Services) oder stark angepasster Standard-Connector. Risiken: Komplexes Mapping (z. B. Vertragspreise versus Shop-Promotions), Performance-Engpässe bei hoher Last, aufwändiger Betrieb (Monitoring, Support).

Szenario C: Hochkritischer Checkout / Echtzeit-lastig (Aufwand: 6–12 Monate, Budget: 120.000–250.000 Euro und mehr)

Ziel: Sehr aktuelle Preise, Bestände und Steuern im Hot Path, hohe Last (viele parallele Nutzer), strenge SLAs (z. B. Checkout-Antwortzeit unter 2 Sekunden). Typisch für große B2B-Plattformen, Marktplätze oder hochfrequentierte B2C-Shops mit ERP-Integration.

Architektur: Produkte per Batch plus Event-basierte Delta-Updates, Kunden Event-basiert plus Realtime-Fallback, Preise und Verfügbarkeit mit dediziertem Caching-Layer (z. B. Redis) mit Sub-Sekunden-TTL, Realtime-API als Fallback, Bestellungen per Async Submit via Queue, separate Order-Validierungs-API vor Checkout, Status und Historien per Event-Stream oder Polling alle paar Minuten.

Tools: Microservice-Architektur, API-Gateway, Event-Streaming, hochverfügbare Middleware. Risiken: Hoher Entwicklungs- und Betriebsaufwand, Abhängigkeit von SX.e-API-Performance, Versionierungs- und Release-Management wird komplex.

Build vs. Buy: Standard-Connector oder individuelle Integration?

Die Entscheidung „kaufen oder bauen" hängt von mehreren Faktoren ab:

Hinweis: Seit Januar 2023 entwickelt Optimizely (ehemals Insite) die Standard-Connectoren für Infor SX.e nicht mehr aktiv weiter – Bugfixes werden nur noch geliefert, wenn es keine Workarounds gibt. Das bedeutet: Wenn du auf den Standard-Connector setzt, musst du damit rechnen, Sonderanforderungen selbst zu entwickeln oder über Partner umzusetzen.

Aufwandstreiber und Kostenfaktoren: Was macht die Integration wirklich teuer?

Ohne konkrete Preise zu nennen, lassen sich die größten Aufwandstreiber klar benennen:

• Kundenspezifische Preise und Verträge: Jede Sonderlogik (Staffelpreise, Vertragsrabatte, zeitlich begrenzte Aktionen) erhöht Mapping- und Testaufwand erheblich. Faktor: plus 30 bis 50 Prozent Aufwand.
• Multi-Warehouse: Rollup-Logik, Default-Warehouse-Entscheidung, Fulfillment-Routing – jede zusätzliche Komplexität kostet. Faktor: plus 20 bis 40 Prozent Aufwand.
• Komplexe Steuer- und Payment-Prozesse: Echtzeit-Steuerberechnung, mehrere Payment-Gateways, Teilzahlungen, Stornos – jeder Sonderfall muss getestet und abgesichert werden. Faktor: plus 15 bis 30 Prozent Aufwand.
• B2B-Rechte und Freigaben: Rollen, Budgets, Approval-Workflows – falls erforderlich, dominiert das die Projektlaufzeit. Faktor: plus 40 bis 80 Prozent Aufwand.
• Datenqualität: Wenn Stammdaten im ERP unvollständig oder inkonsistent sind, frisst die Bereinigung Wochen bis Monate. Faktor: schwer planbar, oft Projektblocker.
• ERP-API-Performance: Wenn SX.e-APIs langsam sind, brauchst du entweder ERP-Tuning (kostet ERP-Experten-Zeit) oder eine Architektur-Änderung (kostet Dev-Zeit). Faktor: plus 10 bis 50 Prozent Aufwand, je nach Ausgangslage.

Wer macht was? Verantwortlichkeiten in der Infor SX.e Shopware Integration

Integrationsprojekte scheitern oft an unklaren Zuständigkeiten. Hier eine kompakte RACI-Logik:

Praxis-Tipp: Kläre diese Rollen im Kickoff und dokumentiere sie im Projektplan. Wenn später Probleme auftreten (z. B. falsche Bestände), weißt du sofort, wer zuständig ist – und vermeidest Finger-Pointing.

Die vier größten Risiken – und wie du sie entschärfst

Jedes Integrationsprojekt birgt Risiken. Hier die vier kritischsten – und wie du sie entschärfst:

Risiko 1: Overselling

Problem: Kunde bestellt, Shop zeigt „lieferbar", aber im ERP ist nichts mehr da. Ursache: Falsche Verfügbarkeitsdefinition, veralteter Cache, fehlende Reservierung. Gegenmaßnahme: Nutze die korrekte Verfügbarkeitsformel (Total Available Now), setze kurze Cache-TTLs für Hot Paths, implementiere eine Reservierungsstrategie (z. B. Soft-Reservation im Warenkorb für 15 Minuten).

Risiko 2: Preisabweichungen

Problem: Preis im Checkout weicht von ERP-Rechnung ab. Ursache: Shop-Promotions, die SX.e nicht kennt, ERP korrigiert Preise beim Submit, zeitliche Verzögerung. Gegenmaßnahme: Definiere klare Pricing-Ownership, teste alle Rabatt-, Staffel- und Promotion-Kombinationen vor Go-live, aktiviere Override-Flags in SX.e falls nötig.

Risiko 3: Order-Fails

Problem: Bestellung wird im Shop abgeschlossen, aber kommt nie in SX.e an. Ursache: API-Timeout, Netzwerkfehler, ungültige Daten, fehlende Fehlerbehandlung. Gegenmaßnahme: Implementiere Retry-Queue mit Dead-Letter-Mechanik, Monitoring mit Alerts (z. B. Slack, E-Mail), manuelle Review-Möglichkeit für fehlgeschlagene Orders, klare Fehlermeldungen für Support.

Risiko 4: Performance im Checkout

Problem: Checkout dauert mehr als fünf Sekunden, Abbruchrate steigt. Ursache: Langsame SX.e-APIs für Preis, Steuer und Verfügbarkeit, keine Entkopplung, synchrone Calls. Gegenmaßnahme: Kurzzeit-Caching, Async-Calls wo möglich, Timeouts mit Fallback-Regeln, Performance-Tests mit realistischer Last, ERP-API-Tuning.

Minimal-Setup für den Start: Was du wirklich am ersten Tag brauchst

Du musst nicht alles auf einmal bauen. Hier das absolute Minimal-Setup für einen funktionsfähigen Infor SX.e Shopware Shop:

• Produkte: Artikelnummern, Beschreibungen, Kategorien, Bilder – Import per Batch (nachts). Keine Varianten, keine kundenspezifischen Sortimente.
• Preise: Listenpreise – Import per Batch (nachts) oder Cache mit 15-Minuten-TTL. Keine Staffelpreise, keine kundenspezifischen Preise.
• Verfügbarkeit: Total Available Now – Cache mit fünf bis 15 Minuten TTL, Single-Warehouse. Keine Reservation, keine Multi-Warehouse-Logik.
• Kunden: E-Mail, Name, Adresse – Registrierung im Shop, manuelles Matching mit SX.e-Kundennummer (später automatisierbar). Keine Bill-To/Ship-To-Strukturen.
• Bestellungen: Submit per API, Retry-Queue bei Fehler, manuelle Review für Fails. Keine Freigaben, keine automatische Statusrückmeldung.
• Payment: Standard-Gateway (z. B. Stripe), Referenz wird an SX.e übergeben. Keine komplexen Zahlungsmethoden (Kauf auf Rechnung, Raten).

Mit diesem Setup kannst du in vier bis sechs Wochen live gehen – und dann iterativ erweitern (kundenspezifische Preise, Varianten, Multi-Warehouse, Self-Service-Status, Freigaben).

Checkliste für die Agentur- und Anbieterauswahl: Darauf solltest du achten

Wenn du eine Agentur oder einen Integrationspartner suchst, prüfe diese Punkte:

• Erfahrung mit Infor SX.e: Hat die Agentur bereits SX.e-Projekte umgesetzt? Kann sie Referenzen nennen? Kennt sie die Verfügbarkeitslogik, Pricing-APIs, Batch-Jobs?
• Shopware-Expertise: Hat die Agentur Shopware-6-Projekte gemacht? Kennt sie B2B-Suite, Rule Builder, API-first-Architektur?
• Integrationsarchitektur: Kann die Agentur Middleware bauen oder nutzt sie nur Standard-Connectoren? Kennt sie Event-Streaming, Queues, Caching?
• Testing und QA: Hat die Agentur einen strukturierten Test-Ansatz (Unit, Integration, Last, User Acceptance)? Werden Edge-Cases getestet?
• Betrieb und Support: Bietet die Agentur Monitoring, Alerting, 24/7-Support? Gibt es Runbooks für typische Fehlerszenarien?
• Transparenz bei Aufwand und Risiken: Nennt die Agentur klare Aufwandsspannen? Benennt sie Risiken offen? Oder verspricht sie „plug & play" ohne Wenn und Aber?
• Flexibilität: Kann die Agentur auch individuelle Anforderungen umsetzen (z. B. Sonder-Mappings, Custom-Workflows)? Oder ist sie auf Standard-Connectoren beschränkt?

Rote Flaggen: Agentur kennt SX.e nicht, verspricht Festpreise ohne Anforderungsanalyse, bietet keinen Support nach Go-live, hat keine Referenzen in ERP-Integration.

Fazit: So gehst du die Infor SX.e Shopware Integration richtig an

Eine Infor SX.e Shopware Integration ist kein Plug-and-Play-Projekt – aber mit klarer Strategie, realistischer Planung und den richtigen Partnern absolut machbar. Die wichtigsten Takeaways:

• Verstehe deine Anforderungen: MVP, B2B-Portal oder Hochleistungs-Setup? Definiere das vor dem ersten Gespräch mit Agenturen.
• Definiere Systemführerschaften: Wer führt Preise? Wer führt Verfügbarkeit? Wer darf Promotions vergeben? Diese Entscheidungen treiben Architektur und Aufwand.
• Nutze die richtige Verfügbarkeitsformel: Total Available Now, nicht nur On Hand. Das allein verhindert 80 Prozent aller Overselling-Probleme.
• Plane Retry und Monitoring: Order-Fails werden passieren – die Frage ist, ob du sie rechtzeitig bemerkst und beheben kannst.
• Starte klein, erweitere iterativ: Minimal-Setup (Produkte, Listenpreise, einfache Verfügbarkeit, Order-Submit) kann in vier bis sechs Wochen live gehen. Dann Schritt für Schritt erweitern.
• Wähle Partner mit ERP-Erfahrung: Shopware-Expertise allein reicht nicht – du brauchst jemanden, der SX.e kennt und Integrationen bauen kann. Für den generellen Projekt-Check vor dem Start kann auch ein Shopware-Check hilfreich sein.
• Budget realistisch kalkulieren: MVP ab 15.000 Euro, B2B-Portal 50.000 bis 120.000 Euro, Hochleistung 120.000 Euro und mehr. Datenqualität und Sonderlogik treiben Kosten massiv.

Wenn du diese Prinzipien befolgst, vermeidest du die typischen Fails (Overselling, Preisabweichungen, Order-Fails, Performance-Probleme) und baust eine Integration, die skaliert, stabil läuft und deine Kunden begeistert.