Design und Implementierung einer mobilen, Workflow-orientierten BlackBerry-Anwendung für den Zugriff auf ein SAP-System

Größe: px
Ab Seite anzeigen:

Download "Design und Implementierung einer mobilen, Workflow-orientierten BlackBerry-Anwendung für den Zugriff auf ein SAP-System"

Transkript

1 Fachhochschule Wiesbaden Fachbereich Design Informatik Medien Studiengang Allgemeine Informatik Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker/in (FH) Design und Implementierung einer mobilen, Workflow-orientierten BlackBerry-Anwendung für den Zugriff auf ein SAP-System vorgelegt von Alexander Opatz am 28. Februar 2007 Referent: Prof. Dr. R. Kröger Korreferent: Dipl.-Ing. Dipl.-Kfm. T. Schneider

2 II

3 Erklärung Ich versichere, dass ich die Diplomarbeit selbstständig verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Wiesbaden, Alexander Opatz Hiermit erkläre ich mein Einverständnis mit den im Folgenden aufgeführten Verbreitungsformen dieser Diplomarbeit: Verbreitungsform ja nein Einstellung der Arbeit in die Bibliothek der FHW Veröffentlichung des Titels der Arbeit im Internet Veröffentlichung der Arbeit im Internet Wiesbaden, Alexander Opatz III

4 IV

5 Inhaltsverzeichnis 1 Einleitung 1 2 Grundlagen Die BlackBerry-Architektur BES - BlackBerry Enterprise Server BB-MDS-Studio BB-Handheld RIM Push-Technologie Web Services WSDL - Web Services Description Language SOAP SAP SAP-CRM SAP-XI - exchange Infrastructure J2ME - Java 2 Platform Micro Edition Überblick Deployment MIDlet Suite OTA Provisioning Programmierung Lebenszyklus PushRegistry Graphische Benutzerschnittstelle RMS - Persistente Speicherung ksoap Web-Service-Bibliothek Optimierungen für mobile Anwendungen Sicherheitskonzept V

6 3 Analyse Anforderungen Rahmenbedingungen Anwendungsfälle Server-initiiert Client-initiiert Problembereiche Server SAP-CRM Datenmodellierung Web Service zum SAP-CRM-System Mobile Gateway Mobile Client Kommunikation mit dem Web Service JSR Web-Service-API für J2ME REST-Web-Services Voranalysen Evaluierung Synchronisation und Offline-Modus Usability der mobilen Anwendung Logging und Unit-Tests Design Architekturüberblick mobilecrm Allgemeine Design-Prinzipien Benutzerschnittstelle Model und Backend-Zugriffe Abbildung der Anwendungsfälle Server-initiiert Client-initiiert Integrationsszenarien in SAP-XI VI

7 5 Implementierung Entwicklungswerkzeuge SOAP-Parsing RMS-Schnittstelle Multi-Threading Worker-Thread Push-Thread Logging und Internationalisierung Workarounds javax.microedition.midlet.midlet javax.microedition.lcdui.gauge Statische PushRegistry-Verbindungen im JAD Initialisierung von statischen Attributen Qualitätssicherung Styleguide Software-Metriken Automatisierte Tests Implementierungsaufwand Performance-Bewertung Messreihe Messreihe Messreihe Messreihe Bewertung Zusammenfassung Literaturverzeichnis 121 A Abkürzungen 123 VII

8 VIII

9 Abbildungsverzeichnis 2.1 Aufbau der BlackBerry-Architektur Komponenten des BES aus [RIM06a] Verschlüsselung zwischen BB-Endgerät und BES Aufbau einer Beschreibung eines Web Service mit WSDL nach [HL04] Aufbau einer SOAP-Nachricht (HTTP als Transportprotokoll) Überblick der SAP-Module Aktivitätsmanagement im GUI-Client von SAP SAP-XI Aufbau der J2ME-Komponenten Lebenszyklus eines MIDlets, angelehnt an [Sch04] Zusammenhang der Klassen des LCDUI, adaptiert aus [Sch04] MIDlet-Suite übergreifende Zugriffe auf RecordStores Grobe Systemarchitektur Server-initiierte Anwendungsfälle Client-initiierte Anwendungsfälle Zusammenhang der Komponenten von JSR Beispiel für ein Lost-Update bei der Synchronisation Synchronisationslösung 1 für Client-initiiertes Aktivitätsupdate Push-Update, Bestandteil der Synchronisationslösungen 1 und Synchronisationslösung 2 für Client-initiiertes Aktivitätsupdate Mögliches Lost-Update in Synchronisationslösung Verfeinerter Aufbau der Systemarchitektur Klassen der Benutzerschnittstelle (View) Übersicht und Zusammenhang der Screens IX

10 4.4 Business Objects in mobilecrm Komponenten zur Kommunikation mit den Backend-Systemen Sequenzdiagramm zum Anwendungsfall Daten synchronisieren Sequenzdiagramm zum Anwendungsfall Aktivitäten auflisten Sequenzdiagramm zum Anwendungsfall Aktivität anlegen Sequenzdiagramm zum Anwendungsfall Aktivität löschen Sequenzdiagramm zum Anwendungsfall Aktivität anzeigen Sequenzdiagramm zum Anwendungsfall Aktivitätenliste anfordern Sequenzdiagramm zum Anwendungsfall Daten synchronisieren Aufbau eines synchronen Integrationsszenarios im SAP-XI Aufbau der verschiedenen Nachrichtentypen Klassen für Internationalisierung und Logging Kiviat-Graph der Metriken von mobilecrm Messaufbau und Bezeichnung der Messwerte Zeit zum Serialisieren der Anfrage in SOAP-XML-Markup Messreihe 1: Eine Aktivität als Payload Messreihe 2: 14 Aktivitäten als Payload Messreihe 3: Zehn Aktivitäten als Payload X

11 Tabellenverzeichnis 2.1 ksoap Mappings für primitive Datentypen Übersicht der Attribute einer Aktivität in mobilecrm Übersicht der Komponenten von mobilecrm Übersicht der Integrationsszenarien Integrationsszenario ActionPush Integrationsszenario ChangeActivity Integrationsszenario GetActivityList LOC des Package com.csc.bb.mobilecrm LOC des Package com.csc.bb.mobilecrm.gui LOC des Package com.csc.bb.mobilecrm.model LOC des Package com.csc.bb.mobilecrm.model.backend.rms LOC des Package com.csc.bb.mobilecrm.model.backend.sap LOC des Package com.csc.bb.mobilecrm.util LOC des Package com.csc.bb.mobilecrm.tests LOC von mobilecrm und mobilecrmtestsuite Statistische Kenngrößen zu Messreihe 1 (Einheit [ms]) Statistische Kenngrößen zu Messreihe 2 (Einheit [ms]) Statistische Kenngrößen zu Messreihe 3 (Einheit [ms]) Daten aus Messreihe 4 (Einheit [ms]) XI

12 XII

13 Verzeichnis der Quellcodes 2.1 Aufbau einer RIM-Push HTTP-Anfrage Beschreibung eines Web Service aus [W3C01] Beispiel einer SOAP-Nachricht (Anfrage) Beispiel einer SOAP-Nachricht (Antwort) Beispiel eines Java Application Descriptors Beispiel zur Serialisierung in einen Byte-Strom KvmSerializable-Schnittstelle von ksoap JAD der Push-Test-Anwendung Interface zur Umsetzung des Command Pattern build.xml: Target makecod Parameter für den Obfuscator ProGuard SAPmanager.java: Methode receivepush RMSmanager.java: Methode saveactivityentry ModelController.java: Methode getactivity ModelController.java: Methode handlegetactivity ModelController.java: Methode stop PushReceiver.java: Methode run PushReceiver.java: Methode stop Bug in Klasse MIDlet Log-Ausgabe der Testanwendung MIDlet_Destroy_Bug Bug in Klasse Gauge XIII

14 XIV

15 Kapitel 1 Einleitung Die Verbreitung von mobilen Endgeräten wie Smartphones, PDAs und Handys nimmt weltweit rasant zu. Im September 2006 wurde global die Marke von 2.5 Milliarden Handys erreicht. In Westeuropa betrug im Jahr 2004 der Verbreitungsgrad Prozent, d.h. in manchen Ländern ist pro Kopf bereits mehr als ein Handy vorhanden (siehe Studie [Gei05]). Man liest in diesem Zusammenhang auch häufig von pervasive oder ubiquitous computing, womit die Durchdringung und Allgegenwärtigkeit von mobilen oder eingebetteten Endgeräten in allen Lebensbereichen gemeint ist. Dies schafft ein großes Potential für mobile Anwendungen und darauf basierende Geschäftsmodelle. Zur Unterstützung von Geschäftsprozessen können mobile Anwendungen auch in Unternehmen eingesetzt werden. Unter Mobile Business versteht man die Abwicklung von Geschäftsprozessen durch elektronische Kommunikationstechniken mit mobilen Endgeräten. Die besonderen Merkmale des Mobile Business sind örtliche Unabhängigkeit, Erreichbarkeit zu jeder Zeit, einfache Handhabung sowie Identifizierungs- und Telemetriefunktionen. Dadurch lassen sich Prozesse in verschiedenen Geschäftsbereichen effizienter gestalten. Mit dem Einsatz von mobilen Endgeräten innerhalb logistischer Ketten können beispielsweise Daten in Echtzeit erfasst werden. Dies ermöglicht ein besseres Supply Chain Management (SCM) - Engpässe können so früh erkannt werden, und Entscheidungen basieren auf aktuellen Daten. Außendienstmitarbeiter sind zu jeder Zeit in der Lage, ihre Daten des Personal Information Management (PIM) - also z.b. Aufgaben, Termine und Kontakte - und s abzurufen. Diese Funktionalität nennt sich auch Mobile Office und ist auf Kommunikation und Zusammenarbeit ausgerichtet. Anwendungen für den sogenannten Mobile Workforce Support dienen der Unterstützung von Geschäftsprozessen und ermöglichen den mobilen Zugriff auf firmeninterne Backend-Systeme. Beispielsweise können Daten des Customer 1

16 Kapitel 1. Einleitung Relationship Management (CRM) somit zu jeder Zeit an einem beliebigen Ort verfügbar sein, und der Kunde kann ohne Zeitverzögerung Informationen oder spezifische Angebote von seinem Ansprechpartner erhalten. Auch für Konsumenten als Nutzer bringen mobile Anwendungen Zeitersparnis oder eine Verbesserung der Lebensqualität. Entertainment in Form von Spielen und Musik hat sich bereits auf Handys etabliert und gehört schon zum Alltag. Navigations- und Bezahlsysteme steigern die Effizienz im Alltag. Ebenso ist vorstellbar, dass weitergehende standortbezogene Dienste - auch Location Based Services (LBS) genannt - durch erweiterte Funktionen an Attraktivität gewinnen. Im Bereich öffentlicher und sozialer Einrichtungen wie Notfalldienste, Polizei und Militär führt eine schnelle und auch interdisziplinäre Kommunikation durch mobilen Datenaustausch zu effizienterem Agieren und kann dadurch entscheidend oder sogar lebensrettend sein. Zur Verwaltung und Optimierung von Geschäftsprozessen wie beispielsweise dem bereits angesprochenen CRM und SCM haben sich Softwaresysteme etabliert. Die SAP AG ist als Hersteller auf diesem Gebiet führend und ihre Software ist bei großen und mittelständischen Unternehmen weit verbreitet. Die aktuelle Produktlinie setzt mit ihrer Serviceorientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch sollen die Geschäftsprozesse schneller abgewickelt werden, und unmittelbare Anpassungen der Prozesse an die aktuellen Bedürfnisse der Marktlage sind leichter durchführbar. An dieser Stelle kann Mobile Business zu weiteren Optimierungen beitragen. Bei der Arbeit mit sensiblen Daten, seien es Betriebsgeheimnisse oder Abwicklungen von Geschäften mit hohen Transaktionssummen, ist die Gewährleistung der Sicherheit unabdingbar. Neben der verschlüsselten Kommunikation muss garantiert sein, dass die Endgeräte selbst auch sicher sind, da sie Daten lokal speichern können und Zugriff zum Unternehmensnetzwerk haben. Diese Möglichkeiten bietet z.b. die mobile Plattform Black- Berry (BB) des Herstellers Research in Motion (RIM). Die mobilen Endgeräte sind dabei über einen zentralen Server in das Unternehmen eingebunden und jegliche Kommunikation ist verschlüsselt. Auf dem Endgerät selbst können Daten kodiert gespeichert und via Passwort zugriffsgeschützt werden. Über den Server ist es außerdem möglich, die Daten von Geräten über die drahtlose Verbindung zu löschen und IT-Richtlinien anzuwenden. Mit 5,5 Millionen Nutzern weltweit zeigt sich bereits eine gewisse Verbreitung dieser Architektur. Diese Diplomarbeit entstand extern in Kooperation mit der CSC Deutschland Solutions GmbH in Wiesbaden. Sie zielt darauf ab, die vielfach bereits in Unternehmen vorhandene SAP-Infrastruktur in die BlackBerry-Plattform zu integrieren, um so sicheres Mobile Business zu ermöglichen. Ein Workflow in einem SAP-CRM-System wird dabei proto- 2

17 Kapitel 1. Einleitung typisch durch eine mobile Anwendung auf einem BlackBerry-Endgerät abgebildet. Um dabei möglichst plattformunabhängig und generisch vorzugehen, erfolgt die Integration durch Web Services. Durch die damit verbundene Kommunikation in Form von XMLbasierten Nachrichten bleibt die Kopplung zwischen den zu integrierenden Systemen so gering wie möglich, und die Interoperabilität mit anderen Plattformen ist gewahrt. Der Schwerpunkt dieser Arbeit liegt auf dem Entwurf von Konzepten für die Integration, die anhand einer prototypische mobilen Anwendung realisiert werden soll. Die Implementierung des zu entwerfenden Web Service auf SAP-Seite wird durch den Betreuer (Herrn Thomas Schneider) von Seiten der Firma CSC vorgenommen. Der Aufbau dieser Arbeit gliedert sich wie folgt: Im Kapitel Grundlagen werden die technologischen Voraussetzungen BlackBerry, SAP, Web Services und J2ME erläutert, die bei der Bearbeitung des Themas eingesetzt wurden. Daran schließt sich die Analyse an, in der zunächst die Rahmenbedingungen und Anwendungsfälle der Anwendung beschrieben werden, um dann die einzelnen Systembestandteile dieser Arbeit und mögliche Alternativen zu untersuchen. Im Abschnitt Design wird die Realisierung dieser Ausführungen softwaretechnisch entworfen, basierend auf den Entscheidungen in der Analyse und mit der mobilen Anwendung auf dem BB-Endgerät als Schwerpunkt. Darauffolgend werden die wesentlichen und interessanten Teile der Implementierung dargelegt. Das abschließende Kapitel Fazit fasst die gesamte Abhandlung zusammen und gibt einen Ausblick für weitere Entwicklungen in diesem Themenbereich. 3

18 4 Kapitel 1. Einleitung

19 Kapitel 2 Grundlagen Dieses Kapitel dient dazu, den Leser mit Architekturen und Technologien vertraut zu machen, die für das Verständnis dieser Arbeit benötigt werden. Zunächst wird die BlackBerry-Architektur erläutert und darauf folgend ein Überblick über die SAP- Architektur gegeben und im Speziellen auf die Module zur Kundenverwaltung (CRM) und der Integration mit anderen Unternehmensanwendungen (XI) eingegangen. Zum besseren Verständnis der SAP-Integration folgt ein Unterkapitel über Technologien für Web Services. Für die Realisierung dieser Arbeit ist die Java-Plattform für mobile Endgeräte (J2ME) maßgebend und wird darauffolgend vorgestellt. 2.1 Die BlackBerry-Architektur Der kanadische Hersteller RIM bezeichnet mit BB Produkte, die im Zusammenhang mit dieser mobilen Plattform stehen. Einen Überblick darüber gibt Abbildung 2.1. Über mobile Endgeräte ist man in die firmeninternen - und Messaging-Systeme integriert. Das PIM wird ebenso drahtlos abgeglichen. Weiterhin besteht die Möglichkeit, an die Kommunikationsplattform weitere Unternehmensanwendungen anzubinden, um Daten und Funktionen zugänglich zu machen. Einen Überblick der Architektur und des Zusammenspiels der Komponenten liefert [RIM06a]. Die Plattform besteht hauptsächlich aus einem BB-Handheld als Client, der über einen BB-fähigen Mobilfunkanbieter mit einem BlackBerry Enterprise Server (BES) verbunden ist. Die BB-Infrastruktur besteht aus globalen Rechenzentren des Herstellers RIM. Diese nehmen für das Endgerät verschlüsselte Nachrichten von BES-Servern und über eine durch 5

20 2.1. Die BlackBerry-Architektur Kapitel 2. Grundlagen Abbildung 2.1: Aufbau der BlackBerry-Architektur das SRP-Protokoll (SRP steht für Secure Remote Password) authentifizierte Verbindung an. Die Nachricht wird an den entsprechenden Mobilfunkanbieter weitergeleitet, bei dem das BB-Endgerät eingebucht ist, welches die Nachricht empfangen soll. Für diesen Vorgang ist die von RIM bereitgestellte BB-Infrastruktur notwendig, da ein BB-Client sonst nur mit einem Mobilfunkanbieter funktionieren würde. Über GPRS oder UMTS übermittelt der Mobilfunkanbieter die Nachricht zum Endgerät, wo sie entschlüsselt werden kann. Übertragungen in umgekehrter Richtung arbeiten analog, hierbei kodiert jedoch das mobile Endgerät und der BES nimmt die entschlüsselnde Rolle ein. Eine Dekodierung durch die BB-Infrastruktur findet nicht statt. Eine weitere Möglichkeit, das Endgerät mit dem BES zu verbinden, ist mittels USB- Kabelverbindung zur einer Workstation, auf der die BB-Desktop-Software läuft, von der die Daten über das LAN an den BES gesendet werden BES - BlackBerry Enterprise Server Das Herzstück der Architektur ist der BES, über den die gesamte Kommunikation stattfindet. Diese Serversoftware besteht aus mehreren Komponenten, die in Abbildung 2.2 dargestellt sind. Die wesentlichen Komponenten werden in den folgenden Abschnitten besprochen. Über den BES werden standardmäßig bereits das firmeninterne -System (unterstützt werden Microsoft Exchange und IBM Lotus Domino) und einige Instant- 6

21 Kapitel 2. Grundlagen 2.1. Die BlackBerry-Architektur Abbildung 2.2: Komponenten des BES aus [RIM06a] Messaging-Systeme durch entsprechende Clientsoftware in die BB-Endgeräte integriert. Ein besonderes Merkmal ist dabei die sogenannte Push-Technologie, mit der eingehende Nachrichten vom BES aus auf das entsprechende Endgerät gesendet werden können. Dadurch ist es möglich, die Rechen- und die Latenzzeit des -Empfangs zu verringern, und das aufkommende Datenvolumen im Vergleich zu benutzerinitiierten Mail- Abfragen (Polling) zu reduzieren. Über die Desktop-Software kann das Verhalten des E- Mail-Systems benutzerspezifisch eingestellt werden. So können beispielsweise Filter angelegt werden, um zu bestimmen, welche s auf das BB-Gerät gepusht werden sollen. Vom Handheld aus gesendete s werden bei Bedarf mit der Desktop-Software synchronisiert. -Anhänge werden vom BES in ein spezielles Binärformat konvertiert, das die BB-Gerätesoftware standardmäßig anzeigen kann, ohne dass spezifische Clientsoftware nötig ist. Dies funktioniert allerdings nur für Formate, die vom Anhangdienst im BES unterstützt werden und die dieser entsprechend konvertieren kann. Ebenso werden Daten des PIM drahtlos über den BES synchronisiert, so dass die Desktop-Clients und das BB-Endgerät mit den gleichen Daten arbeiten. Verbindungen zwischen dem BES und BB-Handhelds sind immer mit einem symmetrischen Verschlüsselungsverfahren gesichert (vgl. Abbildung 2.1), aktuell durch AES mit 7

22 2.1. Die BlackBerry-Architektur Kapitel 2. Grundlagen Abbildung 2.3: Verschlüsselung zwischen BB-Endgerät und BES einem Schlüssel der Länge 256 Bit. Eine Aufgabe des BES ist also die serverseitige Verund Entschlüsselung, die durch den Dispatcher-Service (siehe Abbildung 2.2) stattfindet. Dazu gehört auch die Verwaltung der geheimen Schlüssel der Endgeräte. Ein Hauptkodierungsschlüssel wird mit einem Handheld generiert, der entweder mit der BB-Desktop-Software oder über die Funkverbindung mit dem BES verbunden ist. Dieser Schlüssel wird an drei Stellen hinterlegt: im BES, im Endgerät und auf dem Mailsystem. Mit dem Hauptkodierungsschlüssel wird der sogenannte Nachrichtenschlüssel chiffriert, mit dem die eigentliche Nachricht verschlüsselt ist (siehe Abbildung 2.3). Die verschlüsselte Nachricht und der zugehörige kodierte Nachrichtenschlüssel werden an den BES gesendet. Durch den dort hinterlegten Hauptschlüssel des Endgeräts kann der Nachrichtenschlüssel dekodiert werden und im nächsten Schritt somit auch die Nachricht. Der Hauptschlüssel des Geräts wird üblicherweise alle 30 Tage automatisch geändert. Eine manuelle Änderung ist jederzeit möglich und kann server- oder clientseitig initiiert sein, Der Nachrichtenschlüssel ändert sich bei jedem Datenpaket (maximal 2kB) 8

23 Kapitel 2. Grundlagen 2.1. Die BlackBerry-Architektur und wird basierend auf Zufallsdaten generiert. Optional kann auch ein Schlüssel zum Inhaltsschutz des Handhelds auf der Grundlage des Geräte-Kennworts generiert werden. Mit Hilfe dieses Schlüssels werden gespeicherte Daten und der Hauptkodierungsschlüssel chiffriert. Detailliertere Informationen zu den Verschlüsselungsmechanismen finden sich im im Kapitel BlackBerry-Codierungsschlüssel in [RIM06b]. Die Sicherheitseinstellungen der BB-Endgeräte lassen sich über IT-Richtlinien zentral vom BES aus drahtlos konfigurieren. Die zuständige Komponente dafür ist der Policy- Service. So kann z.b. unterbunden werden, dass die Benutzer der Endgeräte Anwendungen installieren können, oder es können die Aktivierung des Inhaltsschutzes und sichere Passwörter erzwungen werden. Änderungen an den Richtlinien können für alle oder manuell ausgewählte Endgeräte vorgenommen werden. Der BES stellt mit der Komponente namens Mobile Data System (MDS) Verbindungen zwischen den mobilen Endgeräten und Anwendungen des Unternehmens oder dem Internet her. Die Kommunikation zwischen Endgerät und dem BES ist dabei auf bekannte Weise verschlüsselt, für eine sichere Verbindung zwischen MDS und der Unternehmensanwendung kann SSL verwendet werden. Neben der Verschlüsselung stellt die Dispatcher-Komponente auch einen Dienst zur Optimierung des Datenverkehrs für BB-Endgeräte bereit. Die Optimierung umfasst Datenverkehr von -Kommunikation, MDS-Studio-Applikationen (erstellt mit BBspezifischer IDE), J2ME-Anwendungen und dem BB-Browser (falls diese über das MDS- System übertragen werden). Je nach Anwendungsfall werden die Daten komprimiert oder auch in ein anderes Format konvertiert, welches das BB-Gerät darstellen kann. Eine weitere Funktion des MDS ist der Provisioning-Service, mit dem MDS-Studio- Anwendungen zentralisiert an die Endgeräte verteilt werden können. Für die Anbindung unternehmensspezifischer Anwendungen an BB-Endgeräte bieten sich Applikationen auf Basis von J2ME (siehe Kapitel 2.4) und MDS-Studio-Anwendungen an, welche im nächsten Abschnitt erläutert werden BB-MDS-Studio Die Software BB-MDS-Studio ist eine Entwicklungsumgebung von RIM (siehe Dokumentation [RIM06c]), mit der relativ schnell und leicht graphische Client-Anwendungen erstellt werden können, die auf Web Services zugreifen. Als Ausgangsbasis dient dabei die Beschreibung des Web Service in Form eines WSDL-Dokuments, auf dessen Aufbau später eingegangen wird. Die IDE erstellt aus einem WSDL-Dokument bereits Dialog- 9

24 2.1. Die BlackBerry-Architektur Kapitel 2. Grundlagen felder, die an den Ein- und Ausgabemöglichkeiten des Web Service orientiert sind. Über einen graphischen Assistenten können die Dialoge manuell angepasst werden. Auf Basis der Dialoge kann mittels JavaScript weitere Logik implementiert werden. Die Anwendung wird als XML-Struktur repräsentiert und zusammen mit einer separaten Datei für das JavaScript sowie optionalen Resourcen in ein Java Archive (JAR) verpackt. Der BES stellt eine Datenbank zur Verfügung, in der MDS-Studio-Anwendungen verwaltet werden und von BB-Clients zur Installation drahtlos abgerufen werden können. Vom MDS- Runtime-System im BB-Endgerät wird die Anwendung in native Java-Aufrufe umgesetzt und die Web-Service-Bibliothek bereitgestellt BB-Handheld Aktuelle BB-Endgeräte laufen mit einem eigenen Betriebssystem von RIM und unterstützen J2ME- und MDS-Studio-Anwendungen. Standardmäßig sind auf den Geräten bereits ein -Client und ein Web-Browser installiert. Für den Browser gibt es drei verschiedene Profile: 1. Den WAP-Browser, wobei die Verbindung über das WAP-Gateway des Mobilfunkanbieters aufgebaut wird. 2. Den BlackBerry-Browser, der Verbindungen über das MDS des BES herstellt. 3. Internet-Browser, der Verbindungen über die RIM-Infrastructure (nicht über den BES) schafft. Unter dem Namen BB-Connect bietet RIM Module an, mit denen einige Endgeräte von Drittanbietern, basierend auf den Betriebssystemen Symbian OS und Windows Mobile, einen Großteil an Funktionalitäten der BlackBerry-Enterprise-Lösung nutzen können. Die ausführbaren Anwendungen für BlackBerry-Geräte bzw. die BlackBerry-JVM werden in einem proprietären Format mit der Datei-Extension.cod gespeichert. Die Entwicklungsumgebung von RIM, das Java Development Environment (JDE), bringt einige Entwicklungswerkzeuge mit, die sich auch außerhalb der IDE nutzen lassen. Unverzichtbar ist dabei rapc.exe, ein Compiler, der reguläre J2ME-Anwendungen in das BlackBerry-Format übersetzt. Mit der BlackBerry-Desktop-Software lassen sich die installierten Anwendungen auf einem Endgerät verwalten. 10

25 Kapitel 2. Grundlagen 2.1. Die BlackBerry-Architektur RIM Push-Technologie Der BES stellt eine externe Schnittstelle für Anwendungen des Unternehmens bereit, über die Push-Nachrichten angenommen werden und an das entsprechende BB-Endgerät weitergeschickt werden. Die genaue Funktionsweise wird im BlackBerry Application Developer Guide Volume 1 [RIM05] in Kapitel 10 erläutert. Voraussetzung ist, dass die externe Anwendung das HTTP-Protokoll beherrscht und mit der POST-Methode die Nachricht an den BES übermitteln kann. Eine Nachricht wird entweder im RIM-Push-Protokoll (Aufbau siehe Codeausschnitt 2.1) oder Push Access Protocol (PAP, Teil der WAP 2.0 Spezifikation) verpackt. 1 POST /push?destination=<gerät>&port=<port>&requesturi=<uri> HTTP/1.1 <HTTP-Header> 3 <RIM-spezifische HTTP-Header> 5 <Nachrichteninhalt> Quellcode 2.1: Aufbau einer RIM-Push HTTP-Anfrage Die notwendigen Informationen und Optionen für die Nachrichtenzustellung werden über den URI der HTTP-Anfrage und spezifische HTTP Header übermittelt. Das Zielgerät wird mit Hilfe eines eindeutigen Identifikationsstrings des Geräts, in der Dokumentation des Herstellers PIN genannt, oder der -Adresse des Benutzers identifiziert. Der angegebene Port spezifiziert den Port auf dem Endgerät, auf dem die Anwendung auf eingehende Verbindungen wartet. Dort wird der Inhalt der Nachricht in Form eines Byte-Datenstroms entgegen genommen. Den Parameter REQUESTURI gibt der BES über HTTP an das Endgerät weiter. Über optionale, herstellerspezifische HTTP Header kann beispielsweise die Priorität angegeben werden oder ein URI, den der BES aufruft, um eine Rückmeldung über die Nachrichtenzustellung zu geben. Die Informationen der Rückmeldung werden dabei ebenfalls über HTTP Header transportiert. Es ist auch möglich, Push-Nachrichten eine Lebensdauer zuzuweisen, so daß die Nachricht nicht mehr ausgeliefert wird, falls dies nicht innerhalb des im BES definierten Zeitraums erfolgt ist. Im Gegensatz zum RIM-Push-Protokoll werden beim PAP die protokollspezifischen Informationen in einer XML-Struktur transportiert. Daher wird die Nachricht in Form einer MIME-Multipart-Nachricht versendet, um diese Informationen von dem Nachrichteninhalt zu trennen. 11

26 2.2. Web Services Kapitel 2. Grundlagen 2.2 Web Services Unter einem Web Service versteht man eine Software-Komponente, die über XMLbasierten Nachrichtenaustausch mit anderen Applikationen Daten und Funktionen anbieten und entgegennehmen bzw. ausführen kann. Web Services dienen also der Kommunikation zwischen Anwendungskomponenten. Der Unterschied zu anderen Kommunikationsverfahren ist, dass die Grundlage der Nachrichtenformate XML ist, und Nachrichten über das HTTP-Protokoll übertragen werden können. Dadurch ergibt sich eine große Interoperabilität zwischen verschiedenen Plattformen und Programmiersprachen und die Integration in bestehende Firewall-geschützte Netzwerke fällt leichter. Für die Bereitstellung und Nutzung von Web Services haben sich einige Protokolle etabliert, die in den folgenden Unterkapiteln beschrieben werden. Als Grundlage dient dabei das Buch [HL04] WSDL - Web Services Description Language Mit der Web Services Description Language (WSDL) lassen sich Web Services in Form von XML-Dokumenten beschreiben. Die aktuelle Version 2.0 des WSDL-Standards liegt beim World Wide Web Consortium (W3C) als sogenannte Candidate Recommendation vor [W3C06]. Die zuvor in Entwicklung befindliche Version 1.2 wurde aufgrund größerer Änderungen in 2.0 umbenannt. Der neue Standard unterteilt sich in die Teile Core Language, Message Patterns und Bindings. Einige Elemente wurden umbenannt oder um Attribute erweitert, und das aktuelle SOAP-Binding nutzt nun die Version 1.2 statt 1.1 in der vorherigen Version. Viele Implementierungen nutzen jedoch noch nicht die neuen Standards. Im Folgenden wird WSDL in der Version 1.1 beschrieben (für die Spezifikation siehe [W3C01]), da SAP die neueste Version noch nicht unterstützt. Eine Beschreibung für die Schnittstelle eines Web Service ist notwendig, um die bereitgestellten Operationen sowie erwartete und zurückgegebene Daten unabhängig von der Web-Service-Implementierung zu dokumentieren. Mittlerweile bieten viele Entwicklungswerkzeuge Unterstützung beim Umgang mit WSDL. Ausgehend von einem WSDL- Dokument kann beispielsweise ein Client-Skelett in einer spezifischen Programmiersprache generiert werden, um mit dem Web Service zu kommunizieren. Umgekehrt gibt es Tools, die zu einer Web-Service-Implementierung ein entsprechendes WSDL-Dokument erzeugen. Außerdem gibt es noch graphische Design-Werkzeuge, mit denen man ein WSDL-Dokument entwerfen kann. Die Beschreibung einer Schnittstelle gliedert sich in fünf Teile, die in Abbildung 2.4 dargestellt sind. 12

