Mobile und Cloud Computing öffnen den Weg zu Open Source

Oft wird ein Geschäftsprozess im Unternehmen über mehrere Stationen oder Abteilungen geleitet, bis der Prozess abgeschlossen ist. Die involvierten Mitarbeiter haben dabei unterschiedliche Profile – vom SAP-Experten bis hin zum Gelegenheits-Benutzer.

Um das Einbinden der Gelegenheits-Benutzer in die Geschäftsprozesse möglichst einfach zu gestalten, empfiehlt es sich, die vorhandenen User-Interface-Technologien (UI) zu nutzen. Dies reduziert die Einarbeitungszeit und erhöht die Akzeptanz der Benutzer.

Oft findet man Technologien wie Microsoft SharePoint vor. Wenn nun die in SAP hinterlegten Informationen direkt und ohne Redundanzen in SharePoint angezeigt und bearbeitet werden können, so wird die Einstiegsschwelle zur Dateneingabe in das SAP-System dramatisch reduziert.

Qualität und Aktualität der Daten steigen. Immer öfter verwenden Mitarbeiter aber auch mobile Lösungen wie Tablets oder Smartphones. Wie können diese neuen Benutzergruppen möglichst einfach und sicher auf die im SAP-System vorhandenen Daten zugreifen?

Auch beim Umgang mit Social-Media-Plattformen stellt sich die Frage, wie durch eine engere Verknüpfung der Plattformen mit den unternehmenskritischen Daten im SAP-System innovative neue Lösungen erstellt werden können.

Die in SAP ERP integrierte Variantenkonfiguration bietet eine mächtige Lösung, um abhängig von der Auswahl der Konfiguration im Kundenauftrag sowohl Produktionsprozesse als auch Prozesse im Backoffice zu starten.

Um die Eingabe der Konfiguration noch weiter zu vereinfachen, wurde in diese Studie die Eingabemöglichkeit durch ein inte­griertes 3-D-Modell ermöglicht, das die ausgewählten Attribute sogleich visualisiert.

Eingaben können so unmittelbar visuell überprüft und korrigiert werden, wobei sich gleichzeitig die Akzeptanz durch die Endanwender erhöht. Ein weiteres Beispiel zeigt die Lösung SAP Citizen Connect.

Basierend auf Funktionen des SAP-Systems wurde hier eine mobile Lösung erstellt, die es den Einwohnern einer Stadt oder Gemeinde erlaubt, Probleme oder Missstände direkt vom mobilen Gerät aus in das SAP-System zu senden. Dadurch erübrigen sich früher notwendige Zwischenschritte wie der Anruf in einer Telefonzentrale mit ungenauen Ortsangaben.

Durch diese zusätzlichen Informationen ist nun eine zeitnahe Entscheidung basierend auf richtigen Fakten möglich. Und das direkte Feedback zurück zum Meldenden erhöht die Motivation, auch in Zukunft Missstände zu melden, die sonst unentdeckt bleiben würden.

Lösungsansätze für Non-ABAP

Da das SAP-System offen ist, ließen sich die oben genannten Szenarien bereits seit langer Zeit technisch realisieren. Nachteilig war jedoch, dass jeweils Punkt-zu-Punkt-Lösungen verwendet wurden.

Außerdem benötigte der Entwickler der Non-SAP-Lösung ein profundes Detailwissen über das SAP-System. Entwickler, die sowohl in SAP- als auch in Non-SAP-Entwicklungssprachen einen guten Kenntnisstand haben, sind leider nicht immer vorhanden.

In der Folge verlängern oder verteuern sich Projekte und Wartung kann nur schwierig gewährt werden, da sich gerade das Frontend dynamisch weiterentwickelt. SAP-Bestandskunden und -Partner kennen sich meist sehr gut mit der Programmiersprache ABAP aus.

