n8n oder SAP-Integration — kein Entweder-oder

Artikel 12 · Serie: Einstieg in n8n

Über elf Artikel hat diese Reihe n8n aufgebaut: vom ersten Container über Self-Hosting, Testdaten, regelbasierte und AI-gestützte Klassifikation, Fehlerbehandlung, die SAP-Brücke bis zum Queue-Mode. Zu einer Reihe, die ein Werkzeug erklärt und benutzt, gehört auch der Satz, wo es nicht hingehört. Dieser Artikel zieht die Grenze, und zwar gegenüber den zwei SAP-eigenen Werkzeugen, die im selben Raum stehen: der Cloud Integration und der Edge Integration Cell. Es ist kein Verriss. n8n bleibt am Ende der richtigen Argumente das richtige Werkzeug, nur eben für einen bestimmten Aufgabenraum.

Cloud Integration kommt aus der EAI-Tradition

Der häufigste Denkfehler ist, SAP Cloud Integration als die SAP-Variante von n8n zu sehen. Das ist sie nicht. Cloud Integration, der Kern der SAP Integration Suite, stammt aus der Linie von SAP PI und PO und damit aus der Enterprise Application Integration. Ihre Bausteine sind nicht Webhook und Code-Node, sondern Message Mapping, Content Modifier, Splitter und Router, und ihr Vokabular ist das von SAP-Schnittstellen: IDoc, AS2, SFTP, OData, SOAP.

Das ist ein anderer Ursprung mit anderen Annahmen. Cloud Integration setzt voraus, dass eine Nachricht ein definiertes Format hat, dass sie gemappt, validiert und gegen ein Schema geprüft wird, und dass für jeden Schritt nachvollziehbar bleibt, was mit ihr passiert ist. Diese Welt ist auf den verlässlichen Austausch strukturierter Geschäftsnachrichten zwischen Systemen gebaut, nicht auf das schnelle Verdrahten von Cloud-Diensten. Wer n8n direkt danebenstellt, vergleicht eine Orchestrierungs-Schicht mit einer Integrations-Middleware und verkauft beide falsch.

Edge Integration Cell: Control Plane in der Cloud, Runtime im eigenen Netz

Die Edge Integration Cell ist eine optionale Laufzeit der Integration Suite. Ihr Prinzip lässt sich in einem Satz fassen: Design, Konfiguration und Monitoring bleiben in der Cloud, die Ausführung läuft im eigenen Rechenzentrum. Technisch ist sie ein Kubernetes-Deployment im Kundennetz, das dieselben Integration-Flows ausführt, die man in der BTP entwirft, aber die Nutzdaten verlassen das eigene Netz nicht.

Wer die letzten Artikel mitgebaut hat, erkennt die Bausteine wieder. Die Edge Integration Cell braucht für den Produktivbetrieb eine externe PostgreSQL und Redis, die interne Variante ist nur für Test und Demo gedacht. Das ist genau die Aufteilung, die der Queue-Mode aus Artikel 11 auch trifft. Der Unterschied liegt nicht in der Infrastruktur, sondern in dem, was darüber liegt.

Zwei Eigenschaften grenzen die Edge Integration Cell sauberer ein als jede Marketing-Folie. Erstens ist sie kein autonomes On-Premise-System: Sie überbrückt einen Verbindungsverlust zur Cloud nur temporär, aktuell für vier Stunden, danach endet der Support. Die Control Plane in der Cloud ist Voraussetzung, nicht Beiwerk. Zweitens deckt sie noch nicht den vollen Adapter-Umfang der Cloud Integration ab, insbesondere fehlen die B2B-Adapter. Die Edge Integration Cell löst also nicht das B2B-Problem, sie löst das Datenresidenz-Problem.

n8n bleibt richtig für Orchestrierung und AI-Integration

Die Grenze verläuft entlang der Aufgabe, nicht entlang des Herstellers. n8n ist die bessere Wahl, wenn die Anforderung so aussieht:

• Orchestrierung über mehrere Cloud-Dienste hinweg, bei der kein SAP-B2B-Protokoll im Spiel ist.
• Schnelle Iteration, bei der ein Workflow in Stunden steht und sich täglich ändern darf.
• AI-Agent-Integration, wie sie diese Reihe gebaut hat: LLM-Klassifikation, Tool-Aufrufe, Routing nach Modellantwort.
• Kleine bis mittlere Durchsatz-Anforderungen, bei denen der Queue-Mode mit ein paar Workern reicht.
• Ein Entwickler-Team, das ein Werkzeug bedient, statt einer Integrations-Plattform-Abteilung mit eigenem Betriebsmodell.

In diesem Raum ist die Leichtgewichtigkeit von n8n ein Vorteil, kein Mangel. Genau die Schichten, die Cloud Integration mitbringt und die im SAP-Standard erwartet werden, wären hier Ballast.

Cloud Integration gewinnt bei B2B, Compliance und Durchsatz

Die andere Seite ist genauso klar. Cloud Integration ist überlegen, sobald eine dieser Anforderungen auftritt:

