14.4    Wichtige Frameworks im SAP-Standard 

Was macht einen guten und erfahrenen ABAP-Programmierer aus? Darüber kann man viele interessante Diskussionen führen. Eine der wesentlichen Komponenten dürfte die Kenntnis der im ABAP-Server nutzbaren Frameworks sein.

Die im Folgenden vorgestellten Frameworks sind in erster Linie für Sie als Programmierer von Interesse, denn Sie werden sie möglicherweise bald in einem Projekt verwenden. Darüber hinaus hat die Beschäftigung mit ihnen noch einen weiteren Vorteil: Sie können sie als Steinbruch für Ideen betrachten, und Sie werden vielleicht in Zukunft einmal ein ganz anders gelagertes, aber strukturell verwandtes Problem auf ähnliche Weise lösen.

14.4.1    Web Dynpro ABAP und Floorplan Manager 

Web Dynpro ABAP ist in der SAP-Welt eine der wichtigsten Neuerungen der letzten zehn Jahre. Es handelt sich dabei um eine Oberflächentechnologie, also ein Werkzeug zum Erstellen von Benutzerdialogen für SAP-Anwendungen. In Kapitel 11 haben Sie das Erstellen von Selektionsbildern gelernt und auch einige Sätze über die eng verwandte Dynpro-Programmiertechnik gelesen. Ob Selektionsbild oder Dynpro-Programmierung – die dabei verwendete klassische Oberflächentechnologie deckt nicht mehr das gesamte Spektrum der Anforderungen ab, die man an eine moderne Anwendung stellt. Daher wird sie zunehmend von dem moderneren Web Dynpro ABAP verdrängt. Als frischgebackener ABAP-Programmierer sollten Sie es daher ins Auge fassen, auch die Programmierung von Web-Dynpro-basierten Anwendungen zu erlernen.

Das »Web« im Namen verrät es schon: Anwendungen, die mit Web Dynpro programmiert sind, benötigen keine besondere Client-Software auf Seiten des Nutzers, sondern können in einem gewöhnlichen Webbrowser laufen. Das ist ein erheblicher Vorteil, wenn es darum geht, Anwendungen für Nutzer bereitzustellen, die nur gelegentlich mit dem SAP-System arbeiten und beispielsweise für Urlaubsanträge oder Reisekostenabrechnungen nicht Hunderte von Megabytes an Client-Software auf ihrem PC installieren wollen. Diese Argumente gelten auch für andere Technologien, mit denen SAP-Anwendungen browserfähig gemacht werden, allen voran SAP Fiori. Mit dieser HTML5-basierten Technologie werden Webanwendungen mit einem attraktiven, zeitgemäßen Look & Feel für Desktop-Rechner ebenso wie für die Browser von mobilen Geräten geschaffen. Es würde an dieser Stelle zu weit führen, näher auf SAP Fiori einzugehen, da die ABAP-Programmierung nur einen kleinen Teil der Entwicklung mit SAP Fiori ausmacht. Stattdessen verweisen wir zur Vertiefung auf das Buch Einführung in SAPUI5 von Miroslav Antolovic (SAP PRESS 2014).

Web Dynpro weist gegenüber SAP Fiori einige Vor- und Nachteile auf. Die Technologie punktet ebenfalls mit ihrer Browserfähigkeit und damit, dass sie sich gut für systemübergreifende Anwendungen eignet:

• Erstens fügt sich Web Dynpro gut in das SAP Enterprise Portal ein und erlaubt beispielsweise den Datenaustausch mit anderen Portalanwendungen, auch wenn diese auf einem anderen SAP-System liegen.

• Zweitens besitzt es mit Web Dynpro Java ein Gegenstück auf der SAP-Java-Seite. Damit ist es möglich, Anwendungen herzustellen, deren Dialoge teils im ABAP-System und teils im Java-System liegen und die dennoch ein einheitliches Look & Feel sowie eine gute, durchgängige Benutzerführung besitzen. Die Java-Variante von Web Dynpro wird allerdings nicht mehr von SAP weiterentwickelt. Daher sollten Sie vor ihrem Einsatz sorgfältig prüfen, ob die Zukunftsperspektive von Web Dynpro Java zu Ihren Entwicklungsvorhaben passt.