Allerdings sind ABAP-Kenntnisse in anderen Entwickler-Communities wenig verbreitet, wo vor allem C, Java, Objective-C, PHP oder C# vorherrscht. Daher finden sich heute auch in Unternehmen typischerweise zwei parallele organisatorische Strukturen: eine Abteilung zur Betreuung der SAP-Systeme und eine weitere, die sich um Non-SAP-Themen kümmert.

Ziel für NetWeaver Gateway war auch, die Kommunikationsbarrieren zwischen den beiden Teams zu verringern. Auf der Suche nach einem Instrument, das sowohl von SAP- als auch von Non-SAP-Experten verstanden werden kann, wurde das REST-basierte Protokoll OData gewählt. Dieses Protokoll wird gerade in einen Oasis-Standard überführt, um eine weitere Verbreitung zu beschleunigen.

SAP NW Gateway

Über NetWeaver Gateway wird ein Werkzeug zur Verfügung gestellt, das die Entwicklung von benötigten REST-Services in ABAP-basierten SAP-Systemen beschleunigt und standardisiert.

Viele Tätigkeiten, die nicht direkt mit der Entwicklung des Services zu tun haben, werden dem Entwickler abgenommen wie die Unterstützung von Dialekten (XML oder JSON), das Aufbereiten der Nachrichten, das Analysieren der Nachrichten und zentrales Monitoring. Ein typischer Ablauf bei der Entwicklung einer neuen Benutzeroberfläche kann (vereinfacht dargestellt) wie folgt aussehen:

• In einem gemeinsamen Workshop zwischen den Anwendern – meist repräsentiert durch einen Key-User, den User-Interface-Experten und den Experten für das SAP-Backend – wird die gewünschte neue Benutzeroberfläche definiert und skizziert.
• Basierend auf den Ergebnissen des Workshops werden dann Anforderungen an das SAP-Backend und Front­end abgeleitet. Diese Anforderungen können in einem Entity-Relationship- Modell dokumentiert werden. Dieses Dokument bildet den Startpunkt für die nächsten Schritte. Es kann sowohl in ein SAP-System als auch in die Entwicklungswerkzeuge für Frontend-Entwicklung importiert werden.
• Sowohl im Backend als auch im Frontend werden nun die notwendigen Entwicklungen vorgenommen.

OData kommt

Das OData-Protokoll basiert auf offenen Standards wie HTTP, XML, JSON oder AtomPub. Die bereits bekannten und durch HTTP-definierten Operatoren wie Get, Post, Put, Patch oder Delete haben stets dieselbe Bedeutung.

Die REST-basierte Architektur erlaubt es auch Entwicklern, die keine speziellen SAP-Kenntnisse haben, ohne großen Schulungsaufwand mit Standard-Werkzeugen mit der Entwicklung zu beginnen.

Definition eines OData-Modells: Ein Entity-Relationship-Modell dient als Basis zur Definition des Services. Jeder definierte Service liefert dabei ein Metadaten-Dokument. Dieses jeweils gleich aufgebaute Metadaten-Dokument abstrahiert und gleicht die Daten von Backend-Systemen an.

Ist das Modell einer geplanten Bedienoberfläche beispielsweise aus den Objekten Produkt, Hersteller und Produktkategorie aufgebaut, so wird das gewünschte Modell dann in einem XML-Dokument (EDM) modelliert. Um das Modell in OData zu überführen, ist Wissen zu den zugrunde liegenden Konzepten von OData notwendig:

• Entity Set: Im obigen Beispiel wäre „Product“ ein Entity Set. Es ist vergleichbar mit Listen oder Tabelleneinträgen. Alle Einträge (oder Entities) eines Entity Sets haben denselben Entity Type.
• Entities: sind Instanzen des Entity Types. Sie können strukturiert sein und besitzen ein Schlüssel-Element (Entity Key). Die Struktur eines Entities wird durch Properties definiert. Ein Entity kann einzeln über den Schlüssel angesprochen werden. Über eine Suche können mehrere Einträge zurückgegeben werden.
• Entity Key: besteht aus Properties. Dieser Schlüssel ist wichtig, um einzelne Einträge eindeutig identifizieren zu können. Außerdem wird er benötigt, um Assoziationen zwischen Entity Types zu definieren.
• Association: Dies ist die benannte Verbindung zwischen zwei Entity Types. Jede Association besteht aus zwei Endpunkten, die die Entity Types und die Kardinalität (1:N, 1:1) festlegen.
• Navigation Property: Es dient zur Navigation zwischen Entities und ist mit der Association und dem Entity Type verknüpft.
• EntityContainer: Hier werden alle Entity Sets, die zu einem Service gehören, zusammengefasst.

