Integration Studio

Im Integration Studio spricht die Revenue Cloud mit allem um sie herum. Ihr ERP, Ihr PIM, Ihr CRM, Ihr Lager, Ihr DATEV-Export — und in der Gegenrichtung die Beschaffungssysteme Ihrer Kunden. Es ist eine visuelle Arbeitsfläche, kein Code-Editor. Das zählt, weil in den meisten Mittelstandsunternehmen die Person, die weiß, was ein Artikelstamm-Feld bedeutet, nicht die ist, die Integrationscode schreibt.

Was hier liegt

Workflows sind die Arbeitseinheit. Ein Workflow hat einen Auslöser — einen Zeitplan, ein Event, einen eingehenden Webhook, eine ankommende Datei — und dann eine Kette von Bausteinen, die lesen, umformen, verzweigen und schreiben. „Jede Nacht um 03:00 den Artikelexport aus dem ERP lesen, die Felder mappen, Produkte anlegen oder aktualisieren und melden, was fehlschlug" ist ein Workflow. Workflows sind dauerhaft: Ein Lauf, der um 03:00 startet und vierzig Minuten braucht, übersteht einen Neustart mittendrin, und Sie sehen, wo er stand, als er anhielt.

Ausführungen sind das, was beim Ausführen passiert ist. Jede hat einen Status, eine Dauer, die berührten Datensätze und die Fehler. Diesen Bildschirm öffnen Sie, wenn jemand sagt, die Bestände seien veraltet. Ein Workflow, der nicht gelaufen ist, ist ein anderes Problem als einer, der lief und in Zeile 4.812 scheiterte — die Liste unterscheidet beides.

Zeitpläne entscheiden, wann zeitgesteuerte Workflows starten. Zugangsdaten halten die Verbindungsdaten eines externen Systems — Host, Benutzer und die erwartete Authentifizierung. Secrets halten die Werte, die in keiner Workflow-Definition sichtbar sein sollen. Dass Zugangsdaten getrennt von Workflows liegen, ist der Grund, warum derselbe Workflow erst auf ein Test-ERP und dann auf Produktion zeigen kann, ohne dass ihn jemand umbaut.

Connectors — der Marketplace, installierte Integrationen und Ihre eigenen — sind vorgebaute Teile für konkrete Systeme. Eine installierte Integration bringt eigene Bausteine mit, und Workflows nutzen sie als Node, statt dass Sie rohe HTTP-Aufrufe zusammensetzen.

Events sind das Signal der Plattform selbst. Etwas passiert in der Revenue Cloud — eine Bestellung geht ein, ein Produkt ändert sich, ein Kunde registriert sich — und ein Event wird ausgelöst. Der Event-Katalog listet, welche Events es gibt und was jedes trägt; der Event-Stream zeigt die, die tatsächlich gefeuert haben. Events sind der Weg, sofort zu reagieren statt auf den nächsten Nachtlauf zu warten — der Unterschied zwischen einer Bestellung, die das ERP in vier Sekunden erreicht, und einer in vier Stunden.

Webhooks sind Events über die Grenze. Eingehende Webhooks lassen ein externes System in einen Workflow schieben. Ausgehende Webhooks schieben Plattform-Events an eine URL, die Ihnen gehört. Der Webhook ist die Option mit wenig Zeremonie; der Workflow die mit Fehlerbehandlung, Wiederholungen und Historie. Beginnen Sie mit dem Webhook — und wechseln Sie zum Workflow, sobald Sie zum ersten Mal wissen müssen, warum etwas nicht ankam.

Data Exchange ist die dateiförmige Hälfte der Integration, und die ist im deutschen B2B immer noch die größere. Import- und Exportprofile definieren die Struktur einer Datei und ihr Mapping auf Plattformfelder. Ein SFTP-Server gibt einem ERP einen Ort, eine CSV abzulegen, ohne dass jemand eine API baut. Storage Sync bewegt Dateien zwischen Plattform und Speicher. Viele funktionierende Integrationen sind ein Ordner, eine Namenskonvention und ein Zeitplan.

Punchout verdient einen eigenen Absatz, weil es der Grund ist, warum viele B2B-Shops überhaupt existieren. Eine Punchout-Verbindung lässt einen Einkäufer im eigenen Beschaffungssystem starten — SAP Ariba, Coupa, Onventis, JAGGAER —, mit etablierter Identität in Ihren Shop springen, einen Warenkorb füllen und ihn als Bedarfsanforderung zurückgeben. Einen einzelnen „Punchout"-Bildschirm gibt es im Cockpit heute nicht. Ein Punchout-Setup wird zusammengesetzt: ein Kanal im Commerce Studio für den Katalogausschnitt dieses Kunden, Zugangsdaten hier, und ein Connector oder Workflow für den Rundweg. Punchout erklärt behandelt die Mechanik; Punchout einrichten die Reihenfolge.

