Suchen

SAP Business Suite vs. S/4HANA SAP Gateway Deployment-Modelle im Vergleich

| Autor / Redakteur: Tobias Schießl* / Dipl.-Ing. (FH) Andreas Donner

Derzeit ist nicht klar, wann SAP den Support für den „S/4HANA“-Vorgänger „SAP ERP“ einstellen wird – fest steht aber, dass eine Migration ansteht. Stellt sich also die Frage, wie die Gateway-Infrastruktur in S/4HANA aufgebaut wird und was sich ändert.

Firmen zum Thema

Ein pauschale gültiges SAP-Gateway-Deployment-Modell, das bei der Migration innerhalb vorgegebener Schritte umgesetzt werden kann, gibt es nicht – jedes Unternehmen muss hier seine eigene Lösung entwickeln.
Ein pauschale gültiges SAP-Gateway-Deployment-Modell, das bei der Migration innerhalb vorgegebener Schritte umgesetzt werden kann, gibt es nicht – jedes Unternehmen muss hier seine eigene Lösung entwickeln.
(Bild: © WrightStudio - stock.adobe.com)

Um das S/4HANA-System richtig nutzen zu können, muss das Thema Gateway und Deployment im Migrationsprojekt zwingend zu Beginn betrachtet werden. Dabei gibt es verschiedene Möglichkeiten, das Gateway in die Infrastruktur eines Unternehmens zu integrieren, denn je nach Systemlandschaft und Geschäftsszenarien sind unterschiedliche Deployment-Optionen sinnvoll.

Abbildung 1: Gateway Hub.
Abbildung 1: Gateway Hub.
(Bild: Mindsquare)

Abbildung 2: Embedded Gateway.
Abbildung 2: Embedded Gateway.
(Bild: Mindsquare)

Das Framework SAP Gateway als Bestandteil von „SAP Netweaver“ hat generell die Aufgabe, Anfragen von mobilen und Web-Anwendungen entgegenzunehmen und Inhalte von SAP-Backend-Systemen bereitzustellen. Die Vorteile eines Gateway-Systems liegen dabei in der Sicherheit und Administration, da eingestellt werden kann, welche Anfragen Zugriff erhalten.

Die Administration nach außenlässt sich so von der eigentlichen Geschäftslogik trennen. Durch Verwendung des Open Data Protocols (OData) können beliebige Programmiersprachen verwendet und auch eine Verbindung zu Nicht-SAP-Anwendungen hergestellt werden.

Im Überblick: Welche Deployment-Modelle gibt es?

Generell sind drei Modelle möglich: Eine Option ist das Deployment-Modell Gateway Hub, bei dem ein zentraler Server Anfragen an verschiedene Backend-Systeme weiterleitet (siehe: Abbildung 1) –beispielsweise bei mehreren SAP-Systemen im Unternehmen.

Zum anderen können Unternehmen sich für ein Embedded Gateway entscheiden, das ohne zentralen Verteiler direkt in das klassische SAP-System integriert ist (siehe: Abbildung 2). Darüber hinaus lässt sich gerade während S/4HANA-Migrationsprojekten häufig eine Mischform beobachten: Dabei gibt es einen Gateway Hub, an dem verschiedene Business-Systeme hängen, diese werden Schritt für Schritt auf S/4HANA migriert und mit einem Embedded Gateway verknüpft.

Wie sieht ein Gateway unter der Business Suite aus?

Bei einem klassischen „SAP-Business-Suite“-System empfiehlt die SAP den Gateway Hub, also einen vorgeschalteten Gateway-Server, der losgelöst vom eigentlichen SAP-System besteht und für alle Backend-Systeme greift. Die Business Suite und das Gateway können so unabhängig voneinander aktualisiert werden.