Mit dem oben skizzierten Beispiel lässt sich diese Methodologie besser veranschaulichen: Die Properties des Suppliers sind: ID (Entity Key), Name, Address, Concurrency und Prodcuts (Navigation Property).

Der EntityContainer mit dem Namen DemoService besteht aus den folgenden EntitySets und Associations zwischen den verschiedenen Objekten (die hier aber nicht aufgeführt sind): Products, Categories und Supplier. Basierend auf diesen Prinzipien wird ein Modell definiert.

Operationen basierend auf dem Modell: Ist dieses Modell definiert, so können zur Laufzeit Operationen auf dem Modell stattfinden. Diese Operationen können zum Beispiel Suche, Update, Löschen sein.

Eine Auflistung aller Produkte lässt sich mit der URL http://services.odata.org/OData/OData.svc/Products/ anzeigen. Diese Auflistung kann durch Hinzufügen eines Such-Parameters wie $top noch eingeschränkt werden.

Die Adresse http://services.odata.org/OData/OData.svc/Products/?$top=3 zeigt jetzt nur noch die drei ersten Produkte an. Die Antwort besteht dabei aus einem XML- oder JSON-Dokument mit dem Namen der Properties und ihren Werten.

Zusätzlich werden die Navigations-Properties in der Antwort mit
ausgegeben. Die verknüpften Objekte (Category und Supplier) sind jetzt direkt durch eigene URLs aufrufbar.

Ein einfaches Navigieren anhand der zurückgelieferten URLs ist jetzt auch für Entwickler möglich, die keine detaillierten Kenntnisse des verwendeten Backend-Systems besitzen. Details zur Kategorie und zum Lieferanten sind jetzt direkt erreichbar.

Abfrageoperationen: Viele Benutzeroberflächen basieren auf ähnlichen, einfachen Mustern. Sehr oft beginnen diese Muster mit der Eingabe einer Suche. OData hat verschiedene Möglichkeiten, eine Suche zu formulieren. Allen Operatoren wird dabei ein $ vorangestellt.

Eine Abfrage aller Produkte mit einem Preis unterhalb von 20 wird dann wie folgt formuliert: http://services.odata.org/OData/OData.svc/Products/?$filter=Price le 20.

Werden jetzt aus diesem Ergebnis nur die Werte Preis und Name benötigt, so kann man mittels $select die Spalten der Antwort festlegen: http://services.odata.org/OData/OData.svc/Products?$select=Price,Name.

Auch lassen sich die Antworten sortieren durch $orderby. Natürlich ist dieses Kommando nur bei Ausgabe einer Liste sinnvoll. In diesem Beispiel werden die Produkte der Reihenfolge nach sortiert:

Mittels $top und $skip lassen sich bestimmte Bereiche eines größeren Ergebnisses in einzelnen Paketen reduzieren, die dann bei Bedarf mit geringem Verbrauch an Ressourcen übertragen werden.

http://services.odata.org/OData/OData.svc/Products?$skip=2&$top=2&$orderby=Rating überträgt die dritte und vierte Reihe der Produkte, sortiert nach Bewertung.

Von der Definition zur Implementierung

Nachdem das gewünschte Verhalten definiert ist, kann im SAP-System mit der Implementierung des benötigten Services begonnen werden. Um den Entwickler des benötigten Services bestmöglich zu unterstützen, bietet NetWeaver Gateway für die verschiedenen Anwendungsfälle Unterstützung an.