27 Kapitel 2. Grundlagen 2.2. Web Services Abbildung 2.4: Aufbau einer Beschreibung eines Web Service mit WSDL nach [HL04] Das Wurzelelement einer Beschreibung ist das definitions-element, das alle notwendigen XML-Namensräume einbindet. Innerhalb der darauf folgenden Sektion types können eigene Datentypen definiert werden, falls die XML-Schema-Datentypen nicht ausreichend sind - üblicherweise werden damit komplexere Datentypen als XML-Schema realisiert. Eine WSDL-Beschreibung muss mindestens ein message-element enthalten, das mit Namen und Typ den Aufbau einer Nachricht beschreibt, die der Web Service senden oder empfangen kann. Diese Nachrichtentypen werden in der darauffolgenden porttype-sektion verwendet, in der sie Operationen als Ein- oder Ausgabe-Typ zugeordnet werden. Durch die Reihenfolge und das Vorhandensein der Unterelemente input und output wird festgelegt, welcher Endpunkt die Kommunikation initiiert und ob eine Reaktion von der anderen Seite erwartet wird. Die Struktur unterhalb des Elements binding ist ähnlich wie porttype aufgebaut, allerdings werden dort die Operationen mit einem Transportprotokoll (z.b. SOAP oder HTTP) verknüpft. Eine abstrakte Definition einer Operation kann mehrere Bindungen haben. Der letzte Abschnitt service enthält port-unterelemente, in denen jeweils einem Binding ein URL zugeordnet wird, auf der diese Operation abzurufen ist. Eine beispielhafte Beschreibung eines Web Service durch WSDL findet sich in Quellcode-Listing SOAP Ursprünglich bedeutete SOAP Simple Object Access Protocol, wird aber mittlerweile nur noch als Eigenname verwendet, da eine Objektorientierung nicht gegeben ist. SOAP ist eine Spezifikation zum plattformunabhängigen Austausch von XML-Nachrichten. Initiiert wurde SOAP von Microsoft, basierend auf der Entwicklung von XML-RPC (Spezifikation siehe [Win99]) durch Dave Winer bei UserLand-Software. Die Version 1.1, an der sich auch IBM beteiligte, wurde dem W3C zur Standardisierung vorgelegt. Vielen 13

28 2.2. Web Services Kapitel 2. Grundlagen 1 <definitions name="stockquote" targetnamespace="http://example.com/stockquote.wsdl" 3 xmlns:tns="http://example.com/stockquote.wsdl" xmlns:xsd1="http://example.com/stockquote.xsd" 5 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> 7 <types> 9 <schema targetnamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2000/10/xmlschema"> 11 <element name="tradepricerequest"> <complextype> 13 <all> <element name="tickersymbol" type="string" /> 15 </all> </complextype> 17 </element> <element name="tradeprice"> 19 <complextype> <all> 21 <element name="price" type="float" /> </all> 23 </complextype> </element> 25 </schema> </types> 27 <message name="getlasttradepriceinput"> 29 <part name="body" element="xsd1:tradepricerequest" /> </message> 31 <message name="getlasttradepriceoutput"> 33 <part name="body" element="xsd1:tradeprice" /> </message> 35 <porttype name="stockquoteporttype"> 37 <operation name="getlasttradeprice"> <input message="tns:getlasttradepriceinput" /> 39 <output message="tns:getlasttradepriceoutput" /> </operation> 41 </porttype> 43 <binding name="stockquotesoapbinding" type="tns:stockquoteporttype"> 45 <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <operation name="getlasttradeprice"> 47 <soap:operation soapaction="http://example.com/getlasttradeprice" /> <input> 49 <soap:body use="literal" /> </input> 51 <output> <soap:body use="literal" /> 53 </output> </operation> 55 </binding> 57 <service name="stockquoteservice"> <documentation>my first service</documentation> 59 <port name="stockquoteport" binding="tns:stockquotebinding"> <soap:address location="http://example.com/stockquote" /> 61 </port> </service> 63 </definitions> Quellcode 2.2: Beschreibung eines Web Service aus [W3C01] 14

29 Kapitel 2. Grundlagen 2.2. Web Services Abbildung 2.5: Aufbau einer SOAP-Nachricht (HTTP als Transportprotokoll) SOAP-Implementierungen liegt diese Version zugrunde, die jedoch nur ein Working Draft des W3C ist. Sie wurde bereits abgelöst in Form einer endgültigen Empfehlung des W3C durch die Version 1.2, an der auch Sun Microsystems und Canon erstmalig mitgewirkt haben. In der Version 1.2 besteht die Spezifikation nun aus drei Teilen statt einem. Die Namensräume für Envelope und Encoding haben sich geändert, und statt einer Bindung an HTTP ist die Spezifikation in der Version 1.2 nun allgemeiner gefasst und erlaubt andere Protokolle. Im Folgenden wird auf die Version 1.1 eingegangen (für die Spezifikation siehe [W3C00]), da diese Version in Kombination mit WSDL 1.1 noch bei SAP eingesetzt wird. Im Gegensatz zu XML-RPC muss die Kommunikation über SOAP nicht synchron ablaufen. Eine Nachricht kann jedoch einen Informationsfluss in Gegenrichtung auslösen, ebenso wie eine Nachricht an mehrere Empfänger addressiert werden kann. In der Praxis wird SOAP hauptsächlich mit den sogenannten Message Exchange Pattern (MEP) in der Form Anfrage-Antwort (XML-RPC) und Einzelnachrichten verwendet. Zwischen Sender und Empfänger sieht die Spezifikation noch SOAP intermediaries vor, die die Mitteilung weiterleiten. Üblicherweise wird die Information jedoch direkt vom Sender zum Empfänger geschickt. Als Transportprotokoll für SOAP-Nachrichten wird oft HTTP verwendet, deren gemeinsames Binding im Standard fest integriert wurde. Dabei werden auch die Statuscodes und der Header von HTTP eingesetzt. Es lassen sich aber auch andere Protokolle wie FTP und SMTP für SOAP nutzen. Abbildung 2.5 verdeutlicht den Aufbau einer SOAP-Nachricht, die aus einem Envelope-XML-Element als Wurzel besteht, das als Kind-Elemente Header und Body hat, wobei der Header optional ist. Vor den SOAP-spezifischen Elementen kann gff. noch eine XML-Deklaration stehen, sowie meistens noch der HTTP Header, falls HTTP als Transportprotokoll verwendet wird. Während im SOAP-Envelope verschiedene XML-Schema-Namensräume bekannt gemacht werden, ist der Header relativ offen spezifiziert und bietet so Möglichkeiten, 15

30 2.2. Web Services Kapitel 2. Grundlagen dort optionale Funktionalität einzufügen wie beispielsweise Aspekte der Sicherheit oder Transaktionssteuerungsinformationen. Innerhalb des Body-Tags werden die eigentlichen Nutzdaten in Form von XML- Dokumenten übertragen. Dieses Element und auch Unterelemente davon können im Attribut encodingstyle Angaben darüber machen, welche Regeln für die Deserialisierung von XML in entsprechende Datentypen verwendet werden können. Die SOAP- Spezifikation stellt ein Regelwerk zur Verfügung, das auf den Datentypen von XML- Schema basiert und mit dem Namensraum /encoding/ assoziiert ist. Im Falle eines Fehlers zwischen den Kommunikationspartnern wird dies durch ein Element namens Fault als Unterelement von Body signalisiert. Dieses Element enthält weitere Unterelemente für eine genaue Fehlerrückmeldung. Ein vollständiges Beispiel einer SOAP-Nachricht mit Anfrage und Antwort befindet sich im Quellcode-Listing 2.3 und 2.4. <?xml version= 1.0 encoding= utf-8?> 2 <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 4 xmlns:tns="http://axisversion.sample/xsd" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" 6 xmlns:xsd="http://www.w3.org/2001/xmlschema"> <soap:body> 8 <tns:getversion> </tns:getversion> 10 </soap:body> </soap:envelope> Quellcode 2.3: Beispiel einer SOAP-Nachricht (Anfrage) 1 <?xml version= 1.0 encoding= utf-8?> <soapenv:envelope 3 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:header /> 5 <soapenv:body> <ns:getversionresponse xmlns:ns="http://axisversion.sample/xsd"> 7 <return> Hello I am Axis2 version service, My version is 1.0 May 05, 2006 (12:30:54 IST) 9 </return> </ns:getversionresponse> 11 </soapenv:body> </soapenv:envelope> Quellcode 2.4: Beispiel einer SOAP-Nachricht (Antwort) 16

31 Kapitel 2. Grundlagen 2.3. SAP 2.3 SAP Dieses Unterkapitel bietet einen Überblick der SAP-Softwarelösungen und geht danach auf die für diese Arbeit interessanten Module CRM und XI ein. Die Basis dieses Abschnitts sind die SAP-Schulungsunterlagen [SA03]. Die SAP AG ist ein weltweit agierendes Unternehmen und führender Anbieter von Unternehmenssoftware. Die Service-orientierte Architektur der Software ist darauf ausgelegt, Geschäfte in Echtzeit abzuwickeln, auf veränderte Marktbedingungen schnell reagieren zu können und die Zusammenarbeit der Mitarbeiter zu verbessern. Erreicht werden soll dies durch die Komponente NetWeaver, die dafür zuständig ist, die einzelnen SAP-Module und auch Fremdanwendungen untereinander zu vernetzen und zu integrieren. Ebenso stellt diese Komponente einen Application-Server zur Verfügung, auf dem die weiteren Module aufsetzen. Das Kern-Modul ist mysap ERP, es ist der Nachfolger des SAP R/3 Systems, das weiterhin verfügbar ist, jedoch nicht auf der NetWeaver- Technologie basiert. ERP ist ein Begriff aus den Wirtschaftswissenschaften und bedeutet Enterprise Resource Planning. Damit werden die Basisfunktionalitäten für ein Unternehmen bereitgestellt. Dieser Kern kann um Zusatzkomponenten ergänzt werden, um weitere Geschäftsprozesse abbilden zu können. Einen Überblick dazu gibt die Abbildung 2.6. Das SRM (Supplier Relationship Management) umfasst die Planung und Steuerung von Beziehungen des Unternehmens zu seinen Lieferanten. Das SCM (Supply Chain Management) dient der Optimierung von innerbetrieblichen Logistikketten. Das PLM (Product Lifecycle Management) gestattet allen an der Produktentwicklung beteiligten Einheiten und Partnern Zugriff auf die Daten der Produktentwicklung. Dies kann zur Verkürzung der Produktzyklen beitragen, erlaubt Qualitätsverbesserungen und wird dem Sachverhalt gerecht, dass Unternehmen mit immer mehr Geschäftspartnern kooperieren. Mit Hilfe des CRM lassen sich Kundenbeziehungen verwalten, so dass Mitarbeiter alle nötigen Informationen zu Kunden abrufen können. Auf die Funktionalität dieses Moduls wird im Folgenden näher eingegangen SAP-CRM 4.0 Als inhaltliche Quelle zu diesem Abschnitt dient [BEZ04]. Unter CRM versteht man allgemein Strategien und Verfahren, um Beziehungen von Unternehmen zu Kunden individualisiert verwalten zu können. Die wesentlichen Faktoren für den wirtschaftlichen Erfolg eines Unternehmens - marktgerechte Produkte, profitabler Betrieb und zufriedene Kunden - können durch CRM optimiert werden. Die Zielsetzung ist dabei, die Kunden kontinu- 17

32 2.3. SAP Kapitel 2. Grundlagen Abbildung 2.6: Überblick der SAP-Module ierlich und effizient zu betreuen und die Leistungen den jeweiligen Kundenbedürfnissen anzupassen. Dazu werden alle interessanten Kundendaten wie Kontaktmöglichenkeiten, eine Historie von bisherigen Geschäftsabwicklungen oder auch die Liquidität des Kunden festgehalten. Jeder beteiligte Mitarbeiter hat somit Zugriff auf die Daten und kann den Kunden individuell bedienen. Die Informationen sind also nicht in Köpfen von bestimmten Mitarbeitern oder auf Notizen verteilt, sondern gehören dem Unternehmen und sind für alle am Geschäftsprozess Beteiligten verfügbar. Durch eine Auswertung der CRM- Daten kann auch genau festgestellt werden, welche Kunden am meisten Profit einbringen und welche möglicherweise Verluste verursachen. So können die Kundenbetreuung aufgrund dieses Aspektes entsprechend gestaltet und Prioritäten festgelegt werden. Ebenso kann eine wirtschaftliche Geschäftsfokussierung stattfinden. Durch weitere Analysen können Änderungen im Kundenverhalten und des gesamten Marktgeschehens erkannt und die Ressourcen und Geschäftsprozesse entsprechend adaptiert werden. Die CRM-Software von SAP ist in drei Kategorien unterteilt: Operatives CRM Das operative CRM unterstützt Geschäftsabläufe, die unmittelbar am Kunden ausgerichtet sind. Darunter fällt der Vertrieb eines Unternehmens, der mit Kaufinteressenten und Kunden bis zur Vertragsabwicklung agiert. Im Service werden Kundenbeschwerden entgegen genommen, mit Unterstützung von Lösungsdatenbanken 18

33 Kapitel 2. Grundlagen 2.3. SAP bearbeitet, und Serviceverträge erfüllt. Auch der Bereich Marketing hat direkten Kontakt zu den Kunden. Analytisches CRM Das Ziel von CRM-Analysen ist die Auswertung von Kundenzufriedenheit und Kundenverhalten, deren Ergebnisse wiederum die Entscheidungsgrundlage für Vertrieb und Marketing sind. Kollaboratives CRM Das kollaborative oder auch unternehmensübergreifende CRM dient der Zusammenarbeit des Unternehmens mit Geschäftspartnern. Um den Einsatzbereich eines CRM-Systems weiter zu optimieren, müssen auch beispielsweise die ERP- und SCM-Module zugreifbar sein. So können Bestellungsänderungen oder andere Wünsche des Kunden direkt vom CRM aus abgewickelt werden. Das CRM ist quasi die Schnittstelle des Kunden zum Unternehmen, und somit müssen alle relevanten Geschäftsprozesse im Backend des Unternehmens und auch unternehmensübergreifend bei Lieferanten und Partnern zugreifbar sein. Bei CRM-Lösungen findet sich auch eine Spezialisierung nach Branchen, um konkret den unterschiedlichen Bedürfnissen gerecht zu werden. Für den technischen Zugriff auf ein CRM-System gibt es BAPIs (Business Application Programming Interface) und Funktionen, die remote-fähig sind, sogenannte RFC- Bausteine. RFC steht für Remote Function Call und ist ein von SAP definiertes Protokoll für entfernte Funktionsaufrufe. Dabei übernimmt das Protokoll die Kommunikationssteuerung, Parameterübergabe und die Fehlerbehandlung. Ein BAPI ist ein RFC-fähiger Funktionsbaustein, der einen fest definierten Funktionsumfang hat, meist zusammenfassend für einen bestimmten Geschäftsvorfall. Weiterhin soll eine BAPI-Schnittstelle über Versionswechsel der Software hinaus konstant bleiben und abstrahiert somit mehr als ein RFC-Interface. Eine Funktion des CRM, auf die in diesem Rahmen näher eingegangen wird, ist das Aktivitätsmanagement, das die Mitarbeiter bei der Organisation der täglichen Arbeit unterstützen soll. Eine Aktivität ist vergleichbar mit einem Eintrag in einem Terminkalender, der um zusätzliche Funktionen erweitert ist. Sie dienen der Dokumentation von Interaktionen mit Kunden. Wie sich eine Aktivität im graphischen SAP-Frontend darstellt, ist in Abbildung 2.7 zu sehen. Neben den beteiligten Ansprechpartnern auf Unternehmens- und Kundenseite wird auch der Ort und der Zeitraum festgehalten. Es kann ein Text für den Grund und das Ziel der Aktivität hinterlegt werden, ebenso wie ein Erledigungsstatus, 19

34 2.3. SAP Kapitel 2. Grundlagen Abbildung 2.7: Aktivitätsmanagement im GUI-Client von SAP eine Priorität und ein Ergebnis. Als Anlage können weitere Dokumente und Belege verknüpft sein, beispielsweise Marketingbroschüren oder Briefe, die an den Kunden adressiert wurden. Dabei werden noch die speziellen Möglichkeiten vom System angeboten, einen Aktivitätsbericht zu erstellen oder einen Fragebogen zu entwerfen und Aktivitäten zuzuordnen. In einem Aktivitätsbericht kann der Produktbezug einer Aktivität festgehalten werden oder auch Feedback des Kunden. Mit Hilfe eines Fragebogens können z.b. die Verkaufschancen (Opportunity-Bewertung) in einer Geschäftsbeziehung berechnet werden SAP-XI - exchange Infrastructure Die SAP Exchange Infrastructure (XI) (siehe [SO04]) ist ein Bestandteil von NetWeaver und dient der Integration von SAP- und Fremdanwendungen inner- oder außerhalb des Unternehmens. Hervorgehoben sei an dieser Stelle, dass auch einige SAP-Module wie beispielsweise SRM und CRM über XI angebunden sind. Dies unterstreicht das Serviceorientierte Paradigma der SAP-Architektur. Die an Geschäftsprozessen orientierte Inte- 20

35 Kapitel 2. Grundlagen 2.3. SAP Abbildung 2.8: SAP-XI gration von Applikationen in heterogene Anwendungssysteme nennt sich auch Enterprise Application Integration (EAI). Ein weiteres Ziel, das mit XI verfolgt wurde, ist das Abspeichern von integrationsspezifischem Wissen an zentraler Stelle. So wird vermieden, dass die Unternehmensanwendungen direkt miteinander verknüpft werden und dadurch eine komplexe Struktur mit möglicherweise unterschiedlichen verwendeten Technologien entsteht. Stattdessen kommuniziert jede Applikation mit der XI, die Daten intern durch XML-basierte Nachrichten repräsentiert und an die entsprechende Ziel-Anwendung weiterleitet. Dadurch ist die Kopplung der Anwendungen an den Kommunikationsendpunkten gering. Das interne XI-Protokoll basiert auf SOAP und verwendet Header Extensions und weitere Payload in MIME Multiparts. Der Datenaustausch mit XI kann synchron und asynchron erfolgen. Eine solche Plattform, die Nachrichten zwischen voneinander unabhängigen Systemen vermittelt, nennt man in diesem Zusammenhang auch Messageorientied Middleware (MOM). In Abbildung 2.8 sind die wesentlichen Teile von XI dargestellt. Die Adapter-Engine setzt Nachrichten der zu integrierenden Systeme in das XI-Message-Format um und umgekehrt. Statt Formatumsetzungen für alle Kombinationen miteinander kommunizierender Systeme muss lediglich eine Umsetzung für die entsprechenden Protokolle in beide Richtungen stattfinden, beispielsweise SOAP-Nachrichten in RFC- oder BAPI-Aufrufe umsetzen und umgekehrt. Anstatt die Adapter-Engine zu verwenden, kann mit einer Java- oder ABAP-Anwendung innerhalb des Applikation Servers auch direkt mit der Integration- Engine kommuniziert werden. Die Integration-Engine übernimmt das Routing der konvertierten Nachrichten, und ggf. werden sogenannte Mappings durchgeführt. Mit Hilfe von Mappings können Datenkonvertierungen in XI umgesetzt werden, um die Doku- 21

36 2.3. SAP Kapitel 2. Grundlagen mentstruktur der Nachricht eines Senders an den Empfänger anzupassen. Die Business- Process-Engine setzt auf der Integration-Engine auf und übernimmt die zustandsbehaftete Nachrichtenübermittlung auf Geschäftsprozessebene. Die nötigen Informationen, um Nachrichten zwischen Systemen zu vermitteln, werden in Integration-Repository, Integration-Directory und System-Landscape-Directory (SLD) gespeichert, deren Inhalt im Folgenden erläutert wird: System-Landscape-Directory Das SLD enthält einen Katalog mit Beschreibungen über installierbare Softwareprodukte und deren Komponenten in der Systemlandschaft. Mit Komponenten sind in diesem Fall einzeln installierbare Einheiten gemeint, die jedoch nicht zwangsweise ohne das Hauptprodukt ausführbar sind. Die Beschreibungen enthalten auch jeweils die Version des Produkts oder der Komponente. In einem weiteren Katalog werden die konkreten Systeme erfasst, unterteilt in technische Systeme und weiter abstrahierend in Business-Systeme. Abgespeichert werden diese Daten mit dem Standard Common Information Model (CIM) [DMT06]. Für SAP-Produkte werden bereits entsprechende Beschreibungen mit ausgeliefert. Integration-Repository Im Integration-Repository werden die Schnittstellen der beteiligten Systeme in Form von WSDL- und XML-Schema-Dokumenten hinterlegt. Die Definition von Prozessen kann mittels der Business Process Execution Language (BPEL) [BPE] stattfinden. Für die bereits erwähnten Mappings werden XSLT-Dokumente verwendet. Integration-Directory Durch das Integration-Directory werden Schnittstellen aus dem Integration-Repository konkrete Systeme aus dem SLD zugeordnet. Dadurch werden letztendlich die Systeme festgelegt, die untereinander Nachrichten austauschen. Mit der Browser-basierten Anwendung Integration Builder, die auf der Technologie Java Web Start (JWS) basiert, kann das Design im Integration-Repository entworfen und die Konfiguration im Integration-Directory vorgenommen werden. Das SLD kann über eine Web-Anwendung konfiguriert werden. 22

37 Kapitel 2. Grundlagen 2.4. J2ME - Java 2 Platform Micro Edition 2.4 J2ME - Java 2 Platform Micro Edition Dieses Unterkapitel vermittelt das nötige Wissen, um standardisierte Java-Anwendungen für mobile Endgeräte zu entwickeln. Die Basis dieses Abschnitts sind die Lehr-Bücher [Sch04] und [Yua06] Überblick Die Micro Edition ist eine Spezifikation der Java-Laufzeitumgebung für mobile Endgeräte wie beispielsweise PDAs und Mobiltelefone. Aufgrund der unterschiedlichen Ausprägungen und Einschränkungen solcher Geräte ist J2ME komponentenbasiert aufgebaut und dadurch flexibler als die Java 2 Standard Edition (J2SE). Die Spezifikationen sind im offenen Java Community Process (JCP) unter Federführung großer Hersteller wie Nokia und RIM durch sogenannte Java Specification Requests (JSR) entstanden. Die unterste von drei Schichten in J2ME (siehe Grafik 2.9) bilden sogenannte Konfigurationen. Sie legen fest, welche Hardwareanforderungen ein Gerät erfüllen muss, und definieren zu den Anforderungen passende Standardbibliotheken und eine Java Virtual Machine (JVM). Auf diesen Konfigurationen bauen diverse Profile auf, die weitere fundamentale, gerätespezifische Bibliotheken zur Verfügung stellen. In der letzten Schicht, die auf ein Profil aufsetzt, gibt es optionale Zusatzpakete, beispielsweise eine 3D-API oder XML-Parser. Die Connected Limited Device Configuration (CLDC) zielt auf in der Hardware eingeschränkte Geräte ab. Die Mindestanforderungen sind 160kB nichtflüchtiger Speicher für die VM und Bibliotheken und 32kB flüchtiger Speicher für den Ablauf der VM. Aufgrund dieser Restriktionen ist nur eine Untermenge der J2SE-API vorgesehen und an die Endgeräte angepasst implementiert. Ebenso ist eine auf das Wesentliche reduzierte Kilo Virtual Machine (KVM) verfügbar, die beispielsweise nicht die Java-Reflection-API unterstützt. Die CLDC ist größtenteils auf Mobiltelefonen wiederzufinden und wird im JSR 139 in der Version 1.1 definiert. Details können der zugehörigen Spezifikation [Tai03] entnommen werden. Die Connected Device Configuration (CDC) hingegen hat höhere Hardwareanforderungen, stellt mehr Funktionalität der J2SE-API zur Verfügung und kommt beispielsweise auf High-End PDAs, TV Set-Top-Boxen oder Navigationssystemen zum Einsatz. Im Gegensatz zur CLDC bietet sie eine vollständige J2SE JVM. Für diese Diplomarbeit ist nur die Konfiguration CLDC relevant. 23

38 2.4. J2ME - Java 2 Platform Micro Edition Kapitel 2. Grundlagen Abbildung 2.9: Aufbau der J2ME-Komponenten Auf der CLDC setzt das Mobile Information Device Profile (MIDP) auf. Es stellt eine API für die wesentlichen Merkmale eines Mobiltelefons zur Verfügung (vgl. [MW06]): Lebenszyklus, Deployment und Signieren von Anwendungen Graphische Benutzerschnittstelle (Ein- und Ausgabe) Persistente Speicherung für Anwendungsdaten und Einstellungen Netzwerkverbindungen und HTTP/HTTPS Media API (nur für Audio) Dementsprechend formuliert die Spezifikation weitere Hardware-Anforderungen, zusätzlich zu denen der CLDC, um die Funktionalität des MIDP realisieren zu können. Im Wesentlichen sind dies weiterer Speicher von mind. 256kB für die MIDP-Implementierung und 8kB für persistente Daten, eine minimale Auflösung des Displays mit 96x96 Pixeln und 1 Bit Farbtiefe, sowie eine Tastatur oder einen Touchscreen Deployment In den folgenden Abschnitten erfolgt eine Beschreibung des Packaging und der Installation von J2ME-Anwendungen auf Basis des MIDP (siehe Kapitel 2 der Spezifikation [MW06]) MIDlet Suite Die Installation und das Starten einer Anwendung geschehen über die Application Management Software (AMS), die auf dem Endgerät vom Hersteller implementiert ist. Eine 24

39 Kapitel 2. Grundlagen 2.4. J2ME - Java 2 Platform Micro Edition Deinstallation wird ebenso von der AMS durchgeführt. Eine installierbare Anwendung nennt sich MIDlet Suite und besteht aus einem JAR und einem optionalen Java Application Descriptor (JAD). Ein Beispiel eines JAD findet sich im Quellcode-Listing 2.5. Das JAR enthält die kompilierten Klassen der Anwendung, eine Manifest-Datei, sowie optionale Ressourcen wie Text- und Bilddateien, die von der Anwendung benötigt werden. Der Kompiliervorgang wird mit einem J2SE-Standardcompiler vollzogen. Da die CLDC, wie in Abschnitt erwähnt, nicht den vollen J2SE-VM-Umfang implementiert, muss der generierte Bytecode anschließend noch mit einem sogenannten Preverifier bearbeitet werden. Ein solches Werkzeug wird beispielsweise innerhalb des Wireless Toolkit (WTK) 1 von Sun bereitgestellt, und formt den Bytecode zu einem Äquivalent um, das auf einer KVM lauffähig ist. MIDlet-1: MIDletName, /path/to/midlet/icon.png, com.example.midletclassname 2 MIDlet-Jar-URL: midletsuite.jar MIDlet-Name: Midlet Suite Name 4 MIDlet-Vendor: CSC MIDlet-Version: MicroEdition-Configuration: CLDC-1.1 MicroEdition-Profile: MIDP CustomAttribute: value Quellcode 2.5: Beispiel eines Java Application Descriptors Die Manifest-Datei besteht aus Key:Value-Paaren und beinhaltet notwendige Informationen für das AMS zur Installation. Optional können einige solcher Attribute auch durch einen externen JAD zur Verfügung gestellt werden, so dass die Anwendung an den Benutzer oder das Endgerät angepasst werden kann, ohne das JAR modifizieren zu müssen. Außerdem können eigene anwendungsspezifische Attribute angelegt werden, die jedoch nicht mit MIDlet oder MicroEdition beginnen dürfen. Weitere Details und eine Übersicht zu verpflichtenden Attributen hält die Spezifikation [MW06] auf S. 435 bereit. Mit der Methode getappproperty() der Klasse MIDlet lassen sich alle im JAD angegebenen Attribute der Suite zur Laufzeit abfragen. Die Ressourcen kann ein MIDlet über die Methode java.lang.class.getresourceasstream(string name) als Datenstrom auslesen. Das Wurzelverzeichnis ist dabei das JAR des MIDlets

40 2.4. J2ME - Java 2 Platform Micro Edition Kapitel 2. Grundlagen OTA Provisioning Der Installationsvorgang wird nach dem Over The Air (OTA) Provisioning Verfahren abgewickelt, das in [MW06] Kapitel 2 genauer spezifiziert ist. Die MIDlet Suite liegt dabei auf einem entfernten Web Server vor und wird in mehreren Schritten über die Funkverbindung auf das Endgerät übertragen: 1. Der Benutzer wählt im Endgerät die zu installierende Anwendung in der sogenannten Discovery Application (DA) aus - üblicherweise geschieht dies im WAP- Browser. Durch eine HTTP-GET-Anfrage wird der entsprechenden JAD vom Server auf das Endgerät transferiert und von der AMS ausgewertet. 2. Falls alle im JAD enthaltenen Voraussetzungen zur Installation erfüllt sind, wird durch die AMS das JAR der Anwendung (die URL befindet sich im JAD) ebenfalls via HTTP auf das Gerät geladen und installiert. 3. Falls entsprechende Attribute im JAD vorhanden sind, erzeugt das AMS per HTTP- POST eine Rückmeldung an einen angegebenen Server, in der ein Statuscode der Installation übermittelt wird. Zu beachten ist dabei, dass der Web Server die entsprechenden MIME-Typen für den JAD (text/vnd.sun.j2me.app-descriptor) und das JAR (application/java-archive) im HTTP Header angeben sollte Programmierung In den folgenden Abschnitten wird auf die Entwicklung von J2ME-Anwendungen eingegangen, basierend auf der Konfiguration CLDC 1.1 und dem Profil MIDP Lebenszyklus Wenn der Benutzer eine Anwendung zum Starten ausgewählt hat, wird von der AMS das entsprechende MIDlet geladen. Der Einstiegspunkt einer solchen Anwendung, analog zur Funktion main() in J2SE oder anderen Programmiersprachen, ist in der abstrakten Klasse javax.microedition.midlet.midlet definiert. Eine Applikation muss dementsprechend mindestens eine Klasse beinhalten, die MIDlet erweitert und die Handler-Methoden startapp(), pauseapp() und destroyapp(boolean unconditional) überschreibt. 26

