Spis treści
Warum die Systemintegration über API über die Leistungsfähigkeit eines Unternehmens entscheidet
Fast jedes wachsende E-Commerce-Unternehmen läuft früher oder später gegen dieselbe Wand: Die Daten stecken in getrennten Systemen, und die reden nicht miteinander. Der Shop kennt die Bestellungen, das CRM die Kunden, das ERP die Rechnungen, das Lager wacht über die Bestände – und jede dieser Welten macht ihr eigenes Ding, auf ihre eigene Art. Die Systemintegration über API ist die Schicht, die diese Inseln zu einem einzigen Informationskreislauf verbindet. Statt Menschen Daten von einer Anwendung in die andere übertragen zu lassen.
Und das ist kein abstraktes Problem. Das ist ein realer Kostenfaktor. Ein Mitarbeiter, der eine Bestellung aus dem Shop ins ERP abtippt, verliert Zeit, und irgendwann vertippt er sich – es ist nur eine Frage der Zeit. Lagerbestände, die einmal täglich aktualisiert werden? Bitte sehr, dann verkaufen Sie etwas, das physisch längst nicht mehr im Regal liegt. Verzögerungen im Informationsfluss treffen den Kundenservice, und inkonsistente Daten können jeden Bericht zerlegen.
Die Symptome fehlender Integration sind recht charakteristisch. Dazu gehören unter anderem:
- wiederkehrende Reklamationen aufgrund falscher Lagerbestände,
- Bestellungen, die irgendwo zwischen Shop und Fulfillment “verloren gehen”,
- mehrere Versionen derselben Kundenkartei in verschiedenen Systemen,
- Vertriebsberichte, die nie zusammenpassen.
Im Team von Web Systems behandeln wir Integration als Architekturprojekt und nicht als einmaliges Skript, das zwei Systeme an der Nahtstelle zusammenklebt. Ein Skript löst die Sache für heute. Aber bei der ersten API-Änderung des Anbieters funktioniert es nicht mehr, und niemand weiß mehr, warum. Eine gut entworfene Integration geht von vornherein davon aus, dass sich etwas ändern wird, definiert klar, wofür jedes System zuständig ist, und beschreibt, was passiert, wenn etwas schiefgeht. Seit 2006 befassen wir uns mit der Entwicklung von Software nach Maß und wissen eines: Der Unterschied zwischen Provisorium und durchdachter Architektur zeigt sich erst im dritten Monat, wenn das Bestellvolumen zu wachsen beginnt.
Die Datenflusskarte: was wir zwischen Shop, CRM, ERP und Lager wirklich verbinden
Bevor wir die erste Zeile Code schreiben, zeichnen wir eine Datenflusskarte. Ohne sie wird die Integration zu einem Gewirr von Verbindungen, das später niemand mehr entwirrt. Der typische Kreislauf in einem Handelsunternehmen sieht recht vorhersehbar aus – nur steckt der Teufel wie immer im Detail jedes einzelnen Schritts.
Der Standardweg einer Bestellung verläuft folgendermaßen:
- der Kunde gibt im Shop eine Bestellung auf,
- das Payment-Gateway bestätigt die Zahlung,
- im ERP entstehen ein Verkaufsbeleg und eine Rechnung,
- das Lager reserviert konkrete Bestände für die Abwicklung,
- im CRM werden der Kontakt und die Kaufhistorie des Kunden aktualisiert.
Und auf jeder dieser Stufen kehrt dieselbe Frage wieder: Welches System ist die Quelle der Wahrheit für den jeweiligen Datentyp. Dieser Begriff, in der Anwendungsarchitektur als single source of truth bekannt, bedeutet, dass es für jede Art von Information genau einen Eigentümer gibt, der sie ändern darf. Der Produktpreis kann aus dem ERP stammen, Beschreibung und Fotos aus dem Shop, der Lagerbestand aus dem WMS und die Kontaktdaten des Kunden aus dem CRM.
Schwierig wird es dort, wo zwei Systeme über denselben Datensatz herrschen wollen. Wenn sowohl der Shop als auch das ERP den Preis ändern dürfen, werden sie früher oder später zwei verschiedene Werte eintragen, und die Synchronisation beginnt, sie in zufälliger Reihenfolge zu überschreiben. Und schon haben wir das fertige Rezept für doppelte Karteien, Bestandskonflikte und die klassische Situation, in der niemand weiß, welche Zahl die richtige ist.
Deshalb ist die erste Entwurfsentscheidung, eindeutig festzulegen, wer hier das Sagen hat. Wir benennen das Master-System für Preise, für Lagerbestände und für personenbezogene Daten und behandeln den Rest als Empfänger dieser Information. Diese Disziplin räumt die meisten Konflikte aus, bevor sie überhaupt entstehen. Die Flusskarte wird nebenbei zur Dokumentation, zu der man bei jeder weiteren Änderung zurückkehrt – etwa wenn das Unternehmen einen zweiten Vertriebskanal oder ein neues Zahlungssystem ergänzt.
Muster der API-Integration: REST, Webhooks, Queues und Batch-Synchronisation
Es gibt keinen universellen Weg, Systeme zu verbinden. Die Wahl des Musters hängt vom Volumen ab, davon, welche Verzögerungen Sie schlucken können, und davon, was die API des Anbieters real bereitstellt. Am häufigsten greifen wir zu REST mit Abfragen (Polling), ereignisgesteuerten Webhooks, Message Queues und Batch-Synchronisation – und mischen das je nach konkretem Ablauf.
REST mit Polling ist nichts anderes als die zyklische Frage an ein System: “Gibt es neue Bestellungen?” Einfach, berechenbar, belastet aber bei häufiger Abfrage die API und bringt Verzögerung mit. Webhooks funktionieren umgekehrt: Das Quellsystem meldet uns ein Ereignis selbst, in dem Moment, in dem es eintritt. Die Reaktion ist nahezu sofort, man braucht nur einen zuverlässigen Empfänger und muss den Fall einplanen, dass eine Benachrichtigung schlicht nicht ankommt.
Bei hohem Bestellvolumen lohnt sich die Einführung einer Message Queue und eines Event-Brokers. Die Queue wirkt als Puffer – sie nimmt Ereignisse schneller an, als die Zielsysteme sie verarbeiten können, und gibt sie dann in kontrolliertem Tempo weiter. Dadurch verstopft eine Verkaufsspitze das ERP nicht, und keine Bestellung verdampft während einer kurzzeitigen Überlastung.
Wichtig ist auch die Entscheidung: Punkt-zu-Punkt-Integration oder eine Zwischenschicht? Das Verbinden “jeder mit jedem” funktioniert bei zwei, drei Anwendungen. Aber bei fünf wird daraus ein nicht mehr wartbares Spinnennetz. Middleware, also eine dedizierte Integrationsschicht, zentralisiert die Logik des Datenaustauschs und senkt die Kosten späterer Änderungen.
Die Synchronisation richten wir nach dem Charakter der Daten aus. Lagerbestände und Zahlungsstatus verlangen einen Modus nahe der Echtzeit. Berichte oder Katalogaktualisierungen wiederum vertragen problemlos einen Batch-Modus, der alle paar Stunden läuft.
Tipp: Gehen Sie bei der Wahl des Musters vier Kriterien durch – Transaktionsvolumen, zulässige Verzögerung, Kritikalität der Daten und das, was die API des Anbieters wirklich kann. Der letzte Punkt landet am häufigsten unter dem Tisch, und gerade er entscheidet, ob Webhooks überhaupt infrage kommen.
Typische Fehler und Fallen, die in Integrationsprojekten am meisten kosten
Die teuersten Fehler in Integrationen entstehen nicht durch exotische Technologien. Sie entstehen dadurch, dass einige grundlegende Prinzipien übergangen werden. Wir sehen sie regelmäßig, wenn wir Projekte übernehmen, die zuvor jemand anderes “auf die Schnelle” umgesetzt hat. Die meisten Probleme laufen auf eines hinaus: fehlende Robustheit gegenüber untypischen Situationen.
Die erste Sünde ist fehlende Idempotenz. Idempotenz bedeutet, dass dieselbe Operation zweimal ausgeführt dasselbe Ergebnis liefert wie einmal ausgeführt. Ohne sie erzeugt ein erneuter Sendeversuch einer Bestellung nach einer fehlgeschlagenen Verbindung ein zweites, doppeltes Dokument und belastet im Extremfall die Zahlung doppelt. Das Heilmittel? Jeder Operation einen eindeutigen Schlüssel geben, den das Zielsystem erkennt und bei Wiederholung einfach verwirft.
Die zweite Falle ist das Ignorieren von Limits und Timeouts externer APIs. Jedes Payment-Gateway und jedes ERP setzt ein Rate Limit, also eine maximale Zahl von Anfragen pro Zeiteinheit. Eine Integration, die davon nichts weiß, wird im denkbar schlechtesten Moment blockiert – mitten im Ausverkauf. Ebenso kann ein nicht behandelter Timeout den gesamten Ablauf einfrieren, während er endlos auf eine Antwort wartet, die nie kommt.
Der dritte Fehler: keine Wiederholungs-Queue. Systeme sind mitunter kurzzeitig nicht erreichbar. Das ERP durchläuft ein Update, das Gateway hat eine Wartungspause – ganz normal. Eine Integration ohne Retry-Mechanismus verliert solche Ereignisse schlicht. Eine ausgereifte Lösung speichert die fehlgeschlagene Operation, wiederholt sie mit wachsendem Zeitabstand, und wenn die Versuche erschöpft sind, landet sie in einer Queue, die manuelles Eingreifen erfordert.
Die vierte Falle ist architektonischer Natur: die harte Kopplung an einen konkreten Anbieter. Wenn der Integrationscode eng auf ein einziges Payment-Gateway zugeschnitten ist, bedeutet ein Anbieterwechsel, das halbe System neu zu schreiben. Klüger ist es, auf Abstraktion zu setzen – eine gemeinsame Schnittstelle, hinter der wir die Details des konkreten Anbieters verbergen. Dann ist der Austausch einer Komponente eine punktuelle Änderung und kein kostspieliges Projekt von null.
Sicherheit, Daten und Compliance in API-Integrationen
Eine Integration schiebt sensible Daten durchs Netz: Bestellungen, Rechnungen, personenbezogene Daten von Kunden, Zahlungsinformationen. Sicherheit ist hier weder Zugabe noch Option für später. Sie ist eine Randbedingung. Aus Erfahrung weiß ich, dass das Nachrüsten von Schutzmaßnahmen nach der Einführung ein Vielfaches dessen kostet, was es kostet, sie von Anfang an einzuplanen.
Die Grundlage sind Authentifizierung und Autorisierung. Einfache API-Schlüssel bewähren sich in einfachen Fällen, aber für Verbindungen, die personenbezogene Daten verarbeiten, empfehlen wir OAuth2 mit Tokens von begrenzter Lebensdauer. Ebenso wichtig ist die Rotation der Geheimnisse – der regelmäßige Austausch von Schlüsseln und Tokens, damit ein möglicher Abfluss nur ein begrenztes Zeitfenster hat. Ein statischer Schlüssel, der sich jahrelang nicht ändert, ist ein Risiko, das irgendwo im Hintergrund anwächst.
Die gesamte Übertragung muss verschlüsselt sein und der Umfang der übertragenen Daten auf das notwendige Minimum gekürzt werden. Wenn das Lager nur die Bestellnummer und die Produktliste braucht, warum sollten dort die vollständigen Kreditkartendaten des Kunden landen? Der Grundsatz der Datenminimierung verkleinert die Angriffsfläche und vereinfacht die Einhaltung der Vorschriften.
Personenbezogene Daten in CRM und ERP unterliegen der DSGVO. Das bedeutet die Pflicht, Zugriffe zu protokollieren, zu kontrollieren, wer wann welche Informationen gelesen hat, sowie die Möglichkeit, sie auf Verlangen zu löschen. Eine Integration sollte diese Anforderungen respektieren und sie nicht der Bequemlichkeit halber umgehen. Ein gut entworfener Ablauf erlaubt es zu benennen, welchen Weg ein personenbezogenes Datum genommen hat und wo es zum Stehen kam.
Tipp: Bewahren Sie Geheimnisse niemals im Code oder im Repository auf. Niemals. Schlüssel und Passwörter gehören in einen dedizierten Secret Store (Vault) oder in Umgebungsvariablen, fern von der Anwendungslogik. Es lohnt sich außerdem, API-Verträge zu versionieren, also die formalen Beschreibungen dessen, welche Daten die Systeme in welcher Struktur austauschen. Versionierung sorgt dafür, dass eine Änderung auf Seiten eines Systems die Integration mit dem Rest nicht still und leise kaputtmacht.
Skalierbarkeit, Monitoring und Betrieb der Integration nach der Einführung
Die Einführung ist nicht das Ende. Sie ist erst der Anfang des Lebens einer Integration. Viele Kunden nehmen an, einmal verbundene Systeme würden unbeaufsichtigt endlos weiterlaufen – dabei ist eine Integration ein lebender Organismus. Anbieter ändern ihre APIs, veröffentlichen neue Versionen, ziehen alte Endpunkte zurück. Und jede solche Änderung kann den Datenfluss still und leise abreißen lassen.
Deshalb planen wir das Monitoring von Anfang an ein. Ohne es ist die erste Information über eine Störung häufig ein Anruf eines verärgerten Kunden, dessen Bestellung nicht abgewickelt wurde. Ein sinnvolles Monitoring umfasst mindestens:
- Alarme über fehlgeschlagene Synchronisationen, die in Echtzeit an das Team gehen,
- ein Dashboard mit der Zahl der verarbeiteten und der abgewiesenen Ereignisse,
- Metriken zur Verzögerung zwischen Bestelleingang und Erscheinen im ERP,
- die Kontrolle der wachsenden Wiederholungs-Queue, die ein anwachsendes Problem anzeigt.
Ebenso wichtig ist die Ende-zu-Ende-Verfolgung einer Bestellung. Wenn etwas schiefgeht, müssen wir eine einzelne Transaktion vom Klick im Shop über Zahlung und ERP bis zur Reservierung im Lager nachvollziehen können. Konsistente Logs mit einer Korrelations-ID verkürzen die Diagnose von Stunden auf Minuten. Ohne sie gleicht die Ursachensuche dem Durchsehen mehrerer getrennter Journale ohne gemeinsamen Bezugspunkt.
Eine eigene Sache ist die Skalierung für saisonale Spitzen. Black Friday oder die Vorweihnachtszeit können den Verkehr binnen weniger Stunden vervielfachen. Eine Architektur auf Basis von Queues und durchdachter Pufferung nimmt eine solche Spitze ohne Verlust der Bestandskonsistenz auf. Eine Punkt-zu-Punkt-Integration? Die verstopft einfach. Bei Web Systems planen wir die Leistung mit Reserve, denn sie mitten in der Verkaufsspitze nachzurüsten ist der denkbar schlechteste Moment für Änderungen. Und der Betrieb ist ebenfalls ein Budgetposten, den man besser im Voraus einplant.
FAQ – die häufigsten Fragen zur Integration von Shop, CRM, ERP und Zahlungen
Nachfolgend haben wir die Fragen gesammelt, die wir in Gesprächen über Integration am häufigsten von Kunden hören. Die Antworten stützen sich auf reale Projekte und nicht auf Allgemeinplätze.
Wie lange dauert die Umsetzung einer API-Integration zwischen Shop und ERP?
Das hängt vor allem von der Reife der APIs beider Systeme und von der Zahl der zu verbindenden Abläufe ab. Eine einfache Integration von Bestellungen und Lagerbeständen bei gut dokumentierter API ist meist in wenigen Wochen abgeschlossen. Umfangreichere Projekte – Rechnungen, Korrekturen, mehrere Vertriebskanäle, untypische Geschäftsregeln – brauchen mehr Zeit. Und interessanterweise nimmt nicht das Programmieren selbst die meiste Zeit in Anspruch, sondern die Abstimmung der Quellen der Wahrheit und die Behandlung der Randfälle, die zuvor niemand beschrieben hat.
Ist ein fertiges Plugin besser oder eine dedizierte Integration über API?
Ein fertiges Plugin ist mitunter eine gute Wahl für den Start, wenn die Prozesse standardisiert sind und in seine Annahmen passen. Das Problem tritt bei untypischen Regeln zutage: eigener Logik der Bestandsreservierung, mehreren Lagern, einem speziellen Rechnungsumlauf. Dann erweist sich eine dedizierte Integration trotz höherer Einstiegskosten als günstiger im Betrieb – weil sie das Unternehmen nicht zwingt, sich den Grenzen des Werkzeugs zu beugen. Häufig empfehlen wir einen Mittelweg – eine dedizierte Schicht über bewährten Komponenten.
Was passiert, wenn eines der Systeme nicht mehr antwortet?
In einer gut entworfenen Integration geht nichts verloren. Ereignisse landen in einer Queue, werden mit wachsendem Abstand wiederholt und nach Wiederherstellung des Systems der Reihe nach verarbeitet. Der Kunde bemerkt die Störung nicht einmal, und das Team erhält einen Alarm und kann reagieren, bevor das Problem wächst.
Fazit und Kontakt – Integration als Investition in die Konsistenz des Unternehmens
Eine gut entworfene Systemintegration über API ist kein Kostenblock, sondern eine Investition, die sich in geordneten Daten auszahlt. Sie senkt die Fehler aus manuellem Abtippen, beschleunigt die Bestellabwicklung und sorgt dafür, dass die Berichte endlich stimmen. Statt mehrerer Inseln mit je eigener Version der Wahrheit erhält das Unternehmen einen konsistenten Informationskreislauf, in dem jedes System eine klar zugewiesene Rolle hat.
Aus unserer Erfahrung gibt es vier Entscheidungen, die man gleich zu Beginn bewusst treffen sollte:
- Quelle der Wahrheit – eindeutige Benennung des führenden Systems für Preise, Bestände und Kundendaten.
- Muster des Datenaustauschs – Auswahl von REST, Webhooks, Queues oder Batch-Synchronisation passend zu realem Volumen und Anforderungen.
- Sicherheit – Authentifizierung, Verschlüsselung, Datenminimierung und DSGVO-Konformität.
- Betrieb – Monitoring, Alarme und Robustheit gegenüber API-Änderungen der Anbieter sowie saisonalen Spitzen.
Jedes dieser Elemente lässt sich gut entwerfen oder auf später verschieben und im Betrieb vielfach bezahlen. Und genau diesen Unterschied sieht man nach einigen Monaten Systemlaufzeit, wenn die Zahl der Bestellungen steigt und Situationen auftreten, die ein provisorisches Skript nie vorgesehen hat.
Web Systems ist ein software house aus Łódź, das seit 2006 Web- und Mobilanwendungen, B2B-Systeme, API-Integrationen, Automatisierungen, E-Commerce und Lösungen auf Basis Künstlicher Intelligenz (KI) entwirft und umsetzt. Wenn Sie die Verbindung von Shop, CRM, ERP, Zahlungen und Lager planen, ein MVP einer neuen Anwendung bauen oder über Automatisierung bzw. Modernisierung eines bestehenden Systems nachdenken, nehmen Sie Kontakt mit uns auf – wir sagen Ihnen, womit Sie anfangen und wie Sie es so machen, dass es auch bei größerer Skalierung funktioniert.
