Knowledge
Die Leitung zwischen TYPO3 und SAP ist meist schnell gelegt. Den größeren Teil der Arbeit macht die Abstimmung aus: welche Daten in welche Richtung fließen, wer den Zugang einrichtet und wie die Website reagiert, wenn SAP gewartet wird.
Bevor die Technik feststeht, kläre ich mit allen Beteiligten drei Dinge: welche Daten TYPO3 aus SAP braucht, welche Daten zurück an SAP gehen und welches System für welche Daten führend ist. Bei Aufträgen ist das in der Regel SAP. TYPO3 nimmt die Bestellung entgegen, angelegt und weiterverarbeitet wird sie in SAP. Texte, Bilder und Seitenstruktur führt TYPO3.
Aus diesen Antworten ergibt sich, ob TYPO3 live abfragt, regelmäßig importiert oder beides kombiniert, und welcher Zugang zu SAP dafür passt.
SAP bietet mehrere Arten von Schnittstellen. Welche davon in einem Projekt zur Verfügung steht, hängt vom SAP-System ab, von der IT-Architektur im Unternehmen und oft auch davon, was dort bereits im Einsatz ist.
OData ist der übliche Weg für Webanwendungen. SAP Gateway stellt Daten und Funktionen als Schnittstelle über HTTP bereit, die Antworten kommen als JSON oder XML. In SAP S/4HANA gehört Gateway zum System, und für viele Geschäftsobjekte gibt es fertige Services, die der SAP Business Accelerator Hub auflistet. Passt keiner davon, entwickelt das SAP-Team einen eigenen Service. Auf TYPO3-Seite genügt ein HTTP-Client, wie ihn TYPO3 mit der RequestFactory auf Basis von Guzzle mitbringt.
Über Remote Function Call (RFC) ruft ein externes Programm Funktionsbausteine direkt im SAP-System auf. BAPIs sind solche Funktionsbausteine mit einer fest definierten Schnittstelle für betriebswirtschaftliche Objekte, etwa zum Anlegen eines Kundenauftrags. RFC ist kein Webprotokoll. Der Server, auf dem TYPO3 läuft, braucht dafür das SAP NetWeaver RFC SDK, eine passende PHP-Erweiterung und eine Netzwerkverbindung bis ins SAP-System. Das bindet das Hosting eng an SAP. Häufig ist es einfacher, die benötigten BAPIs über einen OData-Service oder eine Middleware als HTTP-Schnittstelle bereitzustellen.
Viele Unternehmen veröffentlichen SAP-Schnittstellen über eine vorgeschaltete API-Schicht. Bei SAP ist das API Management, ein Teil der SAP Integration Suite auf der SAP Business Technology Platform (BTP). Es setzt vor den eigentlichen Service einen API-Proxy, der Zugriffe absichert, begrenzt und protokolliert. Die Anmeldung läuft dann meist über OAuth 2.0: TYPO3 holt sich mit Client-ID und Secret ein Zugriffstoken und schickt es bei jeder Anfrage mit. Steht das SAP-System im eigenen Rechenzentrum, verbindet der SAP Cloud Connector die BTP mit dem System. Weil er die Verbindung von innen nach außen aufbaut, braucht die Firewall keine eingehenden Freigaben. Ein API-Gateway eines anderen Herstellers funktioniert aus Sicht von TYPO3 genauso.
Betreibt das Unternehmen bereits eine Integrationsplattform, etwa SAP Cloud Integration, SAP Process Orchestration oder ein Produkt eines anderen Herstellers, ist sie meist der vorgesehene Weg. Die Middleware spricht auf der SAP-Seite RFC, OData oder IDoc, das klassische SAP-Format für Stamm- und Bewegungsdaten, und bietet TYPO3 eine einfache HTTP-Schnittstelle an. Die Eigenheiten von SAP bleiben so in der Middleware. Dafür ist ein weiteres Team beteiligt, und Änderungen laufen über dessen Planung.
Der einfachste Weg ist ein regelmäßiger Export. SAP legt eine Datei, etwa als CSV oder XML, auf einem SFTP-Server ab, und TYPO3 importiert sie zeitgesteuert über den Scheduler. Umgekehrt kann TYPO3 Bestellungen als Datei bereitstellen, die SAP abholt und verarbeitet. Das passt gut für Produktkataloge, Standortlisten oder Preislisten, die sich im Lauf eines Tages kaum ändern. Freie Termine oder eine sofortige Auftragsbestätigung brauchen dagegen eine direkte Verbindung.
Eine Live-Abfrage holt die Daten in dem Moment, in dem jemand die Seite aufruft oder eine Eingabe macht. Das ist der richtige Weg für alles, was sich schnell ändert oder für jede Anfrage neu berechnet wird. Bei der Online-Bestellung für Sperrgut fragt TYPO3 die freien Abholtermine direkt in SAP ab, getrennt nach Sperrgut und Schrott, weil für beide unterschiedliche Touren gelten.
Ein regelmäßiger Import übernimmt die Daten als Datensätze in TYPO3. Die Seiten laden schnell, die Suche findet die Inhalte, und die Redaktion kann sie mit eigenen Texten und Bildern ergänzen. SAP wird nur zum Importzeitpunkt angefragt, die Seitenaufrufe bedient TYPO3 allein.
Oft läuft es auf eine Kombination hinaus. In einem B2B-Shop mit TYPO3, angebunden an eine Warenwirtschaft von Microsoft, werden Produkte und Kategorien regelmäßig importiert. Die Preise ruft der Shop live ab, weil sie von der bestellten Menge abhängen können. Für SAP gilt dieselbe Aufteilung.
Schreibende Zugriffe brauchen mehr Sorgfalt als lesende. In der Sperrgut-Bestellung bleiben die Eingaben über alle vier Schritte in der Sitzung, und erst beim Absenden übergibt TYPO3 den Auftrag an SAP. So bekommt SAP nur vollständige Aufträge zu sehen.
Die Eingaben lassen sich schon im Formular auf das abstimmen, was SAP erwartet. Die Adresse wählt man dort per Autovervollständigung aus dem Straßenverzeichnis der Stadtwerke. Damit kommen nur Adressen an, die das Entsorgungssystem kennt. Ob ein Auftrag angelegt ist, entscheidet am Ende SAP, deshalb wertet TYPO3 die Antwort aus. Gibt die Schnittstelle einen Fehler zurück, bekommt die bestellende Person eine verständliche Rückmeldung und kann darauf reagieren.
Wird eine Anfrage nach einer Zeitüberschreitung wiederholt, muss SAP erkennen können, ob der erste Versuch bereits angekommen ist. Dafür eignet sich eine eindeutige Referenz je Auftrag, die TYPO3 mitschickt.
Bei OData-Services kommt eine technische Eigenheit dazu. SAP Gateway schützt schreibende Anfragen mit einem CSRF-Token. Der Client holt es sich vorab mit einer lesenden Anfrage und schickt es zusammen mit dem Session-Cookie beim Schreiben mit. Wer das weiß, setzt es in wenigen Zeilen um. Wer es nicht weiß, verbringt einen Nachmittag mit der Frage, warum SAP jede Bestellung mit 403 beantwortet.
Auch ein gut betriebenes SAP-System hat Wartungsfenster, und Verbindungen können kurz abreißen. Die Website braucht dafür eine Antwort, die Besucherinnen und Besucher verstehen. Jede Anfrage an SAP bekommt deshalb eine kurze Zeitbegrenzung. Fehler landen im Log, auf der Seite erscheint ein Hinweis.
Für geplante Unterbrechungen hat die Sperrgut-Bestellung einen Wartungsmodus mit zwei Stufen. Im Soft-Modus beginnt niemand mehr eine neue Bestellung, und wer gerade mittendrin ist, hat noch 30 Minuten Zeit zum Abschließen. Im Hard-Modus ist die Anwendung sofort gesperrt. Die Mitarbeitenden schalten den Modus selbst im Browser um und hinterlegen einen eigenen Hinweistext.
Bei importierten Daten hilft eine Plausibilitätsprüfung über kurze Aussetzer der Quelle hinweg. Für den Spielplan eines Theaters habe ich den Import so gebaut, dass TYPO3 bei einer vorübergehend leeren Antwort die vorhandenen Daten bis zur nächsten erfolgreichen Aktualisierung weiterverwendet. Die Daten kommen dort nicht aus SAP, das Prinzip passt aber genauso auf einen SAP-Import.
Wie sich TYPO3 bei SAP anmeldet, gibt in der Regel die IT auf Kundenseite vor. Üblich sind ein technischer Benutzer mit Passwort, ein Client-Zertifikat oder OAuth 2.0 über ein API-Gateway. Für technische Zugänge empfiehlt SAP in seiner Dokumentation Zertifikate statt Passwörtern.
Die Verbindung der Sperrgut-Bestellung unterstützt mehrere Verfahren, von der klassischen Anmeldung bis zur Absicherung über das API-Gateway der Stadtwerke.
Unabhängig vom Verfahren bekommt der technische Benutzer in SAP genau die Berechtigungen, die die Website braucht. Die Zugangsdaten liegen in der Konfiguration des Servers, getrennt vom Code der Extension.
Eine SAP-Anbindung entsteht gemeinsam mit dem SAP-Team auf Kundenseite, intern oder bei einem SAP-Dienstleister. Von dort kommen:
Ich übernehme die TYPO3-Seite: eine eigene Extension für die Verbindung, die Formulare und Ausgaben, die Fehlerbehandlung und die Tests gegen das Testsystem. Am schnellsten geht es voran, wenn beide Seiten früh eine Beispielanfrage mit echter Antwort austauschen. Mehr zu Schnittstellen und eigenen Extensions steht auf der Seite zur TYPO3-Entwicklung.
FAQ
Ja. TYPO3 spricht OData-Services von SAP Gateway direkt über HTTP an, ebenso Schnittstellen hinter einem API-Gateway oder dem API Management der SAP Integration Suite. Funktionsbausteine und BAPIs lassen sich per RFC aufrufen, dafür braucht der Webserver das SAP NetWeaver RFC SDK und eine PHP-Erweiterung. Die Anbindung selbst steckt in einer eigenen TYPO3-Extension.
Nicht zwingend. Stellt SAP einen OData-Service bereit, verbindet sich TYPO3 direkt damit. Betreibt das Unternehmen bereits eine Integrationsplattform, ist sie oft der vorgesehene Weg, weil Absicherung, Protokollierung und die Übersetzung zwischen Formaten dort zentral geregelt sind.
Ja. Die Fragen sind dieselben wie bei SAP: welche Daten live abgefragt und welche importiert werden, was zurück ins ERP geschrieben wird und wie sich TYPO3 anmeldet. Ein Beispiel ist ein B2B-Shop in TYPO3, der Produkte, Preise und Kundendaten aus einer Microsoft-Warenwirtschaft bezieht.
Das Projekt im Detail, oder direkt ins Gespräch: