// stack · schnittstelle
SAP ist in vielen Unternehmen das führende System für Artikel, Preise, Kunden und Aufträge — und damit die Quelle für genau die Daten, die auf der Website erscheinen sollen. Für siteway ist die Anbindung deshalb keine Frage von „irgendwie exportieren“, sondern eine Frage der Architektur: Die Website spricht nie direkt mit dem ERP-Kern, sondern über eine definierte Schnittstelle — OData oder eine Integrationsschicht. Diese Seite beschreibt beide Wege und wie wir sie anbinden.
// definition
SAP ist die ERP-Software der SAP SE aus Walldorf — ein System, in dem Unternehmen ihre Geschäftsprozesse führen und, für eine Website entscheidend, ihre Stammdaten: Artikel, Preise, Kunden, Aufträge, Bestände. Neben dem seit Jahrzehnten verbreiteten klassischen ERP steht die neuere Produktlinie S/4HANA. Welche davon im Haus läuft, ändert an der Architektur einer Anbindung erstaunlich wenig — an der Frage, welcher Weg nach draußen freigeschaltet ist, dagegen viel.
SAP ist ein weites Feld, und diese Seite versucht nicht, es zu vermessen. Sie beschreibt den Ausschnitt, der für eine Website zählt: Wie kommen Daten heraus? Dafür gibt es zwei etablierte Wege. Der erste sind OData-Services — SAP Gateway ist die REST-Schnittstelle der ABAP-Plattform und stellt Geschäftsdaten über HTTPS bereit, wahlweise als JSON oder XML. Die aufrufende Seite braucht dafür kein SAP-Spezialwissen.
Der zweite Weg ist eine Integrationsschicht beziehungsweise Middleware, die das ERP kapselt und nach außen eine eigene, schlankere Schnittstelle anbietet. SAP bündelt solche Bausteine unter der Integration Suite; genauso kann es eine Middleware sein, die im Unternehmen ohnehin schon steht. Welcher Weg es wird, entscheidet in der Praxis die IT-Abteilung des Kunden — sie gibt frei, was das System nach außen zeigen darf. Unsere Aufgabe beginnt dahinter.
// praxis
spiegeln · nicht durchreichen
Der erste Schritt ist kein technischer, sondern ein organisatorischer: Wir klären mit der IT des Kunden, welcher Weg freigeschaltet wird. Ein OData-Service, den das Gateway bereitstellt, oder eine Integrationsschicht, die vor dem ERP steht — beides trägt, aber nur eines davon ist im konkreten Haus vorgesehen. Diese Entscheidung fällt vor dem Angebot, nicht im Projekt. Danach steht fest, mit wem die Website spricht, wer die Schnittstelle betreibt und wen wir fragen, wenn sich etwas ändert.
Dann kommt das Feld-Mapping, und es kommt vor der ersten Zeile Code. Ein Artikel im ERP hat sehr viele Felder; eine Website braucht davon einen bewussten Ausschnitt. Wir halten schriftlich fest, welches ERP-Feld auf welches Website-Feld geht, was Pflicht ist, was optional bleibt und was das Haus gar nicht erst verlässt — Einkaufskonditionen, Margen, Lieferantendaten und interne Bemerkungen gehören nicht in ein öffentliches JSON. Für mehrsprachige Auftritte gehört dazu die Frage, welche Sprachfassungen das System überhaupt führt.
Der wichtigste Punkt danach ist eine Architekturentscheidung, und sie ist nicht verhandelbar: Ein ERP ist kein Frontend-Backend. Es ist nicht dafür gebaut, jeden Seitenaufruf zu beantworten. Produktdaten, Preise und Verfügbarkeiten werden deshalb im festen Takt in das CMS gespiegelt, und das Frontend liest aus dem eigenen Bestand. Das hält die Seite schnell, macht sie unabhängig von der Erreichbarkeit des ERP und sorgt dafür, dass ein Wartungsfenster im System keinen leeren Produktkatalog produziert.
Live abgefragt wird nur, was live sein muss. Der Auftragsstatus im Kundenzugang gehört dazu, der Produktname nicht. Und selbst die Live-Abfrage bekommt ein Zeitlimit und eine Rückfallebene: Antwortet das System nicht rechtzeitig, zeigt die Seite den zuletzt bekannten Stand mit Hinweis, statt den Besucher in einen Ladebalken laufen zu lassen. Ein langsames ERP darf nie eine langsame Website ergeben.
Bleibt der Fehlerfall, der in Angeboten gern fehlt. Läuft ein Abgleich ins Leere oder kommt er unvollständig zurück, bleibt der letzte gute Stand stehen, der Lauf wird protokolliert und mit Abstand erneut versucht. Ein abgebrochener Import darf nie den Bestand leeren. Dasselbe gilt für den Rückkanal: Geht eine Anfrage nicht durch, ist sie trotzdem gesichert und geht zusätzlich per E-Mail raus. Die buchbare Leistung dahinter beschreiben wir unter Schnittstellenentwicklung.
// technik · 6 details
generisch statt geraten
SAP-Landschaften unterscheiden sich stark von Haus zu Haus — welche Module laufen, was angepasst wurde, was nach außen freigegeben ist. Deshalb steht hier bewusst das, was systemunabhängig gilt, statt Konkretes, das im nächsten Projekt schon nicht mehr stimmt. Die verbindlichen Details liefert die IT des Kunden zum Projektstart.
// d-01weg a
OData ist ein offener Standard nach REST-Prinzipien, heute bei OASIS angesiedelt: Zugriff über HTTPS, Daten als JSON oder XML. SAP Gateway stellt Geschäftsdaten auf diesem Weg bereit — die aufrufende Seite braucht kein SAP-Spezialwissen, sondern spricht mit einer Web-Schnittstelle.
zweck: daten lesen
// d-02weg b
Statt das ERP direkt anzusprechen, spricht die Website mit einer Middleware davor. Sie kapselt das System, bietet nach außen eine schlankere Schnittstelle und entkoppelt beide Seiten. Ob dafür Bausteine aus der SAP Integration Suite dienen oder eine vorhandene Middleware, entscheidet die IT.
zweck: erp kapseln
// d-03datenmodell
Welches ERP-Feld wird welches Website-Feld? Das Mapping steht als Dokument, bevor gebaut wird: Pflichtfelder, optionale Felder, Einheiten, Sprachen — und die Liste dessen, was das Haus nicht verlässt. Die Artikelnummer aus dem ERP bleibt dabei der Schlüssel, über den ein zweiter Lauf den Datensatz wiedererkennt.
zweck: klarheit vor code
// d-04takt
Der Import läuft in festem Takt und schreibt die Daten als eigene Inhaltsart in das CMS. Ausgeliefert wird danach aus dem eigenen Bestand — aus Cache oder statisch erzeugten Seiten. Das entkoppelt die Website vom Systemzustand und macht Filter und Suche schnell, weil sie auf lokalen Daten arbeiten.
zweck: tempo & unabhängigkeit
// d-05live
Manches muss aktuell sein: Auftragsstatus, Lieferdatum, ein kundenindividueller Preis. Diese Abfragen laufen serverseitig und gezielt — mit Zeitlimit, mit kurzer Zwischenspeicherung und mit einer Rückfallebene, die den zuletzt bekannten Stand zeigt, wenn das System nicht rechtzeitig antwortet.
zweck: aktualität ohne risiko
// d-06sicherheit
Zugangsdaten liegen serverseitig, nie im Browser und nie im Repository. Der Zugang wird auf das Nötigste beschränkt: lesend, wo lesend reicht, und nur auf die freigegebenen Daten. Jeder Lauf und jeder Fehler wird protokolliert, damit im Zweifel nachvollziehbar ist, was wann gelaufen ist.
zweck: trennung & nachweis
Aus den gespiegelten Daten wird kein Datenbankauszug, sondern eine Website. Der Produktkatalog filtert über die Felder, die im Mapping definiert sind — Kategorie, Merkmale, Maße, Ausführung — und arbeitet auf dem eigenen Bestand, also ohne Wartezeit auf ein fremdes System. Die Produktseite bekommt eine sprechende, dauerhafte URL, die Merkmale als Tabelle, zugehörige Dokumente und, wo es passt, Preis und Verfügbarkeit. Datenblätter entstehen aus denselben Feldern, statt als PDF gepflegt zu werden.
Für angemeldete Kunden kommt der Kundenzugang dazu: Aufträge, Lieferungen, Belege, wiederkehrende Bestellungen. Hier wird gezielt live abgefragt, weil ein Auftragsstatus von gestern wertlos wäre — mit Zeitlimit und Rückfallebene, wie oben beschrieben. Und darunter steht die Anfrage- oder Bestellstrecke, die einen Warenkorb oder eine Anfrage in Richtung ERP zurückgibt, statt sie in einem Postfach zu parken.
Beim Datenschutz laufen zwei Richtungen auseinander. Artikeldaten sind in der Regel unkritisch — Kundendaten sind es nie. Deshalb: Felder auf das Nötige begrenzen, Übertragung ausschließlich serverseitig über TLS, Zugriffe protokollieren, Löschfristen benennen und die Website sauber vom ERP getrennt halten. Was in den Kundenzugang darf und was nicht, ist eine Freigabefrage, keine Programmierfrage. Mehr dazu im Stack unter Sicherheit & Datenschutz.
// integration
drei systeme · ein muster
Der Weg ist in jedem CMS derselbe, und er ist bewusst systemunabhängig: Die Website spricht nie direkt mit dem ERP-Kern, sondern immer mit einer definierten Schnittstelle davor — einem freigegebenen OData-Service oder einer Integrationsschicht. Dahinter bleibt SAP unberührt, davor kann sich die Website weiterentwickeln, ohne dass jemand am führenden System schraubt. Was das CMS dafür mitbringen muss, ist schnell benannt: eine eigene Inhaltsart mit genau den Feldern aus dem Mapping, ein Platz für Bilder und Dokumente, und die Artikelnummer aus dem ERP als Schlüssel. Über diesen Schlüssel erkennt der zweite Lauf den Datensatz wieder und aktualisiert ihn, statt eine Dublette anzulegen.
Der zweite Teil ist die Frage nach dem Takt: Die Daten werden in das CMS gespiegelt, damit die Seite schnell bleibt und auch dann verfügbar ist, wenn das ERP gerade in einem Wartungsfenster steht. Ein geplanter Lauf holt die Änderungen, das Frontend liest aus dem eigenen Bestand, und nur die Detailseiten und Listen, die sich wirklich geändert haben, werden aus dem Cache genommen. Erst dadurch werden Artikel aus SAP auf der Website zu echten Seiten mit dauerhafter URL — auffindbar, verlinkbar, indexierbar — statt zu einem eingebetteten Fremdinhalt. Welches CMS darunter arbeitet, ändert an dieser Mechanik nichts; nur die Werkzeuge heißen anders.
// cms-01typo3
Im Konzernumfeld ist TYPO3 oft ohnehin gesetzt — und es bringt alles mit, was eine ERP-Anbindung braucht. Wir bauen sie als eigene Extension auf Basis von Extbase: Das TCA beschreibt das Datenmodell, also die Inhaltsart mit genau den Feldern aus dem Mapping. Der Import läuft als Scheduler-Task in festem Takt, die Datensätze liegen als Records in einem Systemordner, Bilder und Dokumente in FAL. Gerendert wird über Fluid-Templates, sprechende URLs für Liste und Detailseite kommen aus dem Site Handling. Die Zugangsdaten zur Schnittstelle liegen in der Extension-Konfiguration und damit serverseitig. Die Redaktion sieht die Datensätze im Backend, pflegt eigene Texte in Feldern daneben, die der Import nicht anfasst, und platziert Teaser als Content-Element auf jeder Seite.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so bleibt sie beim Theme-Wechsel bestehen und lässt sich unabhängig vom Design weiterentwickeln. Die Artikel werden ein Custom Post Type mit eigenen Meta-Feldern für die Produktdaten und Taxonomien für die Filter, also Kategorie, Serie und Ausführung. Ein geplanter Lauf holt die Änderungen aus der Schnittstelle und schreibt sie über die Artikelnummer als Schlüssel nach. Eine eigene REST-Route nimmt serverseitige Aufrufe entgegen, etwa wenn ein vorgelagertes System eine Aktualisierung anstoßen soll; die Zugangsdaten liegen in der Server-Konfiguration und nie im Frontend. Fürs Ausspielen kommen Template-Dateien und Blöcke für den Editor dazu, damit die Redaktion Liste, Filter und Teaser dort platziert, wo sie hingehören.
// cms-03statamic
Statamic läuft auf Laravel — und dieser Unterbau macht eine ERP-Anbindung besonders geradlinig. Ein Blueprint beschreibt das Datenmodell mit den Feldern aus dem Mapping. Ein Artisan-Command holt die Daten von der Schnittstelle und schreibt sie als Entries in eine eigene Collection; den Takt bestimmt der Laravel-Scheduler. Bilder und Datenblätter landen als Assets im eigenen Container. Die Zugangsdaten stehen in der .env und bleiben damit außerhalb des Codes. Antlers oder Blade rendern Liste, Filter und Detailseite, Static Caching liefert sie aus, sodass eine Anfrage an das ERP im Normalbetrieb gar nicht erst nötig ist. Im Control Panel pflegt die Redaktion Beschreibungstexte und Reihenfolge in Feldern, die der Import nicht überschreibt.
// entscheidung
zuordnung statt rangliste
Das ist die Frage, die über Tempo, Stabilität und Aufwand einer SAP-Anbindung entscheidet — und sie wird nicht pauschal beantwortet, sondern je Datenart. An drei Mustern lässt sich das zuordnen.
// e-01spiegeln
Artikelbezeichnungen, Beschreibungen, technische Merkmale, Kategorien, Datenblätter: Diese Daten ändern sich selten und müssen nicht sekundengenau stimmen. Sie werden im festen Takt gespiegelt und aus dem eigenen Bestand ausgeliefert — der Normalfall, und der Grund, warum die Seite schnell ist.
import im takt
// e-02live
Auftragsstatus, Lieferdatum, ein kundenindividueller Preis im angemeldeten Bereich: Hier wäre der Stand von gestern wertlos. Diese Abfragen laufen gezielt und serverseitig — mit Zeitlimit, kurzer Zwischenspeicherung und einer Rückfallebene, die den letzten bekannten Stand zeigt.
abfrage mit timeout
// e-03kombination
Meist die richtige Antwort: Der gespiegelte Bestand trägt Katalog, Filter und Suche, die Live-Abfrage ergänzt an den wenigen Stellen, an denen Aktualität zählt. Ein Weg für die Menge, ein Weg für den Moment — und die Website bleibt schnell, weil der zweite Weg die Ausnahme ist.
bestand + moment
Fünf Fragen entscheiden die Richtung, und sie lassen sich in einem Termin mit der IT beantworten. Welcher Weg nach draußen ist freigegeben — ein OData-Service oder eine Integrationsschicht? Welche Felder dürfen die Schnittstelle passieren, und welche auf keinen Fall? Wie viele Datensätze sind es, und wie oft ändern sie sich? Soll die Website nur lesen oder auch etwas zurückgeben? Und wer ist auf Kundenseite Ansprechpartner, wenn sich an der Schnittstelle etwas ändert?
Danach steht das Mapping als Dokument, bevor gebaut wird. Dieselbe Logik greift bei anderen Systemen dieser Klasse: weclapp und Dynamics 365 Business Central bringen eigene Schnittstellen mit, Salesforce sitzt auf der Kundenseite desselben Datenflusses. Welche Anbindung ein Projekt bekommt, klären wir im Konzept — vor dem Bauen, mit Begründung.
// faq
SAP ist die ERP-Software der SAP SE aus Walldorf. Unternehmen führen darin ihre Geschäftsprozesse und vor allem ihre Stammdaten: Artikel, Preise, Kunden, Aufträge, Bestände. Neben dem seit Jahrzehnten verbreiteten klassischen ERP steht die neuere Produktlinie S/4HANA; für die Website ist die Unterscheidung selten entscheidend, für den Weg nach draußen dagegen schon. Denn für eine Website heißt SAP vor allem eines: Das ERP ist das führende System für die Daten, die auf der Seite erscheinen sollen. Gepflegt wird im ERP, angezeigt wird auf der Website — und dazwischen liegt eine Schnittstelle, keine zweite Pflegestelle.
Über zwei Wege. Der erste sind OData-Services: SAP Gateway stellt Geschäftsdaten als REST-Schnittstelle über HTTPS bereit, in JSON oder XML, sodass ein externes System sie lesen kann, ohne SAP-Interna zu kennen. Der zweite ist eine Integrationsschicht beziehungsweise Middleware, die das ERP kapselt und nach außen eine eigene, schlankere Schnittstelle anbietet; SAP bündelt solche Bausteine unter der Integration Suite, es kann aber genauso eine bestehende Middleware des Unternehmens sein. Welcher Weg es wird, entscheidet in der Praxis nicht die Agentur, sondern die IT-Abteilung des Kunden: Sie gibt frei, was aus dem System heraus erreichbar sein darf.
OData ist ein offener Standard für den Zugriff auf Daten über das Web, ursprünglich von Microsoft entwickelt und heute bei der OASIS-Organisation angesiedelt. Er folgt REST-Prinzipien, läuft über HTTP beziehungsweise HTTPS und liefert Daten wahlweise als JSON oder als XML. Im SAP-Umfeld ist OData der Standardweg nach draußen: SAP Gateway ist die REST-Schnittstelle der ABAP-Plattform und stellt Geschäftsdaten als OData-Services bereit. Der Vorteil für uns ist, dass die aufrufende Seite kein SAP-Spezialwissen braucht — sie spricht mit einer dokumentierten Web-Schnittstelle wie mit jeder anderen auch.
Nein, und das ist Absicht. Die Website spricht nie direkt mit dem ERP-Kern, sondern immer mit einer definierten Schnittstelle davor — einem freigegebenen OData-Service oder einer Integrationsschicht. Dahinter bleibt das ERP unberührt, davor kann sich die Website weiterentwickeln, ohne dass jemand am führenden System schraubt. Das trennt sauber, wer wofür verantwortlich ist: Die IT verantwortet, was die Schnittstelle herausgibt, wir verantworten, was die Website daraus macht. Und es hält den Zugriff klein, denn eine Schnittstelle lässt sich auf genau die Felder beschränken, die nach draußen dürfen.
Nichts, was der Besucher merkt — wenn die Anbindung richtig gebaut ist. Ein ERP ist kein Frontend-Backend: Es ist nicht dafür gedacht, jeden Seitenaufruf zu beantworten, und es hat Wartungsfenster. Deshalb werden Produktdaten, Preise und Verfügbarkeiten im festen Takt in das CMS gespiegelt, und das Frontend liest aus dem eigenen Bestand. Fällt ein Abgleich aus, bleibt der letzte gute Stand stehen, der Lauf wird protokolliert und mit Abstand erneut versucht. Ein abgebrochener Import darf nie den Bestand leeren. Live abgefragt wird nur, was wirklich live sein muss — und selbst das mit Timeout und Rückfallebene, damit ein Wartungsfenster im ERP nicht die Website ausbremst.
Ein Artikel im ERP hat sehr viele Felder; eine Website braucht davon einen bewussten Ausschnitt. Nach draußen gehen die Felder, die ein Besucher sehen soll: Bezeichnung, Beschreibung, technische Merkmale, Zuordnung zu Kategorien, Dokumente, gegebenenfalls Preis und Verfügbarkeit. Im System bleibt alles, was intern ist — Einkaufskonditionen, Margen, Lieferantendaten, Kalkulationen, interne Bemerkungen. Deshalb steht bei uns das Feld-Mapping als Dokument, bevor gebaut wird: Es hält fest, welches ERP-Feld auf welches Website-Feld geht, was Pflicht ist, was optional bleibt und was das Haus gar nicht erst verlässt.
Vier Dinge kommen immer wieder vor. Ein Produktkatalog mit Filter und Suche, der auf den gespiegelten Artikeldaten arbeitet und damit ohne Wartezeit auf ein fremdes System auskommt. Datenblätter und Downloads, die aus denselben Feldern erzeugt werden, statt als PDF gepflegt zu werden. Ein Kundenzugang, in dem angemeldete Kunden ihre Aufträge, Lieferungen und Belege sehen — hier wird gezielt live abgefragt, weil ein Auftragsstatus von gestern wertlos wäre. Und eine Anfrage- oder Bestellstrecke, die den Warenkorb oder die Anfrage in Richtung ERP zurückgibt. Was davon sinnvoll ist, hängt am Geschäftsmodell, nicht an der Technik.
Ja, in allen drei Systemen — und wir bauen die Anbindung jeweils selbst, mit den Bordmitteln, die das CMS dafür mitbringt. In TYPO3 entsteht eine eigene Extension: Extbase als Unterbau, TCA als Datenmodell, der Import als Scheduler-Task, die Datensätze als Records, das Frontend über Fluid, die Zugangsdaten in der Extension-Konfiguration. Im Konzernumfeld ist TYPO3 damit oft gesetzt. In WordPress entsteht ein eigenes Plugin statt Theme-Code: ein Custom Post Type mit Meta-Feldern, ein geplanter Lauf für den Abgleich und eine eigene REST-Route für serverseitige Aufrufe. In Statamic liegt Laravel darunter: ein Artisan-Command im Scheduler, ein Blueprint als Datenmodell, die Datensätze als Entries in einer Collection, die Zugangsdaten in der .env. Die Mechanik bleibt in allen drei Fällen dieselbe — nur die Werkzeuge heißen anders.
// womit das zusammenhängt
systeme, frontend & leistung
// stack · schnittstelle
ERP aus der Cloud, gedacht für den Mittelstand — anderes System, dieselbe Frage: Was gehört auf die Website und in welchem Takt?
zur technik →
// stack · schnittstelle
Die ERP-Linie aus dem Microsoft-Umfeld und wie ihre Artikel- und Auftragsdaten den Weg auf eine Website finden.
zur technik →
// stack · schnittstelle
Die Kundenseite desselben Datenflusses: Wo das ERP Artikel führt, führt das CRM Kontakte — und die Website spielt Anfragen zurück.
zur technik →
// stack · grundlage
Wo Kundendaten und Zugangsdaten im Spiel sind, wird es ernst: serverseitige Schlüssel, TLS, minimale Rechte, Protokollierung.
zur technik →
// leistung · frontend
Was aus den gespiegelten Artikeldaten wird: Katalog mit Filter und Suche, Produktseiten mit dauerhafter URL, Datenblätter aus den Feldern.
zur leistung →
// leistung · buchen
Die Technik hier, das Angebot dort: Analyse, Mapping, Umsetzung, Monitoring und Betrieb der Anbindung. Hier wird gebucht.
zur leistung →
// Produktdaten aus SAP auf deine Website?
Projekt anfragen