SAP Business One anbinden: Service Layer, OData und RFC-Middleware im Vergleich

SAP Business One ist in vielen mittelständischen Unternehmen das Rückgrat für Finanzbuchhaltung, Lager und Vertrieb. Sobald dieses ERP-System an andere Werkzeuge wie ein CRM, einen Onlineshop oder ein Reporting-Dashboard angebunden werden soll, stellt sich eine grundsätzliche Architekturfrage: über den REST-basierten Service Layer mit OData oder über eine klassische RFC-Middleware. Diese Entscheidung hat direkten Einfluss auf Projektaufwand, Wartbarkeit und letztlich auf den Preis der Automatisierung, weshalb sie am Anfang jedes SAP-B1-Integrationsprojekts sauber getroffen werden sollte.

In diesem Beitrag stellen wir beide Ansätze gegenüber, zeigen wie n8n als Automatisierungsschicht dazwischen sitzt und worauf du bei Authentifizierung, Fehlerbehandlung und Skalierung achten musst. Stand: Juli 2026.

Service Layer vs. RFC-Middleware: der Grundkonflikt

SAP Business One bietet zwei grundsätzlich verschiedene Wege, um von außen auf Daten zuzugreifen:

• Service Layer: Eine moderne, RESTful Web-API, die HTTP-Anfragen entgegennimmt und Daten im JSON-Format zurückgibt. Sie folgt dem OData-Protokoll und ist speziell für die Integration mit modernen Cloud- und Automatisierungswerkzeugen konzipiert.
• RFC (Remote Function Call): Das ältere, SAP-eigene Protokoll, über das klassische SAP-Systeme kommunizieren. Für den Zugriff aus einem Automatisierungstool wie n8n heraus brauchst du hier zwingend eine Middleware-Schicht, etwa einen Node.js-Dienst mit einer RFC-Bibliothek oder eine Integrationsplattform wie SAP Cloud Integration, die die RFC-Aufrufe in eine HTTP-Schnittstelle übersetzt.

Der entscheidende Unterschied für dein Projekt: Der Service Layer spricht bereits die Sprache, die n8n von Haus aus versteht, nämlich HTTP und JSON. Bei RFC brauchst du zusätzlich eine eigenständige Middleware-Komponente, die separat entwickelt, gehostet und gewartet werden muss. Das erhöht den initialen Aufwand und die Anzahl der beweglichen Teile im System, kann sich aber lohnen, wenn du bereits eine bestehende SAP-Integrationslandschaft mit RFC-Bausteinen hast oder Funktionen brauchst, die der Service Layer nicht abdeckt.

Der Service-Layer-Ansatz mit n8n

Für die Mehrheit der Automatisierungsprojekte ist der Service Layer der pragmatischere Einstieg. Der HTTP Request Node ist laut n8n-Dokumentation "one of the most versatile nodes in n8n" und erlaubt es, "HTTP requests to query data from any app or service with a REST API" zu senden. Genau das braucht es für den Service Layer, da es keinen dedizierten SAP-B1-Node in n8n gibt und du die Anbindung selbst über HTTP-Aufrufe modellierst.

Ablauf einer typischen Anbindung

• Login: Ein HTTP-Request-Node sendet einen POST an den Login-Endpunkt des Service Layer (üblicherweise `https://<server>:<port>/b1s/v1/Login`) mit CompanyDB, UserName und Password im Body.
• Session-Cookie: Die Antwort enthält ein `B1SESSION`-Cookie, das du in n8n zwischenspeicherst, zum Beispiel über ein Set-Node oder eine Static-Data-Ablage, und bei allen folgenden Requests im Header mitschickst.
• OData-Abfragen: Nachfolgende HTTP-Request-Nodes greifen auf Entitäten wie `Orders`, `BusinessPartners` oder `Items` zu. OData-Query-Parameter wie `$select`, `$filter`, `$orderby` und `$top` reduzieren die Datenmenge auf genau das, was der Workflow braucht, statt komplette Datensätze zu laden und erst in n8n zu filtern.
• Session-Timeout: Service-Layer-Sessions laufen nach einer gewissen Inaktivität ab. Ein robuster Workflow prüft den Status-Code der Antwort und erneuert die Session bei Bedarf automatisch, statt bei einem 401-Fehler einfach abzubrechen.