41 Kapitel 2. Grundlagen 2.4. J2ME - Java 2 Platform Micro Edition Abbildung 2.10: Lebenszyklus eines MIDlets, angelehnt an [Sch04] Ein MIDlet kennt die drei Zustände paused, active und destroyed. Der Zustand eines MIDlets kann sowohl von der AMS als auch vom MIDlet selbst in einen anderen überführt werden (siehe Abbildung 2.10). Wenn ein Zustandsübergang von der AMS ausgelöst wird, ruft diese zunächst die entsprechende Handler-Methode des MIDlets auf. Wird der Zustand vom MIDlet selbst geändert, durch den Aufruf einer der Methoden notifypaused() oder notifydestroyed(), so werden die Handler- Methoden nicht aufgerufen, dafür muss das MIDlet ggf. selbst sorgen. Mittels notify- Destroyed() im MIDlet (nicht überschreibbar, da final) wird eine Anwendung regulär beendet, System.exit() verursacht im Kontext mit MIDP spezifikationsgemäß eine SecurityException. Bei Aufruf einer Anwendung wird von der AMS zunächst der Konstruktor des MIDlets aufgerufen, und der Zustand ist paused. Im Konstruktor können nicht-zeitaufwändige Initialisierungen erfolgen. Weitere Ressourcenanforderungen und das Erfüllen der eigentlichen Aufgabe der Applikation erfolgen in startapp() bzw. von dort aus delegiert in anderen Klassen. Die Methode startapp() wird ebenfalls von der AMS aufgerufen, und der Zustand ändert sich zu active. Wenn das Display von einer anderen Anwendung, z.b. einem eingehenden Telefonanruf, benötigt wird, pausiert die AMS das MIDlet. In der Handler-Methode pauseapp() sollte das MIDlet dabei zuvor angeforderte Ressourcen freigeben. Falls das MIDlet Hintergrund-Threads gestartet hat, so laufen diese weiter, auch wenn das MIDlet pausiert. Daher sollten solche Threads nicht viele Ressourcen wie CPU-Zeit, Speicher und Bandbreite benötigen oder anderenfalls gestoppt werden. Soll das MIDlet durch die AMS beendet werden, so wird destroyapp(boolean unconditional) aufgerufen, wobei der Parameter angibt, ob das MIDlet den Befehl zur Beendigung mit einer MIDletStateChangeException verweigern kann oder nicht. Weiterhin werden in dieser Methode üblicherweise Ressourcen freigegeben - bei- 27

42 2.4. J2ME - Java 2 Platform Micro Edition Kapitel 2. Grundlagen spielsweise Deskriptoren freigeben oder Threads beenden - und ggf. Anwendungsdaten persistent gespeichert PushRegistry Für Anwendungen, die auf bestimmte Ereignisse warten, stellt die AMS eine sogenannte PushRegistry zur Verfügung. Bei dieser Komponente können sich Anwendungen dynamisch via javax.microedition.io.pushregistry oder statisch über einen Eintrag im JAD registrieren und werden dann von der AMS gestartet, wenn ein entsprechendes Ereignis eintritt. Dadurch ist es für eine Applikation möglich, auf eingehende TCP- und UDP-Verbindungen an einem registrierten Port oder auf eine SMS von einer bestimmten Rufnummer zu reagieren. Darüberhinaus bietet die PushRegistry noch die Möglichkeit, einen Timer zu setzen, so dass die Anwendung regelmäßig gestartet wird. Der Vorteil der PushRegistry ist, dass die Anwendung erst gestartet wird, wenn das Ereignis eintritt und nicht selbst aktiv wartet. Somit können Ressourcen gespart werden. Die AMS wartet auf eingehende Verbindungen an registrierten Ports und startet das zugehörige MIDlet, das die Verbindung über javax.microedition.io.connector mit der Methode open() öffnen kann. Das MIDlet ist, wenn es gestartet ist, selbst für eingehende Verbindungen und darauf empfangene Daten verantwortlich. Die AMS überwacht dies erst wieder, nachdem das MIDlet beendet wurde. Zu beachten ist dabei, dass im JAD das Attribut MIDlet-Permissions entsprechend die vollqualifizierten Klassennamen der PushRegistry und der verwendeten Netzwerkklassen enthält Graphische Benutzerschnittstelle Das Lowest Common Denominator User Interface (LCDUI) im Package javax-.microedition.lcdui ist ein Framework der J2ME für grafische Benutzerschnittstellen und untergliedert sich in eine High- und Low-Level-API. Letzteres ermöglicht pixelgenaues Zeichnen auf dem Display, das Nutzen von gerätespezifischen Hardwarefunktionalitäten wie beispielsweise Auflösung, Farbtiefe und das Abfragen von Tasten. Die Low-Level-API kommt z.b. bei Spielen zum Tragen und wird hier nicht näher betrachtet. Im Gegensatz dazu ist die High-Level-API eine abstrahierende Schicht über den gerätespezifischen Grafik-Elementen, den sogenannten Widgets. Dies hat zur Folge, dass Anwendungen, die diese API nutzen, nicht auf jedem Gerät das gleiche Look and Feel - also Erscheinungsbild und Bedienung der Widgets - haben. Auf der anderen Seite integriert 28

43 Kapitel 2. Grundlagen 2.4. J2ME - Java 2 Platform Micro Edition sich die Anwendung so automatisch, und der Benutzer hat das vom Endgerät gewohnte Look and Feel. Ein Überblick der Klassenhierarchie der LCDUI wird in Abbildung 2.11 gegeben. Gemeinsam ist beiden APIs, dass sie eine dem MIDlet zugeordnete Instanz der Klasse Display verwenden, die das physikalische Display repräsentiert und mit der statischen Methode Display.getDisplay(MIDlet m) abgefragt werden kann. Zu einem Zeitpunkt kann auf dem Display ein einziges Objekt dargestellt werden, das die abstrakte Klasse Displayable erweitert. Darin werden bereits die Funktionalitäten für einen Fenster-Titel, -Laufschrift und Hinzufügen von Bedienelementen zur Interaktion mit dem Benutzer zur Verfügung gestellt. Um die Benutzereingaben zu bearbeiten, kann man einem Displayable-Objekt auch CommandListener übergeben, die häufig als anonyme Klasse implementiert werden. Das Framework ruft dessen Callback-Methode commandaction(command c, Displayable d) bei entsprechenden Events seriell auf, d.h. weitere Callbacks werden erst aufgerufen, wenn der vorherige beendet wurde. Aus diesem Sachverhalt heraus ergibt sich die Empfehlung, in Callback-Methoden keine zeitaufwändigen Operationen einzubetten. Welches Objekt auf dem Bildschirm sichtbar sein soll, kann mit der Methode Display-.setCurrent(Displayable nextdisplayable) gesetzt werden. Diese Methode darf jedoch nicht im Konstruktor des MIDlets sondern erst in startapp() aufgerufen werden. Über Display lassen sich außerdem Informationen zum Display abfragen sowie die Hintergrundbeleuchtung und der Vibrationsalarm steuern. Von Displayable erbt die Klasse Canvas, an der die Low-Level-API ansetzt. Das Pendant für die Highlevel API ist Screen, von dem sich die Benutzerelemente List, Alert, TextBox und Form ableiten. Dabei ist Form ein flexibles Element, das man mit Items bestücken kann, die eigene ItemCommandListener haben können. Es gibt vorgefertigte Unterklassen von Item, die häufig benötigte Funktionalitäten zur Verfügung stellen, beispielsweise eine Auswahl mittels ChoiceGroup, die vereinfachte Eingabe eines Datums durch DateField und Fortschrittsbalken (Klasse Gauge). Die Aktualisierung auf dem Display gestaltet sich einfach: Modifiziert man Elemente, führt das LCDUI Framework automatisch eine Aktualisierung durch, eine TextBox kümmert sich z.b., wenn nötig, eigenständig um einen Scrollbalken. Ein wichtiger Aspekt bei der Programmierung von graphischen Benutzerschnittstellen ist die Verwendung von Threads. Die Logik einer Anwendung sollte in einem separaten Thread laufen, damit der Ausführungsstrang der LCDUI jederzeit Aktualisierungen in der graphischen Repräsentation vornehmen kann. 29

44 2.4. J2ME - Java 2 Platform Micro Edition Kapitel 2. Grundlagen Abbildung 2.11: Zusammenhang der Klassen des LCDUI, adaptiert aus [Sch04] 30

45 Kapitel 2. Grundlagen 2.4. J2ME - Java 2 Platform Micro Edition Abbildung 2.12: MIDlet-Suite übergreifende Zugriffe auf RecordStores RMS - Persistente Speicherung Um Daten auf mobilen Endgeräten persistent speichern zu können, definiert das MIDP eine abstrakte, herstellerunabhängige Schnittstelle - das sogenannte Record Management System (RMS). Details können der Spezifikation [MW06] in Kapitel 14 entnommen werden. Das RMS im Package javax.microedition.rms bietet den Klassen einer MIDlet Suite die Funktionalität, RecordStores anzulegen, die dann wiederum eine Sammlung von Records enthalten. Ein Record ist ein Datensatz in Form eines Java Byte-Arrays von beliebigem Inhalt und Länge, dem vom RMS ein Primärschlüssel als Identifikator zugeordnet wird. Der Datentyp des Primärschlüssels ist int, und die Vergabe beginnt mit 1, jeder weitere Record erhält n+1. Schlüssel von gelöschten Datensätzen werden nicht neu vergeben. Ein RecordStore ist durch einen innerhalb der MIDlet Suite eindeutigen Namen bezeichnet, der 1 bis 32 Unicode-Zeichen umfassen kann, wobei Groß- und Kleinschreibung beachtet wird. Seit MIDP 2.0 kann ein RecordStore über ein Attribut auch für andere MIDlet Suites zugänglich gemacht werden. Der Zugriff erfolgt dabei über die Bezeichner des MIDlet-Suite-Herstellers, der MIDlet Suite selbst (beides Attribute im JAD, siehe auch 2.4.2) und den Namen des RecordStores. Dies ist in Abbildung 2.12 veranschaulicht. Wenn eine MIDlet Suite deinstalliert wird, schreibt die Spezifikation vor, dass alle zugehörigen RecordStores mit gelöscht werden. Für das Öffnen und Anlegen von Record- Stores stellt die Klasse RecordStore die statische Methode openstore in verschie- 31

46 2.4. J2ME - Java 2 Platform Micro Edition Kapitel 2. Grundlagen denen Ausprägungen (Überladung) zur Verfügung. Ebenso kann man statisch Record- Stores löschen und sich alle zu der MIDlet Suite gehörenden RecordStores auflisten lassen. Nachdem ein RecordStore geöffnet wurde, wird er durch eine Instanz der Klasse RecordStore repräsentiert, über die alle weiteren Operationen erreichbar sind. Im Wesentlichen sind dies die Methoden addrecord(), setrecord zum Modifizieren eines vorhandenen Datensatzes und deleterecord. Bei jedem Aufruf dieser Methoden wird die Version des RecordStores inkrementiert sowie der Zeitpunkt der letzten Änderung festgehalten. Diese Attribute können auch über die API abgerufen werden. Eine Implementierung des RMS muss zusichern, dass diese Operationen immer atomar nacheinander ablaufen - Transaktionen werden jedoch nicht unterstützt. Bei der Verwendung von Threads muss daher beachtet werden, dass bei zusammengehörenden, aufeinander folgenden Operationen für das zugehörige RecordStore-Objekt mittels eines synchronized-block in Java der exklusive Zugriff sichergestellt ist. Um nun das Datenmodell einer Anwendung mittels RMS zu speichern, müssen die Objekte zu Byte-Arrays serialisiert werden (siehe Codebeispiel 2.6). Dafür bietet es sich an, die Klasse java.io.dataoutputstream zu verwenden, die für alle primitiven Datentypen inkl. String eine Methode zum Schreiben in einen Ausgabestrom besitzt. Dahinter wird ein weiterer Ausgabestrom vom Typ ByteArrayOutputStream geschaltet, der die serialisierten Daten des DataOutputStreams erhält und eine Methode tobytearray() zur Verfügung stellt. Zu beachten gilt es dabei, dass String-Objekte, die den Wert null referenzieren, nicht serialisiert werden können. Statt dessen kann ein leerer String verwendet werden. Außerdem sollte der äußere Ausgabestrom nach der Benutzung mittels close() geschlossen werden. Analog dazu funktioniert die Deserialisierung aus dem RMS mit den Klassen ByteArrayInputStream und DataInput- Stream. Für das Suchen von Datensätzen bietet ein RecordStore(-Objekt) die Methode enumeraterecords(recordfilter a, RecordComparator b, boolean ke epupdated). Optional kann man spezifische Implementierungen von RecordFilter und RecordComparator übergeben, so dass die Enumeration auf Basis des Inhalts eines Records gefiltert und die Reihenfolge der Records innerhalb der Enumeration beeinflusst werden kann. Für den Fall, dass für die beiden ersten Parameter null übergeben wird, enthält die Enumeration alle Records des RecordStores und die Reihenfolge ist beliebig. Das Resultat von enumeraterecords() implementiert das Interface RecordEnumeration, über das man durch die Ergebnismenge der Records iterieren kann und deren Primärschlüssel oder den Inhalt abrufen kann. Der dritte Parameter keepupdated gibt an, ob die Datensatzrepräsentation sich mit ändern soll, falls am 32

47 Kapitel 2. Grundlagen 2.4. J2ME - Java 2 Platform Micro Edition private String s = "string"; 2 private boolean b = true; private int i = 42; 4 public byte[] serialize() throws IOException { 6 ByteArrayOutputStream bytestream = new ByteArrayOutputStream(); DataOutputStream datastream = new DataOutputStream(byteStream); 8 datastream.writeutf(s); 10 datastream.writeboolean(b); datastream.writeint(i); 12 datastream.close(); 14 return bytestream.tobytearray(); } Quellcode 2.6: Beispiel zur Serialisierung in einen Byte-Strom RecordStore Änderungen vorgenommen werden. Mit statischen Enumerationen können Probleme beim Iterieren auftreten, wenn gleichzeitig der RecordStore manipuliert wird. In diesem Fall bieten sich dynamische Enumerationen an, die jedoch auch mehr Systemressourcen benötigen ksoap Web-Service-Bibliothek Eine Möglichkeit, unter der J2ME- und der J2SE-Plattform Web Services zu konsumieren, bietet das im Sourcecode frei verfügbare Projekt ksoap 1. Dieser SOAP-Parser ist speziell für in der Hardware eingeschränkte Geräte gedacht und implementiert daher auch nicht die gesamte Spezifikation von SOAP. Für übliche Web Services ist der Umfang jedoch nach [Yua06] ausreichend. Zum Parsing von XML-basierten SOAP-Dokumenten kommt die kxml-bibliothek in der Version 2 zum Einsatz, die das XML-Pull API (xmlpull.org) implementiert. Mit diesem Parsing-Modell kann man durch die Elemente des XML-Dokuments seriell iterieren und benötigte Informationen abfragen, wie z.b. Inhalt des Elements und Attributwerte. Im Vergleich zum etablierten Parsing-Modell Simple API for XML (SAX) kann das Pull-Modell unter Umständen performanter arbeiten, da der Programmierer die Kontrolle über den Fluß des Parsings hat. Bei SAX wird das gesamte Dokument seriell bis zum Ende abgearbeitet und entsprechende benutzerdefinierte Handler-Methoden für die Elemente vom Parser werden aufgerufen. Das Document Object Model (DOM) ist für größere XML-Dokumente auf eingeschränkten Endgeräten ohnehin keine Alternative, da eine Repräsentation des gesamten Dokuments dabei im Speicher gehalten wird

48 2.4. J2ME - Java 2 Platform Micro Edition Kapitel 2. Grundlagen XML-Datentyp xsd:int xsd:long xsd:string xsd:boolean Java-Datentyp java.lang.integer java.lang.long java.lang.string java.lang.boolean Tabelle 2.1: ksoap Mappings für primitive Datentypen Für die in SOAP verwendeten Datentypen hat ksoap bereits für die in Tabelle 2.1 enthaltenen Typen eine standardmäßige Zuordnung zu Java-Datentypen. Alle weiteren primitiven Datentypen, d.h. Elemente ohne Unterelemente, kapselt ksoap in einem Objekt der Klasse SoapPrimitive. Diese enthält den Namen und Namensraum des Datenelements sowie dessen Wert in Form eines Strings. Komplexe Datentypen mit Unterelementen werden durch eine Instanz der Klasse Soap- Object repräsentiert, die analog Name und Namensraum des Elements als Attribut aufnimmt. Die Kind-Elemente werden in einem Vektor als Object gespeichert, gepaart mit einer Instanz von PropertyInfo, in der die XML-spezifischen Namensinformationen gehalten werden. Das referenzierte Object kann dabei je nach Kind- Element eine Instanz von SoapObject, SoapPrimitive oder einer anwendungsspezifischen Java-Klasse sein. Letzteres ist dann der Fall, wenn beim SOAP-Parser (SoapSerializationEnvelope) eine Klasse für die Deserialisierung der spezifischen Klasse registriert wurde. Eine solche Klasse kann das Interface Marshal implementieren und stellt somit je eine Methode für das Entpacken von XML-Elementen in ein spezifisches Java-Objekt und umgekehrt zur Verfügung. Als Synonym für (De)Serialisierung wird auch (Un)Marshaling verwendet. Eine Alternative zu dem Low- Level-Zugriff bietet das Interface KvmSerializable (siehe Abbildung 2.7). Ein Objekt, das diese Schnittstelle implementiert, kann durch den SOAP-Parser automatisiert sowohl serialisiert als auch deserialisiert werden. Für jedes Attribut des Objekts muss über die Methode getpropertyinfo eine beschreibende PropertyInfo-Instanz, die als Parameter übergeben wird, gefüllt werden. Darin wird der Name des zugehörigen XML-Elements des Attributs gespeichert, sowie der Java-Datentyp. Der Datentyp kann ein primitiver sein (siehe Tabelle 2.1) oder es wird auf eine weitere Klasse verwiesen, die KvmSerializable implementiert. Über die Methoden setproperty bzw. getproperty kann der SOAP-Parser das entsprechende Attribut, das aus dem XML-Dokument extrahiert wurde, setzen bzw. den Wert des Attributs erfragen und in das zugehörige XML-Element serialisieren. 34

49 Kapitel 2. Grundlagen 2.4. J2ME - Java 2 Platform Micro Edition 1 public interface KvmSerializable { Object getproperty(int index); 3 int getpropertycount(); void setproperty(int index, Object value); 5 void getpropertyinfo(int index, Hashtable properties, PropertyInfo info); } Quellcode 2.7: KvmSerializable-Schnittstelle von ksoap Optimierungen für mobile Anwendungen Die Entwicklung von Anwendungen für mobile Endgeräte bringt einige besondere Anforderungen mit sich. Die Fähigkeiten der Hardware sind stark begrenzt (vgl. MIDP in Abschnitt 2.4.1), und somit müssen CPU-Zeit und Speicher besonders effizient eingesetzt werden, was in [Yua06] Kapitel 7 näher erläutert wird. Um dies zu erreichen, sind die verwendeten Bibliotheken für mobile Anwendungen leichtgewichtiger als die J2SE- Alternativen, haben also sowohl eine geringere Größe als auch eine Anpassung an den geringen zur Laufzeit zur Verfügung stehenden Speicher. An dieser Stelle bietet sich noch die Möglichkeit, beim Packaging die Größe zu minimieren. Von der Anwendung nicht benötigte Klassen können aus den Bibliotheken entfernt werden. Dies übernimmt meist ein sogenannter Obfuscator, ursprünglich dafür gedacht, den Binärcode von Anwendungen zu verschleiern, um eine Decompilierung zu erschweren. Er läßt sich weiterhin dazu verwenden, den Binärcode durch Umbenennung von Klassen und Methoden noch zu verkleinern und Methodenaufrufe inline zur ersetzen. Um den Code aus Bibliotheken nicht in jede MIDlet-Suite hinzufügen zu müssen, gibt es bei BB-Geräten die Möglichkeit, shared libraries zu installieren, die von mehreren Anwendungen gleichzeitig benutzt werden. Mit der noch in Planung befindlichen Version 3 des MIDP (JSR 271) ist die Aufnahme von gemeinsamen Bibliotheken in den Standard geplant. Ein weiterer Ansatzpunkt für Performance-Optimierungen ist die Garbage Collection, die soweit wie möglich vermieden werden sollte, da sie kostbare CPU-Zeit in Anspruch nimmt. Empfohlene Möglichkeiten nach [Yua06] den Speicherverbrauch zu reduzieren sind: 1. Arrays gegenüber Collection Containern bevorzugen. 2. Bei String-Manipulationen eine StringBuffer-Instanz verwenden (Modifikationen von String-Objekten erzeugen neue Instanzen). 35

50 2.4. J2ME - Java 2 Platform Micro Edition Kapitel 2. Grundlagen 3. Ressourcen wie Netzwerkverbindungen, RecordStores und Filehandles frühestmöglich wieder freigeben. In Java lassen sich durch den Einsatz von finally- Blöcken Ressourcen auch nach Auftritt einer Exception freigeben. 4. Design Pattern sollten daraufhin überprüft werden, dass sie nicht zu viele Klassen und Schnittstellen-Schichten mit sich bringen. In [Yua06] wird als Beispiel eine schlankere Screen-basierte Logik statt einer klassischen Model View Controller (MVC)-Architektur bevorzugt. 5. Erzeugte Instanzen nach Möglichkeit wiederverwenden, anstatt neue zu erzeugen. Um Ein- und Ausgabe-Operationen zu beschleunigen, empfiehlt es sich, die vom Endgerät angesprochenen externen Netzwerkschnittstellen nach außen hin nicht zu feingranular zu gestalten, so dass insgesamt weniger Aufrufe dieser Schnittstellen notwendig sind. Desweiteren sollten diese Operationen gepuffert und nicht zeichenweise angesprochen werden. Bei den meisten J2ME-Schnittstellen bietet sich eine Kombination aus einem byte[]-puffer und einem ByteArrayOutputStream an (bzw. analog für einen Eingabestrom). Der Netzwerkverkehr und die Latenz für den Benutzer lassen sich reduzieren, indem J2ME-Anwendungen Anwendungsdaten lokal speichern. Dies ermöglicht zudem unter Umständen auch eine gewisse Funktionalität der Anwendung, wenn das Gerät keine Verbindung zu einem Netzwerk herstellen kann. Beim Zwischenspeichern der Daten ist zu beachten, dass dies möglichst zeitnah geschieht, um Datenverluste zu vermeiden, auch unter dem Gesichtspunkt, dass leistungsfähige Endgeräte noch unzureichende Betriebslaufzeiten im mobilen Einsatz haben. Eine benutzerfreundliche Anwendung sollte benutzerspezifische Einstellungen ebenfalls speichern, lange Operationen auf mehrere Dialoge aufteilen und Rückmeldungen über den Status geben. Ein weiterer Aspekt bei der Entwicklung einer Anwendung ist, dass sie auf möglichst vielen Endgeräten lauffähig sein sollte. Dabei hilft es, wenn sich die Applikation über einen JAD konfigurieren lässt und die Benutzerschnittstelle im Quellcode leicht angepasst werden kann. Für die Entwicklung von J2ME-Anwendungen auf den BB-Endgeräten hat RIM einen Programmier-Leitfaden in [RIM05] ab Seite 30 integriert, der weitere Java-Optimierungen auf Quellcode-Ebene liefert. 36

51 Kapitel 2. Grundlagen 2.4. J2ME - Java 2 Platform Micro Edition Sicherheitskonzept Über den JAD besteht seit MIDP 2.0 auch die Möglichkeit, MIDlet Suites mittels Public- Key-Verfahren zu signieren. Dazu wird eine Prüfsumme des JARs mit dem privaten Schlüssel signiert und zusammen mit dem zugehörigen öffentlichen Schlüsssel in Form eines Zertifikats in den JAD eingetragen. Bei Installation der MIDlet Suite wird die Prüfsumme des JARs gebildet, mittels Zertifikat die Prüfsumme im JAD entschlüsselt und mit der ermittelten verglichen. Das Zertifikat selbst muss immer von einer Certification Authority (CA) signiert sein. So ist sichergestellt, dass der Inhalt der sogenannten Trusted MIDlet Suite seit dem Zeitpunkt der Signierung nicht verändert wurde und einem bestimmten Softwarehersteller anhand des Zertifikats zugeordnet werden kann. Um die Integrität des Zertifikats zu überprüfen, sind in den Endgeräten üblicherweise die Zertifikate der Root-CAs hinterlegt. Daher muss der JAD eine Zertifikat-Kette bis hin zu einem Root-Zertifikat beinhalten. Im einfachsten Fall ist dies nur ein Zertifikat (das des Softwareherstellers), wenn es von einer Root-CA signiert ist. Eine MIDlet-Suite, die keine Signatur im JAD enthält, wird als Untrusted MIDlet Suite eingestuft und unterliegt dadurch Einschränkungen beim Zugriff auf die J2ME APIs. In diesem Fall muss der Nutzer explizit für Verbindungen über HTTP zustimmen. Alle weiteren Netzwerkfunktionalitäten im Package javax.microedition.io sind ausschließlich durch Trusted MIDlet Suites benutzbar. Anwendungen gemäß der MIDP 1.0 Spezifikation werden ebenfalls als untrusted eingestuft. An dieser Stelle sei noch erwähnt, dass Attribute im JAD gleichnamige im Manifest überschreiben, außer es handelt sich um eine Trusted MIDlet Suite. In diesem Fall wird die Installation abgebrochen, wenn sich die Werte der Attribute in JAD und Manifest unterscheiden. 37

52 2.4. J2ME - Java 2 Platform Micro Edition Kapitel 2. Grundlagen 38

53 Kapitel 3 Analyse In diesem Kapitel werden zunächst die Anforderungen an die gesamte Systemarchitektur und die zu entwickelnde mobile Client-Anwendung erläutert, die von nun an auch mobilecrm genannt wird. Dies geschieht durch die Rahmenbedingungen, die durch die Betreuung seitens der Firma CSC und der FH Wiebaden festgelegt wurden, sowie durch eine Beschreibung der Anwendungsfälle, die die Anwendung abdecken soll. Innerhalb dieses Rahmens werden darauffolgend die Möglichkeiten zur Realisierung untersucht, aufgegliedert in die einzelnen Systembestandteile Server, Mobile-Gateway und Client. 3.1 Anforderungen Rahmenbedingungen Die bei der Themenstellung gemachten Vorgaben beeinflussen Analyse und Design der Diplomarbeit. Sie begrenzen die möglichen Lösungansätze für die Realisierung und werden in diesem Abschnitt ausführlich beschrieben: 1. Nutzung der BlackBerry-Enterprise-Architektur Vorgegeben ist die Verwendung der BB-Infrastruktur (siehe Kapitel 2.1). Die für diese Arbeit wesentlichen Teile dieser mobilen Plattform sind der BES im Unternehmensnetzwerk und ein spezielles mobiles Endgerät, auf dem die mobile Anwendung läuft. Ein BB-Endgerät vom Typ 7100v ist vorhanden. Insbesondere soll auch die Push-Funktionalität eingesetzt werden, um Daten aus einem SAP-System über den BES an das mobile Endgerät zu übermitteln. 39

54 3.1. Anforderungen Kapitel 3. Analyse 2. Anbindung an SAP-CRM im Unternehmen Die BB-Anwendung soll mit einem SAP-CRM 4.0 System (siehe Kapitel 2.3.1) kommunizieren und dadurch prototypisch die Funktionalität zum Verwalten von Aktivitäten im CRM bieten. 3. Smart-Client-Anwendung Die mobile Anwendung soll ein sogenannter Smart Client sein. Im Gegensatz zu einer Browser-basierten Applikation benutzt der Smart Client die lokale Benutzerschnittstelle des BB-Endgeräts und macht von der Möglichkeit Gebrauch, Daten lokal zu speichern. 4. Einsatz von Web-Service-Technologien Die Kommunikation zwischen dem SAP-CRM und der mobilen Anwendung soll durch einen Web Service erfolgen. Die damit in Zusammenhang stehenden Technologien sind speziell für plattformübergreifende Anwendungen sehr gut geeignet und ein aktueller Technologie-Trend im Rahmen von SOA. 5. Generische Vorgehensweise Ein weiteres Ziel dieser Arbeit ist es, bei der Realisierung möglichst generisch vorzugehen, so dass bei der Entwicklung von weiteren mobilen Anwendungen auf Basis der SAP- und BB-Infrastruktur oder Web Services davon profitiert werden kann. Abbildung 3.1: Grobe Systemarchitektur Aus diesen Vorgaben resultieren zunächst die in Abbildung 3.1 vereinfacht dargestellten Komponenten, die für diese Arbeit relevant sind und untersucht werden. Diese Systemarchitektur wird in den Unterkapiteln ab 3.2 ff. detailliert betrachtet. Im Folgenden wird zuerst genauer definiert, welche Anforderungen die mobile Applikation aus Anwendersicht erfüllen soll. 40

55 Kapitel 3. Analyse 3.1. Anforderungen Abbildung 3.2: Server-initiierte Anwendungsfälle Anwendungsfälle In diesem Abschnitt werden die Anwendungsfälle definiert, die abstrakt beschreiben, welche Interaktionen zwischen dem Benutzer, mobilecrm und dem SAP-System stattfinden. Die Anwendungsfälle wurden in Server- und Client-initiiert unterschieden. In den Abbildungen 3.2 und 3.3 sind die sogenannten Use-Cases mit UML modelliert. Die Anwendungsfälle beziehen sich auf das Aktivitätsmanagement. Der Workflow sieht dabei so aus, dass Änderungen am SAP-CRM-System über eine Push-Nachricht an alle beteiligten Clients propagiert werden, und umgekehrt Änderungen auf dem Endgerät möglichst direkt zum SAP-CRM-System übertragen werden. Nach Anlegen einer Aktivität kann sie den Status open oder In Process annehmen, und wird durch den Status Completed oder auch Rejected abgeschlossen. Dabei kann der Erledigungsstatus noch prozentual hinterlegt werden. Im SAP-CRM-System selbst wird eine Aktivität nie gelöscht, sondern bleibt als Beleg erhalten Server-initiiert Aktivitätsänderung Sobald eine Aktivität im SAP-System neu angelegt oder modifiziert wird, muss an die Ansprechpartner auf Unternehmensseite ein Update auf das BB-Endgerät geschickt werden. Dazu muss für den Ansprechpartner in der Aktivität seine BlackBerry- -Adresse hinterlegt sein. Daten synchronisieren Nach einer Aktivitätsänderung werden die neuen Daten vom SAP-System über die Push-Funktion des BES an die zugehörigen BB-Endgeräte geschickt. Die mobile Anwendung auf dem Endgerät empfängt und speichert die Aktivität. 41

56 3.1. Anforderungen Kapitel 3. Analyse Abbildung 3.3: Client-initiierte Anwendungsfälle Client-initiiert In die Kategorie Client-initiiert fallen Aktionen, die der Benutzer in der mobilen Anwendung ausführen kann. Aktivitäten auflisten Alle auf dem BB-Endgerät lokal gespeicherten Aktivitäten werden aufgelistet, zur Auswahl für weitere Aktionen mit einer Aktivität. Aktivität anlegen Der Benutzer kann in der Anwendung eine neue Aktivität anlegen. Dafür werden die essentiellen Daten einer Aktivität eingegeben und gespeichert. Dabei wird nur ein Teil der Attribute unterstützt, die im SAP-System hinterlegt werden können. Aktivität modifizieren Ist eine Aktivität auf dem Endgerät bereits vorhanden, so können die Daten verän- 42

57 Kapitel 3. Analyse 3.1. Anforderungen dert und abgespeichert werden. Darunter fällt insbesondere auch das Ändern des Status der Aktivität. Aktivität löschen Eine Aktivität kann vom Anwender gelöscht werden. Dies bezieht sich allerdings nur auf die lokale Speicherung auf dem Endgerät, im SAP-System werden keine Datensätze gelöscht. Zum Abschließen der Aktivität wird lediglich der Status auf Completed gesetzt. Aktivität anzeigen Der Anwender kann eine gespeicherte Aktivität auswählen und sich die Daten anzeigen lassen. Eine Interaktion mit dem SAP-System findet dabei nicht statt. Es wird nur eine Auswahl der Attribute dargestellt, die im SAP-System hinterlegt werden können. Aktivitätenliste anfordern Alle Aktivitäten, die den Benutzer der mobilen Anwendung betreffen, werden Benutzer-initiiert auf das Endgerät geladen und abgespeichert. Somit lassen sich im SAP-System bereits vorhandene Aktivitäten anfordern. Daten synchronisieren Neue oder modifizierte Aktivitäten auf Client-Seite werden automatisch mit dem SAP-System abgeglichen. Für diesen Vorgang muss das Endgerät eine Verbindung zum BES haben. Ein Synchronisationsvorgang kann auch vom Benutzer initiiert werden. Dies ist beispielsweise sinnvoll, falls ein automatisierter Synchronisierungsvorgang zuvor fehlgeschlagen ist Problembereiche Die Analyse lässt sich in verschiedene Problembereiche aufteilen, welche jeweils verschiedene Komponenten der gesamten Systemarchitektur betreffen. Diese sind zur Einordnung im Folgenden kurz umrissen. Synchronisation Konsistenter Datenabgleich zwischen Client und Server bei konkurrierenden Zugriffen. Usability Benutzerfreundlichkeit und Internationalisierung. 43

58 3.2. Server Kapitel 3. Analyse Web Service Bereitstellung einer SAP-Schnittstelle durch einen serverseitigen Web Service und dessen Kommunikation mit dem Client. Dabei geht es um die Auswahl oder Programmierung einer Implementierung auf Server- und Client-Seite, sowie deren Kompatibilität. Die nachfolgenden Teile der Analyse sind anhand der einzelnen Systemkomponenten Server, Mobile Gateway und Mobile Client gegliedert. Die Betrachtung beginnt serverseitig, da das SAP-CRM-System den Informationsfluss, die Beschaffenheit und den Zusammenhang der Daten vorgibt. 3.2 Server SAP-CRM Die in den Anforderungen festgelegte Funktionalität der Anwendung in Bezug auf Aktivitäten kann durch Benutzen der BAPI- und RFC-Schnittstellen des mysap-crm- Moduls in der Version 4.0 abgedeckt werden. Die Modifikation von Aktivitäten - also ändern und neu anlegen - lässt sich über die Funktion CRMXIF_ORDER_SAVE durchführen. Eine Liste von mehreren benutzerspezifischen Aktivitäten kann durch BAPI- _ACTIVITYCRM_GETDETAILMULT abgefragt werden. Hierfür werden jedoch die eindeutigen IDs der Aktivitäten benötigt, die in einer vorhergehenden Abfrage ermittelt werden müssen. Dies lässt sich durch den Aufruf von CRM_MY_ACTIVITIES vereinfachen, der als Parameter den SAP-Benutzernamen erwartet und alle zugehörigen Aktivitäten zurück liefert Datenmodellierung Das graphische Frontend von SAP bietet für das Management von Aktivitäten den in Abbildung 2.7 bereits vorgestellten, umfangreichen Interaktionsdialog, der viele Verweise zu weiteren Dialogen enthält wie beispielsweise mehr Details zu den Kontaktpersonen. Diese Menge von Informationen ist für die Bearbeitung auf einem eingeschränkten mobilen Endgerät zu groß, um übersichtlich dargestellt werden zu können. In Tabelle 3.1 sind die auf dem BB-Endgerät verfügbar gemachten Attribute aufgelistet und anhand von 44

59 Kapitel 3. Analyse 3.2. Server Beispieldaten verdeutlicht. Zum Einen sind dabei Datenfelder enthalten, die das SAP- System verpflichtend als belegt voraussetzt. Weiterhin werden für die technische Umsetzung einige Attribute benötigt wie beispielsweise die eindeutige ID und die Version einer Aktivität. Zum Anderen wurden weitere Attribute abgebildet, die für das Szenario eines mobilen Einsatzes Sinn ergeben. Dies sind vor allem die Attribute, die den Status, die Vervollständigung in Prozent und den Zeitpunkt einer Aktivität definieren Web Service zum SAP-CRM-System Um Punkt 2 der Rahmenbedingungen in Abschnitt zu erfüllen, muss eine Schnittstelle in Form eines Web Service für das SAP-CRM-System geschaffen werden. Dafür bieten sich mehrere Alternativen: Eigene Web-Service-Implementierung innerhalb des Application-Server von SAP SAP-XI Middleware SAP-CRM Web-Service-Schnittstelle (CRM-spezifische Middleware) Middleware von Drittanbietern, die SAP-Adapter besitzt Das CRM-Modul verfügt erst ab der Version 5 über eine Web-Service-Schnittstelle. Eine mögliche Alternative bietet sich durch die NetWeaver-Komponente, auf der das CRM- Modul aufsetzt. Im Application Server Web AS 6.4 kann eine J2EE-Applikation ablaufen, die über RFC- und BAPI-Aufrufe das CRM ansprechen kann und diese Schnittstellen als Web Service zugänglich macht. NetWeaver stellt außerdem das XI-Modul (siehe Kapitel 2.3.2) zur Verfügung, das für den Datenaustausch zwischen SAP-Modulen und auch Fremdanwendungen via Web Services gedacht ist. Um Punkt 5 der Rahmenbedingungen (3.1.1) bestmöglichst zu erfüllen, sollte XI zur Realisierung näher betrachtet werden. Eine Implementierung auf Server-Seite entfällt dabei und erleichtert weitere mobile Anwendungen. Ein weiterer Vorteil ist die zentrale Konfiguration der zu integrierenden Systeme, die XI prinzipbedingt mit sich bringt. Neben XI gibt es auch weitere Middleware- Produkte von Drittanbietern wie IBM oder Oracle, die ebenfalls an SAP-Module angebunden werden können. Für die Umsetzung dieser Arbeit wurde XI verwendet, da entsprechende Softwarelizenzen und administrierte Systeme schon vorhanden sind. Innerhalb des Unternehmens kann bereits auf Erfahrung mit dem SAP-System zurückgegriffen werden. 45

60 3.2. Server Kapitel 3. Analyse Attribut-Bezeichnung Beispielwert activitypartnerid activitypartner Tobias Foo / Flensburg category 001 categorytext Sales Call priority 3 prioritytext High goal 005 goaltext Better cust. retent. directiontext Outbound direct 1 objecttype BUS validfrom validto fromtime 16:45:00 totime 16:55:00 contactpersonid contactperson Foo / Himmelbrug salesrepresentative employeeresponsible createdby AOPATZ changedon createdon systemstatusid I1002 systemstatustext Open Planned userstatusid E0001 userstatustext Open completion 000 transactiondescription Wichtiger Anruf, 50 mio projekt transactiontype ZMS0 transactionnumber objectguid urxewgmzdka41rkhmscggw== organizationalunit S distributionchannel 01 salesorganization O changedby Constant Tabelle 3.1: Übersicht der Attribute einer Aktivität in mobilecrm 46

61 Kapitel 3. Analyse 3.3. Mobile Gateway Durch die Benutzung von XI ergibt sich auch, welches der beiden in Abschnitt vorgestellten Push-Protokolle verwendet wird. Da die ausgehenden Nachrichten von XI XML-basiert sind, ist das PAP aus der WAP-Spezifikation nicht geeignet, da dieses die Nachricht als MIME-Multipart-Nachricht aufbaut. Das RIM-Push-Protokoll hingegen enthält alle für die Übertragung notwendigen Informationen im URI der Push-Anfrage an den BES oder in optionalen HTTP Headern. Im Gegensatz zu PAP kann die Payload dadurch XML-konform sein. 3.3 Mobile Gateway Die Verwendung der BlackBerry-Plattform ist Vorgabe nach Punkt 1 der Rahmenbedingungen in Abschnitt Daher werden an dieser Stelle keine alternativen Lösungen betrachtet, die analog zum BES als Mobile-Gateway für mobile Endgeräte eine sichere Verbindung zum Unternehmensnetzwerk herstellen können. Unternehmen wie beispielsweise Audi hatten im Jahr 2005 Bedenken gegenüber der Lösung geäußert, da durch die externe BlackBerry-Infrastruktur des Herstellers RIM (siehe Abbildung 2.1) prinzipiell die Möglichkeit der Industriespionage besteht. Gewissheit würde an dieser Stelle nur Einsicht in den Quellcode bringen, der von RIM allerdings nicht zur Verfügung gestellt wird. Die Sicherheitsfunktionen der BlackBerry-Architektur sind formal sehr umfangreich (siehe Abschnitt 2.1). Neben der Verschlüsselung des Datenverkehrs werden auch IT-Richtlinien unterstützt, und die auf dem Endgerät gespeicherten Daten können ebenso kodiert und drahtlos gelöscht werden. Ein Artikel zur Kritik an der BlackBerry-Nachrichten-Verschlüsselung ist nachzulesen bei [Sch05], der unter anderem zwei Sicherheitsstudien zusammenfasst und zu dem Schluß kommt, dass diese Architektur prinzipiell als sicher einzustufen ist, unter der Annahme, dass die Algorithmen korrekt implementiert sind und keine Hintertüren in der Software vorhanden sind. Der Quellcode des BES wurde im Rahmen einer der zuvor erwähnten Studien untersucht, offen zugänglich ist der Code jedoch nicht, so dass die Sicherheit dennoch Vertrauen in den Hersteller voraussetzt. In Hinblick auf die Performance des BES wurden vom Hersteller weitreichende Funktionen implementiert. Die einzelnen Komponenten des Systems können bei Bedarf jeweils auf einer eigenen Servermaschine verteilt betrieben werden, so dass die Performance skalierbar ist. Ebenso ist es möglich, mehrere Instanzen des BES bereit zu stellen, um eine große Anzahl von BB-Endgeräten damit arbeiten zu lassen. Durch das symmetrische Verschlüsselungsverfahren wird der Overhead so gering wie möglich gehalten und gleichzei- 47

62 3.4. Mobile Client Kapitel 3. Analyse tig die Payload durch die Dispatcher-Komponente des BES komprimiert. Dies ist vor allem für GPRS-basierte Endgeräte entscheidend, da die Bandbreite dort sehr eingeschränkt ist. Für die Realisierung wird der BES für MS Exchange in der aktuellen Version 4.1 in Kombination mit Windows 2003 Server verwendet. Die Wahl des -Systems (IBM Lotus Domino und Novell GroupWise sind die Alternativen) ist dabei nicht von Bedeutung, da es nur für den BES selbst benötigt wird und die mobile Anwendung keine - Funktionen benutzt. Der BES kann nur auf den Server-Betriebssystemen Windows 2000 Server und Windows 2003 Server von Microsoft betrieben werden. Als Lizenz für den BES wird eine kostenlose Trial-Version von RIM benutzt, deren Einschränkung darin besteht, dass nur ein Endgerät damit betrieben werden kann, was für diese Untersuchung jedoch auch ausreichend ist. 3.4 Mobile Client Die zu realisierende mobile Anwendung für das BB-Endgerät soll gemäß den Rahmenbedingungen über einen Web Service Funktionalitäten des SAP-CRM zur Verfügung stellen. SAP bietet eine Gesamtlösung für den mobilen Zugriff auf CRM-Systeme, die sogenannte SAP Mobile Infrastructure (MI). MI bietet für PDAs und Laptops eine J2SE-basierte Anwendung, die Logik, lokales Zwischenspeichern und Arbeiten im Offline-Modus unterstützt. Für eingeschränkte mobile Endgeräte ist nur eine Browser-basierte Lösung vorgesehen, die diese Funktionen nicht unterstützt. Die MI kann daher nicht als gleichwertige Alternative zu dem in dieser Arbeit entwickelten mobilecrm gesehen werden. Die Kommunikation des BB-Endgeräts mit dem BES (siehe Abschnitt 2.1.1) funktioniert auf zwei möglichen Wegen. Serverseitig im Unternehmen initiierte Verbindungen werden als Push-Nachricht über den BES an das Endgerät gesendet, der dabei als Proxy fungiert, und Nachrichten für Endgeräte im Offline-Modus zwischenspeichert. Client-initiierte Verbindungen werden über das MDS-Modul des BES aufgebaut, das ebenfalls eine Proxyfunktion übernimmt. Für die Implementierung der mobilen Anwendung bieten sich folgende Möglichkeiten: BB-MDS-Studio J2ME mit der API in MIDP und CLDC J2ME unter teilweiser Nutzung der propietären API von RIM 48

63 Kapitel 3. Analyse 3.4. Mobile Client Anwendungen für aktuelle BB-Endgeräte werden prinzipiell in J2ME (siehe Abschnitt 2.4) und ggf. herstellerspezifischen Erweiterungen programmiert. RIM bietet zusätzlich mit dem MDS-Studio (vgl. Abschnitt 2.1.2) eine Möglichkeit, auf Web Services basierende Anwendungen IDE-gestützt sehr schnell entwickeln zu können. Diese Lösung bietet jedoch keinen Zugriff auf die Java-API des Endgeräts. Dadurch ist keine lokale Speicherung von Daten möglich, und das Arbeiten im Offline-Modus (Rahmenbedingungen Punkt 3) wäre folglich nicht möglich. Ebenso ist eine Übertragung von Aktivitätsdaten in das PIM somit von vornherein ausgeschlossen. Mit MDS-Studio erstellte Programme werden in einem proprietären XML-Format gespeichert, und von der MDS-Runtime im Endgerät in Java-Aufrufe umgesetzt. Daher sind an dieser Stelle keine Erweiterungen möglich. Eine alternative Lösungsmöglichkeit besteht in einer J2ME-Anwendung, die zudem auch kompatibel zu anderen Endgeräten ist. Diese Kompatibilität käme allerdings erst zum Tragen, wenn die Anwendung auf eine andere mobile Plattform portiert werden sollte. Weiterhin sieht diese Möglichkeit für die Benutzerschnittstelle die abstrakte API des graphischen Framework LCDUI (siehe Abschnitt ) innerhalb J2ME vor. Der Vorteil von LCDUI liegt darin, dass die GUI sich leicht auf andere Endgeräte portieren läßt. Dabei ist das Erscheinungsbild der graphischen Komponenten, Bedienelemente und Menüs automatisch an das Endgerät angepasst, und der Anwender findet sich durch die gewohnte Gestaltung so leichter zurecht. Erreicht wird dies durch angepasste Implementierungen der LCDUI API durch die Hersteller der Endgeräte. Die Kommunikation mit dem Web Service muss in J2ME jedoch selbst implementiert bzw. an eine Bibliothek delegiert werden, während MDS-Studio dies kapselt. Statt die API von MIDP für Benutzerschnittstelle und Netzwerk-Kommunikation zu verwenden, kann auch die proprietäre API des Herstellers RIM verwendet werden. Die zuvor erwähnten Vorteile entfallen dabei. Um Zugriff auf die API zu erlangen, muss die Anwendung mit kostenpflichtigen Schlüsseln von RIM signiert werden. Als Rahmenumgebung für die Implementierung von mobilecrm kommt daher J2ME mit den APIs von MIDP und CLDC zum Einsatz Kommunikation mit dem Web Service Ein wesentliches Merkmal der mobilen Anwendung ist, dass der Datenaustausch mit dem SAP-CRM-System über einen Web Service stattfinden soll. In diesem Abschnitt geht es um die Auswahl entsprechender Protokolle und deren Implementierungen, die für den 49

64 3.4. Mobile Client Kapitel 3. Analyse Web Service eingesetzt werden sollen. Als Protokoll kommen die folgenden beiden Möglichkeiten in Betracht: SOAP REST-basierter Web Service mit XML-Payload gemäß URI-spezifischer XML- Schemata. Für das SOAP-Parsing gibt es im J2ME-Umfeld mehrere Alternativen: ksoap Bibliothek (Open Source) Referenz-Implementierung (RI) des JSR 172 von Sun (Open Source) Wingfoot SOAP-Client (Closed Source) Eine mögliche Protokollkombination wurde mit SOAP und WSDL bereits in Abschnitt 2.2 beschrieben, ebenso wie ein SOAP-Parser für J2ME mit ksoap in In den nächsten beiden Abschnitten wird zunächst mit der JSR 172 eine weitere SOAP-Parser- API vorgestellt, sowie durch REST eine Alternative zum SOAP-Protokoll. Darauf folgen minimale Testanwendungen für die SOAP-Bibliotheken und die Push-Funktion, bevor es abschließend zu einer Auswertung und Abwägung kommt JSR Web-Service-API für J2ME Mit dem JSR 172 wurde im März 2004 innerhalb des JCP die endgültige Version einer Web-Service-API für Endgeräte mit CLDC oder CDC festgelegt (für die Spezifikation siehe [EY03]). Sun stellt eine Referenz-Implementierung 1 für diese API im Sourcecode frei zur Verfügung. Eine Übersicht bietet Kapitel 17 in [Yua06]. Hersteller von Endgeräten können eine Implementierung dieser API als optionales Paket zur Verfügung stellen - neuere Mobilfunkgeräte bieten diese Option mittlerweile, die BB-Modelle von RIM jedoch nicht. Die API baut auf Untermengen der Java API for XML Processing (JAXP) v1.2 und der Java API for XML-based RPC (JAX-RPC) v1.0 auf, die bereits für die J2SE existieren. Die JAXP wurde auf einen SAX-Parser reduziert. Primitive Datentypen innerhalb von SOAP werden analog zu ksoap in entsprechende Datentypen in Java umgewandelt. Für komplexe Typen werden JavaBeans mit Getund Set-Methoden erzeugt. Im Unterschied zu ksoap bietet JSR 172 keine Möglichkeit, komplexe SOAP-Datentypen mit eigenen Java-Klassen zu assoziieren

65 Kapitel 3. Analyse 3.4. Mobile Client Abbildung 3.4: Zusammenhang der Komponenten von JSR 172 Sowohl das XML-Parsing als auch die entfernten SOAP-Aufrufe werden durch die Schnittstelle des JSR 172 vollständig gekapselt. Eine Übersicht der einzelnen Komponenten und der Kommunikation zwischen ihnen kann der Abbildung 3.4 entnommen werden. Die Aufrufe erfolgen über einen sogenannten Stub, in dem die Operationen des anzusprechenden Web Service als lokale Methoden repräsentiert werden. Der Stub wird mit Hilfe eines Stub-Generators erzeugt, der die zugehörige WSDL-Beschreibung des Web Service benötigt. Dies vereinfacht und beschleunigt die Anwendungsentwicklung stark, und stellt durch die automatisierte Verarbeitung der Web-Service-Beschreibung einen deutlich weniger fehleranfälligen Ansatz dar. Jedoch ist im Gegensatz zu ksoap bei der JSR 172 API auch kein Zugriff auf die XML-Struktur der SOAP-Nachrichten vorgesehen. Der Stub ist Teil der Client-Anwendung und kommuniziert über das Service Provider Interface (SPI) mit der Implementierung des JSR 172. Durch diese Interface-Zwischenschicht ist es möglich, die Anwendung inkl. der generierten Stubs beizubehalten, wenn man die Implementierung wechselt, z.b. die Anwendung auf einem Endgerät eines anderen Herstellers installiert. Ebenso bietet sich dadurch die Möglichkeit, zwischen dem Client und dem Web Service ein Gateway zu integrieren, das das SOAP-Parsing übernimmt. Das Protokoll zwischen Gateway und der Implementierung des JSR 172 könnte dadurch ein optimiertes Binärprotokoll sein, das für die Client- Anwendung jedoch transparent wäre REST-Web-Services Der REpresentational State Transfer (REST, siehe [Bay02]) ist eine Architektur, die im WWW schon lange eingesetzt wird. In einem Netzwerk aus Clients und Servern stellen die Server über das HTTP-Protokoll Ressourcen bereit, die durch einen URI eindeutig 51

66 3.4. Mobile Client Kapitel 3. Analyse identifiziert werden und eine bestimmte Repräsentation haben, z.b. HTML oder XML. Die Ressourcen können untereinander verknüpft sein. Indem der Client der Verknüpfung folgt, erhält er von dem Server die Repräsentation der angefragten Ressource - der Zustand des Clients ändert sich damit Voranalysen Push-Test Die Push-Funktionalität ist ein Teil von Punkt 1 der Rahmenbedingungen (Abschnitt 3.1.1). Um die korrekte Konfiguration des BES und die Funktionsweise der Push-Registry (siehe Abschnitt ) auf dem Endgerät zu testen, wurde eine minimale Anwendung implementiert. Code-Beispiele aus dem Developer-Guide von RIM, Kapitel Creating client/server push applications (siehe [RIM05]), konnten dabei teilweise übernommen werden. Die Testanwendung besteht aus einem Server- Teil, der mittels einer HTTP POST Anfrage an den BES Push-Port Daten sendet, und einem Client-Teil, der bei eingehenden Daten gestartet wird. MIDlet-1: PushTestMIDlet,,com.csc.aopatz.bb.test.PushTestMIDlet 2 MIDlet-Jar-URL: PushTestClient.jar MIDlet-Name: PushTestClient Midlet Suite 4 MIDlet-Permissions: javax.microedition.io.pushregistry, javax.microedition.io.connector.socket, 6 javax.microedition.io.connector.serversocket MIDlet-Push-1: 8 com.csc.aopatz.bb.test.pushtestmidlet, * MIDlet-Vendor: CSC 10 MIDlet-Version: MicroEdition-Configuration: CLDC MicroEdition-Profile: MIDP-2.0 Quellcode 3.1: JAD der Push-Test-Anwendung Für die Benutzung der PushRegistry und die Kommunikation über die aufgebaute Verbindung muss die Client-Anwendung (PushTestClient) entsprechende Berechtigungen für die Klassen besitzen. Dies geschieht über den JAD, der in Abbildung 3.1 dargestellt ist. Außerdem muss bei der Installation des MIDlets auf dem Endgerät der Port reserviert werden, auf dem die PushRegistry eingehende Verbindungen für die Anwendung entgegen nehmen soll. Dazu bedarf es ebenfalls eines Eintrags im JAD - in diesem Fall wurde Port 7777 gewählt. Für Push-Verbindungen schreibt die MIDP-Spezifikation nicht vor, welche Protokolle unterstützt werden müssen. Während das WTK 2.5 von Sun als Protokoll socket:// erwartet, muss für BB- 52

67 Kapitel 3. Analyse 3.4. Mobile Client Endgeräte verwendet werden. Nachdem die Applikation von der Push- Registry gestartet wurde, werden die eingehenden Daten gelesen und auf dem Display in einer Textbox angezeigt. Der Server (PushTestServer) sendet eine aufgezeichnete SOAP-Nachricht inkl. HTTP Headern durch das RIM-Push-Protokoll an den BES, wobei die - Adresse und der Port des Endgeräts bzw. der Client-Anwendung spezifiziert werden. Nachdem der Client von der PushRegistry gestartet wurde, öffnet er die eingehende Push-Verbindung und liest die einkommenden Daten. Diese werden in einer graphischen Komponente als Text angezeigt. Test von JSR 172 mit XI Web Service Die mobilen Endgeräte von RIM stellen zur Zeit keine Implementierung der Web- Service-API des JSR 172 zur Verfügung. Daher wurde die Referenz-Implementierung (RI) von Sun verwendet. Durch die Testanwendung soll geklärt werden, ob das WSDL-Dokument des SAP-Web-Service mit dem Stub-Generator aus dem WTK kompatibel ist und ob das Parsing der SOAP-Nachrichten mit der RI funktioniert. Weiterhin muss abgeschätzt werden, inwiefern die RI modifiziert werden muss, um eine Nachricht über eine Push-Verbindung entgegenzunehmen. Die Testanwendung (sapjsr172test) besteht aus den Packages der Referenz-Implementierung, die mit dem Präfix csc versehen wurden, um Namenskonflikte zu vermeiden, und dem dem Java-Package com.csc.sap_jsr172_test. Der SAP- Web-Service ist zunächst so konfiguriert, dass er eine Aktivität per Request entgegen nimmt und dann über den BES an das entsprechende BB-Endgerät übermittelt. Anhand der WSDL-Beschreibung können die Stubs problemlos generiert werden, Voraussetzung ist allerdings, dass primitive Datentypen verwendet werden. So muss beispielsweise der Zeitstempel einer Aktivität vom Typ xsd:date als xsd:string übermittelt werden. Aus dem Stub wird nur der Code benötigt, der für das Mapping zwischen XML-Elementen mit entsprechenden Datentypen auf der einen Seite und den Attributen einer Java-Bean auf der anderen Seite zuständig ist. Das Mapping wird zusammen mit dem InputStream einer eingehenden Push- Verbindung an eine Instanz der Klasse SOAPDecoder übergeben, die Bestandteil der RI ist und nicht der API des JSR 172. Das Parsing der SOAP-Nachricht schlägt jedoch fehl. Dieses Resultat ist auch mit dem Beispiel-Web-Service Version des Apache Axis2 Frameworks und unmodifiziertem Client-Stub zu beobachten. 53

68 3.4. Mobile Client Kapitel 3. Analyse Evaluierung Neben den folgenden Entscheidungen bezüglich der Kommunikation von mobilecrm dienen die Tests auch zur Verifizierung des Systemaufbaus. Dazu zählt hauptsächlich die Installation und Konfiguration des BES und die Aktivierung des BB-Endgeräts. Durch den Push-Test wurde zusätzlich noch das Deployment einer Anwendung auf dem Endgerät, die Benutzung der Push-Registry mit JAD und die Kommunikation zwischen BES und dem Endgerät getestet. Web-Service-Protokoll: REST oder SOAP Auf SOAP basierende Web Services nutzen das REST-Prinzip nicht. Die Ressourcen und Operationen werden im Rumpf der SOAP-Nachricht statt über den URI spezifiziert. Alle Nachrichten richten sich an einen URI des Service. Dies hat zur Folge, dass ein Proxy für SOAP-Nachrichten nur schwer implementiert und gewartet werden kann. Somit entfallen Zugriffsbeschränkungen und Caching durch einen Proxy. Zudem können auf SOAP basierende Web Services frei Operationen definieren, während Web Services nach dem REST-Prinzip nur die generischen HTTP-Methoden zur Verfügung stellen. Ein weiterer Unterschied ist, dass bei auf REST basierenden Web Services jede Ressource für ihre Repräsentation innerhalb von HTTP ein spezifisches Protokoll nutzen kann. Bei einer REST-basierten Web- Service-Implementierung entfällt der Overhead von SOAP. Die HTTP-Payload enthält nur die zu übertragenden Daten in Form von XML, beispielsweise gemäß einer XSD. Die mobile Anwendung muss die Verarbeitung der XML-Daten jedoch vollständig selbst implementieren. Die RI des JSR 172 vereinfacht die Entwicklung an dieser Stelle, da ein Stub-Generator diese Arbeit erledigt. Für ksoap ist kein Stub- Generator verfügbar, und der Aufwand ist ähnlich wie bei einer REST-basierten Implementierung. Für beide Varianten ist es jedoch möglich, einen Stub-Generator zu implementieren. In der neuen Version 2.0 der WSDL-Spezifikation wird auch die Beschreibung von REST-basierten Web Services möglich. Prinzipiell hat sich SOAP in Kombination mit WSDL jedoch zur Integration von Softwaresystemen weit verbreitet und lässt sich mit SAP-XI leichter für den Zugriff auf das SAP- CRM-System nutzen, als einen REST-basierten Web Service zu implementieren. Aus diesem Grund wird die Realisierung mit SOAP-Kommunikation durch SAP- XI vollzogen. SOAP-Bibliothek: ksoap oder JSR 172 Die RI des JSR 172 erfüllt Punkt 5 der Rahmenbedingungen am Besten, da für das 54

69 Kapitel 3. Analyse 3.4. Mobile Client Type-Mapping größtenteils auf einen Stub-Generator zurückgegriffen werden kann. Durch die Voranalyse hat sich jedoch ergeben, dass die Test-Anwendung mit der RI des JSR 172 in Kombination mit dem SAP-XI Web Service nicht funktioniert und die RI noch instabil ist. Eine weitere SOAP-Implementierung für mobile Endgeräte ist der Wingfoot- SOAP-Client 1. Der Hersteller bietet die Bibliothek jedoch nur in binärer Form an, wodurch Anpassungen für eine eingehende Push-Verbindung nicht möglich sind und man für Erweiterungen, Bugfixes und Support auf den Hersteller angewiesen ist. Für die Implementierung von mobilecrm kommt Wingfoot deshalb nicht in Betracht. Folglich wird mobilecrm mit der ksoap-bibliothek implementiert, mit der bei Kompatibilitätsproblemen auch auf XML-Ebene gearbeitet werden kann, statt Mappings zu verwenden. Für den Empfang einer Push-Nachricht mit ksoap muss zunächst der entsprechende Codeabschnitt für die eingehende Verbindung aus der Methode call ausgegliedert werden. Daher wurde die Methode receive(input- Stream istream, SoapEnvelope envelope) der öffentlichen Schnittstelle der Klasse HttpTransport hinzugefügt. Im Gegensatz zum Stub-Generator für die API des JSR 172 existiert für ksoap kein frei verfügbarer Stub- Generator, so dass die Zuordnungen zwischen XML-Elementen und Java-Datentypen manuell programmiert werden müssen Synchronisation und Offline-Modus Ein wichtiges Merkmal von mobilecrm ist die Realisierung als Smart Client: die Aktivitäten sollen lokal auf dem Endgerät gespeichert und auch neue Aktivitäten ohne Funknetz- Verbindung angelegt werden können. Für diesen Offline-Modus wird zum lokalen Zwischenspeichern das RMS verwendet, das in Abschnitt vorgestellt wurde und Bestandteil von J2ME ist. Eine andere Option zur Umsetzung der Zwischenspeicherung auf BB-Endgeräten gibt es nicht. Jedoch gibt es Produkte diverser Hersteller, die auf dem RMS aufsetzend eine beschränkte relationale Datenbank realisieren, was jedoch im Rahmen von mobilecrm nicht notwendig ist und nur Overhead wäre. Sobald Daten aus dem SAP-CRM auf dem Endgerät modifiziert werden, können bei der Synchronisation zwischen SAP und mobilecrm Probleme bei der Datenkonsistenz auftreten. Dies ist dann der Fall, wenn zwei oder mehr Benutzer eine bestimmte Aktivität be

70 3.4. Mobile Client Kapitel 3. Analyse Abbildung 3.5: Beispiel für ein Lost-Update bei der Synchronisation arbeiten. Die Synchronisationsprobleme werden in der Datenbanktheorie mit Dirty Read, Inconsistent Read und Lost Update bezeichnet. Die Anomalien eines Inconsistent Read und eines Dirty Read sind dadurch ausgeschlossen, dass die RFC- oder BAPI-basierte Kommunikation mit dem SAP-CRM-System transaktionssicher ist. Ein Lost Update kann durch das SAP-CRM-System nicht verhindert werden. Ein Fallbeispiel für ein solches Problem folgt und ist in Abbildung 3.5 visualisiert: Der Benutzer ändert eine Aktivität A in mobilecrm, die Änderung wird lokal gespeichert, aber es ist kein Funknetz verfügbar. Zwischenzeitlich nimmt die Sekretärin im Unternehmen von einem Kunden einen Anruf entgegen, der eine Änderung in Aktivität A zur Folge hat, beispielsweise eine Terminänderung. Die modifizierte Aktivität wird durch die direkt an das SAP- System angebundene SAP-GUI im CRM abgespeichert und eine Push-Nachricht an den BES gesendet, die dort vorgehalten wird, bis der mobile Nutzer erreichbar ist. Das mobile Endgerät hat wieder Netzempfang und erhält die Push-Nachricht. Dabei werden die lokalen Änderungen überschrieben, falls keine speziellen Vorkehrungen in der Anwendungslogik getroffen werden. Eine weitere Möglichkeit (nicht in Abbildung enthalten) wäre, dass aufgrund von Race Conditions der mobile Nutzer seine Änderung an das SAP-System überträgt, bevor die Push-Nachricht, die durch die Änderung der Sekretärin ausgelöst wird, ihn erreicht. In diesem Fall wäre die getätigte Änderung der Sekretärin im SAP-System überschrieben. 56