Dabei wird im Detail zwischen der Definition und der Implementierung eines Services unterschieden. Die nachfolgenden Schritte finden alle im Service Builder statt. Dieser ist die zentrale Oberfläche innerhalb von NetWeaver Gateway zur Service-Definition und Service-Implementierung.

Zur Definition eines Services wird das Datenmodell entsprechend der zuvor beschriebenen OData-Syntax definiert. Dabei kann das Datenmodell deklarativ durch manuelle Eingabe festgelegt werden.

Der Service Builder unterstützt hier die Definition durch eine an das OData-Datenmodell angelehnte Ordnerstruktur, in der die Kategorien wie Relations oder Entities tabellarisch eingegeben werden können. Das Datenmodell kann alternativ auch durch den Import eines außerhalb des SAP-Systems befindlichen Datenmodells festgelegt werden.

Zudem kann das Datenmodell basierend auf Strukturen und Informationen des zugrunde liegenden SAP-Systems (DDIC/RFC- oder BOR-Schnittstellen) und durch Referenzieren auf Objektmodelle im SAP-System festgelegt werden. Viele Objekte werden intern objekt-orientiert entwickelt.

Es ist daher relativ einfach, diese internen Objekte in OData Services zu überführen. Beispiele hier sind PLM, EAM oder CRM. Aber auch Queries aus Business Warehouse oder Views aus Hana können hierüber einfach in einen OData Service umgewandelt werden.

Zusätzlich wird hier die Implementierung gleich automatisch mit erzeugt. Falls bereits ein Service existiert, der über NetWeaver Gateway entwickelt wurde, kann ein neuer Service basierend auf dem alten Service entwickelt werden.

Dies kann dann sinnvoll sein, wenn zum Beispiel eine Erweiterung oder Änderung notwendig ist, der ursprüngliche Service jedoch nicht verändert werden kann.

Gerade bei Szenarien, die auf BW basieren, können über Generatoren des Service Builders die enthaltenen Queries in OData Services umgewandelt werden. Da nicht alle Queries für die Verwendung als OData Service geeignet sind, müssen die Queries vor der Verwendung im Service Builder im BW Query Designer mit einem Easy-Query-Kennzeichen markiert werden.

Ist die Query nicht umwandelbar, dann kann dieses Kennzeichen nicht gesetzt werden. Eine weitere Möglichkeit zur Integration von Informationen aus dem SAP BW ist das MDX-Format. Auch dieses Format kann über den Generator in einen OData Service umgewandelt werden.

Die Implementierung der definierten Services im SAP-System kann jetzt über zwei Arten erfolgen: durch ein Mapping des OData-Modells auf im SAP-System vorhandene Funktionsbausteine wie RFC, BAPI, BOR.

Dabei kann pro Methode (Löschen, Lesen, Hinzufügen) ein eigener Funktionsbaustein zum Mapping verwendet werden. Das Mapping erfolgt im Service Builder bedienerfreundlich durch Drag&Drop. Oder durch manuelle Implementierung über die SAP-Standard-Werkzeuge in ABAP.

Dabei bietet das Backend Plug-in eine Super-Klasse, die dann entsprechend reimplementiert werden muss. Jede Methode (Lesen, Löschen, Suche) wird eigens entwickelt. In dieser Methode steht dann die eigentliche Logik, also das Coding, das die entsprechenden Funktionsbausteine und Tabellen ausliest oder aktualisiert.

Wurde bei der Definition des Modells eine Assoziation zwischen Entities vorgegeben – wie etwa vom Produkt zur Kategorie –, dann muss diese Assoziation im Service Builder auch implementiert werden.

Sämtliche Implementierungen und generiertes Coding wird im sogenannten Kundennamensraum erzeugt. Das hat zum einen den Vorteil, dass manuelle Anpassungen immer möglich sind. Dies wird auch durch ein Konzept von Erweiterungspunkten unterstützt.