Authentifizierung sauber abbilden

Weil es für den Service Layer kein vorgefertigtes n8n-Credential gibt, arbeitest du mit den generischen Authentifizierungsoptionen des HTTP-Request-Nodes. Laut der Dokumentation zu HTTP-Request-Credentials stehen dafür unter anderem "Basic auth, Custom auth, Digest auth, Header auth, OAuth1 API, OAuth2 API, Query auth" zur Verfügung. Für den klassischen Login-Cookie-Flow des Service Layer reicht meist eine Kombination aus einem initialen Login-Request und einem nachgelagerten Header-Auth-Credential, in das du das Session-Cookie dynamisch einträgst. Wichtig für produktive Umgebungen: Läuft der Service Layer mit einem selbst signierten oder internen Zertifikat, kannst du laut Dokumentation "an SSL certificate with your HTTP request" mitschicken, indem du CA-Bundle, Zertifikat und Private Key als eigenes Credential hinterlegst, statt SSL-Prüfungen pauschal zu deaktivieren.

Der RFC-Middleware-Ansatz

Bei größeren SAP-Landschaften oder wenn Funktionen gebraucht werden, die über den Service Layer nicht abgebildet sind, etwa bestimmte Altprozesse oder tief in der Business-Logik verankerte Funktionsbausteine, führt kein Weg an RFC vorbei. Da n8n RFC nicht nativ spricht, brauchst du eine Middleware-Schicht dazwischen:

• Ein eigener Node.js- oder Python-Dienst mit einer RFC-Bibliothek übersetzt eingehende HTTP-Anfragen in RFC-Aufrufe gegen das SAP-System und gibt die Antwort als JSON zurück.
• n8n spricht diesen Dienst dann ganz normal über den HTTP-Request-Node an, genau wie jede andere REST-API.
• Alternativ übernimmt eine bestehende Integrationsplattform (zum Beispiel SAP Cloud Integration) diese Übersetzung, und n8n wird zur Orchestrierungsebene, die Trigger, Fehlerbehandlung und die Anbindung an Drittsysteme steuert.

Dieser Ansatz bedeutet mehr Entwicklungsaufwand am Anfang, weil die Middleware selbst gebaut, getestet und betrieben werden muss. Dafür bekommst du Zugriff auf Funktionsbausteine, die im Service Layer schlicht nicht existieren, und kannst bestehende SAP-Berechtigungskonzepte auf RFC-Ebene weiterverwenden. Für Projekte mit hohem Integrationswert ist das oft der Punkt, an dem sich eine saubere Architekturentscheidung finanziell auszahlt, weil eine falsch gewählte Anbindung später teuer nachgerüstet werden muss.

Fehlerbehandlung und Betrieb im Blick behalten

Eine SAP-Anbindung, die nur im Idealfall funktioniert, ist für den produktiven Einsatz nicht ausreichend. Baue in jeden Workflow feste Prüfpunkte ein:

• Session-Erneuerung: Erkenne abgelaufene Sessions am Status-Code und erneuere den Login automatisch, statt den Workflow fehlschlagen zu lassen.
• Retry-Logik: Netzwerkprobleme oder kurzfristige Nichtverfügbarkeit des Service Layer sollten über einen begrenzten Retry mit Wartezeit abgefangen werden, nicht über einen einmaligen Versuch.
• Fehlerprotokollierung: Ein separater Error-Pfad im Workflow, der fehlgeschlagene Requests protokolliert und bei Bedarf benachrichtigt, verhindert, dass Datenfehler unbemerkt in nachgelagerte Systeme wandern.