71 Kapitel 3. Analyse 3.4. Mobile Client Zur Verhinderung solcher Probleme gibt es verschiedene sogenannte Replikationsstrategien (siehe [Rah05]). Unter Replikation versteht man die Vervielfältigung von Daten. Im konkreten Fall bezeichnet man die Daten im SAP-CRM-System als Primärdaten, und die Kopien auf den BB-Endgeräten als replizierte Daten. Bei den Strategien unterscheidet man zwischen Verfahren, die eine strenge Konsistenz garantieren (synchrone Änderungen), und solchen, die nur eine schwache Konsistenz erreichen (asynchrone Änderungen). Für eine strenge Konsistenz, die eine Transparenz der Replikation gewährleistet, ist eine Serialisierung der Änderungen an Daten notwendig. Dies wird in den gängigen Verfahren durch Schreibsperren auf allen oder der Mehrheit der Kopien gelöst. Durch den Offline- Modus von mobilecrm ist es möglich, dass parallele Änderungen auf einem Datensatz stattfinden, ebenso wie nicht immer alle Replikate konsistent sind. Daher ist eine strenge Konsistenz nicht realisierbar. Für mobile Anwendungen eignet sich eine sogenannte Merge-Replikation. Dabei ist die Konsistenz der einzelnen Kopien nicht sichergestellt, und es kann beim Synchronisieren zu Konflikten kommen, die dann automatisiert oder ggf. manuell aufgelöst werden müssen. Um solche Konsistenzprobleme sicher zu erkennen, müssen in dem Fall die Datensätze versioniert werden, um unterschiedliche Datenstände identifizieren zu können. Eine sichere Vermeidung von Lost Updates ist nur durch eine Transaktion möglich, so dass die Versionsüberprüfung und das Schreiben des Datensatzes atomar durchgeführt werden können. Zur Unterscheidung der Datenstände kann bei den Datensätzen im SAP-CRM- System das Attribut DocumentNumber herangezogen werden, das bei jeder Transaktion mit der Aktivität automatisch inkrementiert wird. Für die Umsetzung von mobilecrm werden die folgenden zwei Möglichkeiten zur Synchronisation untersucht: 1. Transaktionslogik zwischen Web Service und SAP-CRM-System (Abbildung 3.6). 2. Keine Transaktionslogik, Lost Updates können auftreten (Abbildung 3.8). Die Möglichkeit, Transaktionen über den Web Service anzubieten, wird nicht näher betrachtet, da die Realisierung aufwendiger ist und die Dauer einer einzelnen Transaktion dadurch länger wird. Im schlimmsten Fall müsste eine Transaktion dabei durch einen Timeout abgebrochen werden, falls das BB-Endgerät die Funkverbindung verliert. Der Ablauf von Synchronisationslösung 1 ist in Abbildung 3.6 dargestellt, der BES wurde hierbei zur besseren Übersicht nicht dargestellt. Eine lokal als modifiziert markierte Aktivität wird dabei an den Web Service im SAP-XI gesendet. In einer dort implementierten Transaktionslogik wird innerhalb einer Transaktion mit dem SAP-CRM-System 57

72 3.4. Mobile Client Kapitel 3. Analyse Abbildung 3.6: Synchronisationslösung 1 für Client-initiiertes Aktivitätsupdate 58

73 Kapitel 3. Analyse 3.4. Mobile Client Abbildung 3.7: Push-Update, Bestandteil der Synchronisationslösungen 1 und 2 überprüft, ob sich die DocumentNumber im CRM-System geändert hat im Vergleich zu der Aktivität, die abgespeichert werden soll. Falls die Version gleich geblieben ist, kann die Aktivität ins CRM geschrieben werden, und die Transaktion abgeschlossen werden. Anderenfalls wird die Transaktion abgebrochen, und mobilecrm erhält vom Web Service eine Fehlermeldung. Seitens dem SAP-CRM-System wird nach einer Aktivitätsänderung eine Push-Nachricht im SAP-XI veranlasst (siehe Abbildung 3.7), die alle Benutzer von mobilecrm erhalten, die eine Rolle in der modifizierten Aktivität einnehmen. Wenn die Push-Nachricht eintrifft, muss die Aktivität auf dem Endgerät überschreibbar sein. Deshalb wird die Markierung vor dem Update bereits auf unmodifiziert gesetzt, so dass Race Conditions nicht zu einem Fehlschlagen der Push-Nachricht führen können. Bei einem Push-Update auftretende Versionskonflikte können auf dem Endgerät sicher erkannt werden. Nachdem ein Konflikt festgestellt wurde, muss geprüft werden, ob er sich lösen lässt. Betreffen die Änderungen in beiden Datensätzen nicht die gleichen Attribute, können die zwei Datenversionen möglicherweise automatisiert zusammengeführt werden. Bedingung ist jedoch, dass die geänderten Attribute nicht in einer Abhängigkeit zueinander stehen. Weiterhin muss für eine Zusammenführung auch der unmodifizierte Datensatz auf dem Endgerät vorhanden sein, um die Änderungen in lokalem und SAP-Datensatz erkennen zu können. Betreffen die Änderungen gleiche Attribute, ist ein Zusammenführen (oder auch Merging im Englischen) ohne manuellen Eingriff des Benutzers nicht möglich. Die Funktionalität des automatischen Mergens ist auch als Teil der 59

74 3.4. Mobile Client Kapitel 3. Analyse Abbildung 3.8: Synchronisationslösung 2 für Client-initiiertes Aktivitätsupdate Transaktionslogik im SAP-XI denkbar, so dass kein Fehler an das Endgerät zurückgegeben werden muss und der Vorgang dadurch schneller durchgeführt werden kann. Die Realisierung eines Merge-Vorgangs ist nicht Bestandteil des Prototyps mobilecrm. Der besondere Fall eines Lost-Updates auf Client-Seite kann auftreten, wenn der Benutzer eine Aktivität lokal bearbeitet, während für dieselbe Aktivität ein Push-Update eingeht. Ohne Vorkehrungen kann der Benutzer die neue Version der Aktivität mit der vorherigen überschreiben. Die zweite Synchronisationslösung verwendet keine Transaktionslogik, und daher sind Lost-Updates in diesem Szenario prinzipiell möglich. Der Fokus dieser Arbeit liegt nicht bei der Transaktionssicherheit auf SAP-Seite, weshalb für den Prototyp mobilecrm dieses optimistische Verfahren ausreichend ist. Solange das Endgerät keine Push-Nachricht vom SAP-System erhält, wird davon ausgegangen, dass die lokale Version der Aktivität noch die aktuelle ist. Die modifizierte Aktivität wird ohne weitere Vorkehrungen direkt an den Web Service gesendet und SAP-XI kann eine entsprechende Anfrage an das CRM- System stellen. Nach dem Abspeichern löst das CRM-System Push-Updates für alle an der Aktivität beteiligten BB-Benutzer aus (siehe Abbildung 3.7). Währenddessen erhält der Benutzer, der das Update durchgeführt hat, eine Rückmeldung vom Web Service und markiert die Aktivität lokal als unmodifiziert. Ein Lost-Update kann auftreten, falls ein anderer Benutzer ein Update mit der gleichen Aktivität durchführt, bevor er das Push- Update erhält, und zu einem Merge-Vorgang aufgefordert wird. Neben einer verzögerten Auslieferung einer Push-Nachricht kann dies auch durch eine verloren gegangene Push- Nachricht hervorgerufen werden. Das Zeitfenster, in dem ein Lost-Update auftreten kann, 60

75 Kapitel 3. Analyse 3.4. Mobile Client Abbildung 3.9: Mögliches Lost-Update in Synchronisationslösung 2 beginnt also mit dem Update-Vorgang eines Benutzers und endet, wenn alle mit der Aktivität assoziierten BB-Benutzer die entsprechende Push-Nachricht erhalten haben. Dies ist in Abbildung 3.9 veranschaulicht. Die SAP-XI und der BES als vermittelnde Systeme zwischen Client und SAP-CRM wurden der Einfachheit halber nicht dargestellt. Ein weiteres Problem ergibt sich speziell für den produktiven Einsatz. Die SAP-GUI öffnet Aktivitäten nur lesend, falls ein weiterer SAP-GUI-Client diese Aktivität bereits geöffnet hat. Um keine Konflikte hervorzurufen sollte die Implementierung der mobilen Anwendung auf die Funktionsweise der SAP-GUI abgestimmt sein. Hierfür ist jedoch Detailwissen zur SAP-GUI notwendig. Diese Problemstellung wird für den Entwurf des Prototyps nicht näher betrachtet Usability der mobilen Anwendung Für den erfolgreichen Einsatz einer Anwendung ist die Akzeptanz der End-Anwender ein wichtiger Aspekt. Die Schnittstelle von Mensch zu Maschine sollte möglichst intuitiv bedienbar sein, so dass der Benutzer die Anwendung als eine Hilfe empfindet und keinesfalls dadurch ineffizienter arbeitet. Insbesondere bei mobilen Applikationen stellt dies eine besondere Herausforderung dar, weil die Endgeräte nur eingeschränkte Ein- und Ausgabemöglichkeiten haben. Im Hinblick auf die zu realisierende Anwendung mobile- CRM ergeben sich dabei folgende Schwerpunkte: Internationalisierung Durch die gegebenen Anforderungen, dass die mobile Anwendung ein SAP-CRM- System durch die BlackBerry-Plattform nutzt, ergeben sich als Zielgruppe der Anwendung Mitarbeiter aus mittelständischen, großen oder global agierenden Unternehmen, da nur dort die entsprechende Infrastruktur vorhanden ist oder sich die 61

76 3.4. Mobile Client Kapitel 3. Analyse Investition in selbige lohnen würde. Daraus ergibt sich, dass mobilecrm oder darauf basierende Anwendungen international einsetzbar sein müssen. Internationalisierung (I18N) zur Bedienung der Anwendung muss eine Einstellung der Sprache umfassen. Speziell im Kontext von Geschäftsanwendungen müssen dabei auch landesspezifische Währungen und Maßeinheiten beachtet werden. Bedienbarkeit Die Bedienbarkeit - auch Usability genannt - ist entscheidend, wenn es um die Akzeptanz und effiziente Arbeitsweise der Benutzer mit der Anwendung geht. Es ist von vornherein zu vermeiden, dass End-Anwender aus Effizienzgründen auf Stift und Papier oder andere Anwendungen zurückgreifen. Dies sollte ebenfalls nicht aufgrund einer zu komplexen Bedienung der Anwendung passieren. Die Verantwortung liegt dabei nicht ausschließlich beim Entwickler, sondern Usability ist schon in der Spezifikation der Anforderungen und im Design zu berücksichtigen. Bei Anwendungen mit großem Funktionsumfang sind ein Benutzerhandbuch und Benutzerschulungen ebenso notwendig. Der Grundstein dafür wird bei mobilecrm bereits bei der Datenmodellierung in Abschnitt gelegt, um die Funktionen und die Komplexität der Anwendung an das mobile Endgerät anzupassen. Die durch die mobile Anwendung abzubildenden Funktionen sollen außerdem übersichtlich angeordnet sein. Hierzu kann das Untergliedern von Menüs in Kategorien mit Untermenüs hilfreich sein. Aufgrund des kleineren Displays kann es sinnvoll sein, Dialogfelder, wie beispielsweise das der SAP-GUI (siehe Abbildung 2.7), oder Vorgänge auf mehrere Dialoge zu verteilen. Im Gegensatz zu typischen Desktop-GUI- Anwendungen mit Menüleiste und personalisierbarer Werkzeugleiste ist die Benutzerschnittstelle von mobilen Endgeräten bereits kontext-sensitiv ausgelegt. Zu einer angezeigten graphischen Komponente werden spezifische Aktionen definiert, die damit durchgeführt werden können. Um die Komplexität der Anwendung aus Benutzersicht zu reduzieren, ist eine weitere Möglichkeit, dem Benutzer Arbeit abzunehmen. Dies wäre innerhalb von mobilecrm beispielsweise denkbar mittels Autovervollständigung und sinnvoller Vorbelegung in Eingabefeldern, oder indem die Liste der Aktivitäten nach bestimmten Kriterien sortiert und durchsucht werden kann. Performance Lange Ladezeiten, in denen der Benutzer auf die Anwendung warten muss, sind unbedingt zu vermeiden und beeinflussen die Akzeptanz der Applikation negativ. Infolge der Hardware-Einschränkungen von mobilen Endgeräten ist der Aspekt der 62

77 Kapitel 3. Analyse 3.4. Mobile Client Performance bei Design und Implementierung daher besonders wichtig. Durch die Nutzung eines Web Service kommt erschwerend die Latenz der GPRS-Verbindung und das Parsing von XML hinzu. Um die Leistung des Endgeräts möglichst effizient zu nutzen, werden die in Abschnitt zusammengestellten Optimierungsmöglichkeiten beachtet. Ein Performance-Vorteil ergibt sich bereits aus den Rahmenbedingungen Punkt 3, nach denen die Anwendung als Smart Client realisiert werden soll. Dadurch ist nicht für jede Operation der Anwendung eine Kommunikation mit dem SAP- System notwendig und die Latenz, die der Benutzer erfährt, deutlich geringer Logging und Unit-Tests Für die Rekonstruktion von Fehlern und Debugging kann Logging ein gutes Hilfsmittel sein. In der Java-Welt hat sich unter anderem die Open-Source-Bibliothek log4j etabliert, bei der verschiedene Ausgabeströme, -formatierungen und unterschiedliche Log-Level unterstützt werden. Mit Microlog 1 gibt es eine log4j-ähnliche Implementierung für den Einsatz im J2ME-Umfeld, da log4j selbst nur mit J2SE lauffähig ist. Zusätzlich bietet Microlog noch einen Adapter für das RMS und ein entsprechendes MIDlet zum Auslesen, so dass ein Logging-Ausgabestrom auch so konfiguriert werden kann, dass er im RMS gespeichert wird. Dies ist für mobile Endgeräte sinnvoll, die nicht über eine Konsole im Sinne einer Standard-Ausgabe verfügen. Das weit verbreitete junit Test-Framework ist innerhalb von J2ME nicht verwendbar, so dass auf J2MEUnit 2 zurückgegriffen wird. Die API für einen Testcase ist dabei äquivalent zu junit, jedoch werden Test-Suites aufgrund der fehlenden Reflection-API in J2ME anders aufgerufen, und es gibt einen weiteren TestRunner, der als MIDlet realisiert ist

78 3.4. Mobile Client Kapitel 3. Analyse 64

79 Kapitel 4 Design In diesem Kapitel wird das Design für die zu realisierende Anwendung mobilecrm entworfen. Es basiert auf den Anforderungen aus Abschnitt 3.1 und den Design- Entscheidungen, die während der Analyse getroffen wurden. Zunächst wird ein verfeinerter Architekturüberblick des gesamten Systems gegeben. Der Abschnitt mobilecrm geht auf die einzelnen Komponenten der mobilen Anwendung ein und erläutert danach deren Zusammenspiel, um eine Abbildung der einzelnen Anwendungsfälle zu realisieren. Abschließend wird der Entwurf des Web Service im SAP-XI beschrieben. 4.1 Architekturüberblick Aufgrund der im Analyse-Kapitel getroffenen Technologie- und Design-Entscheidungen ergibt sich ein verfeinerter Aufbau der Architektur, die in Abbildung 4.1 dargestellt ist. Als Endgerät wird von der Firma CSC ein BlackBerry 7100v mit Mobilfunkvertrag bei Vodafone bereitgestellt. Ebenso kann für SAP-XI und SAP-CRM auf die am Standort Wiesbaden vorhandene Infrastruktur in einer Testumgebung zurückgegriffen werden. Auf einer weiteren Servermaschine wurde im Rahmen dieser Arbeit Windows 2003 Server, MS Exchange 2003 und der BES in der Version 4.1 für Exchange installiert und konfiguriert. Die mit 1 und 2 in der Abbildung gekennzeichneten Systembestandteile sind dabei im Rahmen dieser Arbeit zu entwickeln bzw. zu konfigurieren. Der Schwerpunkt dieses Kapitels ist das Design von mobilecrm. Anschließend wird im SAP-XI der zugehörige Web Service entworfen. 65

80 4.2. mobilecrm Kapitel 4. Design 4.2 mobilecrm Abbildung 4.1: Verfeinerter Aufbau der Systemarchitektur Die Anforderungen an die mobile Anwendung mobilecrm wurden bereits in Abschnitt 3.1 festgelegt. Weitere Vorgaben für den Client wurden in Abschnitt 3.4 der Analyse herausgearbeitet. Daraus ergeben sich Teil-Komponenten der Anwendung, die als Java-Packages realisiert werden und im Folgenden beschrieben sind: com.csc.bb.mobilecrm In diesem Package befindet sich der Einstiegspunkt der Anwendung, der gemäß J2ME als MIDlet realisiert ist. In MobileCrmMIDlet wird der Lebenszyklus der Anwendung gesteuert, weitere Komponenten der Applikation initialisiert und die eigentlichen Aufgaben der Anwendung an diese delegiert. com.csc.bb.mobilecrm.gui Die graphischen Komponenten der Benutzerschnittstelle, die die LCDUI-API von J2ME benutzen, sind in diesem Package enthalten. com.csc.bb.mobilecrm.model Die von der Benutzerschnittstelle dargestellten Daten werden in getrennten Komponenten bereitgehalten, ebenso wie deren Synchronisation mit dem RMS auf dem Endgerät und dem Web Service des SAP-Systems. 66

81 Kapitel 4. Design 4.2. mobilecrm com.csc.bb.mobilecrm.util In diesem Package befinden sich Klassen für die Internationalisierung und das Logging. Die Tabelle 4.1 zeigt die Komponenten von mobilecrm mit ihren jeweiligen Zuständigenkeiten in einer Übersicht. Im nächsten Abschnitt werden allgemeine Design- Prinzipien für mobilecrm besprochen. Die darauf folgenden Unterkapitel sind nach der rechten Tabellenspalte gegliedert und betitelt. Java-Package com.csc.bb.mobilecrm.gui com.csc.bb.mobilecrm.model com.csc.bb.mobilecrm.util Zuständigkeit Benutzerschnittstelle Model und Backend-Zugriffe Logging und Internationalisierung Tabelle 4.1: Übersicht der Komponenten von mobilecrm Allgemeine Design-Prinzipien In diesem Abschnitt werden zunächst allgemeine Design-Prinzipien besprochen, die in mehr als einer Komponente von mobilecrm oder komponentenübergreifend Anwendung finden. In [Yua06] werden zwei grundsätzlich verschiedene Architektur-Beispiele für eine mobile Anwendung gegeben. Die Beispielanwendung Smart Ticket von Sun benutzt zahlreiche Interfaces zur Kapselung. Hinter einer Fassade für das Model findet beispielsweise eine Unterteilung in local und remote Model statt, während letzteres noch ein Chain-Handling von einem RMS-Cache und den eigentlich HTTP-Anfragen zu einem Server kapselt. Das Gegenbeispiel zu diesem schwergewichtigen Design bildet die ifeedback-anwendung des Autors ([Yua06]), die ein sogenanntes screen-flow Design verwendet. Der Autor hat mit dieser Anwendung im Jahr 2002 den University Wireless Developer Contest gewonnen, der von NexTel, Sun und Motorola durchgeführt wurde. In einer MVCComponent werden dabei graphische Elemente eines anzuzeigenden Screens zusammengefasst, und die dazu spezifisch erforderliche Programm-Logik für Benutzerinteraktion und Kommunikation mit Backend-Systemen ebenso in dieser Komponente implementiert. Für die Nagivation von einem Screen zum nächsten gibt es keinen zentralen Controller, sondern jede MVC-Komponente ist selbst dafür zuständig, bei welchen Benutzerinteraktionen eine andere Komponente angezeigt werden muss. Von dieser Klasse wird dann eine neue Instanz 67

82 4.2. mobilecrm Kapitel 4. Design angelegt und diese auf dem Display zur Anzeige gebracht - die Kontrolle liegt somit bei der neuen Komponente. Da ein graphisches Element nicht mehrfach angezeigt werden kann (es ist nur ein Display vorhanden), sind die Attribute aller Komponenten statisch und werden somit nicht mit jeder Instanz neu erzeugt. Die leichtgewichtige Architektur bietet klare Vorteile in Bezug auf Performance (siehe dazu Abschnitt ). Durch den reduzierten Umfang an Klassen wird weniger flüchtiger und nicht-flüchtiger Speicher für die Anwendung benötigt, ebenso wird weniger Delegation notwendig. Auf der anderen Seite geht dies zu Lasten der Erweiterbarkeit und Testbarkeit der Anwendung. Insbesondere kann der Code für Backend-Zugriffe nicht sauber wiederverwendet werden. Für mobilecrm kommt eine Variante des MVC Design Pattern zum Einsatz, auch Document-View-Architektur genannt, die einen bestmöglichen Kompromiss aus den unterschiedlichen Design-Ansätzen darstellen soll. Die graphischen Elemente sind dabei View und Controller in einem, und die Navigation von einer zur nächsten Komponente erfolgt ähnlich wie bei dem ifeedback-beispiel. Dafür sind statische Klassenattribute notwendig, damit der gegenseitige direkte Zugriff auf Instanzen möglich ist. In mobile- CRM wird dies durch das Singleton Design Pattern (siehe [GHJV95] S. 127) realisiert und auf alle Klassen angewendet, für die auf Anwendungsebene nur eine Instanz benötigt wird. Hierdurch wird die Neuinstanziierung von Objekten minimiert und die Garbage Collection weniger in Anspruch genommen. Es sei jedoch darauf hingewiesen, dass dies bei umfangreicheren Anwendungen und weiteren Workflows innerhalb der Anwendung zu einem zu hohen Speicherverbrauch führen kann, da einmal erzeugte Komponenten für weitere Benutzungen im Speicher vorgehalten werden. Die Kommunikation mit RMS und SAP-System wird in einem Model gekapselt, auf das alle graphischen Komponenten zugreifen. Die folgenden Abschnitte gehen auf das konkrete Design der Benutzerschnittstelle (View) und des Modells (Document) ein Benutzerschnittstelle Die Benutzerschnittstelle besteht hauptsächlich aus graphischen Komponenten, die die abstrakte Klasse BasicScreen erweitern. Abbildung 4.2 gibt eine Übersicht aller Klassen im Package com.csc.bb.mobilecrm.gui. Bevor ein Screen auf dem Display mit der Methode show() angezeigt werden kann, muss zunächst der Inhalt initialisiert werden, wofür jede graphische Komponente die Methode initdata() individuell überschreibt. Benötigt ein Screen vor der Initiali- 68

83 Kapitel 4. Design 4.2. mobilecrm Abbildung 4.2: Klassen der Benutzerschnittstelle (View) 69

84 4.2. mobilecrm Kapitel 4. Design sierung noch Daten, so kann dies über zusätzliche Set-Methoden geschehen, die vor initdata() aufgerufen werden müssen. Dies ist beispielsweise bei der Klasse Show- ActivityForm der Fall, der man zunächst eine Aktivitäts-ID übergeben muss, bevor die entsprechenden Daten aus dem Model transferiert werden können. Da ein Screen auch den Controller-Part des MVC-Designs übernimmt, wird das Interface CommandListener implementiert, und die Methode commandaction(command cmd, Displayable disp) muss in jeder Unterklasse entsprechend überschrieben werden. Dort können Benutzerinteraktionen verarbeitet und dementsprechend Vorgänge im Screen ausgelöst werden oder andere Screens aufgerufen werden, die wiederum zuvor initialisiert werden müssen. Damit die GUI während solcher Vorgänge nicht blockiert, werden Aufrufe im Model durch den ModelController gekapselt und in einem anderen Thread ausgeführt. Vom Model angefragte Daten werden asynchron vom ModelController an die entsprechende GUI-Komponente übergeben. Dafür muss sie das Interface AsyncDataHandler implementieren, den generischen Parameter der Methode updatedata(object data) zu dem erwarteten Datentyp anpassen (Casting) und dann adäquat verarbeiten. Während eines Vorgangs im Model wird auf dem Display ein Wartebildschirm angezeigt, der in der Klasse StatusBar implementiert ist. Zuvor muss mittels setnextscreen(basicscreen nextscreen) jedoch angegeben werden, welcher Screen nach Abschluß des Vorgangs angezeigt werden soll. Die Statusanzeige kann modellgetrieben aktualisiert werden, so dass der Benutzer eine Rückmeldung erhält, was im Hintergrund geschieht. Dafür wird im ModelController und in StatusBar die Schnittstelle ProgressObserver implementiert. So kann vom Model aus die Methode updateprogress(final int percentage, final String status) aufgerufen werden, die der Controller zur Statusanzeige delegiert. Durch die Notwendigkeit der Schnittstellen AsyncDataHandler und Progress- Observer bei der Kommunikation zwischen Model und ModelController in der GUI- Schicht ist die Model-Fassade unterteilt in die Schnittstelle ModelFacade, die nur Methoden zu Operationen mit den Datensätzen definiert, und die Klasse Model, die ModelFacade implementiert und zusätzlich noch die Kommunikation mit dem Controller umsetzt. Für einen kompletten Übergang von einem Screen zum nächsten ist also auch das Model involviert, weshalb ein Sequenzdiagramm eines solchen Vorgangs erst nach dem Abschnitt zum Model folgt. Der Einstiegspunkt der Benutzerschnittstelle ist das Hauptmenü, in dem ein Vorgang ausgewählt werden kann, angelehnt an die Anwendungsfälle der Applikation. Eine Übersicht der einzelnen Screens von mobilecrm zeigt Abbildung

85 Kapitel 4. Design 4.2. mobilecrm Abbildung 4.3: Übersicht und Zusammenhang der Screens So können neben den wesentlichen Punkten Aktivität anlegen, Liste aller Aktivitäten anzeigen und Synchronisieren auch die Anwendung beendet oder die Benutzereinstellungen angepasst werden. Die zugehörige Implementierung befindet sich in der Klasse MainMenu. Die Liste aller lokal auf dem Endgerät vorhandenen Aktivitäten zeigt der Screen ActivityList an, der intern List aus dem LCDUI-Framework für die Darstellung verwendet. Über ein Kontext-Menü kann eine ausgewählte Aktivität angezeigt, modifiziert oder lokal gelöscht werden. Diese Aufgabe übernimmt die Klasse Show- ActivityForm. Der Screen für die Benutzereinstellungen wird in SettingsMenu nur beispielhaft implementiert, weil für die Testumgebung keine Konfiguration notwendig ist. Im Fehlerfall kann eine Instanz von BasicAlert angezeigt werden. Vor der Anzeige können ein Fehlertext und ein eigener CommandListener übergeben werden. Bereits vorimplementiert sind die Fälle, in denen nach dem Fehler-Dialog der nächste Screen angezeigt sowie dass die Anwendung für kritische Fehler beendet wird. Ist Letzteres nicht der Fall, so muss vor der Anzeige des Dialogs setnextscreen(basicscreen nextscreen) aufgerufen werden. Der ModelController erweitert java.lang.thread, um die Model-Aufrufe in einem von der GUI getrennten Thread auszuführen. Dabei muss ein Aufruf im GUI- 71

86 4.2. mobilecrm Kapitel 4. Design Thread auf einen Aufruf im Model-Thread abgebildet werden. Der objektorientierte Ansatz ist zunächst, für jeden ModelController-Aufruf im GUI-Thread eine anonyme Klasse anzulegen, die ModelAction (siehe Quellcode 4.1) erweitert. Dieses sogenannte Command Design Pattern findet sich in [GHJV95] S Diese Vorgehensweise impliziert für jede Methode des Models eine weitere Klasse und verstößt damit gegen Prinzipien aus dem Abschnitt Optimierungen für mobile Anwendungen im Grundlagen-Kapitel. Deswegen wird der Code, um einen Vorgang im Model durchzuführen, in einer Handler- Methode ebenfalls im ModelController implementiert werden. Jede Handler-Methode ist über eine ID mit der von der GUI aufgerufenen Methode verknüpft. Die ID und ein optionaler Parameter werden in der Handler-Methode gesetzt und in Attributen des ModelControllers gespeichert, und der Model-Thread aufgeweckt, der anhand der ID die zugehörige Handler-Methode aufrufen kann und dann wieder pausiert. Da der Thread nur eine Model- Anfrage bearbeiten kann, müssen die Aufrufe des ModelControllers serialisiert werden. Die öffentlichen Methoden sind deshalb als synchronized deklariert. Um das Model abstrakt zu halten, wurde das Threading und die damit verbundene asynchrone Kommunikation im ModelController im GUI-Package implementiert. Obwohl Model und ModelController die gleichen Methoden für Operationen mit den Model-Komponenten, die im Interface ModelFacade zusammengefasst sind, implementieren müssen, kann der ModelController dieses Interface nicht implementieren, da sich die Methodensignaturen aufgrund der asynchronen Aufrufe unterscheiden. public interface ModelAction { 2 void setexecuteparam(object param); void execute(); 4 } Quellcode 4.1: Interface zur Umsetzung des Command Pattern Model und Backend-Zugriffe Im Model von mobilecrm werden die Datensätze repräsentiert, die mit dem SAP-CRM- System ausgetauscht werden. Neben der Kommunikation mit dem SAP-CRM wird das Model außerdem noch im RMS des mobilen Endgeräts für den Offline-Modus abgespeichert. Die Model-Schicht besteht aus Klassen für die Datenhaltung und den Datenaustausch mit Backend-Systemen. Diese einzelnen Komponenten werden durch eine einzige Schnittstelle nach dem Facade Design Pattern (siehe [GHJV95] S. 185) nach außen hin gekapselt, so dass Änderungen an Sub-Komponenten keinen Einfluß auf die View- 72

87 Kapitel 4. Design 4.2. mobilecrm Abbildung 4.4: Business Objects in mobilecrm Komponenten haben. Der Zugriff auf das RMS erfolgt über die Klasse RMSmanager, die als Singleton implementiert ist und sich im Package com.csc.bb.mobilecrm-.model.backend.rms befindet. Die SOAP-Kommunikation mit dem SAP-System findet über die Schnittstelle der Klasse SAPmanager statt, die alle weiteren Details im Package com.csc.bb.mobilecrm.model.backend.sap kapselt. Klassen, die abstrakte Entitäten aus der Anwendungsdomäne enthalten, werden auch BusinessObjects (BO) genannt. Dabei gibt es im Fall von mobilecrm im Prinzip nur die Entität einer Aktivität aus dem SAP-CRM. Diese wurde jedoch noch feiner zerlegt, da dies Vorteile beim Zugriff auf das RMS mit sich bringt. Einen Überblick über die Schnittstelle der BOs in mobilecrm gibt Abbildung 4.4. In der Klasse ActivityBO sind dabei alle mit dem SAP ausgetauschten Daten einer Aktivität in Form von Attributen enthalten. Einige Daten, die in mehreren GUI- Komponenten benötigt werden, wurden in die Klasse ActivityEntryBO ausgegliedert. Damit die BOs alle serialisierbar sind und die Daten auf Konsistenz überprüft werden können, ist jedes BO Nachfahre der abstrakten Klasse BasicBO, die eine abstrakte Methode validate() vorsieht, die jedes BO entsprechend implementieren muss. Dadurch kann jedes BO auf seine Datenkonsistenz hin überprüft werden. Die Serialisierung erfolgt durch Implementierung der dafür entworfenen Schnittstelle Serializable. Diese wird vom RMSmanager angesprochen, und ein BO ist dafür verantwortlich, all seine Attribute in den übergebenen Ein- bzw. Ausgabe-Strom zu serialisieren bzw. wieder zu deseriali- 73