Zum anderen werden die gängigen Instrumente im ABAP-Umfeld zur Source-Code-Verwaltung und zum Transport verwendet. Als Resultat der Definition und Implementierung ist jetzt ein funktionsfähiger OData Service erstellt.

Nach der Erstellung des Services ist in einem nächsten Schritt die Aktivierung erforderlich. Hintergrund dieses Schrittes ist, dass sich theoretisch die Service-Implementierung auf einem getrennten SAP-System vom zentralen NetWeaver Gateway Server befinden kann.

Durch die Registrierung wird der Service im zentralen System bekannt gemacht und in einen zentralen Servicekatalog für OData Services aufgenommen. Innerhalb der Benutzeroberfläche zur Registrierung und Aktivierung befinden sich auch Tools, die beim Fehlerbeheben und Testen hilfreich sind.

Somit befinden sich im Service Builder alle Funktionen an einem Ort, die zur Definition und Implementierung benötigt werden, wobei in der Benutzeroberfläche zur Registrierung und Aktivierung alle Tools zur Verwaltung eines bereits existierenden Services zu finden sind.

Benutzeroberflächen

Visual Studio LightSwitch: Nachdem der entsprechende Service im SAP-System jetzt implementiert oder generiert wurde, kann der Service direkt in verschiedenen Oberflächen verwendet werden, je nach Anforderung.

Durch die Verwendung eines offenen Standards gibt es viele Möglichkeiten und Anbieter, die das OData-Format unterstützen. Erwähnenswert ist hier das Visual Studio LightSwitch von Microsoft, da es eine offene Lösung zur Erstellung von komplexeren Anwendungen basierend auf Templates bereitstellt, die nach der Generierung leicht erweitert und angepasst werden kann.

Diese Tem­plates können im Erstellungs-Assistenten unter anderem auch mit OData Services verbunden werden. Und seit Microsoft Excel Version 2010 gibt es die Möglichkeit, auch in Excel einen existierenden OData Service einzulesen und die Inhalte in der Tabellenansicht anzuzeigen.

Bei der Umwandlung müssen natürlich einige Anpassungen vorgenommen werden, so werden die Relationen in Tabellen hinterlegt. Dazu ist bei Excel 2010 die Installation des kostenlosen Power Pivot Add-ons notwendig.

Excel kann über diese Möglichkeit zwar nicht die Daten im SAP-System aktualisieren, das Anzeigen von Werten und die Excel-basierte Analyse sind dadurch aber einfach möglich.

Outside Consumption Tools: Über das SAP Community Network werden Erweiterungen zur Verfügung gestellt, die bei der Erstellung von Anwendungen basierend auf HTML5 (jQuery mobile oder SAP UI5), Android, iOS, Java, PHP oder .Net helfen.

Der Entwickler wird dabei durch die Wizard-basierten Erweiterungen unterstützt. Dieser Wizard analysiert den OData Service, um beispielsweise die Relationen und Attribute zu identifizieren. Abhängig von der User-Interface-Technologie stehen List-Detail, manchmal auch Workflow als Template zur Verfügung.

Im nächsten Schritt muss der Entwickler die Bilder, deren Reihenfolge und die darauf sichtbaren Felder definieren. Danach wird der Quell-Code generiert, der als Basis für kundenspezifische Anpassungen verwendet werden kann.

Viele Elemente wie die Proxies können dann direkt als Basis zur individuellen Programmierung der Anwendung verwendet werden. Bei mobilen Technologien wie iOS oder Android erfolgt die Kommunikation anfangs direkt von der App über OData zu NetWeaver Gateway.

Wird die SAP Mobile Platform verwendet, so kann sehr einfach in den zentralen Proxies die Kommunikation auf Mobile Platform umgeschaltet werden, die restliche mobile Anwendung und die erstellten Services im SAP-System können gleich bleiben.

SAP UI5: Am Thema HTML5 arbeiten aktuell viele Browser-Hersteller sowie Hersteller von Werkzeugen zur Erstellung und Wartung von Webseiten. Auch SAP ist aktiv.