Die Vorteile sind hier also die Vereinfachung von Releases und eine einfachere Verwaltung. Als Nachteil gegenüber dem Embedded Deployment ist zu nennen, dass mehr Kommunikation zwischen den Systemen notwendig ist. Der Gateway Hub ist die beste Option in einer Landschaft, die rein aus Business-Suite-Systemen besteht und bei der aktuell keine Migration auf S/4HANA bevorsteht.

Mein Unternehmen möchte auf S/4HANA migrieren. Was muss bezüglich des Gateways beachtet werden?

Solange nur ein S/4HANA-System vorhanden ist, kann das Gateway-System noch separat betrieben werden. Sobald aber eine Landschaft aus mehreren S/4HANA-Systemen besteht, werden aufgrund unterschiedlicher Release-Stände in 95 Prozent der Fälle auch mehrere Gateway-Systeme benötigt.

Das heißt: Wenn ein System aktualisiert wird, muss das entsprechende Gateway ebenfalls aktualisiert werden und im Zuge dessen auch alle anderen Systeme. Daher können die Systemlinien und ihre Update-Zyklen in der Praxis nicht mehr unabhängig voneinander betrachtet werden.

Aufgrund dieser Abhängigkeiten zwischen den Release-Ständen ist in einer Landschaft mit mehreren S/4HANA-Systemen ein Embedded Gateway pro S/4HANA-System zu empfehlen. Darüber hinaus stellt S/4HANA diverse Optimierungsmechanismen für ein Embedded Deployment unter der Bezeichnung „Micro Hub“ bereit. Hier ist ein Mechanismus am Werk, der dafür sorgt, dass Aufrufe schneller bearbeitet werden können und der Nutzer seine Antwort schneller erhält.