Wenn das Datenvolumen wächst, etwa bei mehreren parallelen Integrationen oder hochfrequenten Synchronisationen, lohnt sich ein Blick auf den produktiven Betrieb von n8n selbst. Für selbst gehostete Installationen beschreibt die Dokumentation den Queue-Modus, bei dem eine Hauptinstanz Trigger entgegennimmt und mehrere Worker-Prozesse die eigentlichen Ausführungen übernehmen. Das trennt die Verarbeitungslast von der zeitkritischen Trigger-Annahme und macht die Automatisierung stabiler, wenn viele SAP-Workflows gleichzeitig laufen.

Welcher Ansatz passt zu deinem Projekt

Für die meisten mittelständischen Anbindungen, sei es Auftragsdaten ins CRM spiegeln, Lagerbestände an einen Onlineshop melden oder Rechnungsdaten für ein Reporting-Tool aufbereiten, ist der Service Layer der direktere und wartungsärmere Weg. Er kommt ohne zusätzliche Middleware aus, spricht Standard-HTTP und lässt sich vollständig über den HTTP-Request-Node in n8n abbilden. Die RFC-Middleware-Variante bleibt Projekten vorbehalten, bei denen der Service Layer funktional nicht ausreicht oder eine bestehende RFC-Integrationsschicht bereits vorhanden ist und weiterverwendet werden soll.

Du behältst in beiden Fällen die Kontrolle über deine Daten und den Ablauf: n8n läuft entweder in deiner eigenen Infrastruktur oder in einer von dir gewählten Umgebung, und jeder Schritt der SAP-Anbindung bleibt als Workflow einsehbar und anpassbar, statt in einer intransparenten Blackbox zu verschwinden. Wenn du unsicher bist, welcher Ansatz für deine SAP-Business-One-Landschaft der richtige ist, lohnt sich eine gemeinsame Bestandsaufnahme, bevor die Entwicklung beginnt.

Häufige Fragen

Brauche ich für den Service-Layer-Ansatz einen speziellen SAP-B1-Node in n8n?

Nein. n8n bietet keinen dedizierten SAP-Business-One-Node, aber das ist auch nicht nötig. Der Service Layer ist eine reguläre REST-API mit OData-Unterstützung, die du vollständig über den HTTP-Request-Node abbildest, inklusive Login, Session-Verwaltung und den eigentlichen Datenabfragen.

Wann lohnt sich RFC-Middleware trotz des höheren Aufwands?

RFC-Middleware lohnt sich, wenn du auf Funktionsbausteine angewiesen bist, die der Service Layer nicht abdeckt, oder wenn bereits eine bestehende RFC-Integrationslandschaft existiert, die weiterverwendet werden soll. Für neue, schlanke Integrationsprojekte ist der Service Layer in der Regel der effizientere Startpunkt.

Wie gehe ich mit ablaufenden Service-Layer-Sessions um?

Der Service Layer setzt Sessions nach einer gewissen Inaktivität zurück. Ein robuster n8n-Workflow prüft den Status-Code jeder Antwort, erkennt einen abgelaufenen Login automatisch und stößt einen erneuten Login-Request an, bevor der eigentliche Datenabruf wiederholt wird, statt den gesamten Workflow fehlschlagen zu lassen.

Kann ich SSL-Zertifikate für interne SAP-Server in n8n hinterlegen?

Ja. Laut n8n-Dokumentation lässt sich ein SSL-Zertifikat, bestehend aus CA-Bundle, Zertifikat und privatem Schlüssel, als eigenes Credential anlegen und mit dem HTTP-Request-Node verknüpfen. Das ist die sauberere Lösung gegenüber dem pauschalen Deaktivieren der SSL-Prüfung, gerade bei intern signierten SAP-Zertifikaten.

Was passiert bei hohem Datenvolumen und vielen parallelen SAP-Synchronisationen?

Bei wachsendem Volumen empfiehlt sich für selbst gehostete n8n-Installationen der Queue-Modus. Dabei nimmt eine Hauptinstanz Trigger entgegen, während mehrere Worker-Prozesse die eigentlichen Workflow-Ausführungen übernehmen. Das hält die Automatisierung auch bei mehreren gleichzeitig laufenden SAP-Integrationen stabil und performant.