SAP Gateway oder SAP PI? Reicht nicht eine Middleware aus?
Die SAP User Experience Strategie gibt die Richtung vor: SAPUI5 ist im SAP Umfeld die Technologie für Applikationsentwicklung auf der Höhe der Zeit – das gilt sowohl auf mobilen Geräte wie auch auf dem Desktop. Und wer UI5 sagt, der muss auch Gateway sagen: SAP NetWeaver Gateway stellt die Daten für UI5-basierte Apps und Anwendungen bereit.
Wie ist aber das Verhältnis von Gateway zum weiter verbreiteten SAP PI? Braucht man beides? Welche Komponente wird für welchen Zweck eingesetzt?
Wir sind Ihr Dienstleiter für Ihr Entwicklungsprojekt, das den Anwender in den Mittelpunkt stellt.
Der perfekte Einstieg in das Thema SAPUI5 ist unser SAP UI5 Kickstarter Workshop.
Gerne spreche ich mit Ihnen über Ihre Ausgangslage und zeige Lösungsmöglichkeiten auf. Auf Wunsch unterbreite ich Ihnen im Anschluss ein unverbindliches Angebot.
Kontaktieren Sie mich: Telefon 0211.9462 8572-16 oder per E-Mail info@erlebe-software.de
Ingo Biermann, Fachbereichsleiter
SAP Gateway vs SAP PI
SAP NetWeaver Gateway – Der Türöffner
Zweck des Gateway Servers ist es, die Geschäftsdaten der SAP Business Suite sozusagen aufzuschließen für die Welt der aktuellen benutzerzentrierten Anwendungen. Da wo sich HTML5 und ABAP-Funktionsbausteine unvereinbar gegenüberstanden, wird der Abgrund zwischen den beiden Welten mit dem NetWeaver Gateway überbrückt.
Die Nutzung des OData Protokolls und damit der REST Prinzipien bringt Schnittstellen mit offenen Standards in die Welt der Business Suite. Das Ergebnis ist eine neue Einfachheit: Die altgedienten Baumeister der Serviceorientierten Architektur (SOA) – zu denen auch ich gehöre – müssen zugeben, dass eine SOAP basierte Schnittstelle auf diesem Feld nicht wirklich mithalten kann. Zu komplex ist die Ansteuerung mittels generierten Proxies und oftmals breiten, transaktionsorientierten Signaturen.
In der englischen Community wurde der Begriff der OPU geprägt – nicht die offene Punkte Liste, sondern “Occasional Platform Programers”. Der Ausdruck macht die Bedeutung der Einfachheit in diesem Zusammenhang deutlich: Natürlich KANN man auf die Daten auch ohne OData und SAP NetWeaver Gateway zugreifen. In der Praxis ist es nur eben so, dass pragmatisch gesehen einfache, ad hoc Anwendungsentwicklung, Quick Wins und die Öffnung für Entwickler anderer Plattformen und Systemwelten EINFACHER und BESSER gelingt.
XI – PI – PO
Die NetWeaver Process Integration wird von der SAP anders positioniert, nämlich als die Maschine für die richtigen “Integrationsszenarien”, also in erster Linie für Maschine-zu-Maschine Kommunikation. Es gehören alle Werkzeuge dazu, die einerseits für den Einsatz als Enterprise-Service-Bus oder für den automatischen Austausch von Daten zwischen Geschäftspartnern im B2B-Verkehr.
Alles-auf-Alles ist der Anspruch, den die PI hier hat. Eine große Anzahl von Adaptern verbindet verschiedenen technologische Welten. Besonders hochvolumige asynchrone Szenarien (zum Beispiel per IDoc) mit Monitoring, Queueing und weiteren Diensten sind die Stärke der PI. Das ES-Repository kennt man als komplexes Verzeichnis für unternehmensweite Standardisierung und Mapping-Fähigkeiten im XML.
Unter der Bezeichnung Process Orchestration wird jetzt auch noch das SAP BPM mit in die PI integriert. Hier liegt aber keine Überschneidung zur Gateway Funktionalität vor.
SAP Gateway oder SAP PI? Was also für was?
Der erste Grundsatz: Process Integration ist die Messaging Middleware, Gateway kann keine der Aufgaben übernehmen
Der zweite Grundsatz: SAP Gateway stellt Daten der SAP Business Suite als REST Services zur Verfügung. SAP sieht die PI im Standard für diese Aufgabe nicht vor.
Es bleibt also eine Frage zu beantworten: Kann und soll man die SAP PI dazu bringen, als REST-Provider zu agieren?
Im Standard hat SAP PI keinen passenden Adapter im Bauch. Es gibt inzwischen Drittanbieter, die entsprechende Erweiterungen anbieten und PI in die Lage versetzen, REST-basierte Schnittstellen bereit zu stellen. Es bleibt aber auch damit dabei, dass es keine blitzsaubere Architektur ist, User Interfaces über eine primär nachrichtenorientierte Middleware an ihre Datenlieferanten anzubinden. REST ist eben eine synchrone Client / Server Architektur und basiert damit auf einem grundsätzlich unterschiedlichem Ansatz als eine Middleware. Die vermittelt in erster Linie zwischen den Beteiligten und ist deshalb auch besonders stark in asynchronen Szenarien.
Aus Anwendersicht ist die synchrone Antwortzeit die Schlüsselanforderung für Applikationen und SAP PI hat seine größte Stärke eben nicht in diesem Bereich. Stattdessen haben Sicherheit, Robustheit und hohe Volumen Priorität. UI5 Anwendungen leben von exzellenter Benutzererfahrung und dafür ist eine guten Anbindung an die angezeigten Daten unabdingbar.
Die Antwort fällt aus wie so oft im SAP-Universum: Man KANN schon. Es GIBT Szenarien, in denen das auch sinnvoll sein kann. Im GRUNDSATZ sollte man es aber nicht tun.
Haben Sie andere Erfahrungen gemacht? Nutzen Sie SAP PI als Middleware für HTML5 Anwendungen? Dann interessiert mich Ihr Erfahrungsbericht.
Save as PDF