Da das Walldorfer Unternehmen einen Fokus auf die Unterstützung von unternehmenskritischen Abläufen hat, wurde auch die HTML5-Unterstützung optimiert.

Durch die Verwendung des SAP UI5 Frameworks wird die Erstellung von HTML5-basierten Oberflächen erleichtert. Dies erfolgt beispielsweise durch die Bereitstellung von Controls, die ein einheitliches Erscheinungsbild und eine erleichterte Erstellung bieten.

Verwendete Komponenten

Die Lösung NetWeaver Gateway besteht vereinfacht aus zwei Komponenten, einem Backend Plug-in und dem eigentlichen Gateway Server. Das Backend Plug-in beinhaltet die notwendigen Funktionalitäten, um sich direkt in das Backend integrieren zu können.

Prominentestes Beispiel ist der Service Builder als zentrale Entwicklungs- und Modellierungsumgebung. Der Gateway Server beinhaltet die Server-Funktionen. Hier laufen die eventuell vorhandenen Backend Plug-ins zentral zusammen, hier werden die XML-Files generiert, Antworten entgegengenommen und vieles mehr.

Eine wichtige Rolle spielen die Berechtigungen und der Zugriff zum SAP-System. Im NetWeaver-Applikationsserver ABAP ist bereits Unterstützung für viele Protokolle enthalten wie SAML 2.0, X.509, Basic Authentication oder SSO2 Token.

Diese Protokolle können daher direkt für die Kommunikation mit dem NetWeaver Gateway System verwendet werden. Man kann nun zwischen mehreren Architekturen unterscheiden:

• Installation direkt auf dem Backend System: Bei der einfachsten Installation können sowohl der Gateway Server als auch das Backend Plug-in direkt auf dem SAP-System installiert werden.Dabei muss das System mindestens die NetWeaver Version 7.0 verwenden. Der Vorteil liegt in den geringen Kosten. Weitere Hardware wird nicht benötigt. Da der NetWeaver Gateway Server mit relativ wenig Ressourcen auskommt, können so bereits viele Szenarien bedient werden.
• Installation auf einem separaten System: Gerade wenn mehr als ein Backend-System vorhanden ist, empfiehlt sich die Installation des Gateway Servers auf einem separaten Server.Die Backend Plug-ins werden hier immer noch in den SAP-Systemen installiert. Die verschiedenen SAP-Systeme kommunizieren jetzt direkt mit dem Gateway Server. In den Backend Plug-ins werden auch in diesem Szenario die notwendigen Services entwickelt.

  Dies hat den Vorteil, dass sich die entsprechende Logik direkt im SAP-System befindet. Dadurch kann sehr performant entwickelt werden. Nur die benötigten Daten werden an den zentralen Gateway Server übertragen.

  Selbst komplexere Szenarien wie die Zuweisung von Anfragen vom Gateway Server auf das richtige SAP-System sind möglich – falls beispielsweise pro Region ein eigenes SAP-System vorhanden ist.

  Eine solche Architektur kann gewählt werden, wenn zum Beispiel durch ein Layered-Defence-Konzept erhöhte Sicherheit bei externen Zugriffen bereitgestellt werden soll. Das NetWeaver Gateway System kann dabei auch in der Demilitarisierten Zone (DMZ) installiert werden.

• Ohne Installation auf dem SAP-System: Die beiden oben skizzierten

Optionen haben den Nachteil, dass auf dem SAP-System zusätzlich Software installiert werden muss. In manchen Konstellationen ist die In­stallation von zusätzlicher Software nur schwierig möglich, wenn beispielsweise ein System nach FDA-Standards validiert wurde.

In diesem Fall können sowohl Backend Plug-in als auch Gateway Server auf einem separaten System installiert werden. Die Kommunikation mit dem SAP-System erfolgt über die bereits im System enthaltenen Schnittstellen wie RFC oder BAPI.

Fortsetzung folgt …