Direkter API-Zugriff, Webhooks und die Sandbox sind die Hälfte dieses Studios, die Ihr IT-Team und Ihr Integrator nutzen, ohne je die Arbeitsfläche zu öffnen. Nicht jede Integration sollte ein Workflow sein. Ein ERP-Partner, der alle fünfzehn Minuten Bestellungen abholt, braucht einen begrenzten API-Schlüssel, die Endpunktliste und die Rate-Limits — keinen Node-Graphen. Ein BI-Team braucht einen nächtlichen Bulk-Export. Die IT eines Kunden braucht einen Punchout-Endpunkt. Und alle brauchen einen Ort, an dem Fehler nichts kosten — die Sandbox: ein eigener Mandant mit eigenen Schlüsseln und eigenen Daten. APIs, Webhooks & Sandbox deckt diesen Weg aus Kundensicht ab — wie Sie einen Schlüssel anlegen mit genau genug Rechten, wie Sie eine Sandbox aufsetzen und übergeben, und wo die Grenze zur echten Entwicklung liegt.

Die Bildschirme

Häufige Aufgaben

• Integrationsmuster wählen — Datei, API, Event oder Connector, bevor Sie irgendetwas bauen.
• Führendes System festlegen — welches System je Feld gewinnt. Zuerst klären; das verhindert den meisten späteren Schaden.
• System anbinden — Zugangsdaten, ein Connector, ein erster erfolgreicher Aufruf.
• Felder zuordnen — die ARTNR des ERP auf die SKU der Plattform, und die vierzig anderen.
• Workflow bauen — Auslöser, Bausteine, Fehlerpfad, Aktivierung.
• Fehlgeschlagenen Sync beheben — was die üblichen Fehler tatsächlich bedeuten.
• API-Schlüssel anlegen — für den Integrator, der die Plattform direkt aufruft statt einen Workflow zu bauen.
• Sandbox aufsetzen — ein Mandant, den Ihr Integrator kaputt machen darf, bevor irgendetwas Produktion berührt.
• Integrationen überwachen — Aufrufe, Fehler, Latenz und Webhook-Zustellung, neben der Ausführungshistorie.

Was für dieses Studio geplant ist

Die eigenen Bildschirme des Integration Studios ändern sich am wenigsten von allen Studios. Was sich ändert, ist, was durch sie hindurchfließt.

Jede der geplanten Kern-Apps bringt neue Objekte zum Synchronisieren und neue Events zum Reagieren. Angebote müssen als Offerten ins ERP und als Bestellungen zurück — siehe Quotes & Contracts. Kostenstellen und Freigabegrenzen werden fast immer im System des Kunden gepflegt statt in Ihrem Cockpit getippt — also ein Import; siehe Procurement & Approvals. Übersetzungen und eCl@ss-Klassifikationen kommen von Übersetzungsagentur und Klassifikationsdienst und gehen als BMEcat- und Datanorm-Dateien wieder hinaus — siehe Katalog-Exportprofile. Stücklisten existieren meist schon im ERP oder PLM und brauchen Mapping statt Neuerfassung — siehe Stückliste modellieren. Daueraufträge und Subscriptions erzeugen Bestellungen nach Zeitplan — eine neue Event-Quelle für alles dahinter; siehe Recurring Orders & Subscriptions.

Die zweite Änderung ist Dokumentation statt Produkt: APIs, Webhooks & Sandbox deckt jetzt den Direktzugriffs-Weg ab — Schlüssel, Scopes, die Sandbox, Rate-Limits, Bulk-Exporte — für alle, die integrieren, ohne eine App zu bauen. Diese Bildschirme existieren heute; gefehlt hat die kundengerichtete Beschreibung.

Planen Sie beides ein, wenn Sie ein Integrationsprojekt schneiden. Eine Feldzuordnung, die Kostenstellen ignoriert, weil die App noch nicht installiert ist, ist eine Feldzuordnung, die Sie neu schreiben werden.

Wie es mit den anderen Studios zusammenhängt

Das Commerce Studio ist, wohin die meisten Workflows schreiben. Produkte, Preise, Bestände und Kunden entstehen meist im ERP und landen dort. Die prägende Entscheidung ist, welches System welches Feld besitzt: Gehört der Preis dem ERP und jemand ändert ihn im Commerce Studio, überschreibt der nächste Sync die Änderung — und das sieht aus wie ein Fehler, obwohl eine Regel korrekt arbeitet.

Das Experience Studio konsumiert das Ergebnis. Im Storefront ändert sich nichts, bevor die Daten, die ein Workflow schrieb, vollständig genug zum Rendern sind. Ein halb gelungener Sync zeigt sich als Produkte im Shop mit fehlenden technischen Daten — ein Vollständigkeitsproblem in Katalog-Vollständigkeit und ein Ausführungsproblem hier.

Das Analytics Studio berichtet über Daten, die dieses Studio geliefert hat. Zahlen, die falsch aussehen, sind oft ein Sync, der stehen blieb, kein Report, der lügt — prüfen Sie die Ausführungshistorie, bevor Sie am Dashboard zweifeln.

Das App Studio liefert die Connectors. Installierte Integrationen sind Apps, mit demselben Installations-, Berechtigungs- und Update-Modell wie alles andere auf Ihrem Mandanten.

Sie bauen auf diesem Studio?

Wenn Sie Code dagegen schreiben, statt darin zu arbeiten: Das Developer Portal dokumentiert dasselbe Studio für Entwickler — APIs, SDKs und Erweiterungspunkte.