88 4.2. mobilecrm Kapitel 4. Design Abbildung 4.5: Komponenten zur Kommunikation mit den Backend-Systemen sieren. Für die lokale Speicherung der Daten verwaltet der RMSmanager den Zugriff auf die RecordStores. Die zugehörige UML-Darstellung findet sich in Abbildung 4.5. Für die BOs ActivityBO und ActivityEntryBO werden zur Serialisierung mittels RMSmanager zwei unterschiedliche RecordStores verwendet. Das Schreiben einer Aktivität impliziert gleichzeitig einen neuen ActivityEntryBO-Datensatz, so dass beide Identifikatoren gleich sind. Um die Liste der Aktivitäten (Screen Nr 2 in Abbildung 4.3) anzuzeigen, müssen so nicht alle ActivityBOs gelesen werden, sondern es ist ausreichend, nur die ActivityEntryBOs auszulesen, welche deutlich kleiner sind. Weiterhin können in ActivityEntryBO-Datensätzen Verwaltungsinformationen gespeichert werden wie beispielsweise, ob eine gespeicherte Aktivität auf dem Endgerät bereits modifiziert wurde oder noch im Original-Zustand ist. Bei der Synchronisation mit dem SAP-System müssen so ebenfalls nicht alle ActivityBOs ausgelesen werden. Die öffentliche Schnittstelle sieht Methoden zum Laden, Speichern und Löschen einer Aktivität vor, welche jeweils auch den zugehörigen ActivityEntryBO-Datensatz beachten. Der direkte Zugriff auf ActivityEntryBO-Einträge ist nur über die Methode load- AllActivityEntries() für die Liste aller Aktivitäten vorgesehen. Um die Datenkonsistenz zu gewährleisten, sind alle öffentlichen Methoden synchronized, so dass konkurrierende Zugriffe auf das RMS immer seriell ablaufen. Der RMSmanager ist nach dem Singleton Design Pattern entworfen. Dies spart Referenzen und Delegation zwischen Model und dem PushReceiver, schränkt die Funktionalität der Klasse jedoch nicht ein, da 74

89 Kapitel 4. Design 4.2. mobilecrm auf die RecordStores nicht parallel zugegriffen werden soll. Während die Anwendung aktiv ist, muss sie selbst auf eingehende Push-Verbindungen warten. Um Benutzerinteraktionen nicht zu stören, wird diese Funktionalität in einem eigenen Thread umgesetzt. Die Klasse PushReceiver erweitert java.lang.thread und nimmt auf dem angegebenen Port blockierend in einer Endlos-Schleife Verbindungen entgegen. Eine Verbindung wird dann geöffnet und als InputStream an den SAPmanager übergeben. Das Ergebnis ist ein ActivityBO und wird im RMS abgespeichert. Die Kommunikation mit dem SAP-XI Web Service findet über die Klasse SAPmanager statt (siehe Abbildung 4.5). Um eine Instanz zu erzeugen, werden zunächst die URL des Web Service sowie Benutzername und Passwort für die Authentifizierung beim SAP- XI benötigt. Zum Empfangen eines Push-Updates dient die Methode receivepush(- InputStream inputstream), die als Parameter die eingehende Verbindung erwartet und ein ActivityBO zurückgibt. Mit der Methode getactivities() erhält man einen Vector mit allen Aktivitäten des SAP-Systems, die zum Benutzername gehören. Um eine modifizierte Aktivität zum SAP-CRM zu übermitteln, wird das entsprechende BO an die Methode updateactivity(activitybo activity) übergeben Abbildung der Anwendungsfälle Anhand von Sequenzdiagrammen wird das Zusammenspiel der Komponenten für die in der Analyse festgelegten Anwendungsfälle verdeutlicht (vgl ) Server-initiiert Aktivitätsänderung Dieser Use-Case bezieht sich auf Änderungen einer Aktivität im SAP-CRM- System, die durch einen Client wie mobilecrm (siehe Aktivität modifizieren unter Client-initiierte Anwendungsfälle) oder der SAP-GUI durchgeführt werden. Dieser Vorgang ist der Auslöser für die Datensynchronisation durch eine Push-Nachricht, die nachfolgend beschrieben wird. Daten synchronisieren Der in Abbildung 4.6 dargestellte Ablauf beginnt damit, dass der PushReceiver einen eigenen Thread startet und auf eingehende Push-Verbindungen wartet, die 75

90 4.2. mobilecrm Kapitel 4. Design Abbildung 4.6: Sequenzdiagramm zum Anwendungsfall Daten synchronisieren vom SAP-CRM-System bei Änderungen an Aktivitäten initiiert werden. Die Verbindung wird an den SAPmanager übergeben, wo die ankommenden SOAP- Daten gelesen und das Parsing durchgeführt werden. Die resultierende Instanz eines ActivityBO wird vom PushReceiver im RMS über den RMSmanager abgespeichert. Abschließend wird der erfolgreiche Eingang einer Push-Nachricht über das AsyncEventHandler-Interface an den ModelController als Event übermittelt, und dem Benutzer wird ein entsprechender Informationsdialog angezeigt Client-initiiert Aktivitäten auflisten Ausgehend vom Hauptmenü von mobilecrm wird die Methode initdata() der ActivityList-Instanz aufgerufen (siehe Abbildung 4.7). Während der Initialisierung soll der Warte-Screen StatusBar mit der Methode show() angezeigt werden, zunächst wird jedoch als Folge-Screen die initialisierte ActivityList- Instanz gesetzt. Zur Initialisierung werden alle Aktivitätseinträge im RMS benötigt, deren Beschaffung durch Aufruf der Methode getactivityentries() des ModelControllers angestoßen wird. Die aufgerufenen Methoden der graphischen Komponenten (MainMenu und ActivityList) beenden sich, und der Kontrollfluss des GUI-Threads liegt wieder beim LCDUI-Framework. Damit im ModelController hinterlegt ist, welche GUI-Komponente die Daten angefordert hat, 76

91 Kapitel 4. Design 4.2. mobilecrm Abbildung 4.7: Sequenzdiagramm zum Anwendungsfall Aktivitäten auflisten 77

92 4.2. mobilecrm Kapitel 4. Design Abbildung 4.8: Sequenzdiagramm zum Anwendungsfall Aktivität anlegen muss diese zuvor setcaller(this) am ModelController aufrufen. Der angestoßene Worker-Thread arbeitet die Anfrage durch den Aufruf von handleget- ActivityEntries() ab. Dabei wird die Aufgabe an das Model und von dort aus zum RMSmanager delegiert, der alle Aktivitäten als ActivityEntryBO- Objekte ausliest und in einem java.util.vector zurückgibt. Auch in diesem Fall wird die Statusmeldung des Warte-Screens (StatusBar) wieder vom Model aktualisiert. Für den Transport der ausgelesenen Daten vom ModelController (Worker-Thread) zur GUI-Komponente, die das Interface AsyncDataHandler implementiert, wird die Methode updatedata(object data) genutzt. Abschließend wird der Übergang von StatusBar zum nächsten Screen Activit- List vollzogen. Aktivität anlegen Der Schritt vom Hauptmenü über den Menüeintrag Neue Aktivität anlegen zur graphischen Komponente ShowActivityForm wurde in Abbildung 4.8 zur besseren Übersicht auf die wesentlichen Vorgänge beschränkt. Das Sequenzdiagramm beginnt an der Stelle, nachdem der Benutzer die entsprechenden Daten eingegeben hat und die Speicherung der neuen Aktivität veranlasst. Zunächst wird der Warte- Screen eingeblendet, bevor dann die eigentliche Speicherung im Model im Thread 78

93 Kapitel 4. Design 4.2. mobilecrm des ModelControllers abgearbeitet wird. Wichtig ist dabei, dass das Flag modified im ActivityBO gesetzt wird, was im Model geschieht. Die Aktivität kann dann über den RMSmanager gespeichert werden. Danach wird versucht, die Methode updateactivity erfolgreich aufzurufen, was jedoch nur bei einer Funkverbindung des Endgeräts gelingt. Andernfalls wird die Aktivität beim nächsten Synchronisationsvorgang zum SAP übertragen. An dieser Stelle kommt das modified- Attribut der Aktivität zum Tragen, woran erkannt wird, dass die Aktivität noch nicht synchronisiert wurde. Abschließend wird der nächste Screen angezeigt, was in diesem Fall die ActivityList ist. Aktivität modifizieren Dieser Anwendungsfall unterscheidet sich vom vorherigen nur in dem Punkt, dass zu Beginn die ausgewählte Aktivität in der graphischen Komponente Show- ActivityForm dargestellt wird und nicht mit einer leeren Aktivität begonnen wird. Wie das Laden der Aktivität und das Initialisieren der graphischen Komponente stattfindet, lässt sich im Use-Case Aktivität anzeigen (Abbildung 4.10) nachvollziehen. Der Update-Vorgang ist analog zu dem in Abbildung 4.8. Aktivität löschen Innerhalb der Aktivitätsliste besteht die Option, eine markierte Aktivität zu löschen. Dieser Vorgang ist in Abbildung 4.9 abgebildet und beginnt in der Methode commandaction in der Instanz von ActivityList, der Benutzer hat also den Menü-Eintrag zum Löschen ausgewählt. Nach dem Vorgang im Model soll wieder die Aktivitätsliste angezeigt werden, weshalb zunächst set- NextScreen(this) aufgerufen wird, bevor der StatusBar auf dem Display angezeigt wird. Im Hintergrund wird nun die asynchrone Methode delete- Activity vom ModelController mit der RecordID der zu löschenden Aktivität als Parameter aufgerufen. Nachdem dort der Worker-Thread aufgeweckt wurde, kehrt der Kontrollfluss des GUI-Threads wieder zurück in die graphische Komponente ActivityList, die ihre graphische Repräsentation anpasst (nicht in Abbildung dargestellt). Die Methode commandaction() wird verlassen, und Benutzereingaben können so wieder durch das LCDUI-Framework bearbeitet werden, beispielsweise zum Abbrechen des Vorgangs. Während der Bearbeitung im Model kann eine Statusmeldung über die ProgressObserver Schnittstelle im ModelController mit der Methode updateprogress(- int percentage, String status) bis zur GUI propagiert werden. Das Löschen der Aktivität wird vom Model durch Aufruf der Methode delete- 79

94 4.2. mobilecrm Kapitel 4. Design Abbildung 4.9: Sequenzdiagramm zum Anwendungsfall Aktivität löschen 80

95 Kapitel 4. Design 4.2. mobilecrm Abbildung 4.10: Sequenzdiagramm zum Anwendungsfall Aktivität anzeigen Activity(int recordid) der RMSmanager-Instanz veranlasst. Wenn der Vorgang im Worker-Thread beendet ist, ruft der ModelController die Methode shownextscreen() des StatusBar auf, was in diesem Fall zur Folge hat, dass abschließend wieder die aktualisierte Aktivitätsliste angezeigt wird. Aktivität anzeigen Dieser Anwendungsfall knüpft an Aktivitäten auflisten in Abbildung 4.7 an. Nachdem in der Liste vom Benutzer eine Aktivität ausgewählt wurde, wird initdata() der graphischen Komponente zum Anzeigen einer Aktivität aufgerufen. Damit der asynchrone Datentransfer vom Model zur GUI-Komponente über das AsyncDataHandler-Interface erfolgen kann, muss sich die Komponente zuerst beim ModelController mit setcaller(this) registrieren. Danach wird der Aufruf getactivity(activityid) über den ModelCon- 81

96 4.2. mobilecrm Kapitel 4. Design Abbildung 4.11: Sequenzdiagramm zum Anwendungsfall Aktivitätenliste anfordern troller im Worker-Thread zum Model delegiert. Über die ProgressObserver- Schnittstelle im ModelController kann das Model Statusänderungen des Vorgangs zum Warte-Screen propagieren. Das eigentliche Auslesen der Aktivität wird an den RMSmanager delegiert, der anhand der activityid den Datensatz aus dem RMS auslesen kann, und die Daten als ActivityBO-Instanz zurück gibt. Im Worker-Thread des ModelControllers wird die Aktivität an die aufrufende GUI- Komponente mittels updatedata übergeben. Abgeschlossen wird der Anwendungsfall durch anzeigen der initialisierten ShowActivityForm-Instanz. Aktivitätenliste anfordern Der in Abbildung 4.11 dargestellte Anwendungsfall beginnt durch Auswahl im Hauptmenü, und es wird der Warte-Screen angezeigt. Über den Thread des Model- Controllers wird die Methode getactivies(status) im Model aufgerufen. Der Parameter gibt dabei an, welchen Status die zurückgelieferten Aktivitäten haben sollen, beispielsweise open. Der Aufruf wird an den SAPmanager delegiert, der eine SOAP-Anfrage abschickt, das Parsing der Antwort durchführt und als Resultat einen Vector mit ActivityBO-Instanzen zurückliefert. Diese Aktivitäten werden im Model einzeln über den RMSmanager lokal abgespeichert. Nachdem dieser Vorgang beendet ist, wird wieder das Hauptmenü angezeigt. 82

97 Kapitel 4. Design 4.3. Integrationsszenarien in SAP-XI Abbildung 4.12: Sequenzdiagramm zum Anwendungsfall Daten synchronisieren Daten synchronisieren Ausgehend vom Hauptmenü können lokal modifizierte Aktivitäten mit dem SAP- System synchronisiert werden (siehe Abbildung 4.12). Währenddessen wird dem Benutzer der Warte-Screen angezeigt, und der Vorgang an das Model bzw. den Worker-Thread delegiert. In der Methode synchronizeactivities() werden zunächst über den RMSmanager alle modifizierten Aktivitäten ausgelesen. Für jede dieser Aktivitäten wird die Methode updateactivity aufgerufen, in der die Kommunikation mit dem Web Service auf SAP-Seite stattfindet. Nach erfolgreichem Update einer Aktivität wird im RMS der Status auf unmodified gesetzt. Der Vorgang wird durch erneute Darstellung des Hauptmenüs abgeschlossen. 4.3 Integrationsszenarien in SAP-XI Hier werden die Integrationsszenarien und die dazugehörigen Komponenten aus dem SAP-XI aufgeführt und erläutert. Die Arbeiten zur Integration im SAP-XI wurden durch den Betreuer (Herrn Thomas Schneider) von Seiten der Firma CSC durchgeführt und 83

98 4.3. Integrationsszenarien in SAP-XI Kapitel 4. Design Abbildung 4.13: Aufbau eines synchronen Integrationsszenarios im SAP-XI sind nicht Bestandteil dieser Arbeit. Insbesondere die Definition der Schnittstelle zwischen BB-Endgerät und XI sowie die Auswahl der benötigten BAPIs im SAP-CRM sind in enger Abstimmung mit der Analyse und dem Design der mobilen Anwendung entstanden. Anwendungsfälle werden im SAP-XI durch Integrationsszenarien abgebildet. Einem Integrationsszenario sind verschiedene Anwendungskomponenten zugeordnet. Diese sind im SLD zu pflegen, die Komponente von RIM (BES) muss dort aufgenommen werden. Den einzelnen Anwendungskomponenten werden im Designprozess ein oder mehrere Actions zugeordnet. Die Anwendungsszenarien für die SAP-BB-Integration definieren jeweils nur eine Action pro Anwendungskomponente. In den Actions werden die Message-Interfaces festgelegt, aus denen XI ein WSDL-Dokument generiert. Zwischen den Actions sind die Mappings definiert, die für die Transformation der eigentlichen Nachrichten notwendig sind (siehe Abbildung 4.13). Für ein Mapping gibt es in XI zwei Abstraktionsebenen. Zum einen das Interface Mapping, welches festlegt zwischen welchen Interfaces ein Mapping stattfinden soll. Und dann das eigentliche Mapping der Nachrichten (Message-Mapping). Für ein synchrones Interface Mapping wie im Fall der SAP-BB-Integration werden jeweils zwei Message-Mappings benötigt - eins für die Anfrage und eins für die Antwort. Für die in Abschnitt beschriebenen Anwendungsfälle sind im SAP-XI die in Tabelle 4.2 dargestellten Integrationsszenarien definiert. Dabei werden die Anwendungsfälle Aktivität anlegen, Aktivität modifizieren und Daten synchronisieren nur auf dem Endgerät unterschieden, und alle Resultate über das Szenario ChangeActivity an das SAP-System übermittelt. Die Anwendungsfälle Aktivität anzeigen und Aktivität löschen finden nur lokal im RMS des Endgeräts statt und haben keine Auswirkungen auf das SAP-System. 84

99 Kapitel 4. Design 4.3. Integrationsszenarien in SAP-XI In den folgenden Tabellen 4.3, 4.4 und 4.5 wird der Aufbau der drei Integrationsszenarien beschrieben. Die aus den Szenarien erzeugten WSDL-Dokumente wurden für die Implementierung verwendet und befinden sich im Projektverzeichnis von mobilecrm auf der CD-ROM zu dieser Arbeit. Integrationsszenario ActionPush ChangeActivity GetActivityList Beschreibung Push einer neuen oder geänderten Aktivität auf das BB-Gerät Änderung oder Neuanlage einer Aktivität auf dem BB-Gerät und Update der Daten im SAP-CRM Holen einer Aktivitätenliste aus dem SAP-CRM Tabelle 4.2: Übersicht der Integrationsszenarien 85

100 4.3. Integrationsszenarien in SAP-XI Kapitel 4. Design Datentyp Objekttyp Objekt Beschreibung Integrationszenario ActionPush Definiert das Integrationszenario für die Push Funktionalität von Aktivitäten Action ActivityPushCRM Definiert den serverseitig initiierten Anwendungsfall Pushen einer Aktivität Action ActionPush Definiert den clientseitigen Anwendungsfall Empfangen eines Aktivität Message-Interface ActionPush_In Schnittstelle zwischen SAP-XI und BB-Endgerät für Push-Nachricht RFC-Message- ZACTIVITY_PUSH Schnittstelle zwischen SAP-CRM Interface und XI um eine Aktivität zu pushen Message-Typ ActionPushRequest XSD zur Definition einer Push-Nachricht zum BB-Endgerät Message-Typ ActionPushResponse XSD zur Definition der Antwort vom BB-Server auf einen PushRequest RFC-Message-Typ ZACTIVITY_PUSH Request-Datentyp, welcher die Aktivität beinhaltet RFC-Message-Typ ZACTIVITY_PUSH.- Response-Datentyp als Antwort auf Response ActionPushRequestDatatype einen Aktivitäts-Push Datentyp innerhalb einer Push-Nachricht. Beinhaltet den Datentyp Activity Datentyp ActionPushResponse- Datatype Datentyp eines Response auf eine Push-Nachricht Datentyp Activity Kapselt eine Aktivität und wird im ActionPushRequestDatatype verwendet Interface-Mapping ActionPushMapping Definiert das Mapping vom Aus- Message-Mapping Message-Mapping gangs-interface ZACTIVITY_PUSH auf das Ziel-Interface ActionPush_In Definiert das Mapping des Requests von der Ausgangs-Nachricht ZACTI- VITY_PUSH auf die Ziel-Nachricht ActionPushRequest ActionPushRequest- Mapping ActionPushResponse- Mapping Definiert das Mapping des Responses von der Ausgangs-Nachricht Action- PushResponse auf die Ziel-Nachricht ZACTIVITY_PUSH_RESPONSE Tabelle 4.3: Integrationsszenario ActionPush 86

101 Kapitel 4. Design 4.3. Integrationsszenarien in SAP-XI Objekttyp Objekt Beschreibung Integrationszenario ChangeActivity Definiert das Szenario für das Erzeugen und Ändern von Aktivitäten im CRM Action ChangeActivityAction Definiert den clientseitig initiierten Anwendungsfall für das Erzeugen und Ändern einer Aktivität Action ChangeActivityActionCRdungsfall Definiert den serverzeitigen Anwentivitätenänderung für das Verarbeiten einer Ak- oder einer Neuanlage von einer Aktivität Message-Interface ChangeActivity_Out Schnittstelle zwischen dem Endgerät Message-Typ RFC-Message-Typ RFC-Message-Typ RFC-Message- Interface Message-Typ CRMXIF_ORDER- _SAVE ChangeActivityRequest ChangeActivityResponse XSD zur Definition der Response- Nachricht vom XI auf einen ChangeActivityRequest CRMXIF_ORDER- _SAVE CRMXIF_ORDER- _SAVE.Response und XI für den Dienst ChangeActivity Schnittstelle zwischen XI und SAP- CRM für den Dienst ChangeActivity XSD zur Definition der Request- Nachricht zwischen BB-Endgerät und XI für das Erzeugen oder Ändern einer Aktivität XSD zur Definition der Request- Nachricht zwischen XI und CRM für den RFC-Aufruf CRM- XIF_ORDER_SAVE zum Erzeugen und Ändern einer Aktivität XSD zur Definition der Response- Nachricht als Antwort auf den RFC- Aufruf CRMXIF_ORDER_SAVE Datentyp ChangeActivityRequestDatatype Datentyp innerhalb des ChangeActivity- Request. Enthält den Datentyp Activity Datentyp ChangeActivityResponseDatatype Datentyp innerhalb des ChangeActivity- Response Datentyp Activity Kapselt eine Aktivität und wird im ChangeActivityRequestDatatype verwendet Interface-Mapping ChangeActivityMapping Definiert das Mapping vom Ausgangs- Interface ChangeActivity_Out auf das Message-Mapping Message-Mapping ChangeActivityRequestMapping ChangeActivityResponseMapping Ziel-Interface CRMXIF_ORDER_SAVE Definiert das Mapping des Requests von der Ausgangs- zur Ziel-Nachricht Definiert das Mapping des Responses von der Ausgangs- zur Ziel-Nachricht Tabelle 4.4: Integrationsszenario ChangeActivity 87

102 4.3. Integrationsszenarien in SAP-XI Kapitel 4. Design Objekttyp Objekt Beschreibung Integrationszenario GetActivityList Definiert das Integrationszenario für das holen einer Aktivitätenliste Action RequestActivityList Definiert den clientseitig initiierten Anwendungsfall für das holen einer Aktivitätenliste Action ProvideActivityList Definiert den serverzeitigen Anwendungsfall für das Suchen nach Aktivitäten für einen Anwender Message-Interface RequestActivity- List_Out Schnittstelle zwischen dem BB-Endgerät und SAP-XI für den Dienst GetActivityList RFC-Message-Typ RFC-Message-Typ Datentyp Datentyp RFC-Message- Interface CRM_MY_ACTIVI- TIES Schnittstelle zwischen XI und SAP- CRM für den Dienst GetActivityList Message-Typ ActivityListRequest XSD zur Definition der Request-Nachricht zwischen BB-Endgerät und XI für das holen einer Aktivitätenliste Message-Typ ActivityListResponse XSD zur Definition der Response-Nachricht vom XI auf einen ActivityListRequest CRM_MY_ACTIVI- TIES XSD zur Definition der Request-Nachricht zwischen XI und SAP-CRM für den RFC-Aufruf CRM_MY_ACTIVI- TIES zum Holen einer Aktivitätenliste CRM_MY_ACTIVI- TIES.Response ActivityListRequest- Datatype ActivityListResponseDatatype XSD zur Definition der Response-Nachricht als Antwort auf den RFC-Aufruf CRM_MY_ACTIVITIES Datentyp innerhalb des ActivityListRequest Datentyp innerhalb des ActivityListResponse. Dieser Datentyp beinhaltet eine Liste von Aktivitäten in Form des Datentyps Activity Message-Mapping Message-Mapping Datentyp Activity Kapselt eine Aktivität und wird im ActivityListResponseDatatype verwendet Interface-Mapping ActivityGetList Definiert das Mapping vom Ausgangs- Interface RequestActivityList_Out auf das Ziel-Interface CRM_MY_ACTIVI- TIES ActivityGetListRequestMapping ActivityGetListResponseMapping Definiert das Mapping des Requests von der Ausgangs- zur Ziel-Nachricht Definiert das Mapping des Responses von der Ausgangs- zur Ziel-Nachricht Tabelle 4.5: Integrationsszenario GetActivityList 88

103 Kapitel 5 Implementierung Ausgewählte Einzelheiten aus der Realisierung des im Design entworfenen Modells von mobilecrm werden nun besprochen. Zunächst wird kurz auf die Entwicklungswerkzeuge eingegangen. Danach wird das mittels ksoap implementierte SOAP-Parsing vorgestellt. Darauf folgt mit der RMS-Schnittstelle eine weitere Komponente zum Zugriff auf ein Backend-System. Im Abschnitt Multi-Threading werden die Feinheiten der in mobile- CRM zum Einsatz kommenden Threads dargelegt. Probleme bei der Implementierung, die sich nicht sauber lösen lassen, sind im Abschnitt Workarounds zusammengefasst. Abschließend wird auf die Qualitätssicherung und den Implementierungsaufwand von mobilecrm eingegangen. 5.1 Entwicklungswerkzeuge Für die Implementierung der mobilen Anwendung mobilecrm kommt die Java-Entwicklungsumgebung Eclipse 1 in der Version 3.2 zum Einsatz. Zum Testen der Anwendung wird das in der Analyse ausgewählte Framework J2ME-Unit verwendet, ebenso wie das Logging-Framework Microlog. Die Definition von Namenskonventionen und eine statische Code-Analyse wird mit dem Eclipse-Plugin Checkstyle 2 durchgeführt. Inhaltlich geht das Unterkapitel Qualitätssicherung (Abschnitt 5.7) näher auf die Unit-Tests, einen Styleguide und Software-Metriken ein. Das Eclipse-Plugin Eclipse-ME 3 (Version 1.5.5) erleichtert die Entwicklung mit J2ME. Es bietet Unterstützung für das Wireless Toolkit von Sun und bindet daraus den Emu

104 5.1. Entwicklungswerkzeuge Kapitel 5. Implementierung lator und die Bibliotheken in ein J2ME-Projekt ein. Der Build- und Packaging-Prozess einer mobilen Anwendung, resultierend in einem JAD und einem JAR, kann durch ein von Eclipse-ME generiertes Ant-Skript automatisiert und konfiguriert werden. Die Erweiterbarkeit der Skripte wird ausgenutzt, um aus einer MIDlet-Suite gemäß MIDP eine Blackberry-spezifische Anwendung zu generieren. Der Codeausschnitt dazu findet sich in Quellcode-Listing 5.1. Das Programm zur Konvertierung ist Bestandteil der JDE- Entwicklungsumgebung von RIM, und wird über das Ant-Skript parametrisiert. <target name="makecod" 2 description="builds a.cod file for BlackBerry devices from.jar +.jad"> <mkdir dir="${bb.cod.output}"/> 4 <exec dir="${bb.cod.output}" executable="${bb.jde.bin}\\rapc.exe"> <arg line=" import=${bb.jde.libs}"/> 6 <arg line=" codename=${midlet.name}"/> <arg line=" -midlet../${midlet.name}.jad../${midlet.name}.jar"/> 8 </exec> <copy file="${basedir}/packaging/mobilecrm.alx" todir="${bb.cod.output}"/> 10 </target> Quellcode 5.1: build.xml: Target makecod Durch die bei mobilen Endgeräten typischerweise beschränkte Hardwareleistung spielen Performance-Optimierungen bei mobilen Anwendungen eine wichtige Rolle, so dass dieser Punkt bereits in Analyse und Design beachtet wurde. Die Optimierungsmöglichenkeiten wurden im Grundlagenabschnitt erläutert. Als Obfuscator bietet sich die Benutzung von ProGuard 1 an, der sich in EclipseME integrieren lässt. Die prinzipielle Funktionsweise lässt sich in der Dokumentation des Projekts nachlesen. Für mobilecrm und die zugehörige Testsuite kommen die in Quellcode-Listing 5.2 dargestellten zusätzlichen Parameter für ProGuard zum Einsatz. -keepnames class * 2 -allowaccessmodification Quellcode 5.2: Parameter für den Obfuscator ProGuard Standardmäßig werden Klassennamen von ProGuard verkürzt, zur Erschwerung von Reverse-Engineering und zur Reduzierung der Applikationsgröße. Dies ist im Fall von mobilecrm unerwünscht, da die Implementierung von Logging und Internationalisierung auf den ursprünglichen Klassennamen basiert, und wird durch den ersten Parameter verhindert. Der Parameter -defaultpackage wurde aus der Standard- Konfiguration von EclipseME entfernt, damit die Package-Struktur im JAR erhalten 1 90

105 Kapitel 5. Implementierung 5.2. SOAP-Parsing bleibt. Dies ist für das Auffinden der Ressourcen-Dateien notwendig. Mit dem zweiten Parameter wird ProGuard erlaubt die Access-Modifier innerhalb von Klassen zu ändern. Dadurch können beispielsweise Attribute als public deklariert werden und Methoden können dann inline implementiert werden. Der Methodenaufruf entfällt also, und der Rumpf der Methode wird an die jeweilige Stelle des Aufrufs kopiert, was insbesondere bei trivialen Get- und Set-Methoden sinnvoll ist. Eine weitere Möglichkeit, um die Performance zu verbessern, bietet sich durch das Verwenden von Präprozessor-Direktiven. EclipseME unterstützt diese Funktion erst seit kurzem, und kommt im Rahmen von mobilecrm daher nicht zum Einsatz. Die Direktiven sind in Java-Kommentaren untergebracht, um den Code kompatibel zu halten, so dass er auch ohne Präprozessor compilierbar ist. Durch Einsatz von Preprocessing kann in bestimmten Situationen überflüssiger Code entfernt werden. So ließe sich für eine Release-Version sämtlicher Debugging- und Logging-Code entfernen, und auch Endgerät-spezifische Implementierungen realisieren (siehe z.b. Abschnitt Workarounds). In mobilecrm wird dies zumindest teilweise dadurch erreicht, dass das Logging an zentraler Stelle deaktiviert werden kann. 5.2 SOAP-Parsing Das SOAP-Parsing ist im Package com.csc.bb.mobilecrm.model.backend-.sap vollständig gekapselt, und ist für alle anderen Komponenten transparent. Für jeden komplexen XML-Datentyp innerhalb der verwendeten SOAP-Nachrichten (siehe Message-Typen in den Tabellen 4.3, 4.4 und 4.5) gibt es eine gleichnamige Klasse, die für die (De-)Serialisierung zuständig ist. Dafür wird das KvmSerializable-Interface verwendet, das in den Grundlagen in Abschnitt besprochen wurde. Der Aufbau der fünf verschiedenen SOAP-Nachrichten-Typen ist in Abbildung 5.1 dargestellt. Dabei wird der Zusammenhang zwischen konkreten Instanzen der Klassen aufgezeigt, ähnlich wie es durch die XML-Schema-Definition auf XML-Ebene ausgedrückt wird. Eine Push- Nachricht stellt eine Besonderheit dar, aus Sicht des SAP-XI handelt es sich um eine Push-Anfrage an das Endgerät, weshalb die Benennung des Message-Typs als Request generiert wird. Die Implementierung auf dem BB verarbeitet die Verbindung jedoch als Antwort, und der Payload ist eine Aktivität. Das SOAP-Parsing wird vom Model aus über die Schnittstelle der Klasse SAPmanager (siehe Abschnitt 4.2.3) durchgeführt. Die Vorgehensweise beim Parsing ist anhand der Methode reveivepush in Quellcode-Listing 5.3 dargestellt. Zunächst müssen die 91

