Java-basierte Lösungen für mobile Engeräte mit der SAP Mobile Infrastructure

SAP Mobile Infrastructure

Jörg Kalsbach

Sie betreiben eine Firma. Ihre wesentlichen Prozesse sind in SAP abgebildet. SAP-Know-how ist im Haus vorhanden oder bei Dienstleistern verfügbar, zu denen Sie eine langjährige Beziehung aufgebaut haben. Bei einigen Teilprozessen ist die enge Kopplung an einen Desktop mit Netzwerkverbindung jedoch ausgesprochen hinderlich. Wie schön wäre es, wenn einige Masken auch mittels eines mobilen Endgerätes verwendet werden könnten. Noch viel schöner – und preiswerter – wäre es, wenn diese Lösung nicht zwingend auf eine Netzwerkverbindung angewiesen wäre. Die SAP Mobile Infrastructure (SAP MI) könnte hierzu einen Lösungsansatz bieten.

Die SAP MI ist eine Anwendung, die im SAP Web Application Server (SAP WAS) abläuft. Die Funktionsweise des SAP WAS liegt aber nicht im Fokus dieses Artikels. Weiterhin kann nicht detailliert auf SAP Netweaver als strategische Plattform der SAP eingegangen werden. Aufgrund des engen Rahmens wird die Smart Synchronization nur kurz angerissen.

Im Fokus: Anbindung des Client

Die Prozesse im Backend stehen nicht im Vordergrund der Betrachtung. Diese werden als vorhanden vorausgesetzt. Die mobil zu betreibenden Masken (und damit die zugehörige Geschäftslogik) ist bereits vorhanden. Daher rührt ja häufig erst der Leidensdruck. Es ist ja „schon alles da“. Es muss „nur“ noch auf weitere Clients gebracht werden, auf mobile Endgeräte eben.
Clients lassen sich bezüglich ihrer Mobilität und ihrer Ansprüche an eine Online-Verbindung zu Backend-Systemen in verschiedene Gruppen einordnen. Der traditionelle Client ist immobil und verfügt über eine dauerhafte Netzwerkverbindung. Beispielhafte Applikationen für solche Clients sind der Einkauf bei Amazon oder die Sachbearbeitung innerhalb von SAP. Daneben gibt es mobile Clients, die meistens offline betrieben werden und sich in größeren Abständen mit dem Backend-System synchronisieren. Beispielhafte Anwendungen für dieses Szenario sind Lotus Notes-basierte Applikationen oder der Terminkalender auf einem Palm. Weiterhin gibt es noch den hier interessierenden Anwendungsbereich. Der Client ist mobil, verfügt meistens über eine Netzwerkverbindung, ist aber durchaus in der Lage, Phasen ohne Netzwerkverbindung zu überbrücken.

Geeignete Geschäftsprozesse

Nicht alle Geschäftsprozesse profitieren von einer Ausweitung auf ein mobiles, Offline-fähiges Endgerät. Das Endgerät weist im Vergleich zum Desktop einige Restriktionen auf: kleines Display, geringe Speicherkapazität und Rechenleistung, geringe Batterieleistung etc. Damit lassen sich nur solche Geschäftsprozesse sinnvoll abbilden, die Aufgrund ihrer Ansprüche an Datenvolumen, Rechenleistung, Darstellung und Aktualität der Daten innerhalb der Restriktionen der Hardware überhaupt betrieben werden können. Weitere Ausschlusskriterien sind bspw. lange Auswahllisten, die sich auf kleinen Displays schlecht darstellen lassen. CAD auf dem Mobiltelefon mag eine technische Herausforderung darstellen, wird dem Anwender jedoch keinen Mehrwert bringen. Bei (Teil-)Prozessen, die mit wenigen Eingabemasken abgebildet werden, kann sich die Situation anders darstellen.

Servicetechniker im Außendienst

Am Beispiel des Servicetechnikers im Außendienst lässt sich das Nutzenpotenzial mobiler Lösungen aufzeigen. Der Prozess ist innerhalb von SAP bereits implementiert, die Bearbeitung ist jedoch an einen Desktop mit Netzwerkverbindung gekoppelt. Realistischerweise wird sich ein Techniker morgens eine Liste mit den anstehenden Arbeiten in Papierform ausdrucken. Während des Tages werden Materialverbrauch und Arbeitszeiten ebenfalls auf Papier erfasst. Am Tagesende werden dann die bereits auf Papier erfassten Daten im System aufgenommen. Die Bildschirmmasken für diesen Teilprozess sind unaufwendig, das erforderliche Datenvolumen gering. Bei Servicearbeiten im Außenbereich kann eine Netzwerkverbindung nicht dauerhaft garantiert werden. Daher muss dieses Szenario mit Offline-fähigen Lösungen abgebildet werden.
Bei der mobilen Lösung wird der Techniker mit einem mobilen Endgerät ausgestattet. Er sieht eine Liste von offenen Aufträgen ein und wählt einen Auftrag zur Bearbeitung aus. Alternativ kann ein Dispatcher vorgeschaltet werden, der die Aufträge einzelnen Bearbeitern zuweist. Der Techniker sieht die Detaildaten des Auftrages ein. Vor Ort trägt er nach Abarbeitung des Auftrages Materialverbrauch und Arbeitszeiten ein. Bei Wartungsarbeiten können die zu wartenden Geräte mit Barcodes versehen werden. Durch Einscannen der Barcodes kann gewährleistet werden, dass die Geräte zumindest besucht wurden. Durch die mobile Lösung werden Medienbrüche und die damit verbundenen Probleme vermieden. Der Prozess ist insgesamt durchgängiger und weniger fehleranfällig. Da die Techniker ihre Geräte im Tagesverlauf immer wieder synchronisieren, kann ein Dispatcher während des Tages auf veränderte Bedingungen reagieren (Krankmeldungen, neue Aufträge). Gegenüber Auftraggebern kann zweifelsfrei nachgewiesen werden, dass bestimmte Wartungsarbeiten tatsächlich durchgeführt wurden. Die Eingaben des Technikers stehen bereits während des Tages zentral zur Verfügung.