• Drittens kann auch SAP Business Process Management (BPM), eine Java-basierte Workflow-Umgebung für systemübergreifende Anwendungen, Web Dynpro ABAP einbinden. Dies erleichtert die Verwendung Ihrer Anwendung in system- und fachbereichsübergreifenden Szenarien und erhöht damit letztlich ihren Wert. Schließlich ist eine Software umso wertvoller, je häufiger sie zum Einsatz kommt, um einen Prozess zu unterstützen.

Insgesamt ist das wichtigste Unterscheidungsmerkmal von Web Dynpro gegenüber SAP Fiori aus Programmierersicht, dass die Programmierung und Ausführung von Web-Dynpro-Oberflächen sehr backend-nah sind. Die Programmierung erfolgt in ABAP statt in JavaScript, und die gesamte Frontend-Programmlogik wie Eingabeprüfungen, Navigation und Bildaufbau laufen im SAP-System ab und nicht im Webbrowser.

Wenn Sie Ihre ABAP-Anwendungen mit Web Dynpro ABAP entwickeln, eröffnet sich Ihnen eine Welt von potenziellen Nutzern und Integrationen mit anderen Anwendungen, die auch außerhalb Ihres Systems liegen und sogar auf anderen Technologien basieren können. Dabei ist Web Dynpro ABAP an das typische SAP-Design angepasst und arbeitet auch mit klassischen Dynpro-Oberflächen zusammen. Natürlich ist auch hier nicht alles Gold, was glänzt, und auch Web Dynpro lässt noch den einen oder anderen Wunsch offen. Aber in den meisten Unternehmen, bei denen SAP im Einsatz ist, führt an Web Dynpro ABAP kein Weg mehr vorbei.

Wenn wir über Web Dynpro ABAP sprechen, dürfen wir den Floorplan Manager (FPM) für Web Dynpro ABAP nicht auslassen. Dabei handelt es sich um ein zusätzliches Framework, das Ihnen dabei hilft, standardkonforme Web-Dynpro-Dialoge zu erstellen. Das FPM-Framework unterstützt Sie bei der Erstellung der unterschiedlichen Teilbilder, aus denen der Gesamtdialog zusammengesetzt wird, und bildet dann den Rahmen, der zur Laufzeit alles zu einem funktionierenden Ganzen zusammenfügt – und zwar so, als ob er direkt von SAP programmiert worden wäre.

Eine praktische Referenz für die Web-Dynpro-Programmierung bietet das Buch Web Dynpro ABAP – Das umfassende Handbuch von Roland Schwaiger und Dominik Ofenloch (2. Auflage, SAP PRESS, 2014). Zur Arbeit mit dem Floorplan Manager empfehlen wir das Buch Floorplan Manager für Web Dynpro ABAP von Thomas Frambach und Simon Hoeg (2. Auflage, SAP PRESS, 2014).

14.4.2    SOAP-Webservices 

Webservices erlauben die Kommunikation zwischen Anwendungen über Systemgrenzen hinweg. Mit einem Webservice kann eine Anwendung auf einem System eine Funktion einer Anwendung auf einem anderen System aufrufen. Für solche Remote-Aufrufe stehen seit jeher verschiedenste Technologien und Kommunikationsprotokolle zur Verfügung. Viele Plattformen bieten hierfür proprietäre Protokolle an, die für die jeweilige Plattform optimiert sind – so kommunizieren SAP-Systeme am liebsten mittels des SAP-proprietären Remote Function Call (RFC) untereinander, und SAP stellt auch für Nicht-SAP-Systeme Bibliotheken bereit, die diese in die Lage versetzen, über RFC mit SAP-Systemen zu kommunizieren.

Am Ende bergen solche proprietären Ansätze aber viele Probleme, wenn in einer heterogenen Systemlandschaft mit mehreren unterschiedlichen Plattformen jedes System die Sprache aller anderen Systeme sprechen soll. Zieht eine Funktion von einem System in ein anderes (auf einer anderen Plattform realisiertes) um, müssen alle Nutzer der Funktion auf ein neues Kommunikationsprotokoll umschwenken. Das ist so, als ob sich für den menschlichen Nutzer einer Dienstleistung nicht nur die Telefonnummer des Ansprechpartners ändert, sondern der neue Ansprechpartner plötzlich nur Chinesisch spricht. Dies kann die Bewegungsfreiheit in einer Softwarearchitektur erheblich einschränken.

