Moderne SAP Side-by-Side Extensions mit Hilfe der 12-Faktoren-Applikationen Regeln

Mit SAP S/4 Hana bleibt SAP sich treu und bietet weiterhin eine komplexe Softwarelösung zur Abbildung von Geschäftsprozessen an. Der Standard bietet umfangreiche Funktionalitäten an, die jedoch unmöglich alle individuellen Besonderheiten eines Unternehmens „out-of-the-box“ abbilden können. Erweiterungen, also die Vergrößerung der Funktionalität über den SAP-Standard hinaus, sind nichts Neues und gehören zum gelebten Tagesgeschäft vieler SAP-Kunden.

Wir, als Quanto Solutions, unterstützen Sie schon jahrelang beim Entwurf, der Implementierung, den Tests und der Wartung solcher Erweiterungen. Bislang handelte es sich in der Regel hierbei um Z-Programme.
Aktuelle Software wandert weg vom heimischen Server, hin zur Cloud. Das verändert die Art und Weise, wie solche Extensions entworfen und entwickelt werden. Für S4/Hana werden generell zwei gängige Wege zur Erweiterung angeboten. Diese sind In-App und Side-by Side Extensibility.

Folgende Grafik stellt einen Vergleich zwischen dem klassischen und dem modernen Ansatz dar:

SAP Side by Side Extension

Dieser Blogeintrag widmet sich den SAP Side-by-Side Extensions.
Erweiterungen müssen um aktuelle und künftige Anforderungen an Software gerecht zu werden cloud-nativ sein. Aber was bedeutet cloud-nativ überhaupt?

Die Cloud native computing foundation (CNCF) definiert cloud-nativ wie folgt:

“Cloud native Technologien ermöglichen es Unternehmen, skalierbare Anwendungen in modernen, dynamischen Umgebungen zu implementieren und zu betreiben. “
[QUELLE: https://github.com/cncf/toc/blob/main/DEFINITION.md]

Die vollständige Definition in verschiedene Sprache, darunter auch englisch und deutsch, lässt sich unter https://github.com/cncf/toc/blob/main/DEFINITION.md finden.

Die SAP bezeichnet Microservices, Continuous Delivery und die Verwendung von Containern als

“essential pillars for building cloud-native applications”

Typische Use cases/Anwendungsfälle sind:

1. Proxy Application (hierunter zählen z.B. Registration-Website oder Online-Store)
2. Convenience Application / Benutzerfreundliche Anwendung
3. Substitute Application / Vertreter Anwendung
4. Pre-Processing Application / Vorverarbeitungsanwendungen
5. Post-Porcessing Application / Nachbearbeitungsanwendungen
6. Analytical Application / Analytische Anwendungen

Zur Entwicklung solcher cloud-nativ Anwendungen haben sich Best-Practice Empfehlungen im Laufe der Zeit herauskristallisiert. Die ersten Gedanken zu diesem Thema machten sich die Entwickler rund um Adam Wiggins von Heroku im Jahr 2011. [(https://en.wikipedia.org/wiki/Twelve-Factor_App_methodology)].

Bevor im Detail auf die einzelnen Best-Practice Regeln eingegangen wird, erfolgt hier noch ein kurzer Überblick über das Fundament einer Zwölf-Faktor-Applikation.
Zu den sog. “fundamental guidelines of a twelve-factor application” zählen:

1. Trennnung zwischen Applicationscode und Laufzeitkonfiguration / Separation of application code and runtime configuration
2. Zustandslose und in sich geschlossene Anwendungsprozesse / Stateless and self-contained application processe
3. Nachverfolgbarkeit und Reproduzierbarkeit aller Änderungen / Traceability and reproducibility of all changes

Eine Zwölf-Faktor-Applikation besteht aus den 12 folgenden Empfehlungen bzw. „Regeln“:

1. Codebase
   Eine Anwendung besitzt genau eine Codebase und damit auch ein Repository. Dies ist ein grundlegender Unterschied zu verteilten Systemen und wird mit aktuellen Versionierungstools wie Github, Gitlab o.ä. sichergestellt. Features werden anhand eines Feature-Branch entwickelt, in einen Non-Prod-Branch integriert und schließlich in das produktive System hineingeführt. Dieses Prozedere kann vom Entwicklerteam variiert werden.
2. Dependencies
   Dependencies müssen isoliert werden. Häufig werden zur Verwaltung von Abhängigkeiten spezielle Werkzeuge eingesetzt, wie z.b. Maven oder Gradle für Java, CPAn für Perl oder Rubgygems für Ruby. Unter keinen Umständen sollten mehrere Anwendungen sich gemeinsame Abhängigkeiten in einer Zwölf-Faktor-Applikation teilen.
3. Config
   Konfigurationseinstellungen sollen aus dem Code herausgenommen werden und über Umgebungsvariablen (Environment Variables) gesteuert werden. Hierdurch können die unterschiedlichen Stages, Development, Test und Production, eigenständig konfiguriert werden, ohne dabei den Sourcecode anpassen zu müssen.
4. Backing services
   Backing services sind in einer Cloudnativ-Anwendung alle Anwendungen oder Services, die über ein Netzwerk miteinander kommunizieren. Das können z.b. Datenbanken, Filesharing-, E-Mail-Service usw. sein. Diese remote-Services werden gleichwertig zu lokalen Services behandelt. Hierdurch wird die Komplexität des Codes deutlich reduziert. Alle Services sind via URL gebunden. Die Konfiguration dieser Elemente findet in den Umgebungsvariablen statt (siehe Faktor 3).
5. Build, release, run
   Es sollten eindeutige Phasen des Lebenszyklus einer deployten Version geben.
   Innerhalb der Buildphase wird ein ausführbares Bündel, das sogenannte Build, erzeugt. In der Releasephase wird nun das zuvor erzeugte Build anhand der Konfiguration (siehe Faktor 3) kombiniert und deployt. Jede dieser Phasen ist als eigenständig zu betrachten.
   Die folgende Abbildung zeigt das Zusammenspiel der unterschiedlichen Phasen anschaulich:

6. Processes
   Das Vorgehen zur Entwicklung einer Twelve-Factor App stellt den Prozess in das Zentrum.
   Die Prozesse einer Twelve-Factor App sind zustandslos und setzen die Shared-Nothing-Architekturum.
   Aufgrund dieser Zustandslosigkeit gibt es keine Garantie, dass im Memory gespeicherte Daten außerhalb der Laufzeit des Prozesses zur Verfügung stehen. Die Verwendung des RAMs sollte nur eine kurze Lebensdauer haben. Vielmehr sind Datenbanken bzw. Caches als Langzeitspeicher zu verwenden. Dadurch ist es möglich weitere Instanz bei hoher Belastung zu erzeugen
7. Port binding
   Jeder Prozess wird an seinen eigenen Port gebunden. Mögliche Kollisionen können mit Hilfe von Port-Weiterleitung gelöst werden.
8. Concurrency
   Durch horizontales Skalieren der Prozesse wird Concurrency erreicht. Höhere Last führt zu einer Mehrzahl an Instanzen. Geringere Last führt zur einer Reduzierung.
9. Disposability (Veräußerbarkeit)
   Um den in Faktor 8 genannten Punkt realisieren zu können, ist es notwendig, dass Instanzen schnell sowohl gestartet wie auch gestoppt werden können. Dies wird unter dem Begriff Disposability verstanden.
10. Dev/Prod – Parity
    Die Stages Entwicklung, Test und Produktion sollten sich möglichst ähneln. Hierdurch wird Continuous Delivery erleichtert und mögliche Inkompatibilitäten minimiert. Lange zeitliche Abstände zwischen Entwicklung und Produktivsetzung sollen verhindert werden. Hierdurch soll der Unterschied in der Anzahl der Feature möglichst klein gehalten werden.
11. Logs (Protokolle)
    Logs sind essenziell in der Fehlerbehandlung bei der Software-Entwicklung. Dies gilt weiterhin für Twelve- Factor Apps. Allerdings werden nicht mehr wie bislang üblich, die Logs in einer Datei auf der Festplatte gespeichert. Logs sind hier viel mehr ein Event-Datenstrom über die Gesamtheit aller Applikationen. Um dies übersichtlich zu gestalten, können einzelne Logs z.B. als JSON-Message gespeichert werden.
12. Admin processes (Verwaltungsprozesse)
    Klassische Ansätze zur Administration von Verwaltungsprozessen sind in der “cloud” kaum umzusetzen. Ein Batchjob, der zu einer bestimmten Zeit bzw. Nach einer bestimmten Dauer läuft ist leider nicht zielführend. Da cloud-nativ Applikation gut skalieren, das heißt Ressourcen bedarfsgerecht zu- und abschalten, kann im Vorfeld nicht bestimmt werden wie viele Instanzen zu einer bestimmten Zeit aktiv sein werden.
    Stattdessen wird ein REST-Endpunkt angeboten, der je nach Bedarf ausgeführt wird. Hierdurch wird der Batchjob einmal (von außen) gestartet und von einer Instanz umgesetzt.

Fazit

Die Cloud ist mehr als nur ein Buzzword und bietet eine Reihe von Vorteilen gegenüber klassischen Anwendungen. Auch unter S/4 Hana bleibt die Möglichkeit bestehen individuelle Erweiterungen vorzunehmen. Hierzu empfiehlt sich vor allem die Entwicklung eigener SAP Side-by-Side Extensions. Doch damit diese Erweiterungen nahtlos und effizient arbeiten, gilt es einige Regeln zu beachten. Dieser Blogeintrag ist auf die wichtigsten Aspekte moderner Programmierung eingegangen.

Damit sie auch weiterhin langfristig in einer immer digitalisierteren Welt erfolgreich am Markt bestehen, unterstützt die Quanto Solutions Sie gerne bei der Erstellung von State-of-the-Art Software und sorgt für einen reibungslosen Verlauf hin zur Cloud.

Quellen

• SAP Cloud Extensibility [C_S4CDK_2021]
• Kevin Hoffman – Beyond the Twelve-Factor App Exploring the DNA of Highly Scalable, Resilient Cloud Applications
• Adam Wiggins – The Twelve-Factor App
• Create and Deliver Cloud-Native SAP S/4HANA Extensions (https://open.sap.com/courses/s4h13)

Author: Tristan Hofmann, Quanto Solutions, u.a. zertifiziert in SAP S4C80 Advanced Extensibility with SAP Cloud SDK [C_S4CDK_2021]