Wer SAP Business One im Rücken hat, führt Artikel, Bestände, kundenindividuelle Preise und Belege bereits an einer verlässlichen Stelle. Weltweit nutzen über 83.000 Betriebe das System in mehr als 170 Ländern (SAP News 2025), rund 1,2 Millionen Anwender arbeiten täglich damit (SAP News 2025). Sobald ein Online-Shop dazukommt, stellt sich die Frage, wie beide Systeme sauber miteinander sprechen. Lange lief das über die DI-API, eine COM-basierte Programmierschnittstelle. Heute ist der Service Layer der empfohlene Weg: ein REST-Server, der dem OData-Standard folgt und Daten als JSON austauscht (SAP Help). Dieser Leitfaden zeigt, wie Sie Ihren Shop über den Service Layer an SAP Business One anbinden, welche Authentifizierung dahintersteht und wie Sie Bestand und Vertragspreise mit dem ERP als führender Quelle konsistent halten.
Das Wichtigste in Kürze
- Der Service Layer ist die moderne REST/OData-Schnittstelle von SAP Business One und löst für Web-, Mobil- und Cloud-Anbindungen die ältere, COM-basierte DI-API ab (SAP Help).
- Er tauscht Daten als JSON aus und folgt dem OData-Standard in Version 3.0 und 4.0; seit Feature-Package 2405 ist OData v3 abgekündigt und v4 das primäre Protokoll (SAP Help).
- Zur Authentifizierung dienen ein Session-Login mit den Cookies B1SESSION und ROUTEID oder, seit Version 10.0 FP 2305, OAuth 2.0 und OpenID Connect (SAP Learning). Sitzungen gehören wiederverwendet, nicht pro Anfrage neu geöffnet.
- Das ERP bleibt die führende Quelle: Bestand, Vertragspreise und Belege werden in SAP Business One geführt, der Shop liest sie über den Service Layer und meldet Bestellungen zurück.
- Die Kosten einer Anbindung reichen je nach Ansatz von rund 5.000 bis über 150.000 US-Dollar (WebSolutions NYC 2026); vorgefertigte Konnektoren sind günstiger, eine maßgeschneiderte Service-Layer-Entwicklung teurer, dafür passgenau.
Warum der Service Layer die DI-API ablöst
Die DI-API begleitet SAP Business One seit vielen Jahren. Sie ist eine COM-basierte Programmierschnittstelle für .NET und wird vor allem von Add-ons genutzt, die direkt auf dem Rechner mit dem SAP-Client laufen (SAP Help). Für installierte Desktop-Erweiterungen ist sie nach wie vor sinnvoll. Für eine Shop-Anbindung bringt sie jedoch Nachteile mit: Sie setzt auf die Microsoft-SQL-Edition und Windows auf, koppelt eng an die installierte Umgebung und lässt sich schwerer über mehrere Prozesse skalieren. Wer einen Online-Shop, eine mobile App oder einen Cloud-Dienst anbinden will, stößt damit an Grenzen.
Der Service Layer wurde genau für diese Fälle geschaffen. Er ist die moderne REST-Schnittstelle von SAP Business One, standardisiert, gut dokumentiert und in der Lage, lesend und schreibend ohne COM-Brücke zu arbeiten (SAP Help). Weil er offene Web-Standards spricht, kann ihn nahezu jede Programmiersprache ansprechen, vom PHP im Shopware-Backend bis zu einem eigenen Integrationsdienst. Ob dabei eine direkte Anbindung oder eine Middleware zwischen Shop und ERP die bessere Wahl ist, hängt vom Umfang ab; die Abwägung vertieft der Beitrag REST-API oder Middleware.
REST und OData
Der Service Layer folgt dem OData-Standard. Ressourcen wie Artikel, Geschäftspartner und Aufträge werden über klare URLs angesprochen.
Lesen und Schreiben
Bestände und Preise lesen, Bestellungen und Belege schreiben, alles über dieselbe Schnittstelle ohne COM-Brücke.
Sichere Anmeldung
Session-Login mit B1SESSION-Cookie oder OAuth 2.0 und OpenID Connect ab Version 10.0 FP 2305 (SAP Learning).
Plattformunabhängig
Jede Sprache mit HTTP-Client kann den Service Layer ansprechen, vom Shop-Backend bis zum eigenen Dienst.
Skalierbar
Mehrere parallele Verbindungen und Lastverteilung über den ROUTEID-Cookie statt einer einzelnen COM-Sitzung.
Filtern und Auswählen
Mit $filter, $select und $expand liefert der Service Layer nur die Felder, die der Shop wirklich braucht.
Was der Service Layer technisch ist
Technisch ist der Service Layer ein HTTP-Server, der neben SAP Business One läuft und die Geschäftsobjekte des Systems als OData-Ressourcen bereitstellt (SAP Help). Ein Artikel ist unter einer Adresse wie /b1s/v2/Items('A0001') erreichbar, ein Geschäftspartner unter /b1s/v2/BusinessPartners, ein Auftrag unter /b1s/v2/Orders. Antworten kommen als JSON zurück, Anfragen zum Anlegen oder Ändern gehen ebenfalls als JSON hinein. Über OData-Abfrageparameter lässt sich die Antwort gezielt einschränken: $select holt nur einzelne Felder, $filter grenzt Datensätze ein, $expand zieht verbundene Objekte gleich mit. Das hält die übertragene Datenmenge klein und die Anbindung schnell.
Den Service Layer gibt es in zwei Ausprägungen. Version 1 basiert auf Java und liefert OData in Version 3.0, Version 2 setzt auf .NET Core und OData 4.0 (SAP Business One Blog). Seit Feature-Package 2405 ist OData v3 abgekündigt, sodass Version 4 das primäre Protokoll ist (SAP Help). Für neue Anbindungen ist deshalb die v2-Route unter /b1s/v2/ die richtige Wahl. Die genaue Feldbenennung zwischen ERP und Shop legt man am besten früh fest, damit spätere Korrekturen entfallen.
POST /b1s/v2/Login
Content-Type: application/json
{ "CompanyDB": "SBODEMO_DE", "UserName": "shopsync", "Password": "***" }
# Antwort setzt die Cookies B1SESSION und ROUTEID
GET /b1s/v2/Items('A0001')?$select=ItemCode,ItemName,QuantityOnStock
Cookie: B1SESSION=...; ROUTEID=...Authentifizierung: Session-Login und OAuth 2.0
Bevor der Shop Daten abruft, meldet er sich am Service Layer an. Beim klassischen Session-Login sendet die Anbindung Firmendatenbank, Benutzer und Passwort an den /Login-Endpunkt und erhält die Cookies B1SESSION und ROUTEID zurück (SAP Learning). Der B1SESSION-Cookie weist die Sitzung aus, der ROUTEID-Cookie sorgt in Umgebungen mit Lastverteilung dafür, dass die Folgeanfragen denselben Knoten treffen. Diese Cookies werden bei jeder weiteren Anfrage mitgeschickt.
Entscheidend ist, die Sitzung wiederzuverwenden, statt sich pro Anfrage neu anzumelden (SAP Learning). Eine Anbindung, die für jeden Bestandsabruf eine neue Sitzung öffnet, belastet das System unnötig und wird schnell langsam. Besser ist ein Session-Cache, der den B1SESSION-Cookie hält und erst dann neu anmeldet, wenn die Sitzung abgelaufen ist. Seit Version 10.0 FP 2305 unterstützt der Service Layer zusätzlich OAuth 2.0 und OpenID Connect (SAP Learning), was die Anbindung an eine zentrale Benutzerverwaltung erleichtert. Wie Token sicher gespeichert und erneuert werden, vertieft der Beitrag zu OAuth 2.0 und Token-Sicherheit.
Sitzungen bündeln
Bestand mit dem ERP als führender Quelle
Die wichtigste Regel jeder ERP-Anbindung lautet: Es gibt genau eine führende Quelle. Bestand, Artikelstammdaten und Preise werden in SAP Business One geführt, der Shop liest sie über den Service Layer und meldet Bestellungen zurück. Führt der Shop einen eigenen, konkurrierenden Bestand, entstehen widersprüchliche Verfügbarkeiten und dauerhafter Abgleich von Hand. 61 Prozent (Bitkom, Digitalisierung der Wirtschaft 2025) der Unternehmen können ihr Datenpotenzial nicht voll ausschöpfen, weil Informationen in unverbundenen Systemen liegen, und genau dieser Effekt trifft eine schlecht geplante Shop-Anbindung.
Der Service Layer selbst schickt keine aktiven Benachrichtigungen an den Shop; er antwortet auf Anfragen. Für aktuelle Bestände heißt das, in kurzen Intervallen die geänderten Datensätze abzuholen (Delta-Sync) oder Ereignisse im ERP über einen ergänzenden Mechanismus auszuwerten. Ob sich ein enger Abfragetakt oder eine ereignisgetriebene Kopplung besser eignet, wägt der Beitrag Webhooks gegen Polling ab. Bei mehreren Lägern kommt eine Aggregationslogik hinzu, die filialbezogene und zentrale Bestände zusammenführt; das vertieft der Beitrag zur Bestandssynchronisation über mehrere Lager. Eine bewährte Referenz für den Aufbau ist die Echtzeit-Synchronisation zwischen SAP und Shopware.
| Kriterium | DI-API | Service Layer |
|---|---|---|
| Technologie | COM-Bibliothek für .NET | REST-Server nach OData |
| Datenformat | COM-Objekte | JSON |
| Plattform | Windows, MS-SQL-Edition | plattformunabhängig, HANA-Edition |
| Einsatz | installierte Add-ons | Web, Mobile, Cloud |
| Anmeldung | lokale Verbindung | Session-Login oder OAuth 2.0 |
| Skalierung | an die Umgebung gebunden | mehrere Verbindungen, Lastverteilung |
Vertragspreise und kundenindividuelle Preise
Im B2B ist der Preis selten für alle gleich. SAP Business One kennt Preislisten, Sonderpreise je Geschäftspartner und mengenabhängige Staffeln. Der Service Layer stellt diese Preisfindung über die entsprechenden Objekte bereit, sodass der Shop den korrekten, kundenindividuellen Preis anzeigen kann, statt einen Listenpreis für alle. Damit sieht der eingeloggte Geschäftskunde genau die Konditionen, die im ERP hinterlegt sind, und die Anbindung wird zum verlängerten Arm der im ERP gepflegten Verträge.
Preise sollten dabei nicht fest im Shop hinterlegt, sondern aus dem ERP bezogen und mit Bedacht zwischengespeichert werden. Ein zu langer Cache zeigt veraltete Konditionen, ein zu kurzer belastet den Service Layer. In der Praxis bewährt sich ein Cache mit gezielter Invalidierung, sobald sich eine Preisliste ändert. Wie kundenindividuelle Preise aus dem ERP synchronisiert und sinnvoll gecacht werden, beschreibt der Beitrag zu kundenindividuellen Preisen aus dem ERP im Detail. Für die dahinterliegende Warenwirtschaft gilt dasselbe Prinzip der einen Quelle.
Robuste Anbindung und Betrieb
Eine Anbindung ist nur so gut wie ihr Verhalten im Fehlerfall. Netzausfälle, abgelaufene Sitzungen oder ein kurz nicht erreichbarer Service Layer dürfen nicht dazu führen, dass eine Bestellung doppelt gebucht oder verloren wird. Zwei Prinzipien helfen: Idempotenz sorgt dafür, dass ein mehrfach gesendeter Beleg nur einmal im ERP entsteht, und eine Wiederholungsstrategie mit wachsenden Wartezeiten fängt vorübergehende Störungen ab. Diese Muster vertiefen die Beiträge zu Idempotenz und Retry-Strategien und zur Fehlerbehandlung in Schnittstellen.
- Führende Quelle festlegen: Bestand, Preise und Belege gehören ins ERP; der Shop liest und meldet, statt eigene Wahrheiten zu pflegen.
- Session-Cache aufbauen: Den B1SESSION-Cookie wiederverwenden und erst bei Ablauf neu anmelden.
- Nur benötigte Felder holen: Mit $select und $filter die Antwort klein halten und den Service Layer schonen.
- Idempotent schreiben: Belege mit einer eindeutigen Referenz versehen, damit ein wiederholter Versand keine Dublette erzeugt.
- Fehler abfangen: Wiederholungen mit wachsenden Wartezeiten und eine Ablage für dauerhaft fehlgeschlagene Vorgänge einplanen.
Migration von DI-API und Altsystemen
Viele Betriebe stehen heute vor der Frage, wie sie eine bestehende DI-API-Anbindung ablösen. Der Umstieg auf den Service Layer lohnt sich, wenn ein Shop, eine App oder ein Cloud-Dienst dazukommt oder wenn die alte Anbindung schwer zu warten ist. Wichtig ist, das Datenmodell nicht einfach zu übernehmen, sondern die Feldzuordnung neu und sauber aufzusetzen. Wer zusätzlich von einem älteren SAP-System kommt, findet die Migrationsschritte im Beitrag zum SAP-ECC-Wartungsende 2027.
Der Service-Layer-Ansatz ist kein Sonderfall von SAP Business One, sondern folgt demselben Grundgedanken wie moderne Cloud-ERP-Schnittstellen: eine offene, standardisierte API als Tor zum führenden System. Wer parallel Microsoft Dynamics betreibt, findet den vergleichbaren Weg über OData und das Data Management Framework im Beitrag zur Dynamics-365-Finance-Anbindung. Und wo große Datenmengen im Spiel sind, lohnt der Blick auf API-Limits und Massenimporte, damit ein Vollabgleich den Service Layer nicht ausbremst.
Kosten, E-Rechnung und Vorgehen
Was kostet eine solche Anbindung? Das hängt stark vom Ansatz ab. Über alle Varianten hinweg reicht die Spanne von rund 5.000 bis über 150.000 US-Dollar (WebSolutions NYC 2026). Vorgefertigte Konnektoren beginnen bei etwa 5.000 bis 15.000 US-Dollar Einrichtung (ERP Research 2026), eine Middleware-Plattform liegt oft bei 10.000 bis 30.000 US-Dollar Einführung (ERP Research 2026), eine vollständig maßgeschneiderte Service-Layer-Entwicklung bei 50.000 bis 150.000 US-Dollar (WebSolutions NYC 2026). Entscheidend für die Einordnung ist die Komplexität der Preislogik und die Zahl der angebundenen Prozesse; eine Übersicht der Leistungen gibt die Seite zur SAP-Anbindung sowie die Preisübersicht.
Ein weiterer Grund, ERP und Shop jetzt sauber zu verbinden, ist die E-Rechnung. Seit dem 1. Januar 2025 muss jedes inländische Unternehmen in Deutschland E-Rechnungen empfangen können (Bundesfinanzministerium). Ab dem 1. Januar 2027 gilt die Versandpflicht für Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz, ab dem 1. Januar 2028 für alle übrigen im B2B (Bundesfinanzministerium). Wer Belege ohnehin über den Service Layer aus SAP Business One zieht, kann strukturierte Formate wie XRechnung und ZUGFeRD direkt aus dem führenden System erzeugen. Bei komplexeren Landschaften hilft eine eigene Schnittstelle oder Middleware, und für die saubere Trennung von Kernsystem und Erweiterung lohnt der Beitrag zur SAP Integration Suite und clean-core-Anbindung.
- Systeme und Versionen prüfen: SAP-Business-One-Version, Service-Layer-Route (/b1s/v2/) und die Schnittstelle des Shops erheben.
- Datenmodell festlegen: Führende Quelle bestimmen und die Feldzuordnung zwischen ERP und Shop dokumentieren.
- Anmeldung einrichten: Session-Login oder OAuth 2.0 wählen und den Session-Cache aufsetzen.
- Kernprozesse anbinden: Artikel, Bestand, Vertragspreise, Bestellungen und Belege zuerst, weitere Kanäle danach.
- Testen und live schalten: Fehlerfälle, Lastspitzen und Preisszenarien durchspielen, dann mit engem Monitoring produktiv gehen.
Eine Quelle, viele Kanäle
Eine Schnittstelle ist kein einmaliges Projekt, sondern ein Betrieb. Wer den Service Layer sauber anmeldet, gezielt abfragt und Fehler einplant, bindet den Shop dauerhaft verlässlich an SAP Business One.