Integrationsmuster
Jede Verbindung, die Sie zwischen der Revenue Cloud und einem anderen System bauen, hat eine von drei Formen. Die falsche Form zu wählen ist die teuerste Entscheidung in einem Integrationsprojekt, und sie fällt meist im ersten Meeting, aus Versehen.
Die drei Formen
Batch. Daten bewegen sich nach Zeitplan. Eine Datei oder ein API-Lauf um 02:00 Uhr bringt die Produktänderungen der Nacht herüber, ein weiterer um 06:00 Uhr die Preise. Batch ist auf Durchsatz ausgelegt: Es verarbeitet große Mengen billig, weil niemand darauf wartet. Scheitert es, führen Sie es erneut aus.
Echtzeit. Die Revenue Cloud stellt dem anderen System in dem Moment eine Frage, in dem jemand die Antwort braucht, und wartet. Ein Käufer öffnet eine Produktseite, und der Shop fragt das ERP nach dem Preis dieses Kunden und dem aktuellen Bestand. Nichts wird gespeichert; die Antwort ist so frisch wie die Quelle und so langsam wie die Quelle.
Hybrid. Der Großteil der Daten kommt per Batch, und eine kleine, bewusst gewählte Menge an Feldern wird live abgefragt. Dabei landet fast jedes echte Projekt, und es lohnt sich, das direkt anzusteuern, statt nach zwei Umbauten dort anzukommen.
Welches Muster für welche Daten
Die nützliche Frage zu einem Feld lautet: Wie falsch darf es sein, und wie lange? Zu fragen, wie wichtig es ist, führt nirgendwohin, denn wichtig ist alles.
| Daten | Änderungsrate | Kosten, wenn veraltet | Muster |
|---|---|---|---|
| Produktstammdaten, Beschreibungen, Attribute | Niedrig | Niedrig; eine Beschreibung von gestern ist in Ordnung | Batch, nächtlich |
| Kategorien, Familien, Medien | Niedrig | Niedrig | Batch, nächtlich oder auf Abruf |
| Listenpreise, Preislisten | Niedrig bis mittel | Mittel; ein falscher Listenpreis ist peinlich | Batch, nächtlich |
| Kunden- und Vertragspreise | Mittel | Hoch; ein falscher Vertragspreis ist eine Gutschrift | Echtzeit, oder Batch mit Live-Prüfung im Warenkorb |
| Bestand und Verfügbarkeit | Hoch | Hoch; ein Lieferversprechen auf einen nicht vorrätigen Artikel kostet einen Anruf | Echtzeit, mit zwischengespeichertem Fallback |
| Kundenstamm, Organisationen, Kontakte | Niedrig | Mittel | Batch, plus Echtzeit bei der ersten Anmeldung |
| Kreditlimit, Sperrstatus | Mittel | Sehr hoch; an einen gesperrten Kunden dürfen Sie nicht liefern | Echtzeit beim Checkout |
| Bestellungen ins ERP | Ereignisgetrieben | Sehr hoch | Event, sofort, mit Wiederholungen |
| Bestellstatus, Lieferscheine, Rechnungen | Mittel | Mittel | Batch, mehrmals täglich |
Lesen Sie die Tabelle als Ausgangsposition, nicht als Regel. Ein Ersatzteilgeschäft, in dem ein vorrätiger Artikel den Unterschied zwischen einer laufenden und einer stehenden Maschine macht, braucht Live-Bestand. Ein Großhändler, der aus einem vollen Lager liefert, kann einen zwei Stunden alten Bestandswert mit Hinweis anzeigen und sich eine Integration sparen.
Warum „alles in Echtzeit“ meist falsch ist
Es klingt nach der sicheren Wahl. Es ist die teure, aus vier Gründen.
Ihr Shop erbt die Verfügbarkeit des ERP. Ein synchroner Aufruf bedeutet, dass die Seite nicht rendern kann, bevor das ERP antwortet. Ist das ERP am Sonntagabend in Wartung, ist Ihr Shop am Sonntagabend down. Braucht es an einem schlechten Tag 900 ms, braucht Ihre Kategorieseite an einem schlechten Tag 900 ms je Produkt.
Die Last vervielfacht sich dort, wo Sie sie nicht steuern. Eine Kategorieseite mit 48 Produkten sind 48 Preisaufrufe und 48 Bestandsaufrufe, und ein Crawler auf Ihrem Katalog macht daraus einen Lasttest Ihres ERP, den niemand geplant hat. Die meisten ERP-Systeme wurden für die Zahl der Menschen im Innendienst dimensioniert, nicht für das Internet.
Sie können nicht nach Daten suchen oder filtern, die Sie nicht halten. „Zeig mir alle Artikel unter 50 €, die vorrätig sind“ ist unmöglich, wenn Preis und Bestand in einem anderen System liegen und nur je Produkt abgerufen werden. Facettierte Suche braucht die Daten lokal.
Die Fehlersuche wird schwerer. Bei Batch haben Sie eine Datei und ein Protokoll: Sie sehen genau, was angekommen ist, und führen es erneut aus. Bei Echtzeit haben Sie einen Moment, der vorbei ist, und einen Käufer, der sagt, der Preis sei vor fünf Minuten ein anderer gewesen.
Die Gegenrichtung hat einen passenden Fehler, und der verdient einen Namen: Eine rein nächtliche Integration bedeutet, dass Ihr Shop den Käufern von der Welt von gestern erzählt. Im technischen Großhandel reicht das, um den Kanal zu verlieren, denn der Grund, warum Menschen den Innendienst anrufen, statt online zu bestellen, ist, dass sie der Verfügbarkeit auf dem Bildschirm nicht glauben.
Idempotenz: die Eigenschaft, die Wiederholungen sicher macht
Eine Operation ist idempotent, wenn sie zweimal ausgeführt dieselbe Wirkung hat wie einmal. Diese Eigenschaft entscheidet, ob eine gescheiterte Integration ein fünfminütiger Wiederholungslauf ist oder ein Abend Handarbeit.
Dinge scheitern auf halbem Weg. Eine Dateiübertragung bricht bei Zeile 40.000 von 60.000 ab. Ein Bestellaufruf läuft in den Timeout, und ein Timeout sagt Ihnen nichts darüber, ob die andere Seite ihn verarbeitet hat. Sind Ihre Operationen idempotent, lautet die Antwort in beiden Fällen „noch einmal ausführen“. Sind sie es nicht, lautet sie „erst herausfinden, was durchgekommen ist“.
Drei Regeln machen es möglich:
- Über einen stabilen Geschäftsschlüssel abgleichen, nie über einen
technischen. Produkte über die SKU
4711-A, Kunden über ihre ERP-Kundennummer, Bestellungen über Ihre Bestellnummer. Eine interne Datenbank-ID, die das andere System nie gesehen hat, ist kein Schlüssel, über den Sie abgleichen können. - Upsert statt Insert. Jeder Import sollte bedeuten „mach den Datensatz so“, nicht „lege einen Datensatz an“. Ein Wiederholungslauf konvergiert dann, statt Dubletten zu erzeugen. Deshalb gleicht der Produktimport über die SKU ab und aktualisiert; siehe Produkte in Masse importieren.
- Jeder ausgehenden Nachricht eine ID geben und vom Empfänger Deduplizierung erwarten. Dieselbe Bestellung, zweimal mit derselben Bestellnummer übertragen, ist eine Bestellung. Dieselbe Bestellung, zweimal mit zwei generierten IDs übertragen, sind zwei Lieferungen und ein unangenehmer Anruf.
Der klassische Fehler ist eine nächtliche Bestandsdatei, die als Delta statt als Zustand angewendet wird. Zweimal ausgeführt ist der Bestand um genau die Bewegungen einer Nacht falsch, still, ohne irgendeinen Fehler. Vollzustandsdateien sind langweilig und sicher; Deltas sind effizient und unnachsichtig.
Volllauf oder Delta
Eine verwandte Entscheidung, dieselbe Abwägung:
| Volllauf | Delta | |
|---|---|---|
| Volumen | Alles, bei jedem Lauf | Nur, was sich geändert hat |
| Laufzeit | Lang, bei einem großen Katalog Stunden | Kurz |
| Erholung nach einem verpassten Lauf | Automatisch, der nächste Lauf repariert es | Manuell; die Lücke bleibt eine Lücke |
| Löschungen | Sichtbar: Was fehlt, ist weg | Nur, wenn die Quelle ein Löschsignal sendet |
| Gut für | Kataloge bis zu einigen Hunderttausend Artikeln, nächtlich | Sehr große Kataloge, oder häufige Läufe |
Ein verbreiteter und tragfähiger Kompromiss: Deltas unter der Woche, ein Volllauf am Wochenende, der repariert, was die Deltas verpasst haben. Fahren Sie nur Deltas, planen Sie, wie Sie erfahren, dass ein Artikel vorgelagert gelöscht wurde; sonst wächst Ihr Katalog um Artikel, die es nicht mehr gibt, und niemand merkt es, bis ein Käufer einen bestellt.
So funktioniert es in der Revenue Cloud
- Batch-Läufe sind Workflows im Integration Studio mit Zeitplan; siehe Einen Workflow bauen. Ein Lauf behält sein Protokoll, Sie sehen also, was angekommen ist, und führen ihn erneut aus.
- Echtzeit-Aufrufe passieren, wenn eine Seite oder ein Warenkorb sie braucht, gegen ein angebundenes System; siehe Ein System anbinden.
- Ereignisgetriebene Flüsse reagieren darauf, dass hier etwas passiert, etwa eine aufgegebene Bestellung, und schieben nach außen; siehe Events und Webhooks.
- Dateien sind nach wie vor der Großteil der deutschen B2B-Integration, und sie sind eine vollwertige Option. Import- und Exportprofile unter Data Exchange beschreiben die Struktur einer Datei und ihr Mapping, und der eingebaute SFTP-Server gibt einem ERP einen Ort, an dem es eine CSV ablegen kann, ohne dass jemand eine API baut. Ein Ordner, eine Namenskonvention und ein Zeitplan sind eine funktionierende Integration.
Was auch immer Sie wählen: Entscheiden Sie zuerst, welches System welches Feld besitzt. Diese Entscheidung steht über dem Muster, und sie ist das Thema des nächsten Artikels.
Weiter
- Das führende System festlegen: wer welches Feld besitzt.
- Syncs überwachen: wissen, dass ein Feed kaputt ist, bevor Ihre Käufer es wissen.