The Big Picture

Abb. 1: Systemarchitektur der SAP Mobile Infrastructure

Mobile Lösungen wie der oben dargestellte Ansatz können mit der SAP MI realisiert werden. Abbildung 1 zeigt den Aufbau der SAP MI. Die SAP MI besteht aus drei wesentlichen Komponenten. Auf dem mobilen Endgerät befindet sich die SAP MI Client Component. Sie dient als Laufzeitumgebung für die auf dem Gerät deployten Applikationen und stellt den Applikationen über verschiedene APIs Funktionalitäten wie Synchronisation, Logging, Persistenz (auf dem mobilen Gerät), Konfiguration etc. zur Verfügung. Die Client Component kommuniziert mittels HTTP(S) mit der Server Component.
Auf dem SAP Web Application Server (WAS) befindet sich die SAP MI Server Component. Im SAP WAS laufen ein J2EE Stack und ein ABAP Stack. Beide Stacks kommunizieren über JCo. Die SAP MI Server Component liegt teilweise im J2EE Stack und teilweise im ABAP Stack.
Last, but not least läuft im Hintergrund ein Backend. Dort werden die „echten“ (d.h. nicht gespiegelten) Daten gehalten. Als Backend können SAP oder auch Non-SAP-Systeme dienen. Die Kommunikation mit dem Backend erfolgt über RFC. Die Verwendung eines Non-SAP-Systems als Backend der SAP MI dürfte dabei eher theoretischer Natur sein. Die Schaffung einer RFC-Schnittstelle für das Fremdsystem, die den Erfordernissen der SAP MI Server Component entspricht, wird nicht trivial sein und diesen Weg in den meisten Fällen recht aufwendig machen.

RFC

Bereits innerhalb einer reinen SAP-Landschaft besteht die Notwendigkeit, zwischen mehreren SAP-Systemen zu kommunizieren. Weiterhin bestand schon seit jeher (genauer: vor Java und mobilen Lösungen) die Notwendigkeit, zwischen SAP- und Non-SAP-Systemen zu kommunizieren. Eine der dazu verwendeten Kommunikationsformen ist RFC (Remote Function Call). RFC leistet für SAP Ähnliches wie RMI für Java. RFC ist zwar ein proprietärer Mechanismus, funktioniert jedoch ähnlich wie RPC (Remote Procedure Call, vgl. RFC 1050). Innerhalb der SAP-Welt hat RFC den Status einer klassischen Technologie, einer Schlüsseltechnologie zur Kommunikation. All das klingt leicht angestaubt, vor allen Dingen aber alt und bewährt und damit performant, ausgereift und stabil.
Innerhalb der SAP-Welt können alle für RFC freigegebenen Funktionsbausteine angesprochen werden. Die Freigabe ist dabei deklarativer Natur: Mit der Freigabe ist kein RFC-spezifisches Coding verbunden. Damit wird die komplette SAP-Welt nach außen hin geöffnet.

C-API

Non-SAP-Systeme können nun mittels RFC mit SAP-Systemen kommunizieren. Dazu können sie jede beliebige Sprache verwenden, solange es nur C ist. Tatsächlich existiert ein RFC SDK, das die Anfertigung von C-Programmen ermöglicht, welche RFC zur Kommunikation verwenden. Die Programme lassen sich mit einem ANSI C-kompatiblen C Compiler übersetzen und montieren.
Damit ist SAP nicht nur gegenüber C-Programmen geöffnet. Auch alle Sprachen, die in der Lage sind, mit C-Programmen zu kommunizieren, können diesen Weg in Richtung SAP beschreiten. So verwundert es denn nicht, dass mehrere populäre Skriptsprachen über RFC Bindings verfügen. So finden sich dann auf SAP-Seiten Hinweise auf RFC Bindings für Perl, PHP, Python und Ruby. Die Aufzählung der Sprachen erfolgt hier alphabetisch und stellt keine Wertung dar. Über RFC lassen sich sowohl Inbound- (aus SAP-Sicht, Fremdsystem ruft SAP) als auch Outbound- (SAP ruft Fremdsystem) Aufrufe umsetzen. Dem Mutigen gehört die Welt!
Das Java-seitige Pendant der RFC Bindings ist JNI. Über JNI und die C API kann von Java aus RFC gegen SAP gesprochen werden. Die Kommunikation funktioniert dabei ebenfalls beidseitig, sowohl inbound als auch outbound.

Geschrieben von
Jörg Kalsbach
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.