Wo befindet sich der Schritt ´Gateway Deployment` im Migrationsprojekt?

Das Thema Gateway Deployment sollte bei einem S/4HANA-Migrationsprojekt am Anfang behandelt werden; denn in einem S/4HANA-System sind die meisten Anwendungen nur noch „Fiori“-basiert verfügbar. Teilweise gibt es große Transaktionen nicht mehr, die 20 Jahre lang in der Business Suite genutzt wurden.

Sobald es also in den Bereich Fiori übergeht, wird zwangsläufig ein Gateway-System benötigt, das meine Aufrufe entgegennimmt. Um mein S/4HANA-System richtig nutzen zu können, muss ich das Thema Gateway und Deployment also zwingend zu Beginn betrachten.

Wie sollten Unternehmen vorgehen?

Das kommt ganz auf den Scope des Migrationsprojektes an. Möchten Admins erst einmal eine Systemlinie auf S/4HANA migrieren, müssen sie vielleicht noch nicht zwingend ein bestehendes Gateway abschaffen, sondern können das Gateway-System als Einstiegspunkt weiter nutzen. Es sollte dann auf einen Release-Stand passend zu dem S/4HANA-Backend-System gebracht werden.

Spätestens bei der zweiten, dritten oder vierten Systemlinie werden die Administratoren an den Punkt kommen, dass sie von diesem zentralen Gateway-Hub-System weg und zu einem Embedded Gateway übergehen müssen. Das ist der Punkt, an dem in den S/4HANA-Systemen entsprechend die Gateways konfiguriert und aktiviert werden müssen.

Das S/4HANA-System bringt die Funktionalität für die Gateways standardmäßig mit. Allerdings sind diese aber am Anfang deaktiviert. Wenn direkt im Vorfeld klar ist, dass das Unternehmen relativ schnell alle Systeme auf S/4HANA migrieren möchte, kann auch direkt von Anfang an alles mit Embedded Gateway-Systemen realisiert werden. Das Gateway-Hub-System wird dann sukzessive einfach abgelöst.

Ist S/4HANA für die Administratoren aufwändiger als die Business Suite?

Nicht aufwändiger, aber anders. Es müssen mehr Systeme administriert und verwaltet werden, auf denen die Gateways laufen. Auf der anderen Seite gibt es eine klare Verteilung der verschiedenen Gateway-Systeme. Das heißt: Es bestehen weniger Abhängigkeiten zwischen den Systemen, beispielsweise bezüglich der Aktualisierungen. Zunächst sieht es nach Mehraufwand aus, in der Praxis bringt es aber oben genannte Vorteile mit sich, die an anderer Stelle entlasten.

Wie sieht ein Deployment Modell in der Cloud aus?

Eine in Deutschland bisher selten genutzte Möglichkeit innerhalb der Deployment-Modelle ist die „Fiori Cloud Edition“. Hier läuft das „Fiori Launchpad“ nicht im eigenen Gateway-System, sondern in der Cloud Umgebung, also in einem Rechenzentrum der SAP. Hierbei muss die Cloud mit dem Backend-System kommunizieren. Das kann in zwei Versionen ablaufen:

Option 1: OData Provisioning als Service der SAP
Entweder werden Funktionen, die das Gateway bis jetzt innehatte (Zugriffe entgegennehmen und weiterleiten), ebenfalls in die Cloud ausgelagert. Das nennt sich „OData Provisioning“ und ist ein Service, der in der Cloud-Umgebung von SAP gekauft werden kann.

Damit ist kein Gateway-System im eigenen Netzwerk nötig. So können Unternehmen die komplette Administration und Verwaltung dieser Gateway- Systeme einsparen.

Option 2: Bereitstellung des Fiori Launchpads in der Cloud
Eine andere Möglichkeit besteht darin, lediglich das Fiori Launchpad in der Cloud bereitzustellen und die Bereitstellung der Services nach außen weiterhin über ein eigenes Gateway-System ablaufen zu lassen. In dem Fall haben Unternehmen dann erneut die Qual der Wahl: Wird das über ein Embedded Gateway oder ein Gateway-Hub-System realisiert?

Hier greifen dieselben Einschränkungen wie schon gezeigt. Der einzige Unterschied? Der Nutzer greift am Ende nicht auf das Gateway-System zu, um das Fiori Launchpad aufzurufen, sondern auf die Cloud und nur die Bereitstellung der OData Services, etwa die Datenbeschaffung, wird über das eigene Gateway-System realisiert.

Abhängigkeit als Nachteil des Cloud-Modells

Neben den genannten Vorteilen wie das OData Provisioning, besteht ein Nachteil dieses Modells darin, dass Unternehmen sich in gewissem Maße abhängig von SAP machen. Wenn SAP beispielsweise eine neue Version des Launchpad herausbringt, werden alle Rechenzentren und entsprechend auch das unternehmensrelavante Launchpad aktualisiert. Die Administratoren entscheiden nicht mehr selbst, wann das Updates eingespielt wird, sondern SAP, entsprechend seiner Release-Strategie.

Außerdem unterstützt der Standard des OData Provisioning nicht den vollen Funktionsumfang, den ein Gateway-System realisieren kann. Ich sollte mich also im Vorfeld informieren, ob dieser alles abdeckt, was ich für meine Apps benötige oder ob ich mich durch die Entscheidung für die Fiori Cloud Edition eventuell limitiere.

Tobias Schießl.
Tobias Schießl.
(Bild: © TIM BRUENING * PHOTOGRAPHY)

*Über den Autor

Tobias Schießl ist Fachbereichsleiter für den Fachbereich Mission Mobile im IT-Beratungsunternehmen Mindsquare und betreut dort Themen wie App-Entwicklung, SAP Cloud Platform, Schnittstellen und Infrastrukturen. Schon während seines Masterstudiums in Informatik beschäftigte er sich für die IT-Abteilung einer Bank mit Frameworks, die mobiles Bezahlen per NFC oder Bluetooth ermöglichen. Seit über drei Jahren betreut er verschiedene Kundenprojekte zum Thema Fiori, in denen Deployment-Modelle eine große Rolle spielen.

(ID:46312702)