Modify your S/4
Mit Hana und insbesondere S/4 ändert sich auch einiges in der klassischen Abap-Entwicklung. Zu beachten ist im ersten Schritt insbesondere, über welche Betriebsform man spricht. Zu unterscheiden ist hier zwischen der klassischen On-premise- und der Cloud-Lösung.
Beide Betriebsformen können miteinander kombiniert werden. Während in der On-premise-Lösung noch die klassische Abap-Welt für den SAP-Anwender zugänglich ist, gibt es in der Cloud-Umgebung durchaus einige Restriktionen.
So gut wie jeder SAP-Anwender hat diverse Modifikationen in sein SAP-System eingebaut, mit denen er seine Prozesse individualisiert und sich vom Wettbewerb abhebt. Ob all diese Modifikationen wirklich notwendig waren, sei mal dahingestellt. Dennoch sind einige sicher valide, nicht umsonst wäre sonst darin in Form von Zeit und Geld investiert worden.
In der Cloud-Umgebung ändern sich die Voraussetzungen. Klassische Modifikationen und Änderungen am Code sind mit S/4 ausschließlich noch in der On-premise-Lösung möglich. Es ist zu vermuten, dass mit künftigen Releases auch die Form und Weise, wie wir heute modifizieren, restriktiert wird.
In der Cloud-Umgebung sind keinerlei Modifikationen möglich. Dies bedeutet also, dass der heute bestehende Funktionsumfang entweder in den Standard zurückgeführt oder anders realisiert werden muss, bevor ein Anwender seine SAP-Systeme in der Cloud betreiben kann.
SAP unterscheidet hier zwischen einer Key-User-Erweiterung und einer Managed-Erweiterung. Die Key-User-Erweiterung ermöglicht kleinere Anpassungen am Geschäftsprozess in Form von kundenspezifischen Feldern und kleineren Code-Anpassungen.
Diese Erweiterungen sind nicht mit der heutigen Abap-Workbench zu vergleichen, sondern vielmehr mit einem sehr eingeschränkten Werkzeug.
Vergleichen kann man das in etwa mit den CRM- oder Solution-Manager-Oberflächen, in denen über Konfiguration ja auch neue Feldinhalte geschaffen werden können. Die große Freiheit, die der SAP-Anwender kennt, ist dies natürlich nicht.
Für Anpassungen, die damit technisch nicht implementiert werden können, steht die „Managed extensibility“ zur Verfügung. SAP stellt hierfür in der Cloud für Anwender ein in der Cloud gehostetes Entwicklungssystem zur Verfügung.
Auf diesem System können dann Erweiterungen implementiert werden. Auch diese vermeintliche Freiheit ist jedoch restriktiert. Hier muss sichergestellt werden, dass die Implementierung nicht die Cloud-Betriebsform verletzt.
SAP stellt dies dadurch sicher, dass Modifikationen nicht erlaubt sind. Auch Zugriffe auf SAP-Objekte dürfen nicht über ein definiertes Interface erfolgen. Zu vergleichen ist dies mit den heute freigegebenen BAPIs. Eine Kombination einer On-premise-Lösung mit einer Cloud-Lösung, auf der bestimmte Erweiterungen ablaufen, ist denkbar, erfordert aber einiges an Know-how.
So ist es sicherlich denkbar, dass Fiori-Applikationen in der Cloud betrieben werden und damit skalierbar und hochverfügbar sind. Gleichzeitig erfordern diese Applikationen jedoch auch Gateway Services im ERP-Backendsystem.
SAP empfiehlt hierfür die Entwicklung von Gateway Services. Diese Architektur kann natürlich nur in einem hybriden Szenario umgesetzt werden. In der Liste der kundenspezifischen Objekte stehen ja bekanntlich Formulare immer an allererster Stelle.
SAP löst dies in der Cloud mit einem klaren Commitment in Richtung Adobe Lifecycle Designer. Alle Formulare oder E-Mail-Vorlagen werden also auf Basis von Adobe Forms implementiert. Anders als in der klassischen Welt werden keine Druckprogramme zur Datenaufbereitung genutzt, sondern NetWeaver Gateway.
Grundlage von Formularaufbereitungen sind also OData Services, mit deren Hilfe die relevanten Informationen abgerufen und aufbereitet werden. Es zeigt sich also, dass sich einiges mit S/4 grundlegend ändern wird.
Eine Migration eines ERP- oder CRM-Systems von einer Any-Datenbank auf Hana ändert das Programmiermodell noch nicht. Dennoch – um von der Geschwindigkeit zu profitieren – sind die kundenindividuellen Programme zu prüfen und gegebenenfalls anzupassen.
Mit der Umstellung auf S/4 wird sich am Programmiermodell deutlich mehr ändern. OData Services (NetWeaver Gateway), Fiori und SAPUI5 sowie objektorientierte Entwicklungen sind die relevanten Techniken.
Auch das oftmals noch auf SAPScript oder Smartforms basierende Formularwesen ist damit endgültig ein Oldtimer. Für einen Übergang in Richtung Hana sollten IT-Verantwortliche schon frühzeitig damit beginnen, Modifikationen zu analysieren, Standardisierung herbeizuführen und die neuen Technologien sinnvoll einzusetzen.