106 5.3. RMS-Schnittstelle Kapitel 5. Implementierung Abbildung 5.1: Aufbau der verschiedenen Nachrichtentypen Klassen zum (De-)serialisieren der verwendeten Datentypen mit den entsprechenden XML-Elementen assoziiert werden (Mapping). In ksoap wird mit der Methode call eine SOAP-Anfrage gesendet und die entsprechende Antwort empfangen, jeweils inklusive dem SOAP-Parsing. Für das Lesen und Parsing der empfangenen Push-Nachricht wurde der entsprechende Code aus der Methode call in die Methode receive ausgelagert, so dass er auch ohne eine Anfrage benutzt werden kann. Nach erfolgreichem Parsing kann auf die erzeugten Objekte über das KvmSerializable-Interface des Resultats mit der Methode getproperty zugegriffen werden. Die Schnittstellen aus MIDP und CLDC stellen keine Möglichkeit zum Abfragen des aktuellen Funkverbindungsstatus zur Verfügung. Dies wäre für die Methode update- Activity jedoch wünschenswert, um die Methode im Offline-Zustand des Endgeräts direkt verlassen zu können, statt auf eine Timeout-Rückmeldung des Betriebssystems warten zu müssen. Für BB-Geräte gibt es eine herstellerspezifische Lösung über die Klasse net.rim.device.api.system.radioinfo, die eine Anwendung jedoch nur verwenden kann, wenn sie mit einem kostenpflichtigen Lizenzschlüssel von RIM signiert ist. 5.3 RMS-Schnittstelle Die Schnittstelle des RMSmanager wurde im Design schon vorgestellt (siehe Abschnitt 4.2.3). Die MIDP-API für den Zugriff auf RecordStores wurde im Grundlagenteil beschrieben. In Quellcode-Listing 5.4 wird beispielhaft eine der Methoden des RMSma- 92