Als Antwort auf diese Problematik wurden Webservices ersonnen. Dies ist ein Standard (genauer gesagt, ein Bündel von Standards), mit dem der Versuch unternommen wird, eine Art Lingua franca, also eine von jedermann (in diesem Fall: von jedem IT-System) beherrschte Sprache zu schaffen. Dieser Ansatz erlaubt es, dass Oracle-Systeme mit ABAP-Systemen genauso mühelos kommunizieren wie mit Microsoft-Servern oder Java-Enterprise-Servern. Der Nutzer einer als Webservice bereitgestellten Funktionalität merkt gar nicht und muss sich gar nicht darum kümmern, auf welcher Plattform der genutzte Dienst läuft. Die Plattform könnte jederzeit umgestellt werden, ohne dass dies den Benutzer interessieren muss. Zieht der Dienst um – auch auf eine andere Plattform –, ändert sich aus Sicht des Nutzers höchstens die Adresse, sonst nichts. Das ist so, als ob sich für einen menschlichen Nutzer einer Dienstleistung die Telefonnummer des Ansprechpartners ändern würde, aber eben nicht die Sprache. Kein Problem also, wenn in die Softwarearchitektur mehr Beweglichkeit einzieht!

Wie schafft es der Webservice-Standard, dass er so universell verfügbar ist und auf praktisch allen Softwareplattformen sowohl zum Bereitstellen als auch zum Nutzen von Diensten verwendet werden kann? Die Antwort liegt in der Auswahl der verwendeten Werkzeuge und Standards:

• Webservices basieren in der Regel auf dem Austausch von Daten über HTTP (Hypertext Transfer Protocol). Das ist das Kommunikationsprotokoll des World Wide Web, das von jedem Webbrowser und jedem Webserver beherrscht wird.

• Die dabei übertragenen Daten – Servicebeschreibung, Aufruf und Antwort – sind im XML-Format codiert, das heutzutage ebenfalls zur Grundausstattung von IT-Systemen gehört.

• Die Beschreibung der Datentypen innerhalb der ausgetauschten XML-Dokumente erfolgt mittels XML Schema, einem weitverbreiteten Standard, der nahezu überall dort zu Hause ist, wo es XML gibt.

Die Standards und Spezifikationen rund um Webservices bauen auf diesen weitverbreiteten Standards auf und waren bzw. sind für die verschiedenen Plattformanbieter daher leichter umzusetzen als Standards, die in jedem Punkt (Kommunikation, Datenformat, Schnittstellenbeschreibung) das Rad neu erfinden.

Wenn Sie dieses Thema vertiefen möchten, vermittelt Ihnen das Buch Entwicklung von Enterprise Services für SAP von Markus Peter und Thomas Pohl (SAP PRESS, 2009) einen umfassenden und detaillierten Blick auf das Erstellen und Nutzen von Webservices – einschließlich des besonderen, SAP-spezifischen »Webservice-Dialekts«, der Enterprise Services.

14.4.3    OData-Services mit SAP Gateway 

Für einige Anwendungen sind die im vorangehenden Abschnitt beschriebenen SOAP-Webservices zu kompliziert und zu sperrig. Besonders bei der Programmierung von Webanwendungen kommt es darauf an, dass der im Webbrowser laufende Teil der Anwendung leichtgewichtig und klein ist und die Systemressourcen schont – zumal diese Anwendungen oftmals auf mobilen Endgeräten wie Smartphones und Tablets laufen, auf denen der Speicher und die Prozessorkapazität deutlich knapper sind als auf einem herkömmlichen Desktop-Rechner.

Mit SAP Gateway wurde ein Framework geschaffen, das es dem ABAP-System erlaubt, solche leichtgewichtigen Services bereitzustellen, die optimal auf die Nutzung durch Webanwendungen und mobile Anwendungen zugeschnitten sind. Dabei hat SAP den von der Firma Microsoft entwickelten offenen OData-Standard zugrunde gelegt, der besonders das Arbeiten mit Geschäftsentitäten erleichtert.

