Die Zeit der Leuchttürme ist vorbei
Im Rahmen eines Studentenjobs 1998 stellte ich dem SAP-Basis-Admin die naive Frage, wie ich denn bitteschön von meiner Visual-Basic-Anwendung aus auf dieses SAP zugreifen könne.
Die Anwender mussten seinerzeit per Copy-and-paste Materialdaten vom SAP GUI in die externe Lageranwendung übertragen. Wortlos drückte er mir ein graues, gedrucktes Softcover-Buch in die Hand:
„Mastering SAP Remote Function Call in C/C++“. Rückwirkend betrachtet war das vermutlich seine Art zu sagen: Lass es.
Fast 20 Jahre sind seitdem vergangen und es ist viel Wasser an der Walldorfer SAP-Zentrale vorbei den Leimbach hinuntergeflossen. Die Fragen nach dem Business Benefit und der richtigen technischen Herangehensweise sind nach wie vor aktuell.
Daten- und Prozessintegration
Wenn es um SAP-Schnittstellen geht, unterscheiden wir grundsätzlich zwei große Bereiche: Datenintegration und Prozessintegration.
Bei der Datenintegration geht es in der Regel um den Transport größerer strukturierter Datenmengen. Der Sinn und Zweck ist in Bereichen rund um die Datenanalyse zu sehen.
Das kann von einfachen Charts für die Führungsebene bis hin zur Predictive Analytics und Data Mining mithilfe von künstlicher Intelligenz gehen. In jedem Fall ist dieser Bereich nachgelagert zu den klassischen Geschäftsvorfällen zu sehen, die im Allgemeinen mit SAP ERP abgedeckt werden.
Würde man komplett in der SAP-Welt bleiben, würde man die Datenanalyse-Anforderung klassisch mit BW, Hana und den BO-Front-End-Tools abdecken.
Der zweite große Bereich ist die Prozessintegration. Hier findet der Datentransfer heruntergebrochen auf die einzelne Transaktion statt. Ein Prozess könnte im SAP beginnen und an ein Subsystem abgegeben werden.
Schönes Beispiel hierfür wäre ein Kundenangebot, das im SAP SD entsteht, um dann aber noch außerhalb des SAPs mit Zusatzdaten, Bildern und Zeichnungen angereichert zu werden.
Die Gegenrichtung ist genauso denkbar. Über einen Non-SAP-Workflow werden aus verschiedenen Abteilungen Informationen zu einem neu anzulegenden Materialstammdatensatz eingesammelt. Beteiligt sind das Produktmanagement, der Einkauf und gegebenenfalls noch Kollegen aus der Logistik.
Erst wenn alle Infos komplett und konsistent sind, werden die Daten und der Anlageprozess ans SAP MM übergeben. Praktisch alle SAP-Schnittstellen lassen sich in diese zwei Kategorien Prozess- und Datenintegration einteilen, die sich jeweils technisch komplett unterscheiden.
Sollbruchschnittstellen
Bevor wir technische Aspekte beleuchten, sollten wir die Warum-Frage stellen. SAP durchdringt mit ihrer schier unüberschaubaren Produkt- und Modulpalette theoretisch alle Anforderungen nahezu jedes SAP-Bestandskunden.
Jede Schnittstelle zwischen Systemen oder Herstellern wird oft als eine Art Sollbruchstelle gesehen, die gerade dann besonders lästig wird, wenn sie nicht funktioniert. Und in der Regel ist natürlich die jeweils andere Partei schuld. Und trotzdem gibt es Argumente, die diese Sorgen übertönen.
Oft gehörter Wunsch vom Anwender ist der Ruf nach höherer Performance. Ich möchte mich ausdrücklich gegen den pauschalen Vorwurf wehren, SAP sei langsam, aber trotzdem ist es unter den Walldorfern seit Firmengründung ja fast schon Tradition, ihre Software genau so zu gestalten, dass die verfügbare Hardware immer gefühlt einen Tick zu langsam für die Anwendungen ist.
Das galt lange Zeit vor allem für das SAP BW. Der Einsatz von Hana hat die Sache mit Sicherheit etwas relativiert, trotzdem war es gerade der Datenanalyse-Bereich, der die Geduld des Anwenders bis an die Schmerzgrenze und darüber hinaus strapaziert.
Somit liegt es nahe, dass viele SAP-Bestandskunden in externen Subsystemen eine deutlich bessere Ratio zwischen Kosten und Performance vorfinden.
Ein weiteres wichtiges Argument ist das Abmischen mit Non-SAP-Daten – egal ob in der Daten- oder Prozessintegration. Firmendaten komplett innerhalb der Software eines Herstellers zu halten funktioniert flächendeckend nur im Hochglanzprospekt, aber niemals im wahren Leben.
Und ja, natürlich bietet SAP ERP und SAP BW die Möglichkeit, externe Daten in SAP einzuladen und dort weiterzuverarbeiten, aber ein realistisches, bezahlbares Verfahren ist das mitnichten.
Wer SAP- und Non-SAP-Daten gleichzeitig benötigt, wird sich dazu einen Platz außerhalb von SAP suchen müssen oder er muss viel Zeit und ein großes Budget mitbringen.
Lastenhefte biblischen Ausmaßes
Die Digitalisierung ist in aller Munde. Die Medien, Politiker und Firmenchefs interpretieren alles Mögliche und Unmögliche in diesen Begriff hinein. Sie liefert auch unser drittes Argument, das eigentlich viel älter ist als der Begriff Digitalisierung selbst: Agilität.
Es ist mit Sicherheit dem Alter und der langen Historie von SAP geschuldet, dass bestimmte Muster im Projektmanagement oft anzutreffen sind: Zum Projektstart betritt der Berater den Meeting-Raum, spitzt den Bleistift und lauscht dem zukünftigen Anwender, was er denn gerne hätte.
Das Lastenheft – oft dicker als die Bibel – geht in die Umsetzung und nach quälend langen Monaten oder gar Jahren erfolgt der Produktivstart.
Bedauerlicherweise hat sich die Welt schon dreimal weitergedreht und selbst der Fachanwender vom initialen Meeting ist kein Hellseher. So funktioniert aber das Aufsetzen von SAP-geführten Prozessen im Allgemeinen und das ist das genaue Gegenteil von Agilität.
Wenn wir allerdings die Daten über eine elegante Schnittstelle in ein dafür geeignetes Subsystem übergeben, können wir technisch und organisatorisch dafür sorgen, dass die Iterationszyklen in Projekten von Monaten auf Tage zusammenschrumpfen und die Anpassungsfähigkeit in den Himmel schießt. Das ist Agilität.
Ein großer Vorreiter dieser Denkweise ist im Übrigen Self Service BI, das ja nichts anderes bedeutet, als offiziell zuzugeben, dass beim Erstellen einer Analyse-Datenquelle noch nicht so genau bekannt ist, welche Fragen mit dem Datenbestand überhaupt beantwortet werden sollen.
Wer jetzt glaubt, die Anwender würden mit feuchten Augen und vor Begeisterung zittrigen Händen vor dem Rechner sitzen, der irrt. Die Anwender machen das nämlich ohnehin schon immer so, und zwar mit Excel.
Wir haben nun die drei wichtigsten Argumente kennengelernt: Performance, Abmischen mit Non-SAP-Daten und Agilität. Es gibt viele, viele mehr, aber in den vergangenen zwanzig Jahren und über fast 2500 Schnittstellenprojekte hinweg sind diese drei das Destillat dessen, was SAP-Bestandskunden zu diesem Thema umtreibt. Spannenderweise hat sich daran über die Zeit auch so gut wie nichts geändert.
Technik für den Datentransfer
Betrachten wir zunächst die technischen Aspekte für das Thema Datenintegration, also eine typische Teildisziplin der Business Intelligence. Völlig unabhängig vom Hersteller übernimmt diesen Part eine Schicht, die wir mit ETL (Extract, Transform, Load) oder ELT (Extract, Load, Transform) bezeichnen.
Oft müssen die Daten noch in eine für die Analyse aufbereitete Form gebracht werden, z. B. durch Qualitäts- und Konsistenzchecks. Je nachdem, ob diese Transformation während des Transports oder nach der Ankunft im Zielsystem erledigt wird, spricht man von ETL oder ELT.
In jeder Art von Analysesystem oder Datawarehouse findet sich solch eine Schicht in unterschiedlichen Ausprägungen.
ETL und SQL
Eine der gängigsten Szenarien wäre zum Beispiel die Datenhaltung in einem Microsoft SQL Server. Den ETL-Part würden die sogenannten SQL Server Integration Services (SSIS) übernehmen.
Ein Tool, das mit dem SQL Server zusammen ausgeliefert wird. Hier werden die Datenflüsse grafisch modelliert und dann automatisiert. Das funktioniert so gut und preisgünstig, dass selbst hin und wieder Kunden ohne Microsoft-Background die SSIS nutzen, um Daten in fremde Systeme zu transportieren (z.B. ein Oracle-Datawarehouse).
Die gewünschten Transformationen werden in jedem Fall auf dem Transportweg erledigt. Neben anderen ETL-Anbietern wie Alteryx wäre eine Alternative dazu, die Originaldaten aus den Vorsystemen so zu belassen, wie sie sind, zunächst abzulegen und dann nachgelagert aus einer Staging-Schicht zu veredeln – ELT eben.
Auch diese Vorgehensweise funktioniert sehr gut mit allen gängigen Datenzielen: SQL Server, Oracle, Hadoop-Anwendungen, Amazon Redshift. Die Liste lässt sich endlos weiterführen und hängt vom Geschmack des Kunden ab.
Sind die Daten erst einmal für die Analyse aufbereitet, öffnet sich ein praktisch unendlicher Fundus an Analysemöglichkeiten. Vom klassischen Excel über Power BI bis hin zu Anbietern wie Board oder Tableau, die allesamt Maßstäbe in Sachen User Experience setzen.
Auch wenn SAP in solch einer Landschaft theoretisch nur ein Datenlieferant von vielen ist, so nimmt es doch erfahrungsgemäß eine Sonderstellung ein. Das liegt vor allem daran, dass die Anbindung von SAP technisch eher komplexer ist als andere und auch schnell zum Groschengrab wird, wenn man die falschen Tools verwendet.
Betrachten wir SAP ERP als Datenlieferant, so eignen sich eine Reihe von Quellobjekten als Ausgangspunkt. Im einfachsten Fall Tabellen. Es ist zwar korrekt, dass die Anzahl von SAP-Tabellen irgendwo je nach Release und Modul im sechsstelligen Bereich liegt, aber die wirklich relevanten lassen sich erfahrungsgemäß einfach finden und stellen sich in der Praxis als beherrschbares Problem heraus.
Viele Kunden greifen auch gerne auf Queries zurück. Das ist zwar eine beeindruckend alte Technik, aber gerade SAP-Bestandskunden mit langer Historie können auf bestehende Artefakte zurückgreifen, ohne das Rad neu erfinden zu müssen.
Wenn die Datenmengen größer werden, muss natürlich eine inkrementelle Beladung mit bedacht werden. Die einfachste Möglichkeit ist, klassische OLTP- Datenquellen zu nutzen, so wie sie auch ein BW mit Daten versorgen würden.
Diese Art des Datentransfers wird von SAP im Übrigen gerade renoviert und durch das elegantere und robustere ODP ersetzt. Es ist also nicht absehbar, dass diese Art des Datentransfers in absehbarer Zeit einer Hana-Roadmap zum Opfer fällt.
SAP BW und der Wegezoll namens Hub-Lizenz
Ein wichtiger Aspekt ist die Rolle eines SAP BW. Erfahrungsgemäß nutzen zwei Drittel aller Kunden den Zugriff auf die Daten des SAP ERP und ein Drittel aus dem BW. Für den Weg über das BW kann man im einfachsten Fall auf klassische BEx-Queries zurückgreifen.
Wenn die Datenmengen steigen, können Export-Datasources für eine inkrementelle Weitergabe der Daten vom jeweiligen BW-Objekt in ein nachgelagertes System sorgen.
Ein sehr wichtiger Punkt sei an dieser Stelle noch erwähnt: Sollten die Daten nicht direkt vom ERP, sondern vom BW aus in ein externes Datawarehouse transportiert werden, ist je nach Lizenzbedingung und Vertrag ein Wegezoll mit Namen Open-Hub-Lizenz nach Walldorf zu entrichten.
Politisch soll das offensichtlich die SAP-Bestandskunden von diesem Weg abhalten. Meiner Erfahrung nach führt das aber eher zum gegenteiligen Effekt. Der wird dadurch nämlich finanziell ermutigt, das bestehende BW aus dem Datenfluss gleich ganz zu entfernen.
Die Gründe, die Daten zunächst über ein BW und dann erst in einen DataMart zu transportieren, sind eher dünn und haben oft mehr mit Politik und Historie zu tun als mit technischer Notwendigkeit.
Prozessintegration
Die Technik hinter der Prozessintegration ist grundlegend anders als bei der Datenintegration des vorangegangenen Abschnitts. Hier geht es ja vor allem darum, eine einzelne Transaktion entweder vom SAP nach außen oder von außen an SAP zurückzugeben.
Auf der äußeren Seite kommen oft Workflow-Systeme zum Einsatz. Das könnte zum Beispiel Nintex, K2 oder Microsoft Flow sein. Jeweils technisch in ein SharePoint eingebettet oder auch ohne.
Wenn es keine Workflow-Anwendung ist, finden wir oft Office-Anwendungen (am ehesten Excel) auf der Non-SAP-Seite bis hin zu maschinellen Konsumenten wie eine Förderanlage oder andere Produktionsmaschinen, die ja auch am Datentropf von SAP hängen.
Im Fall von Excel könnte ein typischer Use Case sein, entweder Daten aus SAP in ein Excel-Sheet zu übernehmen (z. B. Kunden-adresse zur Kundennummer) und/oder von dort aus zurückzuspielen (z. B. Materialstücklisten pflegen). Die Anwendungen sind vielfältig und in der Regel ein großer Effizienzgewinn für den Endanwender.
Er muss nämlich seine vertrauten Umgebungen (Excel, SharePoint oder auch andere Software von Drittanbietern) nicht verlassen. SAP und Microsoft haben in der Vergangenheit mit Duet mehrere Versuche unternommen, in diese Kerbe zu schlagen.
Das war wenig von Erfolg gekrönt und am Ende wurden gute Ideen durch die falsche technische Umsetzung und zu viel Politik zu Staub zerrieben. Auf SAP-Seite ist der Ausgangspunkt praktisch immer ein Funktionsbaustein. Das kann entweder ein bestehender Standard-BAPI sein oder ein selbst entwickelter Z-Baustein.
Andere Techniken wie Transaktionsrekorder oder Ähnliches haben sich als wenig flexibel erwiesen. Auch die Nutzung eines SAP Gateways sollte sorgfältig durchdacht werden. Das SAP Gateway ist letztendlich nur ein zusätzlicher Layer, der den Funktionsbaustein in OData übersetzt.
Das hat gleich zwei gravierende Nachteile: Durch die zusätzliche Schicht nehmen Performance und Responsiveness ab; außerdem lassen sich nur manche Geschäftsvorfälle in diese tabellenorientierte Denkweise von OData zwängen.
Use Cases, bei denen die Daten sehr hierarchisch und nicht tabellenartig sind (z. B eine Stückliste oder komplexe Materialstamm-daten), werden in Gateway sehr schnell hässlich und unübersichtlich, was Agilität im Entwicklungsprozess nicht nur einschränkt, sondern oft gänzlich zum Erliegen bringt.
Die Praxis hat gezeigt, dass ein Zugriff mit so wenig Schichten wie möglich am besten, einfachsten und schnellsten funktioniert: direkt vom externen System per RFC auf den Baustein oder das BA zugreifen.
Entweder durch wenige Zeilen Code, die selbst programmiert werden, oder durch intelligente Tools, die das Programmieren in einem grafischen Editor wegkapseln. Auch wenn sich das ein wenig hemdsärmelig anhört, hat es sich in der Praxis fast immer den Gateways und PIs dieser Welt als überlegen dargestellt.
Fazit
Wir haben hier die wichtigsten Aspekte zum Thema SAP-Schnittstellen kennengelernt. Dabei spielt zunächst die Frage eine Rolle, ob der Kunde Massendaten transportieren möchte (Datenintegration) oder Prozesse und Transaktionen innerhalb von SAP mit der Außenwelt verbinden will.
Die wichtigsten Beweggründe dafür sind eine gute Performance und SAP- mit Non-SAP-Daten näher aneinander zu bringen. Ein weiterer Grund ist die Notwendigkeit, Systemlandschaften und Informationsflüsse so zu bauen, dass sie auf zukünftige Veränderungen schon vorbereitet, also agil sind.
Unter technischen Gesichtspunkten können viele Objekte auf SAP-Seite als Datenlieferant gelten: Tabellen, Queries, OLTP-Sources, BW-Queries etc. Bei der Integration von Transaktionen ist der Bestandskunde gut beraten, Zwischenschichten weitestgehend wegzulassen.
Auch wenn diejenigen, die gerne die Zwischenschichten verkaufen wollen, das naturgemäß anders sehen. Die Vorteile überwiegen durch bessere Performance und Agilität. Abschließend sei generell dazu geraten, mehr Pragmatismus und kurze Feedback- und Iterationszyklen zu wagen.
Die Zeit der großen und alle Integrationsprobleme lösenden Leuchtturmprojekte ist vorbei. Am Ende müssen die Dinge in der realen Welt und nicht auf dem Hochglanzpapier stabil funktionieren.
Download as PDF only for members. Please create an account Here