107 Kapitel 5. Implementierung 5.3. RMS-Schnittstelle public ActivityBO receivepush(final InputStream inputstream) 2 throws ApplicationException { 4 final SoapSerializationEnvelope envelope = new SoapSerializationEnvelope(SoapEnvelope.VER11); 6 // add mappings for complex custom types 8 envelope.addmapping("http://csc.com/bbsap", "ActionPushRequest", 10 new ActionPushRequest().getClass()); envelope.addmapping("http://csc.com/bbsap", 12 "Activity", new Activity().getClass()); 14 // needs not to be initialized with URL, // because only a Push is received here (no request) 16 final HttpTransport http = new HttpTransport(null); 18 try { http.receive(inputstream, envelope); 20 } catch (final IOException e) { //... Fehlerbehandlung 22 } Object result = envelope.bodyin; 24 // get ActivityBO 26 result = ((ActionPushRequest) result).getproperty(0); 28 return (ActivityBO) result; } Quellcode 5.3: SAPmanager.java: Methode receivepush nagers dargestellt. Die Instanzen m_byteout und m_out der Streaming-Klassen werden von allen Methoden des RMSmanagers wiederverwendet und nach Benutzung lediglich geschlossen. Für InputStream-Instanzen lässt sich diese Optimierung nicht vornehmen. Beim Speichern eines ActivityEntryBO muss unterschieden werden, ob es sich um einen neuen Datensatz handelt (ID ist -1). In dem Fall muss die nächste zu vergebende ID des RecordStores erfragt werden und im BO gespeichert werden, bevor es dann serialisiert und mit der RMS-Methode addrecord abgespeichert werden kann. Existiert der Datensatz bereits, so wird der alte mit der RMS-Methode setrecord überschrieben. Wichtig ist, dass der zu Beginn geöffnete RecordStore immer vor dem Beenden der Methode wieder geschlossen wird, was durch den finally-block sichergestellt wird. Anderenfalls bleiben die Deskriptoren für den RecordStore geöffnet, auch nach beenden des MIDlets. Die lesenden Methoden des RMSmanager benutzen einen gemeinsamen Puffer zum Einlesen, welcher mit der Methode assertbuffersize(int size) auf die benötigte Größe des zu lesenden Datensatzes angepasst ist. Dies spart CPU-Leistung, da nicht für jede Operation erneut ein Puffer allokiert wird. Bei Datensätzen, deren Größe stark variiert, kann dies zu erhöhtem Speicherverbrauch führen, da der Puffer sich nicht mehr 93

108 5.4. Multi-Threading Kapitel 5. Implementierung 1 //... private static final String ACTIVITY_ENTRY_STORE = "ActivityEntries"; 3 private ByteArrayOutputStream m_byteout; private DataOutputStream m_out; 5 private void saveactivityentry(final ActivityEntryBO activityentry) 7 throws RecordStoreException{ 9 final boolean createifnecessary = true; RecordStore rs = null; 11 try { 13 rs = RecordStore.openRecordStore(ACTIVITY_ENTRY_STORE, createifnecessary); 15 if (activityentry.getrecordid() == -1) { 17 // new record, set id before serialize activityentry.setrecordid(rs.getnextrecordid()); 19 activityentry.serialize(m_out); final byte[] data = m_byteout.tobytearray(); 21 // create new record rs.addrecord(data, 0, data.length); 23 } else { activityentry.serialize(m_out); 25 final byte[] data = m_byteout.tobytearray(); // record update 27 rs.setrecord(activityentry.getrecordid(), data, 0, data.length); } 29 m_byteout.reset(); } catch (RecordStoreException e) { 31 throw e; } finally { 33 if (rs!= null) { rs.closerecordstore(); 35 } } 37 } Quellcode 5.4: RMSmanager.java: Methode saveactivityentry verkleinert. Bei Aktivitäten sind die Attribute jedoch statisch vorgegeben, so dass die Datensatz-Größe nicht stark streut. Dadurch entstehen bei der Wiederverwendung des Puffers in diesem Fall keine Nachteile. 5.4 Multi-Threading Im Design-Kapitel wurden bereits die drei in mobilecrm verwendeten Threads entworfen. Der Hauptstrang (GUI-Thread) ist für die Darstellung der graphischen Komponenten im Package com.csc.bb.mobilecrm.gui zuständig. Die Schnittstelle zum Model, der ModelController, führt lang andauernde Vorgänge im Model in einem anderen Thread (Worker-Thread) aus, so dass die Benutzerschnittstelle nicht blockiert. Um Push- Nachrichten empfangen zu können existiert ein weiterer Thread (Push-Thread), der ein- 94

109 Kapitel 5. Implementierung 5.4. Multi-Threading gehende Push-Verbindungen annimmt und abarbeitet. Im folgenden Abschnitt wird näher auf die Threads im Hintergrund eingegangen, da der Hauptstrang keine Besonderheiten aufweist, die an dieser Stelle betrachtet werden müssen Worker-Thread Der ModelController erweitert java.lang.thread und bietet die Funktionalität der Methoden im Interface ModelFacade. Da der ModelController jedoch für asynchrone Aufrufe gedacht ist, und das Model für synchrone, unterscheiden sich die Methoden-Signaturen, so dass der Zusammenhang nicht durch class Model- Controller implements ModelFacade ausgedrückt werden kann. Auf eine weitere Schnittstelle, die AsyncModelFacade heissen könnte, wurde an dieser Stelle verzichtet, um die Anwendung so schlank wie möglich zu halten. Die öffentlichen Methoden des ModelControllers, die mit der Ausführung im Worker-Thread zu tun haben, sind alle durch das Keyword synchronized vor konkurrierenden Zugriffen geschützt. So ist sichergestellt, dass im Model durchzuführende Vorgänge durch den Worker-Thread seriell abgearbeitet werden. Deadlocks können dabei nicht entstehen, da jeder Vorgang im ModelController unabhängig von anderen Vorgängen ist und irgendwann terminiert. Am Beispiel der Methode getactivity() wird die Funktionsweise des ModelControllers näher erläutert. Die Implementierung für den asynchronen Aufruf aus der GUI- Schicht findet sich in Quellcode-Listing public synchronized void getactivity(final Integer recordid) { m_action = GET_ACTIVITY; 3 m_param = recordid; notifyall(); 5 } Quellcode 5.5: ModelController.java: Methode getactivity Über das Attribut m_action wird dem Worker-Thread über eine ID mitgeteilt, welche Methode im Model aufzurufen ist. Ein optionaler Parameter vom Typ Object kann an das Attribut m_param zugewiesen werden - in diesem Fall die RecordID der auszulesenden Aktivität. Nun wird mit notifyall() der schlafende Worker-Thread aufgeweckt, andere Threads warten nicht auf die ModelController-Instanz. Der Worker-Thread führt die Methode run() des ModelControllers aus. Dort wird in einer Endlos-Schleife je Zyklus ein Vorgang im Model durchgeführt, und der Thread wartet bis zum nächsten Aufruf. 95

110 5.4. Multi-Threading Kapitel 5. Implementierung 1 private void handlegetactivity(final Integer recordid) { try { 3 ActivityBO activity = m_model.getactivity(recordid.intvalue()); m_caller.updatedata(activity); 5 m_statusbar.shownextscreen(); } catch (ApplicationException e) { 7 //... error handling } 9 } Quellcode 5.6: ModelController.java: Methode handlegetactivity 1 public void stop() { m_stopped = true; 3 m_instance = null; try { 5 synchronized (this) { notifyall(); 7 } } catch (final IllegalMonitorStateException e) { 9 // Worker-Thread arbeitet gerade // und beendet sich danach 11 } m_model.stoppushreceiver(); 13 } Quellcode 5.7: ModelController.java: Methode stop Anhand der ID in m_action wird in run() die zugehörige Handler-Methode aufgerufen, die in Quellcode-Listing 5.6 dargestellt ist. Die Aufgabe wird an das Model delegiert, und der Rückgabewert ist eine ActivityBO- Instanz. Über die Schnittstelle AsyncDataHandler wird das Business Object an die aufrufende GUI-Komponente übergeben. Dies setzt voraus, dass diese vor dem Auruf von getactivity zunächst beim ModelController mittels setcaller(- AsyncDataHandler caller) registriert wird. Als Abschluß eines Vorgangs wird der Folge-Screen des StatusBar angezeigt. Zum Beenden des Worker-Threads (siehe Quellcode-Listing 5.7) wird die Abbruchbedingung der Schleife in run() erfüllt, und der Worker-Thread aufgeweckt, so dass die Methode verlassen wird und der Thread sich beendet. Wenn der Worker-Thread gerade aktiv ist, beendet er sich erst nach Abschluß des Vorgangs im Model. Der Push-Receiver im Model wird auch durch den ModelController beendet. 96

111 Kapitel 5. Implementierung 5.4. Multi-Threading 1 public void run() { //... 3 try { m_connection = (StreamConnectionNotifier) Connector.open(m_pushUrl); 5 } catch (IOException e1) { m_errorhandler.reporterror(e1); 7 } 9 while (!m_stopped) { try { 11 m_blocking = true; // wait for Push connection 13 streamconnection = m_connection.acceptandopen(); // connection should NOT be closed by stop() 15 // while receiving data m_blocking = false; 17 inputstream = streamconnection.openinputstream(); 19 // parse SOAP message final ActivityBO activity = m_sapmanager.receivepush(inputstream); 21 // save activity in RMS 23 RMSmanager.getInstance().saveActivity(activity); 25 streamconnection.close(); } 27 //... error handling } 29 } Quellcode 5.8: PushReceiver.java: Methode run Push-Thread Der Thread zum Empfangen neuer Push-Nachrichten ist in der Klasse PushReceiver implementiert. Die Methode run() ist entsprechend überschrieben und ist in Quellcode- Listing 5.8 dargestellt. Zunächst wird ein Connection-Objekt erzeugt, das auf eingehende Verbindungen wartet. Dabei wird die Art des Protokolls und der Port in Form einer URL angegeben. Die BB-Endgeräte benötigen für TCP-Verbindungen auf Port 8888 die URL während es beim Emulator von Sun socket://8888 ist. Die MIDP Spezifikation schreibt nicht vor, welche Protokolle auf einem Endgerät für eingehende Verbindungen unterstützt werden müssen. Nachdem das Connection-Objekt vorhanden ist, werden in einer Endlosschleife Verbindungen entgegen genommen und verarbeitet, bis der Thread beendet werden soll. Mit der Methode acceptandopen() wartet das Connection- Objekt blockierend auf eine eingehende Verbindung. Die Methode kehrt zurück, wenn eine Push-Verbindung aufgebaut ist. Für die weitere Verarbeitung wird der InputStream des Connection-Objekts zum Einlesen und Deserialisieren der SOAP-Nachricht an den SOAP Parser (SAPmanager) übergeben. Das resultierende ActivityBO-Objekt wird 97

112 5.5. Logging und Internationalisierung Kapitel 5. Implementierung im RMS gespeichert, und der Datenstrom geschlossen. Falls die Abbruchbedingung nicht gesetzt wurde, wird dann auf weitere Push-Verbindungen gewartet. Die Methode stop() (siehe Quellcode-Listing 5.9) zum Beenden des Push-Threads setzt die Abbruchbedingung auf true, und falls der Thread gerade beim Warten auf Push-Verbindungen blockiert, wird noch die Connection-Instanz durch close() geschlossen. Dadurch kehrt acceptandopen() zurück, und run() wird in jedem Fall beendet. 1 public void stop() { Log.info(this, "stopping"); 3 m_stopped = true; if(m_blocking) { 5 // interrupt blocking operations try { 7 m_connection.close(); } catch (IOException e) { 9 //... } 11 } } Quellcode 5.9: PushReceiver.java: Methode stop 5.5 Logging und Internationalisierung J2ME stellt für die Internationalisierung von Anwendungen keine API zur Verfügung. Um die Daten getrennt vom Code zu halten, bieten sich Key-Value-Paare in Form von Property-Dateien an, wie sie in J2SE bekannt sind. Für jede Sprache wird dabei eine eigene Datei angelegt, in der der Key ein Bezeichner für eine Ressource wie beispielsweise die Beschriftung einer Titelleiste ist, und der Wert die zugehörige Beschriftung in der entsprechenden Sprache. Ein Überblick der Klassenhierarchie für Internationalisierung und Logging findet sich in Abbildung 5.2. Die Dateien werden im JAR der Anwendung hinterlegt, worauf dann mit der generisch gehaltenen Klasse PropertyFileReader zugegriffen werden kann - J2ME stellt auch diese Funktion nicht standardmäßig bereit. Mit der statischen Klasse I18nResources werden die Konventionen für Dateipfade und -namen der der Sprachdateien sowie für die Bezeichnung der Ressourcen festgelegt. Die Sprachdateien liegen innerhalb des JARs in /resources/i18n/ und tragen als Dateinamen die Sprachkennung nach ISO 639 Code mit der zusätzlichen Endung.property, also beispielsweise de.property für 98

113 Kapitel 5. Implementierung 5.5. Logging und Internationalisierung Abbildung 5.2: Klassen für Internationalisierung und Logging die deutsche Sprache. Auf die Sprachkennung kann innerhalb J2ME über die System- Property microedition.locale zugegriffen werden. Das WirelessToolkit von Sun benutzt dabei RFC 4646 (z.b. de-de), während die BB-Endgeräte die Kennung nach ISO 639 (z.b. de) verwenden. Da aus dem String nach RFC 4646 der Code gemäß ISO 639 extrahiert werden kann, wurde dieser als kleinster gemeinsamer Nenner für die Sprachkennung gewählt, die die Methode loadresources(string locale) erwartet. Die entsprechende Property-Datei wird eingelesen, und die Key-Value-Paare werden in einer Hashtable-Instanz gehalten. Der Bezeichner einer Ressource beginnt mit dem Klassennamen in dem die Ressource benötigt wird und einem frei definierbaren Folge-String, der mit einem Punkt abgetrennt ist. Zum Abrufen einer Ressource aus der Hashtable wird die Methode getstring(object obj, String resource) bereitgestellt, wobei obj das Objekt ist, das die Ressource anfragt, und resource der Folge-String. Soll die Methode innerhalb einer statischen Methode aufgerufen werden, so kann statt dem Objekt auch eine Instanz der Klasse Class übergeben werden. Da die Umwandlung einer Objekt- oder Class-Instanz in den Klassennamen allgemeingültig ist und auch für das Logging benötigt wird, wurde diese Funktion in die Klasse StringUtils ausgelagert. Ein typischer Aufruf der Methode innerhalb des Hauptmenüs MainMenu könnte also folgendermaßen aussehen: I18nResources.getString(this, "title"). Dabei wird aus der entsprechenden Sprachdatei bzw. der Hashtable der Wert für den Key Main- 99

114 5.6. Workarounds Kapitel 5. Implementierung Menu.title ausgelesen. Für das Logging wird die in der Analyse ausgewählte Bibliothek Microlog (siehe Abschnitt 3.4.4) verwendet. Um den kompletten Code der mobilen Anwendung nicht von den Microlog-Klassen abhängig zu machen, wird eine eigene Wrapper-Klasse Log eingeführt, die intern Microlog verwendet. Die Methoden sind an die Microlog-API angelehnt. Eine Priorisierung der Meldungen erfolgt somit über die Methoden error(), info() und debug(). Jedoch wird zusätzlich zur zu loggenden Nachricht noch der Klassenname mit geloggt, in der die Meldung verursacht wurde. Weiterhin sind optionale Informationen wie die Zeit der Nachrichtenausgabe in Millisekunden und Informationen zum ausführenden Thread zuschaltbar. Damit die Meldungen aufgrund des Multithreadings sich nicht gegenseitig beeinträchtigen, sind alle Logging-Methoden synchronized. 5.6 Workarounds In diesem Abschnitt werden implementierungsspezifische Probleme besprochen, die im Zusammenhang mit der Hersteller-Implementierung von MIDP stehen javax.microedition.midlet.midlet Die Spezifikation der MIDP-API sieht innerhalb der Methode startapp() vor, dass im schweren Fehlerfall notifydestroyed() aufgerufen wird, um das MIDlet zu beenden. Handelt es sich nur um einen temporären Fehler, der beim nächsten Start der Anwendung möglicherweise nicht mehr auftritt, so soll stattdessen eine MIDletState- ChangeException geworfen werden. Der Codeausschnitt in Quellcode-Listing 5.10 führt auf dem BB-Endgerät und dem Simulator zu einer Ausnahme in der Implementierung des Herstellers. protected void startapp() throws MIDletStateChangeException { 2 notifydestroyed(); } Quellcode 5.10: Bug in Klasse MIDlet Anhand einer minimalen Testanwendung (MIDlet_Destroy_Bug) kann der Fehler nachvollzogen werden. Die entsprechende Log-Ausgabe des Endgeräts findet sich in Quellcodelisting Erwähnt sei an dieser Stelle noch, dass dieser Fehler mit der Referenzimplementierung im Emulator von Sun (Bestandteil des WTK) nicht auftritt. 100

115 Kapitel 5. Implementierung 5.6. Workarounds 1 Started mobilecrm(101) Foreground mobilecrm(100) 3 START_APP END_APP 5 Foreground net_rim_bb_ribbon_app(63) Exit mobilecrm(100) 7 RuntimeException java.lang.nullpointerexception 9 net_rim_cldc-2 MIDletMain 11 <private> 0x7042 Quellcode 5.11: Log-Ausgabe der Testanwendung MIDlet_Destroy_Bug Als Workaround für dieses Problem wird in mobilecrm bei schwerwiegenden Fehlern innerhalb von startapp() stattdessen immer eine MIDletStateChange- Exception geworfen. Dadurch wird die Anwendung ebenso beendet, der oben beschriebene Fehler tritt jedoch nicht auf javax.microedition.lcdui.gauge Mit der Klasse Gauge kann dem Benutzer ein Fortschritt angezeigt werden. Dabei kann unterschieden werden, ob der Vorgang definierte Einzelschritte hat oder nicht, und ob die Anwendung gerade aktiv ist oder sich in einem Wartezustand befindet. Der Codeausschnitt in Quellcode-Listing 5.12 initialisiert die Darstellung für einen Vorgang mit undefiniert vielen Einzelschritten in einem arbeitenden Zustand. Die Darstellung auf dem Endgerät ist meist als drehende Sanduhr realisiert, während definierte Einzelschritte als Fortschrittsbalken dargestellt werden. Sobald der Konstruktor mit den beschriebenen Parametern aufgerufen wird, ist die CPU des Rechners ausgelastet, auf dem der Emulator läuft. Beim Emulator des WTK ist dies nicht der Fall. Auf dem Endgerät kann darüber keine Aussage getroffen werden, da es keine Überwachungsmöglichkeit gibt, jedoch scheint der Fehler dort nicht aufzutreten, die Benutzbarkeit der Anwendung ist im Gegensatz zum Emulator nicht eingeschränkt. Als Workaround für den Simulator kann die Erzeugung der Gauge-Instanz auskommentiert werden, was lediglich eine graphische Einbuße ist und die Funktion der Anwendung nicht beeinträchtigt. Gauge gauge = new Gauge("test", false, Gauge.INDEFINITE, Gauge.CONTINUOUS_RUNNING); Quellcode 5.12: Bug in Klasse Gauge 101

116 5.6. Workarounds Kapitel 5. Implementierung Statische PushRegistry-Verbindungen im JAD Verbindungen, die für die Funktion eines MIDlets zwingend und dauerhaft erforderlich sind, können nach der MIDP-Spezifikation statisch über einen Eintrag im JAD registriert werden (siehe [MW06] Seite 89). Das BlackBerry-Endgerät (7100v) bricht die Installation einer MIDlet-Suite jedoch nicht spezifikationsgemäß ab, wenn der zu registrierende Port bereits von einer anderen Applikation verwendet wird. Schwerwiegender ist jedoch das Problem, dass die AMS die statische Registrierung entfernt, falls die Anwendung auf dem registrierten Port eine Server-Verbindung öffnet, ohne dass eine eingehende Push- Verbindung verfügbar ist. Eine erneute Registrierung ist nicht möglich, wenn das statische Registrierungsverfahren über den JAD genutzt wurde. Das Entfernen von statischen Einträgen ist in der Spezifikation nicht vorgesehen und nach [Sch04] S. 223 nicht möglich. Wenn das entsprechende MIDlet gestartet ist, nimmt die AMS laut MIDP keine Push- Verbindungen mehr für die Anwendung entgegen, so dass an dieser Stelle das Öffnen einer Server-Verbindung notwendig ist. Dieses Problem kann umgangen werden, indem die Verbindung für Push-Nachrichten dynamisch registriert wird. Der Nachteil der dabei entsteht ist, dass die Anwendung einmalig gestartet werden muss, bevor Push-Nachrichten empfangen werden können Initialisierung von statischen Attributen Ein ClassLoader in Java ist dafür verantwortlich, die zur Ausführung benötigten Klassen einzulesen. Dabei werden auch statische Attribute der zu ladenden Klassen initialisiert. Nach dem Beenden einer Anwendung auf einem mobilen Endgerät würde man möglicherweise erwarten, dass die statischen Variablen oder gar der gesamte Classloader von der Garbage-Collection aus dem Speicher entfernt werden. Bei den Implementierungen des BB-Endgeräts und des BB-Simulators ist dies jedoch nicht der Fall, bei erneutem Starten einer Anwendung sind die Variablen noch mit den vormaligen Werten initialisiert. Als minimale Testanwendung dient ein MIDlet mit einem statischen Zähler vom Typ int. Um Fehler zu umgehen, werden statische Variablen, insbesondere bei den Singleton-Klassen, vor Beenden der Anwendung zurückgesetzt, so dass die Variablen sauber hinterlassen werden, und die dann nicht mehr referenzierten Instanzen entfernt werden können. 102

117 Kapitel 5. Implementierung 5.7. Qualitätssicherung 5.7 Qualitätssicherung Styleguide Mit dem bereits erwähnten Eclipse-Plugin Checkstyle (siehe Abschnitt 5.1) wird der Quellcode von mobilecrm anhand von Regeln überprüft. Diese werden durch ein XML- Dokument spezifiziert (checkstyle-config.xml), das auch über den Konfigurationsdialog in Eclipse erstellt werden kann. Neben der Benutzung der parametrisierbaren Standard-Module gibt es auch die Möglichkeit, eigene Checkstyle-Module zu entwickeln. Im Folgenden werden nur einige ausgewählte Regeln beschrieben, die nicht Bestandteil der üblichen Java-Konventionen sind: Attribute beginnen mit dem Präfix m_ (von Member-Variable), um Attribute von lokalen Variablen optisch unterscheiden zu können, und um Shadowing zu vermeiden, also das Scope-bedingte Verdecken von Variablen mit gleichem Namen. Die Basisklasse Exception und RuntimeException sollten nicht in catch- Blöcken verwendet werden (bzw. nur an bestimmten Stellen). Hintergrund ist, dass mehrere zu fangende Exception-Typen nicht nur einen einzigen catch- Block gefangen werden sollen, da dort beispielsweise auch Nullpointer- und OutOfMemoryExceptions gefangen würden. Die Verschachtelung von try-blöcken ist nicht zugelassen, bei if maximal bis zu einer Tiefe von 2. Dies verbessert die Wartbarkeit des Codes und verringert die Fehleranfälligkeit. Referenzen, die nicht modifiziert werden, sollten als final deklariert werden. Dadurch kann die JVM Optimierungen bei der Ausführung vornehmen. Klassen mit ausschließlich statischen Methoden sollten Konstruktoren als private deklarieren. Die nicht zweckgemäße Instanziierung solcher Klassen ist somit unterbunden. Alle weiteren Regeln können der Konfiguration von Checkstyle entnommen werden. In der Summe tragen sie zu einem einheitlichen, konsistenten Programmierstil bei, und helfen Programmierfehler zu vermeiden sowie Best-Practices durchzusetzen. 103

118 5.7. Qualitätssicherung Kapitel 5. Implementierung Abbildung 5.3: Kiviat-Graph der Metriken von mobilecrm Software-Metriken Die Kenngrößen einer statischen Codeanalyse wurden mit dem Werkzeug SourceMonitor 1 ermittelt. Die wichtigsten Kenngrößen sind in Abbildung 5.3 dargestellt. Alle weiteren Messwerte finden sich auf der CD-ROM zu dieser Arbeit. Dabei ist zu sagen, dass die Komplexität, Anzahl der Statements in einer Methode und vergleichbare Messgrößen erhöht sind. Dies ist darauf zurückzuführen, dass bestimmte Vorgänge mit allen Attributen einer Aktivität durchzuführen sind. Das Aufsplitten dieser Methoden wäre semantisch jedoch nicht sinnvoll und würde die Fehleranfälligkeit des Codes auch tendenziell eher vergrößern Automatisierte Tests Die Durchführung automatisierter Tests mit dem bereits angesprochenen J2MEUnit- Framework (Abschnitt 3.4.4) beschränkt sich auf die Model-Schicht, da die GUI nur manuell getestet werden kann. Die Unit-Tests sind als eigenes Projekt (mobilecrmtestsuite) angelegt, mit Abhängigkeiten zu mobilecrm und der ksoap-bibliothek. Dies hält die

119 Kapitel 5. Implementierung 5.8. Implementierungsaufwand Datei Lines Of Code MobileCrmMIDlet.java 249 Tabelle 5.1: LOC des Package com.csc.bb.mobilecrm Build-Prozesse der einzelnen Projekte übersichtlicher. Die wichtigsten Komponenten im Model sind der RMSmanager und der SAPmanager, in denen die eigentliche Datenverarbeitung stattfindet. Für diese Komponenten wurden Tests angelegt, die mit lokalen Datenströmen arbeiten, damit die Datenkommunikation verifiziert werden kann, und die Tests ohne SAP-System und Netzwerkverbindung durchgeführt werden können. Dafür müssen die zu testenden Klassen entsprechende Test- Parameter erhalten, so dass die darüber liegende Schicht, das Model, nicht mitgetestet werden kann. Die Klasse SAPmanager wurde zur Testbarkeit so erweitert, dass eine Verbindung übergeben werden kann, anstatt eine HTTP-Verbindung zu erzeugen. Um diese Möglichkeit auch auf Ebene des SOAP-Parsers zu haben, wurde die ksoap Bibliothek um eine überladene Methode call erweitert, die eine ServiceConnection der ksoap-api entgegennimmt. Die Testdaten liegen als SOAP-Nachrichten in Form von XML-Dateien vor, die jeweils eingelesen werden, und in einen Datenstrom konvertiert werden, der an die modifizierte Implementierung der ServiceConnection (MyServiceConnection) übergeben werden kann. Die Instanz der ServiceConnection wird an den SAPmanager übergeben, der das SOAP-Parsing übernimmt. Das Ergebnis kann mit einer ActivityBO-Instanz aus der Klasse ActivityTestData verglichen werden. Um eine eingehende Push-Verbindung zu testen muss diese ServiceConnection nicht verwendet werden, da die Methode direkt einen InputStream entgegen nimmt. Die Klasse RMSmanager kann auch im Emulator getestet werden, so dass spezielle Vorkehrungen für das Testen nicht zu treffen sind. Die Methoden werden mit Testdaten aus der Klasse ActivityTestData getestet, so dass die Ergebnisse verifiziert werden können. 5.8 Implementierungsaufwand Dieser Abschnitt gibt den Implementierungsaufwand von mobilecrm in Lines Of Code (LOC) inklusive Kommentarzeilen an. 105

120 5.8. Implementierungsaufwand Kapitel 5. Implementierung Datei Lines Of Code ActivityList.java 183 AsyncDataHandler.java 11 BasicAlert.java 140 BasicScreen.java 38 MainMenu.java 109 ModelController.java 385 SettingsMenu.java 84 ShowActivityForm.java 495 StatusBar.java 108 Tabelle 5.2: LOC des Package com.csc.bb.mobilecrm.gui Datei Lines Of Code ActivityBO.java 733 ActivityEntryBO.java 154 AsyncEventHandler.java 11 BasicBO.java 53 Model.java 242 ModelFacade.java 17 ProgressObserver.java 9 SAPUserBO.java 59 Tabelle 5.3: LOC des Package com.csc.bb.mobilecrm.model Datei Lines Of Code RMSmanager.java 441 Serializable.java 23 Tabelle 5.4: LOC des Package com.csc.bb.mobilecrm.model.backend.rms Datei Lines Of Code ActionPushRequest.java 49 Activity.java 480 ActivityList.java 60 ActivityListRequest.java 86 ActivityListResponse.java 48 ChangeActivityRequest.java 115 ChangeActivityResponse.java 54 PushReceiver.java 122 SAPmanager.java 275 Tabelle 5.5: LOC des Package com.csc.bb.mobilecrm.model.backend.sap 106

121 Kapitel 5. Implementierung 5.8. Implementierungsaufwand Datei Lines Of Code ApplicationException.java 58 I18nResources.java 60 Log.java 149 PropertyFileReader.java 96 StringUtils.java 57 Tabelle 5.6: LOC des Package com.csc.bb.mobilecrm.util Datei Lines Of Code ActivityTestData.java 141 AllTests.java 34 MobileCRMtestrunner.java 18 MyServiceConnection.java 54 RMSmanagerTests.java 82 SAPmanagerTests.java 226 Tabelle 5.7: LOC des Package com.csc.bb.mobilecrm.tests Datei Lines Of Code mobilecrm 5253 mobilecrmtestsuite 555 Gesamt 5808 Tabelle 5.8: LOC von mobilecrm und mobilecrmtestsuite 107

122 5.9. Performance-Bewertung Kapitel 5. Implementierung Abbildung 5.4: Messaufbau und Bezeichnung der Messwerte 5.9 Performance-Bewertung An dieser Stelle werden die im Rahmen von mobilecrm durchgeführten Performance- Messungen zunächst aufgearbeitet und dann bewertet. Diese sind notwendig, um Aussagen über die Praxistauglichkeit der in der Systemarchitektur dieser Arbeit kombinierten Komponenten treffen zu können. Weiterhin können dadurch die primären leistungsbegrenzenden Komponenten ausgemacht werden. Die Messungen wurden auf dem BB-Endgerät als J2MEUnit-Test realisiert. Das Test- Szenario ist der Anwendungsfall Aktivitätenliste anfordern, da dieser vom Endgerät aus initiiert wird, Request und Response beinhaltet, und die Nutzlast vom SAP-CRM in Richtung des BBs variabel ist. Die Testimplementierung ruft die Methode SAPmanager-.getActivities auf, und die Nutzlast kann über die im SAP-CRM verfügbaren Aktivitäten gesteuert werden. Dadurch wird für jede einzelne Messung eine Verbindung aufund abgebaut, was jedoch erwünscht ist, um einen realistischen Testfall zu haben. Zur Testumgebung ist zu sagen, dass SAP-CRM, SAP-XI, BES und deren Netzwerkverbindung nur durch den Test-Client benutzt wurden, so dass die Ergebnisse nicht durch andere Benutzer verfälscht werden. Dies sind optimale Voraussetzungen, so dass in der Praxis eher mit höheren Latenzzeiten zu rechnen ist. Auf der anderen Seite ist das Testsystem auf nicht so leistungsfähiger Hardware installiert, wie es in Produktivsystemen üblich ist. Zu der Auslastung des Mobilfunkanbieters und der RIM-Infrastructure kann keine Aussage getroffen werden. Für die Performance-Tests wurden zunächst innerhalb der ksoap-bibliothek Zeitnahmen in den Code implementiert. Dies geschieht durch Aufruf der Methode System.currentTimeMillis(), die eine Auflösung von 10 Millisekunden hat. Daraus folgt, dass die ermittelten Durchschnittswerte im schlimmsten Fall eine Ungenauigkeit von 10ms haben. Durch den niedrigsten in allen Messreihen ermittelten Wert von 108

123 Kapitel 5. Implementierung 5.9. Performance-Bewertung Abbildung 5.5: Zeit zum Serialisieren der Anfrage in SOAP-XML-Markup 1750ms ergibt sich ein maximaler prozentualer Fehler unter 0,572%. Die Berechnung der Zeitdifferenzen zwischen Messpunkten und die Ausgabe erfolgt erst nach Abschluss einer einzelnen Messung, während einer Messung finden keine Log-Ausgaben statt. Das mobile Endgerät befand sich bei allen Messreihen am selben Ort, so dass der Funk-Empfang vergleichbar ist, der im Übrigen eine gute Signalstärke (-55dBm) aufwies. Der Messaufbau und die Bezeichnung der einzelnen gemessenen Teilstrecken sind in Abbildung 5.4 dargestellt. Die Verbindung zwischen XI und SAP-CRM ist dabei lokal, da beide Anwendungen auf einem Host installiert sind. Die Auswertung der Messgröße Request Parsing wird den Messreihen vorangestellt, da diese Zeitspanne unabhängig von der im Response übertragenen Nutzlast ist und im Vergleich zu anderen Messwerten nicht ins Gewicht fällt. Unter Request Parsing ist die Serialisierung zu verstehen, um aus dem Java-Objekt, das die Daten des Requests enthält, SOAP-XML-Markup zu generieren. In Abbildung 5.5 sind die gemessenen Werte aus den ersten beiden Messreihen dargestellt. Der größte gemessene Wert beträgt 240ms und die Payload ist bei allen Messreihen vergleichbar Messreihe 1 Der Performance-Unittest ist so konfiguriert, dass nacheinander 100 Anfragen vom BB- Endgerät über das XI an das SAP-CRM gesendet werden. Dabei wird in Messreihe 1 zunächst der minimale Testfall betrachtet, bei dem nur eine Aktivität vom SAP-CRM 109

124 5.9. Performance-Bewertung Kapitel 5. Implementierung Gesamtzeit Resp. Parsing Antwortzeit XI Arithmetisches Mittel Minimum Maximum Standardabweichung Tabelle 5.9: Statistische Kenngrößen zu Messreihe 1 (Einheit [ms]) Abbildung 5.6: Messreihe 1: Eine Aktivität als Payload aus gesendet wird. Die nächste Anfrage wird jeweils erst gesendet, wenn die zugehörige Antwort vollständig empfangen und durch das Parsing wurde, sowie die Zeitberechnung stattgefunden hat und ausgegeben wurde. Nach der Ausgabe wird der Test-Thread noch pauschal zwei Sekunden pausiert, so dass die Vorgänge im Betriebssystem, die mit der Ausgabe zu tun haben, gänzlich abgeschlossen sind und einen nächsten Testlauf nicht beeinträchtigen. Die Messergebnisse sind graphisch in Abbildung 5.6 dargestellt. Die statistischen Kenngrößen können Tabelle 5.9 entnommen werden. Die Gesamtzeit wurde in der modifizierten ksoap-bibliothek gemessen. Die Zeitnahme erfolgte dabei vor Deserialisieren der Anfrage und nach dem erfolgreichen Parsing der Antwort. Durch einen weiteren Messwert vor dem Parsing lässt sich dessen Dauer ermitteln. Die Antwortzeit berechnet sich aus der Gesamtzeit abzüglich der Parsing-Zeit von Request und Response. Dem Performance-Monitoring von XI lassen sich die Zeiten für die Bearbeitungszeit der einzelnen Requests entnehmen. Diese Zeit umfasst die Verarbeitung im SAP-XI, die Übertragung zum SAP-CRM und dessen Verarbeitung sowie den Rücktransport und die erneute Bearbeitung des XI. Dabei sei noch einmal darauf 110

125 Kapitel 5. Implementierung 5.9. Performance-Bewertung Abbildung 5.7: Messreihe 2: 14 Aktivitäten als Payload hingewiesen, dass im konkreten Testaufbau die Anwendungen SAP-XI und SAP-CRM auf einem Host installiert sind. Von einem Ausreißer im statistischen Sinne wird in den folgenden Messreihen gesprochen, wenn ein Wert nicht im Intervall des Durchschnitts plus/minus der zweifachen Standardabweichung liegt Messreihe 2 Diese Messreihe wurde unter den gleichen Voraussetzungen wie Messreihe 1 durchgeführt, allerdings mit 14 Aktivitäten als Nutzlast, um das Verhalten der einzelnen Systemkomponenten bei größeren Datenmengen zu testen. Die Darstellung der Messwerte in Abbildung 5.7 zeigt, dass bei dieser zweiten Messreihe starke Schwankungen bei der Datenübertragung vorhanden sind. Eine der 100 durchgeführten Messungen brach sogar durch eine Timeout-Exception ab, weshalb nur 99 Messwerte vorhanden sind. In der Konsolen-Ausgabe des Endgeräts konnten bei der erhöhten Nutzlast deutlich mehr Garbage-Collection-Aufrufe festgestellt werden. Die Zeit für das Parsing des Requests ist jedoch sehr stabil, weshalb die Garbage-Collection-Aufrufe nicht als Begründung für die Ausreißer der Antwortzeit in Frage kommen. Die Antwortzeiten des SAP-XI sind konstant gering, und die Ursache der Schwankungen ist daher vermutlich zwischen dem BES und dem BB-Endgerät zu suchen, denn die CPU-Auslastung auf dem BES ist gering und die Internetanbindung ausreichend dimensioniert. 111

126 5.9. Performance-Bewertung Kapitel 5. Implementierung Gesamtzeit Resp. Parsing Antwortzeit XI Arithmetisches Mittel Minimum Maximum Standardabweichung Tabelle 5.10: Statistische Kenngrößen zu Messreihe 2 (Einheit [ms]) Abbildung 5.8: Messreihe 3: Zehn Aktivitäten als Payload Messreihe 3 Innerhalb der Messreihe 3 wurden ebenfalls 100 Anfragen vom Endgerät über XI an das CRM gesendet, jedoch umfasst die Antwort des CRM zehn Aktivitäten als Nutzlast. Durch diese Messreihe soll erörtert werden, wie sich Parsing und Antwortzeit bei weniger als 14 Aktivitäten verhalten. Die Darstellung der gemessenen Werte ist Abbildung 5.8 zu entnehmen, die statistischen Kenngrößen finden sich in Tabelle Es zeigt sich, dass die Schwankungen der Antwortzeit deutlich geringer ausfallen als in Messreihe 2. Resp. Parsing Antwortzeit XI Arithmetisches Mittel Minimum Maximum Standardabweichung Tabelle 5.11: Statistische Kenngrößen zu Messreihe 3 (Einheit [ms]) 112

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Java Micro Edition. Entwicklung mobiler JavaME-Anwendungen mit CLDC und MIDP. von Klaus D. Schmatz. 2., aktualis. u. erw. Aufl.

Java Micro Edition. Entwicklung mobiler JavaME-Anwendungen mit CLDC und MIDP. von Klaus D. Schmatz. 2., aktualis. u. erw. Aufl. Java Micro Edition Entwicklung mobiler JavaME-Anwendungen mit CLDC und MIDP von Klaus D. Schmatz 2., aktualis. u. erw. Aufl. Java Micro Edition Schmatz schnell und portofrei erhältlich bei beck-shop.de

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Web Services mit Java

Web Services mit Java Web Services mit Java Neuentwicklung und Refactoring in der Praxis Torsten Langner new technology Markt+Technik Verlag Inhaltsverzeichnis Vorwort 13 Warum ausgerechnet dieses Buch? 13 An wen richtet sich

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128 ... Einleitung... 15 1... Grundlagen der Modellierung von Enterprise Services... 23 1.1... Serviceorientierte Architekturen... 26 1.1.1... Merkmale serviceorientierter Architekturen... 27 1.1.2... SOA

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Einsatz von Java-fähigen GPRS-Terminals

Einsatz von Java-fähigen GPRS-Terminals Einsatz von Java-fähigen GPRS-Terminals Ein Bericht aus der Praxis Dr. Fred Könemann INSIDE M2M GmbH 15. VDE/ITG Fachtagung Mobilkommunikation Osnabrück 19.-20. Mai 2010 Dr. Fred Könemann, INSIDE M2M GmbH

Mehr

Java Web Services mit Apache Axis2 Entwickler

Java Web Services mit Apache Axis2 Entwickler Thilo Frotscher, Dapeng Wang, Marc Teufel Java Web Services mit Apache Axis2 Entwickler Vorwort 15 1 Einleitung 25 1.1 Entstehung 26 1.2 Unterstützte Standards 28 1.3 Was beinhaltet Axis2? 29 1.4 Warum

Mehr

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm Web Services Boto Bako Inhaltsverzeichnis 1.Einführung und Motivation...3 2.Verwendete Standards...4 2.1.SOAP...5 2.2.WSDL...6

Mehr

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION Präambel Die COI GmbH entwickelt seit 1988 moderne, prozessorientierte Lösungen rund um die Themen Archivierung, Dokumentenmanagement und Workflow. Als kompetenter

Mehr

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Dokumentation zum Projekt Mail-Adapter in SAP PI 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Inhalt 1. Einleitung... 2 2. Vorgehen... 3 1. Datentyp für die Mail einrichten... 3 2. Message Typen

Mehr

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) Oliver Steinhauer Markus Urban.mobile PROFI Mobile Business Agenda MOBILE ENTERPRISE APPLICATION PLATFORM AGENDA 01 Mobile Enterprise Application Platform

Mehr

XML-RPC & SOAP. Sven Heß & Fabio Caprera Systemprogrammierung SS 08

XML-RPC & SOAP. Sven Heß & Fabio Caprera Systemprogrammierung SS 08 XML-RPC & SOAP & Fabio Caprera Systemprogrammierung SS 08 Inhalt XML-RPC Überblick Entstehung Konzept Fehlerbehandlung Vor- und Nachteile SOAP Überblick Entstehung Konzept Fehlerbehandlung Vor- und Nachteile

Mehr

HOB Remote Desktop VPN

HOB Remote Desktop VPN HOB GmbH & Co. KG Schwadermühlstr. 3 90556 Cadolzburg Tel: 09103 / 715-0 Fax: 09103 / 715-271 E-Mail: support@hob.de Internet: www.hob.de HOB Remote Desktop VPN Sicherer Zugang mobiler Anwender und Geschäftspartner

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

VS11 Slide 1. Verteilte Systeme. Vorlesung 11 Sebastian Iwanowski FH Wedel

VS11 Slide 1. Verteilte Systeme. Vorlesung 11 Sebastian Iwanowski FH Wedel VS11 Slide 1 Verteilte Systeme Vorlesung 11 Sebastian Iwanowski FH Wedel VS11 Slide 2 Verteilte Systeme 1. Innovative Beispiele aus der Praxis 2. Allgemeine Anforderungen und Techniken verteilter Systeme

Mehr

DRAFT, VERSION 1.0, 10.10.06 PETER MACHAT, TECHNICAL ACCOUNT MANAGER T-MOBILE BUSINESS UNIT, RESEARCH IN MOTION DEUTSCHLAND GMBH

DRAFT, VERSION 1.0, 10.10.06 PETER MACHAT, TECHNICAL ACCOUNT MANAGER T-MOBILE BUSINESS UNIT, RESEARCH IN MOTION DEUTSCHLAND GMBH BLACKBERRY UND NOKIA E61 DRAFT, VERSION 1.0, 10.10.06 PETER MACHAT, TECHNICAL ACCOUNT MANAGER T-MOBILE BUSINESS UNIT, RESEARCH IN MOTION DEUTSCHLAND GMBH INPUT: STEFAN TEPPERT, PIPELINE DV-BERATUNG GMBH

Mehr

Web Service Entwicklung mit Java. Sven Lindow

Web Service Entwicklung mit Java. Sven Lindow Web Service Entwicklung mit Java Sven Lindow 22.11.2006 Agenda Einleitung SOAP, REST, WSDL, UDDI Web Services mit Java JWSDP JAX-RPC, JAX-WS 2.0 AXIS, AXIS2 Web Services nutzen Google, Ebay Web Services

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Entwicklung von Serviceangeboten) 1 Agenda Einsatzbereiche von Web Service basierten Angeboten Übersicht zur Java-System Application

Mehr

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft der

Mehr

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) Oliver Steinhauer.mobile PROFI Mobile Business Agenda MOBILE ENTERPRISE APPLICATION PLATFORM AGENDA 01 Mobile Enterprise Application Platform 02 PROFI News

Mehr

SOAP Simple Object Access Protocol

SOAP Simple Object Access Protocol Informatikseminar Tobias Briel Überblick 1. Einführung - was ist? 2. Middlewaretechnologie 3. Aufbau von Nachrichten 4. Vergleiche 5. Beispielanwendung 6. Zusammenfassung 1 Einführung was ist Soap? neue

Mehr

NetWaever-Komponenten

NetWaever-Komponenten NetWaever-Komponenten Bremerhaven 07.05.2006 T4T Bremerhaven 1 Inhaltsverzeichnis 1. People Integration 2. Information Integration 3. Process Integration 4. Solution Management T4T Bremerhaven 2 Kapitel

Mehr

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel 2.6 Managed Code, Angepasste Java

Mehr

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors Installation und Konfiguration des Outlook Connectors Vertraulichkeit Die vorliegende Dokumentation beinhaltet vertrauliche Informationen und darf nicht an etwelche Konkurrenten der EveryWare AG weitergereicht

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final Systembeschreibung Masterplan Kommunikationsinterface ASEKO GmbH Version 1.0 Status: Final 0 Inhaltsverzeichnis 1 Einleitung... 2 2 Architektur... 2 2.1 Anbindung an die MKI Lösung... 2 2.2 Inbound Kommunikationsmethoden...

Mehr

SAP SharePoint Integration. e1 Business Solutions GmbH

SAP SharePoint Integration. e1 Business Solutions GmbH SAP SharePoint Integration e1 Business Solutions GmbH Inhalt Duet Enterprise Überblick Duet Enterprise Use Cases Duet Enterprise Technologie Duet Enterprise Entwicklungs-Prozess Duet Enterprise Vorteile

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2013 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

Mehr

Web Services: Inhalt

Web Services: Inhalt Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich

Mehr

SAP NetWeaver Gateway. Connectivity@SNAP 2013

SAP NetWeaver Gateway. Connectivity@SNAP 2013 SAP NetWeaver Gateway Connectivity@SNAP 2013 Neue Wege im Unternehmen Neue Geräte und Usererfahrungen Technische Innovationen in Unternehmen Wachsende Gemeinschaft an Entwicklern Ausdehnung der Geschäftsdaten

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Wer in der ersten Liga spielt, braucht Profis.

Wer in der ersten Liga spielt, braucht Profis. Wer in der ersten Liga spielt, braucht Profis. Ihr erfahrener und kompetenter SAP Allround - Dienstleister Die Profis für Ihre IT. SAP optimal nutzen: Setzen Sie auf die geballte Manpower der Goetzfried

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

Sind Ihre Anwendungen auf mobilen Endgeräten sicher? Karsten Sohr Technologie-Zentrum Informatik Universität Bremen

Sind Ihre Anwendungen auf mobilen Endgeräten sicher? Karsten Sohr Technologie-Zentrum Informatik Universität Bremen Sind Ihre Anwendungen auf mobilen Endgeräten sicher? Karsten Sohr Technologie-Zentrum Informatik Universität Bremen Inhalt Motivation allgemeine Bedrohungen für mobile Endgeräte bösartige Anwendungen für

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011 Lastenheft swp11-4 3. Mai 2011 Zielbestimmungen In der heutigen Geschäftswelt stehen mittelständische Unternehmen vor dem Dilemma, einerseits interne und externe Kommunikation in angemessener Weise gewährleisten

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Software Engineering 2 (SWT2) Dr. Alexander Zeier. Chapter 3: Introduction to ERP Systems

Software Engineering 2 (SWT2) Dr. Alexander Zeier. Chapter 3: Introduction to ERP Systems Software Engineering 2 (SWT2) Dr. Alexander Zeier Chapter 3: Introduction to ERP Systems Standard Software vs. Individual Software 2 Software wird meist in 2 Phasen erstellt 1. Auftrag eines Kunden zur

Mehr

Netzwerk Technologien in LabVIEW

Netzwerk Technologien in LabVIEW Netzwerk Technologien in LabVIEW von Dirk Wieprecht NI Germany Hier sind wir: Agenda Agenda Bedeutung des Ethernet für die Messtechnik Ethernet-basierende Technologien in LabVIEW Low Level- TCP/IP Objekt

Mehr

Übersicht. Projekt DB-basierte, mobile Systeme. Übersicht. Was sind Web Services? Web Service - Kompakt. Warum das Rad neu erfinden?!

Übersicht. Projekt DB-basierte, mobile Systeme. Übersicht. Was sind Web Services? Web Service - Kompakt. Warum das Rad neu erfinden?! Übersicht HTML Projekt DB-basierte, mobile Systeme JAX-RPC via SOAP Aufgabenblatt 4 Web Services Übersicht Was sind Web Services? "A web service is any service that is available over the Internet, uses

Mehr

FuE-Bereich IuK-Systeme im Gesundheitswesen

FuE-Bereich IuK-Systeme im Gesundheitswesen FuE-Bereich IuK-Systeme im Gesundheitswesen IG XML und Web Services Dipl.-Inform. Axel Schwolow IG Kommunikation im Web Entwicklung früher ausschließlich Kommunikation über Browser heute zunehmend direkt

Mehr

Howto. Konfiguration eines Adobe Document Services

Howto. Konfiguration eines Adobe Document Services Howto Konfiguration eines Adobe Document Services (ADS) Inhaltsverzeichnis: 1 SYSTEMUMGEBUNG... 3 2 TECHNISCHE VERBINDUNGEN ZWISCHEN DEN SYSTEMEN... 3 2.1 PDF BASIERENDE FORMULARE IN DER ABAP UMGEBUNG...

Mehr

Entwicklung und Integration mobiler Anwendungen. Oracle Deutschland B.V. & Co. KG

Entwicklung und Integration mobiler Anwendungen. <Speaker> Oracle Deutschland B.V. & Co. KG Entwicklung und Integration mobiler Anwendungen Oracle Deutschland B.V. & Co. KG Global Users (Millions) Der Trend ist eindeutig. Trend zu mobilen Endgeräten Wachstum des mobilen Datenverkehrs

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Astaro Mail Archiving Getting Started Guide

Astaro Mail Archiving Getting Started Guide Connect With Confidence Astaro Mail Archiving Getting Started Guide Über diesen Getting Started Guide Der Astaro Mail Archiving Service stellt eine Archivierungsplattform dar, die komplett als Hosted Service

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

1. Software-Plattform Android Android. Was ist Android? Managed Code, Angepasste Java Virtual Machine

1. Software-Plattform Android Android. Was ist Android? Managed Code, Angepasste Java Virtual Machine 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel ab 2.6, aktuell 3.8 Managed Code,

Mehr

Mobile Betriebsysteme

Mobile Betriebsysteme Mobile Betriebsysteme Ueli Hofstetter, Philippe Hungerbühler, Anil Kandrical Seminar in Mobile Communication Systems WS 06/07 1 1.1 Kleingeräte für mobile Betriebsysteme Embedded System Personal Digital

Mehr

Weltweit mobiler Zugriff auf zentrale Unternehmensdaten

Weltweit mobiler Zugriff auf zentrale Unternehmensdaten In Echtzeit informiert Neue Features Optimiert Abstimmungsprozesse Alleinstellungsmerkmale Anforderungen Kommunikationsund Vertrebskanäle Immer und überall in Echtzeit informiert und grenzenlos handlungsfähig

Mehr

Vergleich der Plattformen und praktische Erfahrungen. Softwareentwicklung für Smartphones

Vergleich der Plattformen und praktische Erfahrungen. Softwareentwicklung für Smartphones Vergleich der Plattformen und praktische Erfahrungen Softwareentwicklung für Smartphones Die SIC! Software GmbH Experten Mobility Software B2B Umfassende Erfahrung seit 1996: Mobile Internet-Portal Clients

Mehr

Mobile Security Smartphones

Mobile Security Smartphones Mobile Security Smartphones Schmelztiegel privater und geschäftlicher Aktivitäten eberhard@keyon.ch V1.1 2011 by keyon (www.keyon.ch) Über Keyon Warum Smartphones Welcher Nutzen wird vom Unternehmen erwartet?

Mehr

Service. Was ist eine Enterprise Service Architecture und wie reagiert SAP. Warum Monitoring in ZENOS, was monitort die XI?

Service. Was ist eine Enterprise Service Architecture und wie reagiert SAP. Warum Monitoring in ZENOS, was monitort die XI? Service Was ist eine Enterprise Service Architecture und wie reagiert SAP Allgemeine Definition Was gehört in ZENOS (Service-Layer)? Business Logik ZENOS als Provider für SAP-based Services (ESA/SOA) Warum

Mehr

ITS Business Integrator

ITS Business Integrator IBI Weboberfläche zur Datenintegration Location Viewer Asset-Management Smallworld GIS Monitoring Planung Bau Wartung Entstörung Integration Der ITS Business Integrator (IBI) ist eine offene Plattform

Mehr

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A POIS-Praktikum 2007 Prozessimplementierung, RosettaNet PIPs 3A Manuel Blechschmidt, David Foerster, Michael Leben, Mike Nagora, Jonas Rogge, Paul Römer Gliederung 2 Einleitung Was war unsere Aufgabe? Was

Mehr

Termin 4: Web Services Computing

Termin 4: Web Services Computing Arbeitsgruppe Übung Netzbasierte Informationssysteme Termin 4: Web Services Computing Prof. Dr. Adrian Paschke Arbeitsgruppe Corporate Semantic Web (AG-CSW) Institut für Informatik, Freie Universität Berlin

Mehr

Von SAP R/3 zu mysap ERP und NetWeaver

Von SAP R/3 zu mysap ERP und NetWeaver Von SAP R/3 zu mysap ERP und NetWeaver Bremerhaven 06.05.2006 T4T Bremerhaven 1 Inhaltsverzeichnis 1. Motivation für SAP NetWeaver 2. SAP R/3 mysap ERP und SAP Business Suite 3. Application Platform T4T

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Betriebswirtschaftliche Anwendungen 2: Serviceorientierte Anwendungsintegration Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Umrechnung von Währungen Steffen Dorn, Sebastian Peilicke,

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Version 4.4. security.manager. Systemvoraussetzungen

Version 4.4. security.manager. Systemvoraussetzungen Version 4.4 security.manager Systemvoraussetzungen Version 4.4 Urheberschutz Der rechtmäßige Erwerb der con terra Softwareprodukte und der zugehörigen Dokumente berechtigt den Lizenznehmer zur Nutzung

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

Programmieren für iphone und ipad

Programmieren für iphone und ipad Markus Stäuble Programmieren für iphone und ipad Einstieg in die App-Entwicklung für das ios 4 3., aktualisierte und erweiterte Auflage dpunkt.verlag 1 Einleitung 1 1.1 Begriffe 2 1.2 Was behandelt dieses

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Microsoft Dynamics NAV Technische Details

Microsoft Dynamics NAV Technische Details Microsoft Dynamics NAV Technische Details INHALT Microsoft Dynamics NAV Technische Details........................................ [3] Infrastruktur.............................................. [3] Systemanforderungen.....................................

Mehr

E-Mail-Archivierung für Microsoft Outlook und Exchange Server

E-Mail-Archivierung für Microsoft Outlook und Exchange Server windream Exchange E-Mail-Archivierung für Microsoft Outlook und Exchange Server 2 E-Mail-Archivierung für Microsoft Outlook und Exchange Server Das ständig wachsende Volumen elektronischer Mitteilungen

Mehr

Glossar. Launching auf.

Glossar. Launching auf. 243 Ad Hoc Distribution Die Ad Hoc Distribution ist eine Möglichkeit, um Ihre entwickelte Anwendung auf anderen Endgeräten zu verteilen. Diese Art der Verteilung erfolgt ohne den App Store. Die Anzahl

Mehr

Vergleichen von BlackBerry-Lösungen

Vergleichen von BlackBerry-Lösungen Vergleichen von BlackBerry-Lösungen BlackBerry Vergleichsübersicht Nachrichtenfunktionen Express Unterstützte Nachrichtenumgebungen Microsoft Exchange, Lotus Domino und Novell GroupWise Microsoft Exchange

Mehr

ISEC7 Mobile Exchange Delegate

ISEC7 Mobile Exchange Delegate ISEC7 Mobile Exchange Delegate Technische Beschreibung und Konfiguration Inhaltsverzeichnis 1. Versionen 3 2. Architektur und Sicherheit 3. Installationsvoraussetzungen 5 4. Konfiguration des Mailservers

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13

Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13 Inhaltsverzeichnis Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13 Einleitung... 15 Zielgruppe... 16 Aufbau... 16 Inhalt der einzelnen Kapitel... 17 Systemanforderungen...

Mehr

Groupware Integration mit SAP Customer Relationship Management Eine Entscheidungshilfe

Groupware Integration mit SAP Customer Relationship Management Eine Entscheidungshilfe Serverbasierende und clientbasierende Integration im Vergleich Groupware Integration mit SAP Customer Relationship Management Eine Entscheidungshilfe Eine der meist genutzten Anwendungen im Geschäftsalltag

Mehr

Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management

Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management Inauguraldissertation zur Erlangung des akademischen Grades eines Doktors

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

KM - Knowledge Management. SAP ERP Central Component

KM - Knowledge Management. SAP ERP Central Component KM - Knowledge Management SAP ERP Central Component Release 5.0 Release-Informationen Copyright 2004 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen.

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. 181 In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. Wir beginnen mit dem Startup-Unternehmen Seals GmbH aus Frankfurt,

Mehr

Good Dynamics by Good Technology. V1.1 2012 by keyon (www.keyon.ch)

Good Dynamics by Good Technology. V1.1 2012 by keyon (www.keyon.ch) Good Dynamics by Good Technology eberhard@keyon.ch brunner@keyon.ch V1.1 2012 by keyon (www.keyon.ch) 1 Über Keyon Experten im Bereich IT-Sicherheit und Software Engineering Als Value added Reseller von

Mehr

Oliver Olbrich Das ebxml Projekt Entstand 1999 in einer gemeinsamen Initiative von OASIS (Organisation for the Advancement of Structured Information Standards) und UN/CEAFACT (United Nations Center for

Mehr

SMTP-Verfahren POP-Verfahren IMAP-Verfahren

SMTP-Verfahren POP-Verfahren IMAP-Verfahren IT Zertifikat Mailserver 01 Server Mailserver Protokolle Teil des Client-Server-Modells bietet Dienste für lokale Programme/ Computer (Clients) an -> Back-End-Computer Ausbau zu Gruppe von Servern/ Diensten

Mehr

CRONOS CRM Online for OS

CRONOS CRM Online for OS www.osram-os.com CRONOS CRM Online for OS B. Blanz, S. Eichinger 08.09.2014 Regensburg Light is OSRAM Customer Relationship Management Online for OS Page 1. Vorstellung des Projekts CRONOS 04 2. Anforderungsanalyse

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Inhaltsverzeichnis. I. Grundlagen. 1 Einführung in Postfix 3

Inhaltsverzeichnis. I. Grundlagen. 1 Einführung in Postfix 3 xi I. Grundlagen 1 Einführung in Postfix 3 2 SMTP-Kommunikation im Überblick 7 2.1 E-Mail-Kommunikation................................................... 7 2.2 Wie wird eine E-Mail transportiert?.......................................

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Aufgabenstellung und Zielsetzung

Aufgabenstellung und Zielsetzung Aufgabenstellung und Zielsetzung In diesem Szenario werden Sie eine Bestellung, vorliegend im XML-Format, über einen Web-Client per HTTP zum XI- System senden. Dort wird die XML-Datei mittels eines HTTP-Interfaces

Mehr

2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen

2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen 2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen Dienste des Internets Das Internet bietet als riesiges Rechnernetz viele Nutzungsmöglichkeiten, wie etwa das World

Mehr

Integrationsprozesse. cross component BPM - Steuerung systemübergreifender Szenarien. Konrad Lubenow, FHTW Berlin, Juli 2007

Integrationsprozesse. cross component BPM - Steuerung systemübergreifender Szenarien. Konrad Lubenow, FHTW Berlin, Juli 2007 Integrationsprozesse cross component BPM - Steuerung systemübergreifender Szenarien Konrad Lubenow, FHTW Berlin, Juli 2007 Integrationsprozesse XI(ccBPM) normaler Messageaustausch über den Integrationsserver

Mehr

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis

Mehr

Man liest sich: POP3/IMAP

Man liest sich: POP3/IMAP Man liest sich: POP3/IMAP Gliederung 1. Einführung 1.1 Allgemeiner Nachrichtenfluss beim Versenden von E-Mails 1.2 Client und Server 1.2.1 Client 1.2.2 Server 2. POP3 2.1 Definition 2.2 Geschichte und

Mehr

BlackBerry Device Service

BlackBerry Device Service 1 28. Juni 2012 Cosynus Workshop 27.6.2012 BlackBerry Device Service direkte Exchange Active Sync Aktivierung Installation des BlackBerry Fusion BlackBerry Device Server (BDS) 28. Juni 2012 2 Mobile Fusion

Mehr

HVS32. ein Versandsystem das immer passt. Dokumentation. SAP-IDoc Schnittstelle

HVS32. ein Versandsystem das immer passt. Dokumentation. SAP-IDoc Schnittstelle ein Versandsystem das immer passt Dokumentation SAP-IDoc Schnittstelle Inhalt 1 HVS32 Anbindung an SAP mit IDocs...2 1.1 Integration...2 1.1.1 HVS32...2 1.1.2 HVS32-Gateway...2 1.2 Ablauf...3 2 IDoc Typen...4

Mehr

www.eset.de Bewährt. Sicher.

www.eset.de Bewährt. Sicher. www.eset.de Bewährt. Sicher. Starke Authentifizierung zum Schutz Ihrer Netzwerkzugänge und -daten ESET Secure Authentication bietet eine starke zusätzliche Authentifizierungsmöglichkeit für Remotezugriffe

Mehr

Objektorientierte Softwareentwicklung SoSe 15

Objektorientierte Softwareentwicklung SoSe 15 Objektorientierte Softwareentwicklung SoSe 15 Heinz Faßbender Raum E148 Tel. 0241/6009 51913 Email: fassbender@fh-aachen.de www.fassbender.fh-aachen.de FH AACHEN UNIVERSITY OF APPLIED SCIENCES FACHBEREICH

Mehr