Die OData-Spezifikation baut genau wie die SOAP-Webservices auf dem HTTP-Protokoll auf, das auch die Grundlage des World Wide Web ist. Die Spezifikation wurde in dem Streben geschaffen, den Overhead-Anteil zwischen dem zugrunde liegenden HTTP-Protokoll und den Anwendungsdaten, um die es eigentlich geht, so gering wie möglich zu halten und das gesamte Protokoll möglichst einfach und für Menschen nachvollziehbar zu gestalten.

Wenn Sie beabsichtigen, Webanwendungen und mobile Anwendungen zu entwickeln, wird für Sie kein Weg an SAP Gateway vorbeiführen. Zur Vertiefung empfehlen wir Ihnen das Buch OData und SAP Gateway von Carsten Bönnen, Volker Drees, André Fischer, Ludwig Heinz und Karsten Strothmann (SAP PRESS, 2014).

14.4.4    Frameworks für Erweiterungen 

Individualsoftware muss niemand nachträglich an die besonderen Bedürfnisse eines Kunden anpassen – sie ist bereits maßgeschneidert und (nach Möglichkeit) perfekt nach dessen Anforderungen zugeschnitten. Bei den meisten SAP-Anwendungen liegen die Dinge jedoch anders: Es handelt sich um Standardsoftware, also Software von der Stange, die einmal für alle Kunden entwickelt und diesen dann bereitgestellt wird.

So, wie Sie eine Hose von der Stange und die Ärmel eines neuen Jacketts häufig noch kürzen lassen müssen, damit die neue Kleidung wirklich komfortabel passt, müssen auch SAP-Anwendungen an die besonderen Anforderungen jedes Kunden angepasst werden, bevor sie zum Einsatz kommen können. Im Lauf der Jahre sind im SAP-Umfeld verschiedene Werkzeuge und Techniken entstanden, mit denen solche Anpassungen bewerkstelligt werden können.

Customizing

Die am weitesten verbreitete Technik ist das Customizing, bei dem die Anpassung durch das Erstellen kundenspezifischer Tabelleneinträge erfolgt. Diese Tabelleneinträge können kundenspezifische Schlüsselverzeichnisse und Stammdaten wie Buchungskreise, Kostenstellen, Niederlassungen und Regionen sein, aber auch Steuereinträge umfassen, die festlegen, wie sich das System in einer bestimmten Situation verhalten soll. Beispielweise kann über einen Tabelleneintrag festgelegt werden, ob eine vom System als fehlerhaft erkannte elektronische Rechnung eines Lieferanten automatisch mit einer Fehlermeldung zurückgesandt oder zur Prüfung und Bearbeitung zunächst einem menschlichen Sachbearbeiter vorgelegt werden soll.

Modifikation

Nicht jede Anpassung kann mithilfe von Tabelleneinträgen umgesetzt werden. Wenn Programmcoding angepasst werden muss, besteht die Möglichkeit der Modifikation: Man ändert einfach den Quellcode des SAP-Standards. Dies ist die Anpassungstechnik mit den meisten Nachteilen, da der SAP-Standardcode natürlich jederzeit von SAP geändert und neu ausgeliefert werden kann – und was wird dann aus Ihrer Codeänderung? Sie wird entweder überschrieben, oder Sie mischen sie aufwendig ab, führen also die von SAP durchgeführten Änderungen mit Ihren eigenen Änderungen zusammen. In den SAP-Systemen vieler Kunden gibt es so viele Modifikationen, dass SAP-Upgrades wegen des zu erwartenden Aufwands für das Abmischen unmöglich werden. Diese Kunden leben zum Teil mit zehn Jahre alten SAP-Releases und zahlen enorme Beträge dafür, dass SAP diese Systeme weiter wartet, obwohl die verwendeten Releasestände normalerweise nicht mehr unterstützt werden.

Business Add-Ins