• Compliance-getriebene Audit-Pflichten, bei denen jede Nachricht nachvollziehbar und revisionssicher protokolliert sein muss.
• B2B-Protokolle gegenüber Geschäftspartnern: AS2, EDI, IDoc-Ströme mit garantierter Zustellung.
• Definierte SLAs gegenüber Partnern, inklusive fachlicher Recovery, wenn eine Nachricht scheitert.
• Recovery-Mechanik, die im SAP-Standard erwartet wird und die man nicht nachbauen, sondern erben will.
• Große bis sehr große Durchsätze, für die das Persistenz- und Skalierungsmodell von Cloud Integration ausgelegt ist.

Das ist kein Werkzeug-Ranking. Es ist die Beschreibung zweier verschiedener Aufgabenräume. Der Versuch, ein B2B-EDI-Szenario mit garantierter Zustellung in n8n nachzubauen, endet in einem Eigenbau, der die Funktionalität dupliziert, die Cloud Integration mitbringt.

Die Edge Integration Cell löst die Datenresidenz-Frage

Die Edge Integration Cell ist die Antwort auf eine Anforderung, die n8n und Cloud Integration allein nicht gleichzeitig erfüllen: Die Daten dürfen das eigene Netz nicht verlassen, aber die Konfiguration soll trotzdem zentral aus der Cloud kommen. Genau dieser Spalt ist ihr Platz. Sensible Daten bleiben in der externen Datenbank im eigenen Rechenzentrum, in die Cloud wandern nur Monitoring-Metadaten. Für regulierte Branchen und Souveränitäts-Anforderungen ist das der entscheidende Unterschied. Für ein Setup ohne diese Auflagen ist die Edge Integration Cell zusätzlicher Betriebsaufwand ohne Gegenwert, ein eigener Kubernetes-Cluster, den man pflegen muss.

Mischformen sind die Regel

In der Praxis steht selten ein Werkzeug allein. Die Support-Ticket-Triage dieser Reihe lässt sich auf drei Schnitte legen, und der Vergleich zeigt die Trade-offs besser als jede abstrakte Tabelle.

Als reiner n8n-Workflow ist es das, was diese Reihe gebaut hat: Webhook-Trigger, LLM-Klassifikation über zwei Backends, Anreicherung über OData, Routing, alles in einem Werkzeug, in Tagen aufgesetzt. Als Cloud-Integration-iFlow sähe dieselbe Pipeline anders aus: ein HTTPS-Sender-Adapter als Trigger, ein Content Modifier für die Normalisierung, ein Request-Reply gegen einen externen Klassifikationsdienst, Message Mapping auf das Zielformat, Persistierung über den JMS-Adapter. Die AI-Klassifikation wäre ein externer Aufruf, kein nativer Knoten, denn die LLM-Integration ist nicht die Stärke der Cloud Integration. Als Hybrid mit Edge Integration Cell liefe der Teil, der On-Premise-S/4 berührt, auf der Edge-Runtime im eigenen Netz, während die AI-Orchestrierung bei n8n bliebe.

Die Trade-offs liegen an festen Punkten: der Trigger ist überall HTTP, die Klassifikation ist bei n8n nativ und bei Cloud Integration ein Fremdaufruf, die Persistierung ist bei n8n Postgres und bei Cloud Integration JMS mit eigener Recovery, und die Kosten verteilen sich anders, n8n zahlt mit Betriebsaufwand, Cloud Integration mit Lizenz und Nachrichten-Metering. Ein realistisches Zielbild ist deshalb oft kein Entweder-oder: n8n als Orchestrierung für AI-getriebene Workflows, Cloud Integration für die B2B-Schicht zu Partnern, Edge Integration Cell als Brücke zu On-Prem-S/4. Drei Werkzeuge, drei Schichten, ein Architekturbild.

Entscheidungshilfe in fünf Fragen

Für die eigene Lage reichen fünf Fragen, um die Richtung zu finden:

1. Compliance: Müssen Nachrichten revisionssicher und auditierbar protokolliert sein? Wenn ja, spricht das für Cloud Integration.
2. B2B: Sind AS2, EDI oder IDoc-Ströme zu Partnern im Spiel? Wenn ja, ist das Cloud-Integration-Gebiet.
3. Datenresidenz: Dürfen Daten das eigene Netz nicht verlassen, während die Konfiguration zentral bleibt? Wenn ja, ist die Edge Integration Cell gebaut.
4. Durchsatz: Reicht ein Queue-Mode mit wenigen Workern, oder sind sehr hohe, garantierte Durchsätze gefordert? Sehr hoch und garantiert spricht für Cloud Integration.
5. Team: Bedient ein Entwickler-Team das Werkzeug, oder steht eine Integrations-Plattform-Abteilung dahinter? Ohne diese Abteilung bleibt n8n die realistische Wahl.

Drei oder mehr Ja in Richtung Compliance, B2B und Durchsatz, und n8n ist nicht das passende Werkzeug. Bleibt es bei Orchestrierung, AI und überschaubarem Durchsatz, ist alles andere überdimensioniert.

Übergang zu Artikel 13

Damit ist der Aufgabenraum von n8n abgesteckt. Artikel 13 schließt die Reihe und zieht eine praktische Konsequenz aus genau dieser Architektur: die Authentifizierung über OAuth gegen eine BTP-Destination, der echte Token-Flow hinter der APIKey-Vorschau aus Artikel 10. Das ist die Stelle, an der n8n und die SAP-Welt sich sauber die Hand geben.