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

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

Anbieter zum Thema

Lenovo Global Technology Germany GmbH

Paessler AG

Cradlepoint GmbH

mindsquare GmbH

SAP SE

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. Je nach Systemlandschaft und Geschäftsszenarien sind unterschiedliche Deployment-Optionen sinnvoll. Wie so oft muss jedes Unternehmen für sich die Vor- und Nachteile abwägen. Dieser Artikel verschafft einen Überblick und hilft bei der Entscheidungsfindung für ein Deployment-Modell – besonders im Hinblick auf S/4HANA.

Das Framework SAP Gateway als Bestandteil des SAP NetWeavers 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ßen kann so von der eigentlichen Geschäftslogik getrennt werden. 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 Abb. 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 Abb. 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 mein 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 z.B. 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 existiert, 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 dem Namen 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öchte ich erstmal eine Systemlinie auf S/4HANA migrieren, dann muss ich vielleicht noch nicht zwingend mein bestehendes Gateway abschaffen, sondern kann das Gateway-System als Einstiegspunkt weiternutzen. Es sollte dann auf einen Release-Stand passend zu meinem S/4HANA-Backend-System gebracht werden.

Spätestens bei der zweiten, dritten oder vierten Systemlinie werde ich irgendwann an den Punkt kommen, dass ich von diesem zentralen Gateway-Hub-System weg und zu einem Embedded Gateway übergehen muss. Das ist der Punkt, wo ich in den S/4HANA-Systemen entsprechend meine Gateways konfigurieren und aktivieren muss.

Das S/4HANA-System bringt die Funktionalität für die Gateways standardmäßig schon mit, diese sind aber am Anfang zunächst deaktiviert. Nun habe ich mehrere Gateway-Systeme. Wenn direkt im Vorfeld klar ist, dass mein Unternehmen relativ schnell alle Systeme auf S/4HANA migrieren möchte, dann kann natürlich 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 den Administratoren des Gateways 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, d.h. es bestehen weniger Abhängigkeiten zwischen den Systemen z.B. bezüglich Aktualisierungen. Zunächst sieht es nach Mehraufwand aus – in der Praxis bringt es aber oben genannte Vorteile mit sich, die an anderer Stelle wieder entlasten.

Wie sieht mein 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 mehr 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), auch in die Cloud ausgelagert. Das nennt sich OData Provisioning und ist ein Service, der in der Cloud-Umgebung von SAP gekauft werden kann, sodass kein Gateway-System mehr im eigenen Netzwerk benötigt wird. 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 wieder die Qual der Wahl: Wird das über ein Embedded Gateway oder ein Gateway-Hub-System realisiert? Hier greifen dieselben Einschränkungen wie schon diskutiert – 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 (Datenbeschaffung usw.) 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 Launchpads herausbringt, werden alle Rechenzentren und entsprechend auch mein Launchpad aktualisiert. Ich entscheide nicht mehr selbst, wann ich Updates einspiele, sondern SAP entscheidet 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.

Fazit

Leider gibt es kein pauschales SAP-Gateway-Deployment-Modell, das bei der Migration innerhalb vorgegebener Schritte umgesetzt werden kann – jedes Unternehmen hat andere Grundvoraussetzungen und muss seine eigene Lösung entwickeln. Meine Empfehlung: Gehen Sie unter Berücksichtigung der Gesamtstrategie, d.h. wann wird welches System migriert, was ist das passende Deployment-Modell usw., alle möglichen Varianten mit ihren jeweiligen Vor- und Nachteilen durch. Im Detail sollte besprochen werden, was für welches Deployment getan werden muss, welche Hardware dafür benötigt wird und welche Schritte unternommen werden müssen, um von der aktuellen Infrastruktur zur Zielinfrastruktur zu kommen. So können Sie eine Entscheidung für Ihr Projekt treffen.

Tobias Schießl.

Ü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:46294640)