Ein schonenderes Verfahren, das SAP-System mittels Programmierung an die Kundenbedürfnisse anzupassen, besteht in der Verwendung von Business-Add-Ins (BAdIs), die die früher verwendeten User Exits oder Customer Exits ersetzen. BAdIs sind spezielle, von SAP vorgesehene Erweiterungspunkte, bei denen Sie die Möglichkeit haben, an einem bestimmten Punkt in der Verarbeitungslogik Programmlogik einzufügen, die den Ablauf in begrenzter Weise beeinflussen kann. Ein BAdI kann der SAP-Standard z. B. bereitstellen, um Ihnen nach einer Eingabeprüfung durch das System die Möglichkeit zu geben, mit speziellen, kundeneigenen Prüfungen das Ergebnis zu beeinflussen; oder um Ihnen nach Durchlaufen einer Berechnungsfunktion die Chance zu geben, die Berechnungsergebnisse zu übersteuern, falls die Standardmechanik der Berechnungen für Ihre Zwecke nicht ausreicht. Der große Vorteil gegenüber Modifikationen besteht darin, dass SAP für BAdIs Releasestabilität garantiert. Sie steht also dafür ein, dass ein einmal realisiertes BAdI auch mit zukünftigen SAP-Releases funktionieren wird. Außerdem werden Ihre BAdI-Implementierungen selbstverständlich nicht durch SAP-Auslieferungen überschrieben.

Switch und Enhancement Framework

Das modernste Werkzeug zur Anpassung des SAP-Systems ist das Switch und Enhancement Framework. Eigentlich handelt es sich um einen ganzen Werkzeugkasten, dessen Komponenten auch getrennt voneinander eingesetzt werden können – das Switch Framework ebenso wie das Enhancement Framework, und die Elemente des Enhancements Framework (z. B. BAdIs) ohne den Rahmen des Frameworks.

Bei diesem Framework geht es darum, eine Reihe von unterschiedlichen Möglichkeiten für Erweiterungen zu schaffen. Stellen Sie sich einen Softwarehersteller A vor, der eine Anwendung entwickelt. Ein Entwickler B ergänzt diese Software, indem er dazu Erweiterungen programmiert und ausliefert. Mit Unterstützung des Switch und Enhancement Frameworks können die von Entwickler B vorgenommenen Erweiterungen den Code von Hersteller A entweder ergänzen, indem sie an bestimmten Stellen eingeschoben werden, oder auch in Teilen überdecken, sodass der Code von Entwickler B anstelle des Codes von Hersteller A ausgeführt wird.

Solche Erweiterungen können entweder an vorgedachten, vom Ersteller der erweiterten Software A vorgesehenen Stellen erfolgen oder auch wild an (fast) beliebiger Stelle eingebaut werden. Im ersten Fall ist der Hersteller A in der Lage, sich auf eine langfristige Schnittstellenstabilität festzulegen und das störungsfreie Funktionieren des vorgedachten Erweiterungspunktes auch in Folgereleases zu garantieren. Im zweiten Fall (die Erweiterung erfolgt nicht an einer vorgedachten Stelle, sondern wird frei platziert) ist es selten möglich, hundertprozentige Releasestabilität zu erreichen. Die Erweiterung kann zwar nicht wie eine Modifikation durch Neuauslieferungen des erweiterten Codes von Hersteller A überschrieben werden, muss jedoch genau wie eine Modifikation nach jeder Neuauslieferung geprüft und gegebenenfalls angepasst werden.

Das Switch und Enhancement Framework erlaubt es auch, solche Erweiterungen schaltbar zu machen, also gemeinsam mit einem Schalter auszuliefern, über den ein Systemadministrator sie ein- und ausschalten kann. Damit ist es dem Kunden möglich, entweder nur den Originalcode von Hersteller A auszuführen, oder ihn gemeinsam mit den Erweiterungen von Entwickler B zu nutzen. Dieser Teil, der sich mit der Schaltbarkeit befasst, heißt Switch Framework.

Wenn Sie sich mit diesem Thema näher befassen möchten, bietet das Buch SAP Enhancement Packages – Funktionsweise und Implementierung von Martina Kaplan und Christian Oehler (SAP PRESS, 2011) einen praxisorientierten Einstieg.