Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe...

140
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

Transcript of Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe...

Page 1: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Fachhochschule WiesbadenFachbereich Design Informatik Medien

Studiengang Allgemeine Informatik

Diplomarbeitzur 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ögerKorreferent: Dipl.-Ing. Dipl.-Kfm. T. Schneider

Page 2: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

II

Page 3: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Erklärung

Ich versichere, dass ich die Diplomarbeit selbstständig verfasst und keine anderen als dieangegebenen Hilfsmittel benutzt habe.

Wiesbaden, 28.02.2007 Alexander Opatz

Hiermit erkläre ich mein Einverständnis mit den im Folgenden aufgeführten Verbreitungs-formen dieser Diplomarbeit:

Verbreitungsform ja neinEinstellung der Arbeit in dieBibliothek der FHW

Veröffentlichung des Titels derArbeit im Internet

Veröffentlichung der Arbeit imInternet

Wiesbaden, 28.02.2007 Alexander Opatz

III

Page 4: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

IV

Page 5: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Inhaltsverzeichnis

1 Einleitung 1

2 Grundlagen 52.1 Die BlackBerry-Architektur . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 BES - BlackBerry Enterprise Server . . . . . . . . . . . . . . . . 6

2.1.2 BB-MDS-Studio . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.3 BB-Handheld . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.4 RIM Push-Technologie . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 WSDL - Web Services Description Language . . . . . . . . . . . 12

2.2.2 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.1 SAP-CRM 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.2 SAP-XI - eXchange Infrastructure . . . . . . . . . . . . . . . . . 20

2.4 J2ME - Java 2 Platform Micro Edition . . . . . . . . . . . . . . . . . . . 23

2.4.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4.2.1 MIDlet Suite . . . . . . . . . . . . . . . . . . . . . . . 24

2.4.2.2 OTA Provisioning . . . . . . . . . . . . . . . . . . . . 26

2.4.3 Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4.3.1 Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . 26

2.4.3.2 PushRegistry . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.3.3 Graphische Benutzerschnittstelle . . . . . . . . . . . . 28

2.4.3.4 RMS - Persistente Speicherung . . . . . . . . . . . . . 31

2.4.3.5 kSOAP Web-Service-Bibliothek . . . . . . . . . . . . 33

2.4.3.6 Optimierungen für mobile Anwendungen . . . . . . . . 35

2.4.4 Sicherheitskonzept . . . . . . . . . . . . . . . . . . . . . . . . . 37

V

Page 6: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

3 Analyse 39

3.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1.1 Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1.2 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.2.1 Server-initiiert . . . . . . . . . . . . . . . . . . . . . . 41

3.1.2.2 Client-initiiert . . . . . . . . . . . . . . . . . . . . . . 42

3.1.3 Problembereiche . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.1 SAP-CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.2 Datenmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.3 Web Service zum SAP-CRM-System . . . . . . . . . . . . . . . 45

3.3 Mobile Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4 Mobile Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4.1 Kommunikation mit dem Web Service . . . . . . . . . . . . . . . 49

3.4.1.1 JSR 172 - Web-Service-API für J2ME . . . . . . . . . 50

3.4.1.2 REST-Web-Services . . . . . . . . . . . . . . . . . . . 51

3.4.1.3 Voranalysen . . . . . . . . . . . . . . . . . . . . . . . 52

3.4.1.4 Evaluierung . . . . . . . . . . . . . . . . . . . . . . . 54

3.4.2 Synchronisation und Offline-Modus . . . . . . . . . . . . . . . . 55

3.4.3 Usability der mobilen Anwendung . . . . . . . . . . . . . . . . . 61

3.4.4 Logging und Unit-Tests . . . . . . . . . . . . . . . . . . . . . . 63

4 Design 65

4.1 Architekturüberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2 mobileCRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.2.1 Allgemeine Design-Prinzipien . . . . . . . . . . . . . . . . . . . 67

4.2.2 Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . 68

4.2.3 Model und Backend-Zugriffe . . . . . . . . . . . . . . . . . . . . 72

4.2.4 Abbildung der Anwendungsfälle . . . . . . . . . . . . . . . . . . 75

4.2.4.1 Server-initiiert . . . . . . . . . . . . . . . . . . . . . . 75

4.2.4.2 Client-initiiert . . . . . . . . . . . . . . . . . . . . . . 76

4.3 Integrationsszenarien in SAP-XI . . . . . . . . . . . . . . . . . . . . . . 83

VI

Page 7: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

5 Implementierung 89

5.1 Entwicklungswerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.2 SOAP-Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.3 RMS-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.4 Multi-Threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.4.1 Worker-Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.4.2 Push-Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.5 Logging und Internationalisierung . . . . . . . . . . . . . . . . . . . . . 98

5.6 Workarounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.6.1 javax.microedition.midlet.MIDlet . . . . . . . . . . . . . . . . . 100

5.6.2 javax.microedition.lcdui.Gauge . . . . . . . . . . . . . . . . . . 101

5.6.3 Statische PushRegistry-Verbindungen im JAD . . . . . . . . . . . 102

5.6.4 Initialisierung von statischen Attributen . . . . . . . . . . . . . . 102

5.7 Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.7.1 Styleguide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.7.2 Software-Metriken . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.7.3 Automatisierte Tests . . . . . . . . . . . . . . . . . . . . . . . . 104

5.8 Implementierungsaufwand . . . . . . . . . . . . . . . . . . . . . . . . . 105

5.9 Performance-Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.9.1 Messreihe 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5.9.2 Messreihe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

5.9.3 Messreihe 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

5.9.4 Messreihe 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5.9.5 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6 Zusammenfassung 117

7 Literaturverzeichnis 121

A Abkürzungen 123

VII

Page 8: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

VIII

Page 9: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Abbildungsverzeichnis

2.1 Aufbau der BlackBerry-Architektur . . . . . . . . . . . . . . . . . . . . 6

2.2 Komponenten des BES aus [RIM06a] . . . . . . . . . . . . . . . . . . . 7

2.3 Verschlüsselung zwischen BB-Endgerät und BES . . . . . . . . . . . . . 8

2.4 Aufbau einer Beschreibung eines Web Service mit WSDL nach [HL04] . 13

2.5 Aufbau einer SOAP-Nachricht (HTTP als Transportprotokoll) . . . . . . 15

2.6 Überblick der SAP-Module . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7 Aktivitätsmanagement im GUI-Client von SAP . . . . . . . . . . . . . . 20

2.8 SAP-XI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.9 Aufbau der J2ME-Komponenten . . . . . . . . . . . . . . . . . . . . . . 24

2.10 Lebenszyklus eines MIDlets, angelehnt an [Sch04] . . . . . . . . . . . . 27

2.11 Zusammenhang der Klassen des LCDUI, adaptiert aus [Sch04] . . . . . . 30

2.12 MIDlet-Suite übergreifende Zugriffe auf RecordStores . . . . . . . . . . 31

3.1 Grobe Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2 Server-initiierte Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . 41

3.3 Client-initiierte Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . 42

3.4 Zusammenhang der Komponenten von JSR 172 . . . . . . . . . . . . . . 51

3.5 Beispiel für ein Lost-Update bei der Synchronisation . . . . . . . . . . . 56

3.6 Synchronisationslösung 1 für Client-initiiertes Aktivitätsupdate . . . . . . 58

3.7 Push-Update, Bestandteil der Synchronisationslösungen 1 und 2 . . . . . 59

3.8 Synchronisationslösung 2 für Client-initiiertes Aktivitätsupdate . . . . . . 60

3.9 Mögliches Lost-Update in Synchronisationslösung 2 . . . . . . . . . . . 61

4.1 Verfeinerter Aufbau der Systemarchitektur . . . . . . . . . . . . . . . . . 66

4.2 Klassen der Benutzerschnittstelle (View) . . . . . . . . . . . . . . . . . . 69

4.3 Übersicht und Zusammenhang der Screens . . . . . . . . . . . . . . . . . 71

IX

Page 10: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

4.4 Business Objects in mobileCRM . . . . . . . . . . . . . . . . . . . . . . 73

4.5 Komponenten zur Kommunikation mit den Backend-Systemen . . . . . . 74

4.6 Sequenzdiagramm zum Anwendungsfall Daten synchronisieren . . . . . 76

4.7 Sequenzdiagramm zum Anwendungsfall Aktivitäten auflisten . . . . . . . 77

4.8 Sequenzdiagramm zum Anwendungsfall Aktivität anlegen . . . . . . . . 78

4.9 Sequenzdiagramm zum Anwendungsfall Aktivität löschen . . . . . . . . . 80

4.10 Sequenzdiagramm zum Anwendungsfall Aktivität anzeigen . . . . . . . . 81

4.11 Sequenzdiagramm zum Anwendungsfall Aktivitätenliste anfordern . . . . 82

4.12 Sequenzdiagramm zum Anwendungsfall Daten synchronisieren . . . . . 83

4.13 Aufbau eines synchronen Integrationsszenarios im SAP-XI . . . . . . . . 84

5.1 Aufbau der verschiedenen Nachrichtentypen . . . . . . . . . . . . . . . . 92

5.2 Klassen für Internationalisierung und Logging . . . . . . . . . . . . . . . 99

5.3 Kiviat-Graph der Metriken von mobileCRM . . . . . . . . . . . . . . . . 104

5.4 Messaufbau und Bezeichnung der Messwerte . . . . . . . . . . . . . . . 108

5.5 Zeit zum Serialisieren der Anfrage in SOAP-XML-Markup . . . . . . . . 109

5.6 Messreihe 1: Eine Aktivität als Payload . . . . . . . . . . . . . . . . . . 110

5.7 Messreihe 2: 14 Aktivitäten als Payload . . . . . . . . . . . . . . . . . . 111

5.8 Messreihe 3: Zehn Aktivitäten als Payload . . . . . . . . . . . . . . . . . 112

X

Page 11: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Tabellenverzeichnis

2.1 kSOAP Mappings für primitive Datentypen . . . . . . . . . . . . . . . . 34

3.1 Übersicht der Attribute einer Aktivität in mobileCRM . . . . . . . . . . . 46

4.1 Übersicht der Komponenten von mobileCRM . . . . . . . . . . . . . . . 67

4.2 Übersicht der Integrationsszenarien . . . . . . . . . . . . . . . . . . . . 85

4.3 Integrationsszenario ActionPush . . . . . . . . . . . . . . . . . . . . . . 86

4.4 Integrationsszenario ChangeActivity . . . . . . . . . . . . . . . . . . . . 87

4.5 Integrationsszenario GetActivityList . . . . . . . . . . . . . . . . . . . . 88

5.1 LOC des Package com.csc.bb.mobileCRM . . . . . . . . . . . . . . 105

5.2 LOC des Package com.csc.bb.mobileCRM.gui . . . . . . . . . . 106

5.3 LOC des Package com.csc.bb.mobileCRM.model . . . . . . . . . 106

5.4 LOC des Package com.csc.bb.mobileCRM.model.backend.rms106

5.5 LOC des Package com.csc.bb.mobileCRM.model.backend.sap106

5.6 LOC des Package com.csc.bb.mobileCRM.util . . . . . . . . . . 107

5.7 LOC des Package com.csc.bb.mobileCRM.tests . . . . . . . . . 107

5.8 LOC von mobileCRM und mobileCRMtestsuite . . . . . . . . . . . . . . 107

5.9 Statistische Kenngrößen zu Messreihe 1 (Einheit [ms]) . . . . . . . . . . 110

5.10 Statistische Kenngrößen zu Messreihe 2 (Einheit [ms]) . . . . . . . . . . 112

5.11 Statistische Kenngrößen zu Messreihe 3 (Einheit [ms]) . . . . . . . . . . 112

5.12 Daten aus Messreihe 4 (Einheit [ms]) . . . . . . . . . . . . . . . . . . . 113

XI

Page 12: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

XII

Page 13: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Verzeichnis der Quellcodes

2.1 Aufbau einer RIM-Push HTTP-Anfrage . . . . . . . . . . . . . . . . . . 11

2.2 Beschreibung eines Web Service aus [W3C01] . . . . . . . . . . . . . . 14

2.3 Beispiel einer SOAP-Nachricht (Anfrage) . . . . . . . . . . . . . . . . . 16

2.4 Beispiel einer SOAP-Nachricht (Antwort) . . . . . . . . . . . . . . . . . 16

2.5 Beispiel eines Java Application Descriptors . . . . . . . . . . . . . . . . 25

2.6 Beispiel zur Serialisierung in einen Byte-Strom . . . . . . . . . . . . . . 33

2.7 KvmSerializable-Schnittstelle von kSOAP . . . . . . . . . . . . . . 35

3.1 JAD der Push-Test-Anwendung . . . . . . . . . . . . . . . . . . . . . . 52

4.1 Interface zur Umsetzung des Command Pattern . . . . . . . . . . . . . . 72

5.1 build.xml: Target makecod . . . . . . . . . . . . . . . . . . . . . . . . 90

5.2 Parameter für den Obfuscator ProGuard . . . . . . . . . . . . . . . . . 90

5.3 SAPmanager.java: Methode receivePush . . . . . . . . . . . . . . . 93

5.4 RMSmanager.java: Methode saveActivityEntry . . . . . . . . . . 94

5.5 ModelController.java: Methode getActivity . . . . . . . . . . . . . 95

5.6 ModelController.java: Methode handleGetActivity . . . . . . . . . 96

5.7 ModelController.java: Methode stop . . . . . . . . . . . . . . . . . . . 96

5.8 PushReceiver.java: Methode run . . . . . . . . . . . . . . . . . . . . . . 97

5.9 PushReceiver.java: Methode stop . . . . . . . . . . . . . . . . . . . . . 98

5.10 Bug in Klasse MIDlet . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.11 Log-Ausgabe der Testanwendung MIDlet_Destroy_Bug . . . . . . . . . 101

5.12 Bug in Klasse Gauge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

XIII

Page 14: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

XIV

Page 15: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 1

Einleitung

Die Verbreitung von mobilen Endgeräten wie Smartphones, PDAs und Handys nimmtweltweit rasant zu. Im September 2006 wurde global die Marke von 2.5 Milliarden Han-dys erreicht. In Westeuropa betrug im Jahr 2004 der Verbreitungsgrad 74 - 110 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 eingebet-teten Endgeräten in allen Lebensbereichen gemeint ist. Dies schafft ein großes Potentialfür mobile Anwendungen und darauf basierende Geschäftsmodelle. Zur Unterstützungvon Geschäftsprozessen können mobile Anwendungen auch in Unternehmen eingesetztwerden.

Unter Mobile Business versteht man die Abwicklung von Geschäftsprozessen durch elek-tronische Kommunikationstechniken mit mobilen Endgeräten. Die besonderen Merkmaledes Mobile Business sind örtliche Unabhängigkeit, Erreichbarkeit zu jeder Zeit, einfa-che Handhabung sowie Identifizierungs- und Telemetriefunktionen. Dadurch lassen sichProzesse in verschiedenen Geschäftsbereichen effizienter gestalten. Mit dem Einsatz vonmobilen Endgeräten innerhalb logistischer Ketten können beispielsweise Daten in Echt-zeit erfasst werden. Dies ermöglicht ein besseres Supply Chain Management (SCM) -Engpässe können so früh erkannt werden, und Entscheidungen basieren auf aktuellenDaten. Außendienstmitarbeiter sind zu jeder Zeit in der Lage, ihre Daten des Personal In-

formation Management (PIM) - also z.B. Aufgaben, Termine und Kontakte - und E-Mailsabzurufen. Diese Funktionalität nennt sich auch Mobile Office und ist auf Kommunikationund Zusammenarbeit ausgerichtet. Anwendungen für den sogenannten Mobile Workforce

Support dienen der Unterstützung von Geschäftsprozessen und ermöglichen den mobilenZugriff auf firmeninterne Backend-Systeme. Beispielsweise können Daten des Customer

1

Page 16: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 1. Einleitung

Relationship Management (CRM) somit zu jeder Zeit an einem beliebigen Ort verfügbarsein, und der Kunde kann ohne Zeitverzögerung Informationen oder spezifische Angebotevon seinem Ansprechpartner erhalten. Auch für Konsumenten als Nutzer bringen mobi-le Anwendungen Zeitersparnis oder eine Verbesserung der Lebensqualität. Entertainmentin Form von Spielen und Musik hat sich bereits auf Handys etabliert und gehört schonzum Alltag. Navigations- und Bezahlsysteme steigern die Effizienz im Alltag. Ebensoist vorstellbar, dass weitergehende standortbezogene Dienste - auch Location Based Ser-

vices (LBS) genannt - durch erweiterte Funktionen an Attraktivität gewinnen. Im Bereichöffentlicher und sozialer Einrichtungen wie Notfalldienste, Polizei und Militär führt ei-ne schnelle und auch interdisziplinäre Kommunikation durch mobilen Datenaustausch zueffizienterem Agieren und kann dadurch entscheidend oder sogar lebensrettend sein.

Zur Verwaltung und Optimierung von Geschäftsprozessen wie beispielsweise dem bereitsangesprochenen CRM und SCM haben sich Softwaresysteme etabliert. Die SAP AG istals Hersteller auf diesem Gebiet führend und ihre Software ist bei großen und mittelstän-dischen Unternehmen weit verbreitet. Die aktuelle Produktlinie setzt mit ihrer Service-

orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auchder eingebundenen Fremdsysteme. Dadurch sollen die Geschäftsprozesse schneller abge-wickelt werden, und unmittelbare Anpassungen der Prozesse an die aktuellen Bedürfnisseder Marktlage sind leichter durchführbar. An dieser Stelle kann Mobile Business zu wei-teren Optimierungen beitragen.

Bei der Arbeit mit sensiblen Daten, seien es Betriebsgeheimnisse oder Abwicklungen vonGeschäften mit hohen Transaktionssummen, ist die Gewährleistung der Sicherheit unab-dingbar. Neben der verschlüsselten Kommunikation muss garantiert sein, dass die End-geräte selbst auch sicher sind, da sie Daten lokal speichern können und Zugriff zum Un-ternehmensnetzwerk 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 Kommunika-tion ist verschlüsselt. Auf dem Endgerät selbst können Daten kodiert gespeichert und viaPasswort zugriffsgeschützt werden. Über den Server ist es außerdem möglich, die Datenvon 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 dieserArchitektur.

Diese Diplomarbeit entstand extern in Kooperation mit der CSC Deutschland SolutionsGmbH in Wiesbaden. Sie zielt darauf ab, die vielfach bereits in Unternehmen vorhande-ne SAP-Infrastruktur in die BlackBerry-Plattform zu integrieren, um so sicheres MobileBusiness zu ermöglichen. Ein Workflow in einem SAP-CRM-System wird dabei proto-

2

Page 17: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 1. Einleitung

typisch durch eine mobile Anwendung auf einem BlackBerry-Endgerät abgebildet. Umdabei möglichst plattformunabhängig und generisch vorzugehen, erfolgt die Integrationdurch Web Services. Durch die damit verbundene Kommunikation in Form von XML-basierten Nachrichten bleibt die Kopplung zwischen den zu integrierenden Systemen sogering wie möglich, und die Interoperabilität mit anderen Plattformen ist gewahrt. DerSchwerpunkt dieser Arbeit liegt auf dem Entwurf von Konzepten für die Integration, dieanhand einer prototypische mobilen Anwendung realisiert werden soll. Die Implementie-rung des zu entwerfenden Web Service auf SAP-Seite wird durch den Betreuer (HerrnThomas Schneider) von Seiten der Firma CSC vorgenommen.

Der Aufbau dieser Arbeit gliedert sich wie folgt: Im Kapitel Grundlagen werden die tech-nologischen Voraussetzungen BlackBerry, SAP, Web Services und J2ME erläutert, die beider Bearbeitung des Themas eingesetzt wurden.Daran schließt sich die Analyse an, in der zunächst die Rahmenbedingungen und Anwen-dungsfälle der Anwendung beschrieben werden, um dann die einzelnen Systembestand-teile dieser Arbeit und mögliche Alternativen zu untersuchen. Im Abschnitt Design wirddie Realisierung dieser Ausführungen softwaretechnisch entworfen, basierend auf denEntscheidungen in der Analyse und mit der mobilen Anwendung auf dem BB-Endgerätals Schwerpunkt. Darauffolgend werden die wesentlichen und interessanten Teile der Im-

plementierung dargelegt. Das abschließende Kapitel Fazit fasst die gesamte Abhandlungzusammen und gibt einen Ausblick für weitere Entwicklungen in diesem Themenbereich.

3

Page 18: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 1. Einleitung

4

Page 19: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 2

Grundlagen

Dieses Kapitel dient dazu, den Leser mit Architekturen und Technologien vertrautzu machen, die für das Verständnis dieser Arbeit benötigt werden. Zunächst wirddie 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 bes-seren Verständnis der SAP-Integration folgt ein Unterkapitel über Technologien für WebServices. 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 mitdieser mobilen Plattform stehen. Einen Überblick darüber gibt Abbildung 2.1. Über mo-bile Endgeräte ist man in die firmeninternen E-Mail- und Messaging-Systeme integriert.Das PIM wird ebenso drahtlos abgeglichen. Weiterhin besteht die Möglichkeit, an dieKommunikationsplattform weitere Unternehmensanwendungen anzubinden, um Datenund 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 neh-men für das Endgerät verschlüsselte Nachrichten von BES-Servern und über eine durch

5

Page 20: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 Verbindungan. Die Nachricht wird an den entsprechenden Mobilfunkanbieter weitergeleitet, bei demdas BB-Endgerät eingebucht ist, welches die Nachricht empfangen soll. Für diesen Vor-gang ist die von RIM bereitgestellte BB-Infrastruktur notwendig, da ein BB-Client sonstnur mit einem Mobilfunkanbieter funktionieren würde. Über GPRS oder UMTS übermit-telt der Mobilfunkanbieter die Nachricht zum Endgerät, wo sie entschlüsselt werden kann.Übertragungen in umgekehrter Richtung arbeiten analog, hierbei kodiert jedoch das mo-bile Endgerät und der BES nimmt die entschlüsselnde Rolle ein. Eine Dekodierung durchdie 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 derdie Daten über das LAN an den BES gesendet werden.

2.1.1 BES - BlackBerry Enterprise Server

Das Herzstück der Architektur ist der BES, über den die gesamte Kommunikation statt-findet. Diese Serversoftware besteht aus mehreren Komponenten, die in Abbildung 2.2dargestellt sind. Die wesentlichen Komponenten werden in den folgenden Abschnittenbesprochen.

Über den BES werden standardmäßig bereits das firmeninterne E-Mail-System (un-terstützt werden Microsoft Exchange und IBM Lotus Domino) und einige Instant-

6

Page 21: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 eingehen-de Nachrichten vom BES aus auf das entsprechende Endgerät gesendet werden können.Dadurch ist es möglich, die Rechen- und die Latenzzeit des E-Mail-Empfangs zu ver-ringern, 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 an-gelegt werden, um zu bestimmen, welche E-Mails auf das BB-Gerät gepusht werden sol-len. Vom Handheld aus gesendete E-Mails werden bei Bedarf mit der Desktop-Softwaresynchronisiert. E-Mail-Anhänge werden vom BES in ein spezielles Binärformat konver-tiert, das die BB-Gerätesoftware standardmäßig anzeigen kann, ohne dass spezifische Cli-entsoftware nötig ist. Dies funktioniert allerdings nur für Formate, die vom Anhangdienstim BES unterstützt werden und die dieser entsprechend konvertieren kann. Ebenso wer-den Daten des PIM drahtlos über den BES synchronisiert, so dass die Desktop-Clientsund das BB-Endgerät mit den gleichen Daten arbeiten.

Verbindungen zwischen dem BES und BB-Handhelds sind immer mit einem symmetri-schen Verschlüsselungsverfahren gesichert (vgl. Abbildung 2.1), aktuell durch AES mit

7

Page 22: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 Ver-und 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 derBB-Desktop-Software oder über die Funkverbindung mit dem BES verbunden ist. DieserSchlü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 werdenan den BES gesendet. Durch den dort hinterlegten Hauptschlüssel des Endgeräts kannder Nachrichtenschlüssel dekodiert werden und im nächsten Schritt somit auch die Nach-richt. 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 clientseitiginitiiert sein, Der Nachrichtenschlüssel ändert sich bei jedem Datenpaket (maximal 2kB)

8

Page 23: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 2. Grundlagen 2.1. Die BlackBerry-Architektur

und wird basierend auf Zufallsdaten generiert. Optional kann auch ein Schlüssel zum In-haltsschutz des Handhelds auf der Grundlage des Geräte-Kennworts generiert werden.Mit Hilfe dieses Schlüssels werden gespeicherte Daten und der Hauptkodierungsschlüs-sel chiffriert. Detailliertere Informationen zu den Verschlüsselungsmechanismen findensich im im Kapitel „BlackBerry-Codierungsschlüssel“ in [RIM06b].

Die Sicherheitseinstellungen der BB-Endgeräte lassen sich über IT-Richtlinien zentralvom 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 Anwendun-gen installieren können, oder es können die Aktivierung des Inhaltsschutzes und sicherePasswörter erzwungen werden. Änderungen an den Richtlinien können für alle oder ma-nuell ausgewählte Endgeräte vorgenommen werden.

Der BES stellt mit der Komponente namens Mobile Data System (MDS) Verbindungenzwischen den mobilen Endgeräten und Anwendungen des Unternehmens oder dem In-ternet her. Die Kommunikation zwischen Endgerät und dem BES ist dabei auf bekannteWeise verschlüsselt, für eine sichere Verbindung zwischen MDS und der Unternehmens-anwendung kann SSL verwendet werden.

Neben der Verschlüsselung stellt die Dispatcher-Komponente auch einen Dienst zur Op-timierung des Datenverkehrs für BB-Endgeräte bereit. Die Optimierung umfasst Da-tenverkehr von E-Mail-Kommunikation, MDS-Studio-Applikationen (erstellt mit BB-spezifischer IDE), J2ME-Anwendungen und dem BB-Browser (falls diese über das MDS-System übertragen werden). Je nach Anwendungsfall werden die Daten komprimiert oderauch 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 Anbindungunternehmensspezifischer Anwendungen an BB-Endgeräte bieten sich Applikationen aufBasis von J2ME (siehe Kapitel 2.4) und MDS-Studio-Anwendungen an, welche im nächs-ten Abschnitt erläutert werden.

2.1.2 BB-MDS-Studio

Die Software BB-MDS-Studio ist eine Entwicklungsumgebung von RIM (siehe Doku-mentation [RIM06c]), mit der relativ schnell und leicht graphische Client-Anwendungenerstellt werden können, die auf Web Services zugreifen. Als Ausgangsbasis dient dabeidie Beschreibung des Web Service in Form eines WSDL-Dokuments, auf dessen Aufbauspäter eingegangen wird. Die IDE erstellt aus einem WSDL-Dokument bereits Dialog-

9

Page 24: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

2.1. Die BlackBerry-Architektur Kapitel 2. Grundlagen

felder, die an den Ein- und Ausgabemöglichkeiten des Web Service orientiert sind. Übereinen graphischen Assistenten können die Dialoge manuell angepasst werden. Auf Basisder Dialoge kann mittels JavaScript weitere Logik implementiert werden. Die Anwen-dung wird als XML-Struktur repräsentiert und zusammen mit einer separaten Datei fürdas JavaScript sowie optionalen Resourcen in ein Java Archive (JAR) verpackt. Der BESstellt eine Datenbank zur Verfügung, in der MDS-Studio-Anwendungen verwaltet wer-den 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 umgesetztund die Web-Service-Bibliothek bereitgestellt.

2.1.3 BB-Handheld

Aktuelle BB-Endgeräte laufen mit einem eigenen Betriebssystem von RIM und unterstüt-zen J2ME- und MDS-Studio-Anwendungen. Standardmäßig sind auf den Geräten bereitsein E-Mail-Client und ein Web-Browser installiert. Für den Browser gibt es drei verschie-dene Profile:

1. Den WAP-Browser, wobei die Verbindung über das WAP-Gateway des Mobil-funkanbieters 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 denBES) schafft.

Unter dem Namen BB-Connect bietet RIM Module an, mit denen einige Endgeräte vonDrittanbietern, 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 wer-den in einem proprietären Format mit der Datei-Extension .cod gespeichert. Die Ent-wicklungsumgebung von RIM, das Java Development Environment (JDE), bringt eini-ge Entwicklungswerkzeuge mit, die sich auch außerhalb der IDE nutzen lassen. Unver-zichtbar ist dabei rapc.exe, ein Compiler, der reguläre J2ME-Anwendungen in dasBlackBerry-Format übersetzt. Mit der BlackBerry-Desktop-Software lassen sich die in-stallierten Anwendungen auf einem Endgerät verwalten.

10

Page 25: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 2. Grundlagen 2.1. Die BlackBerry-Architektur

2.1.4 RIM Push-Technologie

Der BES stellt eine externe Schnittstelle für Anwendungen des Unternehmens bereit, überdie Push-Nachrichten angenommen werden und an das entsprechende BB-Endgerät wei-tergeschickt werden. Die genaue Funktionsweise wird im BlackBerry Application Devel-oper Guide Volume 1 [RIM05] in Kapitel 10 erläutert. Voraussetzung ist, dass die externeAnwendung das HTTP-Protokoll beherrscht und mit der POST-Methode die Nachrichtan 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.0Spezifikation) 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 überden URI der HTTP-Anfrage und spezifische HTTP Header übermittelt. Das Zielgerät wirdmit Hilfe eines eindeutigen Identifikationsstrings des Geräts, in der Dokumentation desHerstellers PIN genannt, oder der E-Mail-Adresse des Benutzers identifiziert. Der angege-bene Port spezifiziert den Port auf dem Endgerät, auf dem die Anwendung auf eingehendeVerbindungen wartet. Dort wird der Inhalt der Nachricht in Form eines Byte-Datenstromsentgegen genommen. Den Parameter REQUESTURI gibt der BES über HTTP an das End-gerät weiter. Über optionale, herstellerspezifische HTTP Header kann beispielsweise diePriorität angegeben werden oder ein URI, den der BES aufruft, um eine Rückmeldungüber die Nachrichtenzustellung zu geben. Die Informationen der Rückmeldung werdendabei ebenfalls über HTTP Header transportiert. Es ist auch möglich, Push-Nachrichteneine Lebensdauer zuzuweisen, so daß die Nachricht nicht mehr ausgeliefert wird, fallsdies nicht innerhalb des im BES definierten Zeitraums erfolgt ist.

Im Gegensatz zum RIM-Push-Protokoll werden beim PAP die protokollspezifischen In-formationen in einer XML-Struktur transportiert. Daher wird die Nachricht in Form einerMIME-Multipart-Nachricht versendet, um diese Informationen von dem Nachrichtenin-halt zu trennen.

11

Page 26: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

2.2. Web Services Kapitel 2. Grundlagen

2.2 Web Services

Unter einem Web Service versteht man eine Software-Komponente, die über XML-basierten Nachrichtenaustausch mit anderen Applikationen Daten und Funktionen anbie-ten und entgegennehmen bzw. ausführen kann. Web Services dienen also der Kommuni-kation zwischen Anwendungskomponenten. Der Unterschied zu anderen Kommunikati-onsverfahren ist, dass die Grundlage der Nachrichtenformate XML ist, und Nachrichtenüber das HTTP-Protokoll übertragen werden können. Dadurch ergibt sich eine große Inte-roperabilität zwischen verschiedenen Plattformen und Programmiersprachen und die Inte-gration in bestehende Firewall-geschützte Netzwerke fällt leichter. Für die Bereitstellungund Nutzung von Web Services haben sich einige Protokolle etabliert, die in den folgen-den Unterkapiteln beschrieben werden. Als Grundlage dient dabei das Buch [HL04].

2.2.1 WSDL - Web Services Description Language

Mit der Web Services Description Language (WSDL) lassen sich Web Services in Formvon XML-Dokumenten beschreiben. Die aktuelle Version 2.0 des WSDL-Standards liegtbeim World Wide Web Consortium (W3C) als sogenannte Candidate Recommendation

vor [W3C06]. Die zuvor in Entwicklung befindliche Version 1.2 wurde aufgrund größe-rer Änderungen in 2.0 umbenannt. Der neue Standard unterteilt sich in die Teile Core

Language, Message Patterns und Bindings. Einige Elemente wurden umbenannt oder umAttribute erweitert, und das aktuelle SOAP-Binding nutzt nun die Version 1.2 statt 1.1in der vorherigen Version. Viele Implementierungen nutzen jedoch noch nicht die neuenStandards. Im Folgenden wird WSDL in der Version 1.1 beschrieben (für die Spezifikati-on siehe [W3C01]), da SAP die neueste Version noch nicht unterstützt.

Eine Beschreibung für die Schnittstelle eines Web Service ist notwendig, um die be-reitgestellten Operationen sowie erwartete und zurückgegebene Daten unabhängig vonder Web-Service-Implementierung zu dokumentieren. Mittlerweile bieten viele Entwick-lungswerkzeuge Unterstützung beim Umgang mit WSDL. Ausgehend von einem WSDL-Dokument kann beispielsweise ein Client-Skelett in einer spezifischen Programmierspra-che generiert werden, um mit dem Web Service zu kommunizieren. Umgekehrt gibt esTools, die zu einer Web-Service-Implementierung ein entsprechendes WSDL-Dokumenterzeugen. Außerdem gibt es noch graphische Design-Werkzeuge, mit denen man einWSDL-Dokument entwerfen kann. Die Beschreibung einer Schnittstelle gliedert sich infünf Teile, die in Abbildung 2.4 dargestellt sind.

12

Page 27: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 not-wendigen XML-Namensräume einbindet. Innerhalb der darauf folgenden Sektion typeskönnen eigene Datentypen definiert werden, falls die XML-Schema-Datentypen nichtausreichend sind - üblicherweise werden damit komplexere Datentypen als XML-Schemarealisiert. Eine WSDL-Beschreibung muss mindestens ein message-Element enthalten,das mit Namen und Typ den Aufbau einer Nachricht beschreibt, die der Web Servicesenden oder empfangen kann. Diese Nachrichtentypen werden in der darauffolgendenportType-Sektion verwendet, in der sie Operationen als Ein- oder Ausgabe-Typ zuge-ordnet werden. Durch die Reihenfolge und das Vorhandensein der Unterelemente inputund output wird festgelegt, welcher Endpunkt die Kommunikation initiiert und ob eineReaktion 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 oderHTTP) verknüpft. Eine abstrakte Definition einer Operation kann mehrere Bindungen ha-ben. Der letzte Abschnitt service enthält port-Unterelemente, in denen jeweils einemBinding ein URL zugeordnet wird, auf der diese Operation abzurufen ist. Eine beispiel-hafte Beschreibung eines Web Service durch WSDL findet sich in Quellcode-Listing 2.2.

2.2.2 SOAP

Ursprünglich bedeutete SOAP Simple Object Access Protocol, wird aber mittlerweile nurnoch als Eigenname verwendet, da eine Objektorientierung nicht gegeben ist. SOAP isteine Spezifikation zum plattformunabhängigen Austausch von XML-Nachrichten. Initi-iert wurde SOAP von Microsoft, basierend auf der Entwicklung von XML-RPC (Spe-zifikation 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

Page 28: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

Page 29: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 W3Cdurch die Version 1.2, an der auch Sun Microsystems und Canon erstmalig mitgewirkthaben. In der Version 1.2 besteht die Spezifikation nun aus drei Teilen statt einem. DieNamensräume für Envelope und Encoding haben sich geändert, und statt einer Bindungan HTTP ist die Spezifikation in der Version 1.2 nun allgemeiner gefasst und erlaubt an-dere Protokolle. Im Folgenden wird auf die Version 1.1 eingegangen (für die Spezifikationsiehe [W3C00]), da diese Version in Kombination mit WSDL 1.1 noch bei SAP eingesetztwird.

Im Gegensatz zu XML-RPC muss die Kommunikation über SOAP nicht synchron ab-laufen. Eine Nachricht kann jedoch einen Informationsfluss in Gegenrichtung auslösen,ebenso wie eine Nachricht an mehrere Empfänger addressiert werden kann. In der Praxiswird SOAP hauptsächlich mit den sogenannten Message Exchange Pattern (MEP) in derForm Anfrage-Antwort (XML-RPC) und Einzelnachrichten verwendet. Zwischen Senderund Empfänger sieht die Spezifikation noch SOAP intermediaries vor, die die Mitteilungweiterleiten. Üblicherweise wird die Information jedoch direkt vom Sender zum Empfän-ger geschickt. Als Transportprotokoll für SOAP-Nachrichten wird oft HTTP verwendet,deren gemeinsames Binding im Standard fest integriert wurde. Dabei werden auch dieStatuscodes und der Header von HTTP eingesetzt. Es lassen sich aber auch andere Proto-kolle wie FTP und SMTP für SOAP nutzen.

Abbildung 2.5 verdeutlicht den Aufbau einer SOAP-Nachricht, die aus einem Enve-

lope-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. nocheine XML-Deklaration stehen, sowie meistens noch der HTTP Header, falls HTTP alsTransportprotokoll verwendet wird.

Während im SOAP-Envelope verschiedene XML-Schema-Namensräume bekannt ge-macht werden, ist der Header relativ offen spezifiziert und bietet so Möglichkeiten,

15

Page 30: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

2.2. Web Services Kapitel 2. Grundlagen

dort optionale Funktionalität einzufügen wie beispielsweise Aspekte der Sicherheit oderTransaktionssteuerungsinformationen.

Innerhalb des Body-Tags werden die eigentlichen Nutzdaten in Form von XML-Dokumenten übertragen. Dieses Element und auch Unterelemente davon können im At-tribut encodingStyle Angaben darüber machen, welche Regeln für die Deseriali-sierung 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 http://schemas.xmlsoap.org/soap-

/encoding/ assoziiert ist. Im Falle eines Fehlers zwischen den Kommunikationspart-nern wird dies durch ein Element namens Fault als Unterelement von Body signalisiert.Dieses Element enthält weitere Unterelemente für eine genaue Fehlerrückmeldung. Einvollständiges Beispiel einer SOAP-Nachricht mit Anfrage und Antwort befindet sich imQuellcode-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

Page 31: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 2. Grundlagen 2.3. SAP

2.3 SAP

Dieses Unterkapitel bietet einen Überblick der SAP-Softwarelösungen und geht danachauf die für diese Arbeit interessanten Module CRM und XI ein. Die Basis dieses Ab-schnitts sind die SAP-Schulungsunterlagen [SA03].

Die SAP AG ist ein weltweit agierendes Unternehmen und führender Anbieter von Un-ternehmenssoftware. Die Service-orientierte Architektur der Software ist darauf ausge-legt, Geschäfte in Echtzeit abzuwickeln, auf veränderte Marktbedingungen schnell rea-gieren zu können und die Zusammenarbeit der Mitarbeiter zu verbessern. Erreicht wer-den soll dies durch die Komponente NetWeaver, die dafür zuständig ist, die einzelnenSAP-Module und auch Fremdanwendungen untereinander zu vernetzen und zu integrie-ren. Ebenso stellt diese Komponente einen Application-Server zur Verfügung, auf demdie weiteren Module aufsetzen. Das Kern-Modul ist mySAP ERP, es ist der Nachfol-ger 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 bedeutetEnterprise Resource Planning. Damit werden die Basisfunktionalitäten für ein Unterneh-men bereitgestellt. Dieser Kern kann um Zusatzkomponenten ergänzt werden, um weite-re Geschäftsprozesse abbilden zu können. Einen Überblick dazu gibt die Abbildung 2.6.Das SRM (Supplier Relationship Management) umfasst die Planung und Steuerung vonBeziehungen des Unternehmens zu seinen Lieferanten. Das SCM (Supply Chain Mana-gement) dient der Optimierung von innerbetrieblichen Logistikketten. Das PLM (ProductLifecycle Management) gestattet allen an der Produktentwicklung beteiligten Einheitenund Partnern Zugriff auf die Daten der Produktentwicklung. Dies kann zur Verkürzungder Produktzyklen beitragen, erlaubt Qualitätsverbesserungen und wird dem Sachverhaltgerecht, dass Unternehmen mit immer mehr Geschäftspartnern kooperieren. Mit Hilfedes CRM lassen sich Kundenbeziehungen verwalten, so dass Mitarbeiter alle nötigen In-formationen zu Kunden abrufen können. Auf die Funktionalität dieses Moduls wird imFolgenden näher eingegangen.

2.3.1 SAP-CRM 4.0

Als inhaltliche Quelle zu diesem Abschnitt dient [BEZ04]. Unter CRM versteht man all-gemein Strategien und Verfahren, um Beziehungen von Unternehmen zu Kunden indivi-dualisiert verwalten zu können. Die wesentlichen Faktoren für den wirtschaftlichen Erfolgeines Unternehmens - marktgerechte Produkte, profitabler Betrieb und zufriedene Kunden- können durch CRM optimiert werden. Die Zielsetzung ist dabei, die Kunden kontinu-

17

Page 32: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

2.3. SAP Kapitel 2. Grundlagen

Abbildung 2.6: Überblick der SAP-Module

ierlich und effizient zu betreuen und die Leistungen den jeweiligen Kundenbedürfnissenanzupassen. Dazu werden alle interessanten Kundendaten wie Kontaktmöglichenkeiten,eine Historie von bisherigen Geschäftsabwicklungen oder auch die Liquidität des Kundenfestgehalten. Jeder beteiligte Mitarbeiter hat somit Zugriff auf die Daten und kann denKunden individuell bedienen. Die Informationen sind also nicht in Köpfen von bestimm-ten Mitarbeitern oder auf Notizen verteilt, sondern gehören dem Unternehmen und sindfür alle am Geschäftsprozess Beteiligten verfügbar. Durch eine Auswertung der CRM-Daten kann auch genau festgestellt werden, welche Kunden am meisten Profit einbrin-gen und welche möglicherweise Verluste verursachen. So können die Kundenbetreuungaufgrund dieses Aspektes entsprechend gestaltet und Prioritäten festgelegt werden. Eben-so kann eine wirtschaftliche Geschäftsfokussierung stattfinden. Durch weitere Analysenkönnen Änderungen im Kundenverhalten und des gesamten Marktgeschehens erkanntund die Ressourcen und Geschäftsprozesse entsprechend adaptiert werden.

Die CRM-Software von SAP ist in drei Kategorien unterteilt:

• Operatives CRMDas operative CRM unterstützt Geschäftsabläufe, die unmittelbar am Kunden aus-gerichtet sind. Darunter fällt der Vertrieb eines Unternehmens, der mit Kaufinter-essenten und Kunden bis zur Vertragsabwicklung agiert. Im Service werden Kun-denbeschwerden entgegen genommen, mit Unterstützung von Lösungsdatenbanken

18

Page 33: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 2. Grundlagen 2.3. SAP

bearbeitet, und Serviceverträge erfüllt. Auch der Bereich Marketing hat direktenKontakt zu den Kunden.

• Analytisches CRMDas Ziel von CRM-Analysen ist die Auswertung von Kundenzufriedenheit undKundenverhalten, deren Ergebnisse wiederum die Entscheidungsgrundlage für Ver-trieb und Marketing sind.

• Kollaboratives CRMDas kollaborative oder auch unternehmensübergreifende CRM dient der Zusam-menarbeit des Unternehmens mit Geschäftspartnern.

Um den Einsatzbereich eines CRM-Systems weiter zu optimieren, müssen auch beispiels-weise die ERP- und SCM-Module zugreifbar sein. So können Bestellungsänderungenoder andere Wünsche des Kunden direkt vom CRM aus abgewickelt werden. Das CRM istquasi die Schnittstelle des Kunden zum Unternehmen, und somit müssen alle relevantenGeschäftsprozesse im Backend des Unternehmens und auch unternehmensübergreifendbei Lieferanten und Partnern zugreifbar sein. Bei CRM-Lösungen findet sich auch eineSpezialisierung nach Branchen, um konkret den unterschiedlichen Bedürfnissen gerechtzu werden.

Für den technischen Zugriff auf ein CRM-System gibt es BAPIs (Business Applicati-on 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 Proto-koll für entfernte Funktionsaufrufe. Dabei übernimmt das Protokoll die Kommunikations-steuerung, Parameterübergabe und die Fehlerbehandlung. Ein BAPI ist ein RFC-fähigerFunktionsbaustein, der einen fest definierten Funktionsumfang hat, meist zusammenfas-send für einen bestimmten Geschäftsvorfall. Weiterhin soll eine BAPI-Schnittstelle überVersionswechsel der Software hinaus konstant bleiben und abstrahiert somit mehr als einRFC-Interface.

Eine Funktion des CRM, auf die in diesem Rahmen näher eingegangen wird, ist das Ak-tivitätsmanagement, das die Mitarbeiter bei der Organisation der täglichen Arbeit unter-stü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 Interak-tionen mit Kunden. Wie sich eine Aktivität im graphischen SAP-Frontend darstellt, ist inAbbildung 2.7 zu sehen. Neben den beteiligten Ansprechpartnern auf Unternehmens- undKundenseite wird auch der Ort und der Zeitraum festgehalten. Es kann ein Text für denGrund und das Ziel der Aktivität hinterlegt werden, ebenso wie ein Erledigungsstatus,

19

Page 34: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 ver-knüpft sein, beispielsweise Marketingbroschüren oder Briefe, die an den Kunden adres-siert wurden. Dabei werden noch die speziellen Möglichkeiten vom System angeboten,einen Aktivitätsbericht zu erstellen oder einen Fragebogen zu entwerfen und Aktivitätenzuzuordnen. In einem Aktivitätsbericht kann der Produktbezug einer Aktivität festgehal-ten werden oder auch Feedback des Kunden. Mit Hilfe eines Fragebogens können z.B. dieVerkaufschancen (Opportunity-Bewertung) in einer Geschäftsbeziehung berechnet wer-den.

2.3.2 SAP-XI - eXchange Infrastructure

Die SAP Exchange Infrastructure (XI) (siehe [SO04]) ist ein Bestandteil von NetWeaverund dient der Integration von SAP- und Fremdanwendungen inner- oder außerhalb desUnternehmens. Hervorgehoben sei an dieser Stelle, dass auch einige SAP-Module wiebeispielsweise SRM und CRM über XI angebunden sind. Dies unterstreicht das Service-orientierte Paradigma der SAP-Architektur. Die an Geschäftsprozessen orientierte Inte-

20

Page 35: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 Ab-speichern von integrationsspezifischem Wissen an zentraler Stelle. So wird vermieden,dass die Unternehmensanwendungen direkt miteinander verknüpft werden und dadurcheine komplexe Struktur mit möglicherweise unterschiedlichen verwendeten Technologienentsteht. Stattdessen kommuniziert jede Applikation mit der XI, die Daten intern durchXML-basierte Nachrichten repräsentiert und an die entsprechende Ziel-Anwendung wei-terleitet. Dadurch ist die Kopplung der Anwendungen an den Kommunikationsendpunk-ten gering. Das interne XI-Protokoll basiert auf SOAP und verwendet Header Extensionsund weitere Payload in MIME Multiparts. Der Datenaustausch mit XI kann synchronund asynchron erfolgen. Eine solche Plattform, die Nachrichten zwischen voneinanderunabhängigen Systemen vermittelt, nennt man in diesem Zusammenhang auch Message-

orientied Middleware (MOM).

In Abbildung 2.8 sind die wesentlichen Teile von XI dargestellt. Die Adapter-Engine setztNachrichten der zu integrierenden Systeme in das XI-Message-Format um und umge-kehrt. Statt Formatumsetzungen für alle Kombinationen miteinander kommunizierenderSysteme muss lediglich eine Umsetzung für die entsprechenden Protokolle in beide Rich-tungen stattfinden, beispielsweise SOAP-Nachrichten in RFC- oder BAPI-Aufrufe umset-zen und umgekehrt. Anstatt die Adapter-Engine zu verwenden, kann mit einer Java- oderABAP-Anwendung innerhalb des Applikation Servers auch direkt mit der Integration-

Engine kommuniziert werden. Die Integration-Engine übernimmt das Routing der kon-vertierten Nachrichten, und ggf. werden sogenannte Mappings durchgeführt. Mit Hilfevon Mappings können Datenkonvertierungen in XI umgesetzt werden, um die Doku-

21

Page 36: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 zustandsbehafteteNachrichtenübermittlung auf Geschäftsprozessebene.

Die nötigen Informationen, um Nachrichten zwischen Systemen zu vermitteln, werdenin Integration-Repository, Integration-Directory und System-Landscape-Directory (SLD)gespeichert, deren Inhalt im Folgenden erläutert wird:

• System-Landscape-DirectoryDas SLD enthält einen Katalog mit Beschreibungen über installierbare Software-produkte und deren Komponenten in der Systemlandschaft. Mit Komponenten sindin diesem Fall einzeln installierbare Einheiten gemeint, die jedoch nicht zwangs-weise ohne das Hauptprodukt ausführbar sind. Die Beschreibungen enthalten auchjeweils die Version des Produkts oder der Komponente. In einem weiteren Katalogwerden die konkreten Systeme erfasst, unterteilt in technische Systeme und wei-ter abstrahierend in Business-Systeme. Abgespeichert werden diese Daten mit demStandard Common Information Model (CIM) [DMT06]. Für SAP-Produkte werdenbereits entsprechende Beschreibungen mit ausgeliefert.

• Integration-RepositoryIm Integration-Repository werden die Schnittstellen der beteiligten Systeme inForm von WSDL- und XML-Schema-Dokumenten hinterlegt. Die Definition vonProzessen kann mittels der Business Process Execution Language (BPEL) [BPE]stattfinden. Für die bereits erwähnten Mappings werden XSLT-Dokumente verwen-det.

• Integration-DirectoryDurch das Integration-Directory werden Schnittstellen aus dem Integration-Reposi-tory konkrete Systeme aus dem SLD zugeordnet. Dadurch werden letztendlich dieSysteme 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 dieKonfiguration im Integration-Directory vorgenommen werden. Das SLD kann über eineWeb-Anwendung konfiguriert werden.

22

Page 37: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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-Anwendungenfür mobile Endgeräte zu entwickeln. Die Basis dieses Abschnitts sind die Lehr-Bücher[Sch04] und [Yua06].

2.4.1 Überblick

Die Micro Edition ist eine Spezifikation der Java-Laufzeitumgebung für mobile Endge-räte wie beispielsweise PDAs und Mobiltelefone. Aufgrund der unterschiedlichen Aus-prägungen und Einschränkungen solcher Geräte ist J2ME komponentenbasiert aufgebautund dadurch flexibler als die Java 2 Standard Edition (J2SE). Die Spezifikationen sind imoffenen Java Community Process (JCP) unter Federführung großer Hersteller wie Nokiaund RIM durch sogenannte Java Specification Requests (JSR) entstanden.

Die unterste von drei Schichten in J2ME (siehe Grafik 2.9) bilden sogenannte Konfi-gurationen. Sie legen fest, welche Hardwareanforderungen ein Gerät erfüllen muss, unddefinieren zu den Anforderungen passende Standardbibliotheken und eine Java Virtual

Machine (JVM). Auf diesen Konfigurationen bauen diverse Profile auf, die weitere fun-damentale, gerätespezifische Bibliotheken zur Verfügung stellen. In der letzten Schicht,die auf ein Profil aufsetzt, gibt es optionale Zusatzpakete, beispielsweise eine 3D-APIoder XML-Parser.

Die Connected Limited Device Configuration (CLDC) zielt auf in der Hardware einge-schränkte Geräte ab. Die Mindestanforderungen sind 160kB nichtflüchtiger Speicher fürdie VM und Bibliotheken und 32kB flüchtiger Speicher für den Ablauf der VM. Auf-grund dieser Restriktionen ist nur eine Untermenge der J2SE-API vorgesehen und an dieEndgerä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ößtenteilsauf 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 Hardwareanforderun-gen, stellt mehr Funktionalität der J2SE-API zur Verfügung und kommt beispielsweiseauf High-End PDAs, TV Set-Top-Boxen oder Navigationssystemen zum Einsatz. Im Ge-gensatz zur CLDC bietet sie eine vollständige J2SE JVM. Für diese Diplomarbeit ist nurdie Konfiguration CLDC relevant.

23

Page 38: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 eineAPI 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ätz-lich zu denen der CLDC, um die Funktionalität des MIDP realisieren zu können. Im We-sentlichen sind dies weiterer Speicher von mind. 256kB für die MIDP-Implementierungund 8kB für persistente Daten, eine minimale Auflösung des Displays mit 96x96 Pixelnund 1 Bit Farbtiefe, sowie eine Tastatur oder einen Touchscreen.

2.4.2 Deployment

In den folgenden Abschnitten erfolgt eine Beschreibung des Packaging und der Instal-lation von J2ME-Anwendungen auf Basis des MIDP (siehe Kapitel 2 der Spezifikation[MW06]).

2.4.2.1 MIDlet Suite

Die Installation und das Starten einer Anwendung geschehen über die Application Ma-

nagement Software (AMS), die auf dem Endgerät vom Hersteller implementiert ist. Eine

24

Page 39: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

Deinstallation wird ebenso von der AMS durchgeführt. Eine installierbare Anwendungnennt sich MIDlet Suite und besteht aus einem JAR und einem optionalen Java Applica-

tion Descriptor (JAD). Ein Beispiel eines JAD findet sich im Quellcode-Listing 2.5. DasJAR enthält die kompilierten Klassen der Anwendung, eine Manifest-Datei, sowie optio-nale 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 2.4.1 erwähnt, nicht den vollen J2SE-VM-Umfang implementiert, mussder generierte Bytecode anschließend noch mit einem sogenannten Preverifier bearbei-tet werden. Ein solches Werkzeug wird beispielsweise innerhalb des Wireless Toolkit

(WTK)1 von Sun bereitgestellt, und formt den Bytecode zu einem Äquivalent um, dasauf 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: 1.0.11

6 MicroEdition-Configuration: CLDC-1.1

MicroEdition-Profile: MIDP-2.0

8 CustomAttribute: value

Quellcode 2.5: Beispiel eines Java Application Descriptors

Die Manifest-Datei besteht aus Key:Value-Paaren und beinhaltet notwendige Informa-tionen für das AMS zur Installation. Optional können einige solcher Attribute auch durcheinen externen JAD zur Verfügung gestellt werden, so dass die Anwendung an den Be-nutzer oder das Endgerät angepasst werden kann, ohne das JAR modifizieren zu müssen.Außerdem können eigene anwendungsspezifische Attribute angelegt werden, die jedochnicht mit „MIDlet“ oder „MicroEdition“ beginnen dürfen. Weitere Details und eine Über-sicht zu verpflichtenden Attributen hält die Spezifikation [MW06] auf S. 435 bereit. Mitder Methode getAppProperty() der Klasse MIDlet lassen sich alle im JAD ange-gebenen Attribute der Suite zur Laufzeit abfragen. Die Ressourcen kann ein MIDlet überdie Methode java.lang.Class.getResourceAsStream(String name) alsDatenstrom auslesen. Das Wurzelverzeichnis ist dabei das JAR des MIDlets.

1http://java.sun.com/products/sjwtoolkit/download-2_5.html

25

Page 40: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

2.4.2.2 OTA Provisioning

Der Installationsvorgang wird nach dem Over The Air (OTA) Provisioning Verfahren ab-gewickelt, das in [MW06] Kapitel 2 genauer spezifiziert ist. Die MIDlet Suite liegt dabeiauf einem entfernten Web Server vor und wird in mehreren Schritten über die Funkver-bindung auf das Endgerät übertragen:

1. Der Benutzer wählt im Endgerät die zu installierende Anwendung in der soge-nannten Discovery Application (DA) aus - üblicherweise geschieht dies im WAP-Browser. Durch eine HTTP-GET-Anfrage wird der entsprechenden JAD vom Ser-ver auf das Endgerät transferiert und von der AMS ausgewertet.

2. Falls alle im JAD enthaltenen Voraussetzungen zur Installation erfüllt sind, wirddurch die AMS das JAR der Anwendung (die URL befindet sich im JAD) ebenfallsvia 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 derInstallation ü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 HTTPHeader angeben sollte.

2.4.3 Programmierung

In den folgenden Abschnitten wird auf die Entwicklung von J2ME-Anwendungen einge-gangen, basierend auf der Konfiguration CLDC 1.1 und dem Profil MIDP 2.0.

2.4.3.1 Lebenszyklus

Wenn der Benutzer eine Anwendung zum Starten ausgewählt hat, wird von der AMSdas entsprechende MIDlet geladen. Der Einstiegspunkt einer solchen Anwendung, ana-log zur Funktion main() in J2SE oder anderen Programmiersprachen, ist in der ab-strakten Klasse javax.microedition.midlet.MIDlet definiert. Eine Applika-tion muss dementsprechend mindestens eine Klasse beinhalten, die MIDlet erweitert unddie Handler-Methoden startApp(), pauseApp() und destroyApp(boolean

unconditional) überschreibt.

26

Page 41: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 ei-nes MIDlets kann sowohl von der AMS als auch vom MIDlet selbst in einen an-deren überführt werden (siehe Abbildung 2.10). Wenn ein Zustandsübergang von derAMS ausgelöst wird, ruft diese zunächst die entsprechende Handler-Methode des MID-lets auf. Wird der Zustand vom MIDlet selbst geändert, durch den Aufruf einer derMethoden 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 re-gulä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 MID-lets aufgerufen, und der Zustand ist paused. Im Konstruktor können nicht-zeitaufwändigeInitialisierungen erfolgen. Weitere Ressourcenanforderungen und das Erfüllen der eigent-lichen Aufgabe der Applikation erfolgen in startApp() bzw. von dort aus delegiert inanderen 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. Inder Handler-Methode pauseApp() sollte das MIDlet dabei zuvor angeforderte Res-sourcen freigeben. Falls das MIDlet Hintergrund-Threads gestartet hat, so laufen dieseweiter, auch wenn das MIDlet pausiert. Daher sollten solche Threads nicht viele Ressour-cen wie CPU-Zeit, Speicher und Bandbreite benötigen oder anderenfalls gestoppt wer-den. Soll das MIDlet durch die AMS beendet werden, so wird destroyApp(booleanunconditional) aufgerufen, wobei der Parameter angibt, ob das MIDlet den Befehlzur Beendigung mit einer MIDletStateChangeException verweigern kann odernicht. Weiterhin werden in dieser Methode üblicherweise Ressourcen freigegeben - bei-

27

Page 42: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

spielsweise Deskriptoren freigeben oder Threads beenden - und ggf. Anwendungsdatenpersistent gespeichert.

2.4.3.2 PushRegistry

Für Anwendungen, die auf bestimmte Ereignisse warten, stellt die AMS eine sogenann-te PushRegistry zur Verfügung. Bei dieser Komponente können sich Anwendungen dy-namisch via javax.microedition.io.PushRegistry oder statisch über einenEintrag im JAD registrieren und werden dann von der AMS gestartet, wenn ein entspre-chendes Ereignis eintritt. Dadurch ist es für eine Applikation möglich, auf eingehendeTCP- und UDP-Verbindungen an einem registrierten Port oder auf eine SMS von einerbestimmten Rufnummer zu reagieren. Darüberhinaus bietet die PushRegistry noch dieMö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 Er-eignis eintritt und nicht selbst aktiv wartet. Somit können Ressourcen gespart werden.Die AMS wartet auf eingehende Verbindungen an registrierten Ports und startet das zu-gehörige MIDlet, das die Verbindung über javax.microedition.io.Connectormit der Methode open() öffnen kann. Das MIDlet ist, wenn es gestartet ist, selbst füreingehende Verbindungen und darauf empfangene Daten verantwortlich. Die AMS über-wacht dies erst wieder, nachdem das MIDlet beendet wurde. Zu beachten ist dabei, dassim JAD das Attribut MIDlet-Permissions entsprechend die vollqualifizierten Klas-sennamen der PushRegistry und der verwendeten Netzwerkklassen enthält.

2.4.3.3 Graphische Benutzerschnittstelle

Das Lowest Common Denominator User Interface (LCDUI) im Package javax-

.microedition.lcdui ist ein Framework der J2ME für grafische Benutzerschnitt-stellen und untergliedert sich in eine High- und Low-Level-API. Letzteres ermöglichtpixelgenaues Zeichnen auf dem Display, das Nutzen von gerätespezifischen Hardware-funktionalitä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 be-trachtet.

Im Gegensatz dazu ist die High-Level-API eine abstrahierende Schicht über den geräte-spezifischen Grafik-Elementen, den sogenannten Widgets. Dies hat zur Folge, dass An-wendungen, die diese API nutzen, nicht auf jedem Gerät das gleiche Look and Feel - alsoErscheinungsbild und Bedienung der Widgets - haben. Auf der anderen Seite integriert

28

Page 43: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

sich die Anwendung so automatisch, und der Benutzer hat das vom Endgerät gewohnteLook and Feel.

Ein Überblick der Klassenhierarchie der LCDUI wird in Abbildung 2.11 gegeben. Ge-meinsam ist beiden APIs, dass sie eine dem MIDlet zugeordnete Instanz der KlasseDisplay verwenden, die das physikalische Display repräsentiert und mit der stati-schen Methode Display.getDisplay(MIDlet m) abgefragt werden kann. Zu ei-nem Zeitpunkt kann auf dem Display ein einziges Objekt dargestellt werden, das dieabstrakte Klasse Displayable erweitert. Darin werden bereits die Funktionalitäten füreinen Fenster-Titel, -Laufschrift und Hinzufügen von Bedienelementen zur Interaktionmit dem Benutzer zur Verfügung gestellt. Um die Benutzereingaben zu bearbeiten, kannman einem Displayable-Objekt auch CommandListener übergeben, die häufig alsanonyme Klasse implementiert werden. Das Framework ruft dessen Callback-MethodecommandAction(Command c, Displayable d) bei entsprechenden Events se-riell auf, d.h. weitere Callbacks werden erst aufgerufen, wenn der vorherige beendet wur-de. Aus diesem Sachverhalt heraus ergibt sich die Empfehlung, in Callback-Methodenkeine zeitaufwändigen Operationen einzubetten.

Welches Objekt auf dem Bildschirm sichtbar sein soll, kann mit der Methode Display-.setCurrent(Displayable nextDisplayable) gesetzt werden. Diese Me-thode darf jedoch nicht im Konstruktor des MIDlets sondern erst in startApp() aufge-rufen werden. Über Display lassen sich außerdem Informationen zum Display abfragensowie die Hintergrundbeleuchtung und der Vibrationsalarm steuern.

Von Displayable erbt die Klasse Canvas, an der die Low-Level-API ansetzt. DasPendant 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 manmit Items bestücken kann, die eigene ItemCommandListener haben können. Esgibt vorgefertigte Unterklassen von Item, die häufig benötigte Funktionalitäten zur Ver-fügung stellen, beispielsweise eine Auswahl mittels ChoiceGroup, die vereinfachteEingabe 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 Benutzerschnittstellenist die Verwendung von Threads. Die Logik einer Anwendung sollte in einem separatenThread laufen, damit der Ausführungsstrang der LCDUI jederzeit Aktualisierungen in dergraphischen Repräsentation vornehmen kann.

29

Page 44: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

Abbildung 2.11: Zusammenhang der Klassen des LCDUI, adaptiert aus [Sch04]

30

Page 45: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

Abbildung 2.12: MIDlet-Suite übergreifende Zugriffe auf RecordStores

2.4.3.4 RMS - Persistente Speicherung

Um Daten auf mobilen Endgeräten persistent speichern zu können, definiert das MIDPeine abstrakte, herstellerunabhängige Schnittstelle - das sogenannte Record Management

System (RMS). Details können der Spezifikation [MW06] in Kapitel 14 entnommen wer-den.

Das RMS im Package javax.microedition.rms bietet den Klassen einer MID-let Suite die Funktionalität, RecordStores anzulegen, die dann wiederum eine Sammlungvon Records enthalten. Ein Record ist ein Datensatz in Form eines Java Byte-Arrays vonbeliebigem Inhalt und Länge, dem vom RMS ein Primärschlüssel als Identifikator zuge-ordnet 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 neuvergeben. Ein RecordStore ist durch einen innerhalb der MIDlet Suite eindeutigen Namenbezeichnet, der 1 bis 32 Unicode-Zeichen umfassen kann, wobei Groß- und Kleinschrei-bung beachtet wird. Seit MIDP 2.0 kann ein RecordStore über ein Attribut auch für andereMIDlet Suites zugänglich gemacht werden. Der Zugriff erfolgt dabei über die Bezeich-ner des MIDlet-Suite-Herstellers, der MIDlet Suite selbst (beides Attribute im JAD, sieheauch 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 zu-gehö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

Page 46: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 las-sen. Nachdem ein RecordStore geöffnet wurde, wird er durch eine Instanz der KlasseRecordStore repräsentiert, über die alle weiteren Operationen erreichbar sind. Im We-sentlichen sind dies die Methoden addRecord(), setRecord zum Modifizieren ei-nes vorhandenen Datensatzes und deleteRecord. Bei jedem Aufruf dieser Methodenwird die Version des RecordStores inkrementiert sowie der Zeitpunkt der letzten Ände-rung festgehalten. Diese Attribute können auch über die API abgerufen werden.

Eine Implementierung des RMS muss zusichern, dass diese Operationen immer atomarnacheinander ablaufen - Transaktionen werden jedoch nicht unterstützt. Bei der Verwen-dung von Threads muss daher beachtet werden, dass bei zusammengehörenden, auf-einander folgenden Operationen für das zugehörige RecordStore-Objekt mittels einessynchronized-Block in Java der exklusive Zugriff sichergestellt ist.

Um nun das Datenmodell einer Anwendung mittels RMS zu speichern, müssen die Ob-jekte zu Byte-Arrays serialisiert werden (siehe Codebeispiel 2.6). Dafür bietet es sichan, die Klasse java.io.DataOutputStream zu verwenden, die für alle primitivenDatentypen inkl. String eine Methode zum Schreiben in einen Ausgabestrom besitzt.Dahinter wird ein weiterer Ausgabestrom vom Typ ByteArrayOutputStream ge-schaltet, der die serialisierten Daten des DataOutputStreams erhält und eine MethodetoByteArray() 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 einleerer String verwendet werden. Außerdem sollte der äußere Ausgabestrom nach der Be-nutzung mittels close() geschlossen werden. Analog dazu funktioniert die Deseriali-sierung aus dem RMS mit den Klassen ByteArrayInputStream und DataInput-Stream.

Für das Suchen von Datensätzen bietet ein RecordStore(-Objekt) die Methode enume-rateRecords(RecordFilter a, RecordComparator b, boolean ke

epUpdated). Optional kann man spezifische Implementierungen von RecordFilterund RecordComparator übergeben, so dass die Enumeration auf Basis des Inhaltseines Records gefiltert und die Reihenfolge der Records innerhalb der Enumeration be-einflusst werden kann. Für den Fall, dass für die beiden ersten Parameter null über-geben wird, enthält die Enumeration alle Records des RecordStores und die Reihenfol-ge ist beliebig. Das Resultat von enumerateRecords() implementiert das InterfaceRecordEnumeration, über das man durch die Ergebnismenge der Records iterie-ren kann und deren Primärschlüssel oder den Inhalt abrufen kann. Der dritte ParameterkeepUpdated gibt an, ob die Datensatzrepräsentation sich mit ändern soll, falls am

32

Page 47: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

private String s = "string";2 private boolean b = true;private int i = 42;

4public byte[] serialize() throws IOException {

6 ByteArrayOutputStream byteStream = new ByteArrayOutputStream();DataOutputStream dataStream = new DataOutputStream(byteStream);

8dataStream.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önnenProbleme beim Iterieren auftreten, wenn gleichzeitig der RecordStore manipuliert wird.In diesem Fall bieten sich dynamische Enumerationen an, die jedoch auch mehr Sys-temressourcen benötigen.

2.4.3.5 kSOAP Web-Service-Bibliothek

Eine Möglichkeit, unter der J2ME- und der J2SE-Plattform Web Services zu konsumie-ren, bietet das im Sourcecode frei verfügbare Projekt kSOAP1. Dieser SOAP-Parser istspeziell für in der Hardware eingeschränkte Geräte gedacht und implementiert daher auchnicht die gesamte Spezifikation von SOAP. Für übliche Web Services ist der Umfang je-doch nach [Yua06] ausreichend.

Zum Parsing von XML-basierten SOAP-Dokumenten kommt die kXML-Bibliothek inder Version 2 zum Einsatz, die das XML-Pull API (xmlpull.org) implementiert. Mit die-sem Parsing-Modell kann man durch die Elemente des XML-Dokuments seriell iterierenund benötigte Informationen abfragen, wie z.B. Inhalt des Elements und Attributwer-te. Im Vergleich zum etablierten Parsing-Modell Simple API for XML (SAX) kann dasPull-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 zumEnde abgearbeitet und entsprechende benutzerdefinierte Handler-Methoden für die Ele-mente vom Parser werden aufgerufen. Das Document Object Model (DOM) ist für größe-re XML-Dokumente auf eingeschränkten Endgeräten ohnehin keine Alternative, da eineRepräsentation des gesamten Dokuments dabei im Speicher gehalten wird.

1http://ksoap2.sourceforge.net

33

Page 48: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

XML-Datentyp Java-Datentypxsd:int java.lang.Integerxsd:long java.lang.Longxsd:string java.lang.Stringxsd:Boolean 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 ent-haltenen Typen eine standardmäßige Zuordnung zu Java-Datentypen.

Alle weiteren primitiven Datentypen, d.h. Elemente ohne Unterelemente, kapselt kSOAPin einem Objekt der Klasse SoapPrimitive. Diese enthält den Namen und Na-mensraum des Datenelements sowie dessen Wert in Form eines Strings. Komple-xe Datentypen mit Unterelementen werden durch eine Instanz der Klasse Soap-

Object repräsentiert, die analog Name und Namensraum des Elements als Attributaufnimmt. Die Kind-Elemente werden in einem Vektor als Object gespeichert, ge-paart mit einer Instanz von PropertyInfo, in der die XML-spezifischen Namens-informationen gehalten werden. Das referenzierte Object kann dabei je nach Kind-Element eine Instanz von SoapObject, SoapPrimitive oder einer anwendungs-spezifischen Java-Klasse sein. Letzteres ist dann der Fall, wenn beim SOAP-Parser(SoapSerializationEnvelope) eine Klasse für die Deserialisierung der spezifi-schen Klasse registriert wurde. Eine solche Klasse kann das Interface Marshal im-plementieren und stellt somit je eine Methode für das Entpacken von XML-Elemen-ten 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 Ob-jekt, das diese Schnittstelle implementiert, kann durch den SOAP-Parser automatisiertsowohl 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öri-gen XML-Elements des Attributs gespeichert, sowie der Java-Datentyp. Der Datentypkann ein primitiver sein (siehe Tabelle 2.1) oder es wird auf eine weitere Klasse ver-wiesen, die KvmSerializable implementiert. Über die Methoden setProperty

bzw. getProperty kann der SOAP-Parser das entsprechende Attribut, das aus demXML-Dokument extrahiert wurde, setzen bzw. den Wert des Attributs erfragen und in daszugehörige XML-Element serialisieren.

34

Page 49: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

2.4.3.6 Optimierungen für mobile Anwendungen

Die Entwicklung von Anwendungen für mobile Endgeräte bringt einige besondere An-forderungen mit sich. Die Fähigkeiten der Hardware sind stark begrenzt (vgl. MIDP inAbschnitt 2.4.1), und somit müssen CPU-Zeit und Speicher besonders effizient einge-setzt werden, was in [Yua06] Kapitel 7 näher erläutert wird. Um dies zu erreichen, sinddie verwendeten Bibliotheken für mobile Anwendungen leichtgewichtiger als die J2SE-Alternativen, haben also sowohl eine geringere Größe als auch eine Anpassung an den ge-ringen zur Laufzeit zur Verfügung stehenden Speicher. An dieser Stelle bietet sich nochdie Möglichkeit, beim Packaging die Größe zu minimieren. Von der Anwendung nichtbenötigte Klassen können aus den Bibliotheken entfernt werden. Dies übernimmt meistein sogenannter Obfuscator, ursprünglich dafür gedacht, den Binärcode von Anwendun-gen zu verschleiern, um eine Decompilierung zu erschweren. Er läßt sich weiterhin dazuverwenden, den Binärcode durch Umbenennung von Klassen und Methoden noch zu ver-kleinern und Methodenaufrufe ’inline’ zur ersetzen. Um den Code aus Bibliotheken nichtin jede MIDlet-Suite hinzufügen zu müssen, gibt es bei BB-Geräten die Möglichkeit, sha-red libraries zu installieren, die von mehreren Anwendungen gleichzeitig benutzt werden.Mit der noch in Planung befindlichen Version 3 des MIDP (JSR 271) ist die Aufnahmevon 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 Anspruchnimmt. Empfohlene Möglichkeiten nach [Yua06] den Speicherverbrauch zu reduzierensind:

1. Arrays gegenüber Collection Containern bevorzugen.

2. Bei String-Manipulationen eine StringBuffer-Instanz verwenden (Modifika-tionen von String-Objekten erzeugen neue Instanzen).

35

Page 50: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

3. Ressourcen wie Netzwerkverbindungen, RecordStores und Filehandles frühest-mö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 Klassenund Schnittstellen-Schichten mit sich bringen. In [Yua06] wird als Beispiel eineschlankere 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 Endge-rät angesprochenen externen Netzwerkschnittstellen nach außen hin nicht zu feingranularzu gestalten, so dass insgesamt weniger Aufrufe dieser Schnittstellen notwendig sind.Desweiteren sollten diese Operationen gepuffert und nicht zeichenweise angesprochenwerden. Bei den meisten J2ME-Schnittstellen bietet sich eine Kombination aus einembyte[]-Puffer und einem ByteArrayOutputStream an (bzw. analog für einen Ein-gabestrom).

Der Netzwerkverkehr und die Latenz für den Benutzer lassen sich reduzieren, indemJ2ME-Anwendungen Anwendungsdaten lokal speichern. Dies ermöglicht zudem unterUmständen auch eine gewisse Funktionalität der Anwendung, wenn das Gerät keine Ver-bindung zu einem Netzwerk herstellen kann. Beim Zwischenspeichern der Daten ist zubeachten, dass dies möglichst zeitnah geschieht, um Datenverluste zu vermeiden, auchunter dem Gesichtspunkt, dass leistungsfähige Endgeräte noch unzureichende Betriebs-laufzeiten im mobilen Einsatz haben.

Eine benutzerfreundliche Anwendung sollte benutzerspezifische Einstellungen ebenfallsspeichern, lange Operationen auf mehrere Dialoge aufteilen und Rückmeldungen überden Status geben.

Ein weiterer Aspekt bei der Entwicklung einer Anwendung ist, dass sie auf möglichstvielen Endgeräten lauffähig sein sollte. Dabei hilft es, wenn sich die Applikation übereinen JAD konfigurieren lässt und die Benutzerschnittstelle im Quellcode leicht angepasstwerden kann.

Für die Entwicklung von J2ME-Anwendungen auf den BB-Endgeräten hat RIM einenProgrammier-Leitfaden in [RIM05] ab Seite 30 integriert, der weitere Java-Optimierun-gen auf Quellcode-Ebene liefert.

36

Page 51: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

2.4.4 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 privatenSchlüssel signiert und zusammen mit dem zugehörigen öffentlichen Schlüsssel in Formeines Zertifikats in den JAD eingetragen. Bei Installation der MIDlet Suite wird die Prüf-summe des JARs gebildet, mittels Zertifikat die Prüfsumme im JAD entschlüsselt undmit der ermittelten verglichen. Das Zertifikat selbst muss immer von einer Certification

Authority (CA) signiert sein. So ist sichergestellt, dass der Inhalt der sogenannten Trus-

ted MIDlet Suite seit dem Zeitpunkt der Signierung nicht verändert wurde und einembestimmten Softwarehersteller anhand des Zertifikats zugeordnet werden kann. Um dieIntegrität des Zertifikats zu überprüfen, sind in den Endgeräten üblicherweise die Zertifi-kate der Root-CAs hinterlegt. Daher muss der JAD eine Zertifikat-Kette bis hin zu einemRoot-Zertifikat beinhalten. Im einfachsten Fall ist dies nur ein Zertifikat (das des Soft-wareherstellers), wenn es von einer Root-CA signiert ist. Eine MIDlet-Suite, die keineSignatur im JAD enthält, wird als Untrusted MIDlet Suite eingestuft und unterliegt da-durch Einschränkungen beim Zugriff auf die J2ME APIs. In diesem Fall muss der Nutzerexplizit für Verbindungen über HTTP zustimmen. Alle weiteren Netzwerkfunktionalitä-ten im Package javax.microedition.io sind ausschließlich durch Trusted MIDletSuites benutzbar. Anwendungen gemäß der MIDP 1.0 Spezifikation werden ebenfalls alsuntrusted eingestuft.

An dieser Stelle sei noch erwähnt, dass Attribute im JAD gleichnamige im Manifest über-schreiben, außer es handelt sich um eine Trusted MIDlet Suite. In diesem Fall wird dieInstallation abgebrochen, wenn sich die Werte der Attribute in JAD und Manifest unter-scheiden.

37

Page 52: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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

38

Page 53: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 3

Analyse

In diesem Kapitel werden zunächst die Anforderungen an die gesamte Systemarchitek-tur und die zu entwickelnde mobile Client-Anwendung erläutert, die von nun an auchmobileCRM genannt wird. Dies geschieht durch die Rahmenbedingungen, die durch dieBetreuung seitens der Firma CSC und der FH Wiebaden festgelegt wurden, sowie durcheine Beschreibung der Anwendungsfälle, die die Anwendung abdecken soll. Innerhalbdieses Rahmens werden darauffolgend die Möglichkeiten zur Realisierung untersucht,aufgegliedert in die einzelnen Systembestandteile Server, Mobile-Gateway und Client.

3.1 Anforderungen

3.1.1 Rahmenbedingungen

Die bei der Themenstellung gemachten Vorgaben beeinflussen Analyse und Design derDiplomarbeit. Sie begrenzen die möglichen Lösungansätze für die Realisierung und wer-den in diesem Abschnitt ausführlich beschrieben:

1. Nutzung der BlackBerry-Enterprise-ArchitekturVorgegeben ist die Verwendung der BB-Infrastruktur (siehe Kapitel 2.1). Die fürdiese Arbeit wesentlichen Teile dieser mobilen Plattform sind der BES im Unter-nehmensnetzwerk und ein spezielles mobiles Endgerät, auf dem die mobile Anwen-dung läuft. Ein BB-Endgerät vom Typ 7100v ist vorhanden. Insbesondere soll auchdie Push-Funktionalität eingesetzt werden, um Daten aus einem SAP-System überden BES an das mobile Endgerät zu übermitteln.

39

Page 54: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

3.1. Anforderungen Kapitel 3. Analyse

2. Anbindung an SAP-CRM im UnternehmenDie BB-Anwendung soll mit einem SAP-CRM 4.0 System (siehe Kapitel 2.3.1)kommunizieren und dadurch prototypisch die Funktionalität zum Verwalten vonAktivitäten im CRM bieten.

3. Smart-Client-AnwendungDie mobile Anwendung soll ein sogenannter Smart Client sein. Im Gegensatz zueiner Browser-basierten Applikation benutzt der Smart Client die lokale Benutzer-schnittstelle des BB-Endgeräts und macht von der Möglichkeit Gebrauch, Datenlokal zu speichern.

4. Einsatz von Web-Service-TechnologienDie Kommunikation zwischen dem SAP-CRM und der mobilen Anwendung solldurch einen Web Service erfolgen. Die damit in Zusammenhang stehenden Tech-nologien sind speziell für plattformübergreifende Anwendungen sehr gut geeignetund ein aktueller Technologie-Trend im Rahmen von SOA.

5. Generische VorgehensweiseEin weiteres Ziel dieser Arbeit ist es, bei der Realisierung möglichst generisch vor-zugehen, so dass bei der Entwicklung von weiteren mobilen Anwendungen auf Ba-sis 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 dargestelltenKomponenten, die für diese Arbeit relevant sind und untersucht werden. Diese Systemar-chitektur wird in den Unterkapiteln ab 3.2 ff. detailliert betrachtet. Im Folgenden wirdzuerst genauer definiert, welche Anforderungen die mobile Applikation aus Anwender-sicht erfüllen soll.

40

Page 55: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 3. Analyse 3.1. Anforderungen

Abbildung 3.2: Server-initiierte Anwendungsfälle

3.1.2 Anwendungsfälle

In diesem Abschnitt werden die Anwendungsfälle definiert, die abstrakt beschreiben, wel-che Interaktionen zwischen dem Benutzer, mobileCRM und dem SAP-System stattfinden.Die Anwendungsfälle wurden in Server- und Client-initiiert unterschieden. In den Abbil-dungen 3.2 und 3.3 sind die sogenannten Use-Cases mit UML modelliert.

Die Anwendungsfälle beziehen sich auf das Aktivitätsmanagement. Der Workflow siehtdabei so aus, dass Änderungen am SAP-CRM-System über eine Push-Nachricht an al-le beteiligten Clients propagiert werden, und umgekehrt Änderungen auf dem Endgerätmöglichst direkt zum SAP-CRM-System übertragen werden. Nach Anlegen einer Aktivi-tät kann sie den Status open oder In Process annehmen, und wird durch den StatusCompleted oder auch Rejected abgeschlossen. Dabei kann der Erledigungsstatusnoch prozentual hinterlegt werden. Im SAP-CRM-System selbst wird eine Aktivität niegelöscht, sondern bleibt als Beleg erhalten.

3.1.2.1 Server-initiiert

• AktivitätsänderungSobald eine Aktivität im SAP-System neu angelegt oder modifiziert wird, mussan die Ansprechpartner auf Unternehmensseite ein Update auf das BB-Endgerätgeschickt werden. Dazu muss für den Ansprechpartner in der Aktivität seineBlackBerry-E-Mail-Adresse hinterlegt sein.

• Daten synchronisierenNach einer Aktivitätsänderung werden die neuen Daten vom SAP-System über diePush-Funktion des BES an die zugehörigen BB-Endgeräte geschickt. Die mobileAnwendung auf dem Endgerät empfängt und speichert die Aktivität.

41

Page 56: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

3.1. Anforderungen Kapitel 3. Analyse

Abbildung 3.3: Client-initiierte Anwendungsfälle

3.1.2.2 Client-initiiert

In die Kategorie Client-initiiert fallen Aktionen, die der Benutzer in der mobilen Anwen-dung ausführen kann.

• Aktivitäten auflistenAlle auf dem BB-Endgerät lokal gespeicherten Aktivitäten werden aufgelistet, zurAuswahl für weitere Aktionen mit einer Aktivität.

• Aktivität anlegenDer Benutzer kann in der Anwendung eine neue Aktivität anlegen. Dafür werdendie essentiellen Daten einer Aktivität eingegeben und gespeichert. Dabei wird nurein Teil der Attribute unterstützt, die im SAP-System hinterlegt werden können.

• Aktivität modifizierenIst eine Aktivität auf dem Endgerät bereits vorhanden, so können die Daten verän-

42

Page 57: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 3. Analyse 3.1. Anforderungen

dert und abgespeichert werden. Darunter fällt insbesondere auch das Ändern desStatus der Aktivität.

• Aktivität löschenEine Aktivität kann vom Anwender gelöscht werden. Dies bezieht sich allerdingsnur auf die lokale Speicherung auf dem Endgerät, im SAP-System werden keineDatensätze gelöscht. Zum Abschließen der Aktivität wird lediglich der Status aufCompleted gesetzt.

• Aktivität anzeigenDer Anwender kann eine gespeicherte Aktivität auswählen und sich die Daten an-zeigen lassen. Eine Interaktion mit dem SAP-System findet dabei nicht statt. Eswird nur eine Auswahl der Attribute dargestellt, die im SAP-System hinterlegt wer-den können.

• Aktivitätenliste anfordernAlle Aktivitäten, die den Benutzer der mobilen Anwendung betreffen, werdenBenutzer-initiiert auf das Endgerät geladen und abgespeichert. Somit lassen sichim SAP-System bereits vorhandene Aktivitäten anfordern.

• Daten synchronisierenNeue oder modifizierte Aktivitäten auf Client-Seite werden automatisch mit demSAP-System abgeglichen. Für diesen Vorgang muss das Endgerät eine Verbindungzum BES haben. Ein Synchronisationsvorgang kann auch vom Benutzer initiiertwerden. Dies ist beispielsweise sinnvoll, falls ein automatisierter Synchronisie-rungsvorgang zuvor fehlgeschlagen ist.

3.1.3 Problembereiche

Die Analyse lässt sich in verschiedene Problembereiche aufteilen, welche jeweils ver-schiedene Komponenten der gesamten Systemarchitektur betreffen. Diese sind zur Ein-ordnung im Folgenden kurz umrissen.

• SynchronisationKonsistenter Datenabgleich zwischen Client und Server bei konkurrierenden Zu-griffen.

• UsabilityBenutzerfreundlichkeit und Internationalisierung.

43

Page 58: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

3.2. Server Kapitel 3. Analyse

• Web ServiceBereitstellung einer SAP-Schnittstelle durch einen serverseitigen Web Service unddessen Kommunikation mit dem Client. Dabei geht es um die Auswahl oder Pro-grammierung einer Implementierung auf Server- und Client-Seite, sowie derenKompatibilität.

Die nachfolgenden Teile der Analyse sind anhand der einzelnen Systemkomponenten Ser-

ver, Mobile Gateway und Mobile Client gegliedert. Die Betrachtung beginnt serverseitig,da das SAP-CRM-System den Informationsfluss, die Beschaffenheit und den Zusammen-hang der Daten vorgibt.

3.2 Server

3.2.1 SAP-CRM

Die in den Anforderungen festgelegte Funktionalität der Anwendung in Bezug auf Ak-tivitä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 durch-führen. Eine Liste von mehreren benutzerspezifischen Aktivitäten kann durch BAPI-

_ACTIVITYCRM_GETDETAILMULT abgefragt werden. Hierfür werden jedoch die ein-deutigen IDs der Aktivitäten benötigt, die in einer vorhergehenden Abfrage ermittelt wer-den 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 zu-rück liefert.

3.2.2 Datenmodellierung

Das graphische Frontend von SAP bietet für das Management von Aktivitäten den in Ab-bildung 2.7 bereits vorgestellten, umfangreichen Interaktionsdialog, der viele Verweisezu weiteren Dialogen enthält wie beispielsweise mehr Details zu den Kontaktpersonen.Diese Menge von Informationen ist für die Bearbeitung auf einem eingeschränkten mo-bilen Endgerät zu groß, um übersichtlich dargestellt werden zu können. In Tabelle 3.1sind die auf dem BB-Endgerät verfügbar gemachten Attribute aufgelistet und anhand von

44

Page 59: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 Umset-zung einige Attribute benötigt wie beispielsweise die eindeutige ID und die Version einerAktivität. Zum Anderen wurden weitere Attribute abgebildet, die für das Szenario einesmobilen Einsatzes Sinn ergeben. Dies sind vor allem die Attribute, die den Status, dieVervollständigung in Prozent und den Zeitpunkt einer Aktivität definieren.

3.2.3 Web Service zum SAP-CRM-System

Um Punkt 2 der Rahmenbedingungen in Abschnitt 3.1.1 zu erfüllen, muss eine Schnitt-stelle in Form eines Web Service für das SAP-CRM-System geschaffen werden. Dafürbieten 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. Einemö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 alsWeb Service zugänglich macht. NetWeaver stellt außerdem das XI-Modul (siehe Kapi-tel 2.3.2) zur Verfügung, das für den Datenaustausch zwischen SAP-Modulen und auchFremdanwendungen via Web Services gedacht ist. Um Punkt 5 der Rahmenbedingun-gen (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 An-wendungen. Ein weiterer Vorteil ist die zentrale Konfiguration der zu integrierenden Sys-teme, 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 ange-bunden werden können. Für die Umsetzung dieser Arbeit wurde XI verwendet, da ent-sprechende Softwarelizenzen und administrierte Systeme schon vorhanden sind. Inner-halb des Unternehmens kann bereits auf Erfahrung mit dem SAP-System zurückgegriffenwerden.

45

Page 60: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

3.2. Server Kapitel 3. Analyse

Attribut-Bezeichnung BeispielwertactivityPartnerId 0000600039activityPartner Tobias Foo / 73365 Flensburgcategory 001categoryText Sales Callpriority 3priorityText Highgoal 005goalText Better cust. retent.directionText Outbounddirect 1objectType BUS2000126validFrom 2007-06-22validTo 2007-06-22fromTime 16:45:00toTime 16:55:00contactPersonId 0000600037contactPerson Foo / 76228 HimmelbrugsalesRepresentative 2000000010employeeResponsible 0000500550createdBy AOPATZchangedOn 20070214172936createdOn 20070122155130systemStatusId I1002systemStatusText Open PlanneduserStatusId E0001userStatusText Opencompletion 000transactionDescription Wichtiger Anruf, 50 mio projekttransactionType ZMS0transactionNumber 0000000201objectGUID urxewgMZdka41RkHMscGgw==organizationalUnit S 50000790distributionChannel 01salesOrganization O 50000609changedBy Constant

Tabelle 3.1: Übersicht der Attribute einer Aktivität in mobileCRM

46

Page 61: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 3. Analyse 3.3. Mobile Gateway

Durch die Benutzung von XI ergibt sich auch, welches der beiden in Abschnitt 2.1.4vorgestellten Push-Protokolle verwendet wird. Da die ausgehenden Nachrichten von XIXML-basiert sind, ist das PAP aus der WAP-Spezifikation nicht geeignet, da dieses dieNachricht als MIME-Multipart-Nachricht aufbaut. Das RIM-Push-Protokoll hingegenenthält alle für die Übertragung notwendigen Informationen im URI der Push-Anfragean den BES oder in optionalen HTTP Headern. Im Gegensatz zu PAP kann die Payloaddadurch XML-konform sein.

3.3 Mobile Gateway

Die Verwendung der BlackBerry-Plattform ist Vorgabe nach Punkt 1 der Rahmenbedin-gungen in Abschnitt 3.1.1. Daher werden an dieser Stelle keine alternativen Lösungenbetrachtet, die analog zum BES als Mobile-Gateway für mobile Endgeräte eine sichereVerbindung 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 (sieheAbbildung 2.1) prinzipiell die Möglichkeit der Industriespionage besteht. Gewissheit wür-de an dieser Stelle nur Einsicht in den Quellcode bringen, der von RIM allerdings nichtzur Verfügung gestellt wird. Die Sicherheitsfunktionen der BlackBerry-Architektur sindformal sehr umfangreich (siehe Abschnitt 2.1). Neben der Verschlüsselung des Daten-verkehrs werden auch IT-Richtlinien unterstützt, und die auf dem Endgerät gespeichertenDaten können ebenso kodiert und drahtlos gelöscht werden. Ein Artikel zur Kritik an derBlackBerry-Nachrichten-Verschlüsselung ist nachzulesen bei [Sch05], der unter anderemzwei Sicherheitsstudien zusammenfasst und zu dem Schluß kommt, dass diese Architek-tur prinzipiell als sicher einzustufen ist, unter der Annahme, dass die Algorithmen korrektimplementiert sind und keine Hintertüren in der Software vorhanden sind. Der Quellcodedes BES wurde im Rahmen einer der zuvor erwähnten Studien untersucht, offen zugäng-lich ist der Code jedoch nicht, so dass die Sicherheit dennoch Vertrauen in den Herstellervoraussetzt.

In Hinblick auf die Performance des BES wurden vom Hersteller weitreichende Funktio-nen implementiert. Die einzelnen Komponenten des Systems können bei Bedarf jeweilsauf einer eigenen Servermaschine verteilt betrieben werden, so dass die Performance ska-lierbar ist. Ebenso ist es möglich, mehrere Instanzen des BES bereit zu stellen, um einegroße Anzahl von BB-Endgeräten damit arbeiten zu lassen. Durch das symmetrische Ver-schlüsselungsverfahren wird der Overhead so gering wie möglich gehalten und gleichzei-

47

Page 62: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

3.4. Mobile Client Kapitel 3. Analyse

tig die Payload durch die Dispatcher-Komponente des BES komprimiert. Dies ist vor al-lem für GPRS-basierte Endgeräte entscheidend, da die Bandbreite dort sehr eingeschränktist.

Für die Realisierung wird der BES für MS Exchange in der aktuellen Version 4.1 in Kom-bination mit Windows 2003 Server verwendet. Die Wahl des E-Mail-Systems (IBM Lo-tus 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 E-Mail-Funktionen benutzt. Der BES kann nur auf den Server-Betriebssystemen Windows 2000Server und Windows 2003 Server von Microsoft betrieben werden. Als Lizenz für denBES wird eine kostenlose Trial-Version von RIM benutzt, deren Einschränkung darin be-steht, dass nur ein Endgerät damit betrieben werden kann, was für diese Untersuchungjedoch auch ausreichend ist.

3.4 Mobile Client

Die zu realisierende mobile Anwendung für das BB-Endgerät soll gemäß den Rahmenbe-dingungen ü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 sogenann-te SAP Mobile Infrastructure (MI). MI bietet für PDAs und Laptops eine J2SE-basierteAnwendung, die Logik, lokales Zwischenspeichern und Arbeiten im Offline-Modus un-terstützt. Für eingeschränkte mobile Endgeräte ist nur eine Browser-basierte Lösung vor-gesehen, die diese Funktionen nicht unterstützt. Die MI kann daher nicht als gleichwer-tige Alternative zu dem in dieser Arbeit entwickelten mobileCRM gesehen werden. DieKommunikation des BB-Endgeräts mit dem BES (siehe Abschnitt 2.1.1) funktioniert aufzwei möglichen Wegen. Serverseitig im Unternehmen initiierte Verbindungen werden alsPush-Nachricht über den BES an das Endgerät gesendet, der dabei als Proxy fungiert, undNachrichten für Endgeräte im Offline-Modus zwischenspeichert. Client-initiierte Verbin-dungen werden über das MDS-Modul des BES aufgebaut, das ebenfalls eine Proxyfunk-tion ü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

Page 63: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 3. Analyse 3.4. Mobile Client

Anwendungen für aktuelle BB-Endgeräte werden prinzipiell in J2ME (siehe Abschnitt2.4) und ggf. herstellerspezifischen Erweiterungen programmiert. RIM bietet zusätzlichmit dem MDS-Studio (vgl. Abschnitt 2.1.2) eine Möglichkeit, auf Web Services basieren-de Anwendungen IDE-gestützt sehr schnell entwickeln zu können. Diese Lösung bietetjedoch keinen Zugriff auf die Java-API des Endgeräts. Dadurch ist keine lokale Spei-cherung von Daten möglich, und das Arbeiten im Offline-Modus (RahmenbedingungenPunkt 3) wäre folglich nicht möglich. Ebenso ist eine Übertragung von Aktivitätsdatenin das PIM somit von vornherein ausgeschlossen. Mit MDS-Studio erstellte Programmewerden in einem proprietären XML-Format gespeichert, und von der MDS-Runtime imEndgerät in Java-Aufrufe umgesetzt. Daher sind an dieser Stelle keine Erweiterungenmöglich.

Eine alternative Lösungsmöglichkeit besteht in einer J2ME-Anwendung, die zudem auchkompatibel zu anderen Endgeräten ist. Diese Kompatibilität käme allerdings erst zumTragen, wenn die Anwendung auf eine andere mobile Plattform portiert werden sollte.Weiterhin sieht diese Möglichkeit für die Benutzerschnittstelle die abstrakte API des gra-phischen Framework LCDUI (siehe Abschnitt 2.4.3.3) innerhalb J2ME vor. Der Vorteilvon LCDUI liegt darin, dass die GUI sich leicht auf andere Endgeräte portieren läßt. Da-bei ist das Erscheinungsbild der graphischen Komponenten, Bedienelemente und Menüsautomatisch an das Endgerät angepasst, und der Anwender findet sich durch die gewohn-te Gestaltung so leichter zurecht. Erreicht wird dies durch angepasste Implementierungender LCDUI API durch die Hersteller der Endgeräte. Die Kommunikation mit dem WebService muss in J2ME jedoch selbst implementiert bzw. an eine Bibliothek delegiert wer-den, während MDS-Studio dies kapselt.

Statt die API von MIDP für Benutzerschnittstelle und Netzwerk-Kommunikation zu ver-wenden, kann auch die proprietäre API des Herstellers RIM verwendet werden. Die zuvorerwähnten Vorteile entfallen dabei. Um Zugriff auf die API zu erlangen, muss die Anwen-dung mit kostenpflichtigen Schlüsseln von RIM signiert werden. Als Rahmenumgebungfür die Implementierung von mobileCRM kommt daher J2ME mit den APIs von MIDPund CLDC zum Einsatz.

3.4.1 Kommunikation mit dem Web Service

Ein wesentliches Merkmal der mobilen Anwendung ist, dass der Datenaustausch mit demSAP-CRM-System über einen Web Service stattfinden soll. In diesem Abschnitt geht esum die Auswahl entsprechender Protokolle und deren Implementierungen, die für den

49

Page 64: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

3.4. Mobile Client Kapitel 3. Analyse

Web Service eingesetzt werden sollen. Als Protokoll kommen die folgenden beiden Mög-lichkeiten 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 Abschnitt2.2 beschrieben, ebenso wie ein SOAP-Parser für J2ME mit kSOAP in 2.4.3.5. In dennä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 folgenminimale Testanwendungen für die SOAP-Bibliotheken und die Push-Funktion, bevor esabschließend zu einer Auswertung und Abwägung kommt.

3.4.1.1 JSR 172 - Web-Service-API für J2ME

Mit dem JSR 172 wurde im März 2004 innerhalb des JCP die endgültige Version einerWeb-Service-API für Endgeräte mit CLDC oder CDC festgelegt (für die Spezifikationsiehe [EY03]). Sun stellt eine Referenz-Implementierung1 für diese API im Sourcecodefrei 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 je-doch 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 J2SEexistieren. Die JAXP wurde auf einen SAX-Parser reduziert.

Primitive Datentypen innerhalb von SOAP werden analog zu kSOAP in entsprechen-de Datentypen in Java umgewandelt. Für komplexe Typen werden JavaBeans mit Get-und Set-Methoden erzeugt. Im Unterschied zu kSOAP bietet JSR 172 keine Möglichkeit,komplexe SOAP-Datentypen mit eigenen Java-Klassen zu assoziieren.1http://www.sun.com/software/communitysource/j2me/wsa/download.xml

50

Page 65: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 dieSchnittstelle des JSR 172 vollständig gekapselt. Eine Übersicht der einzelnen Komponen-ten und der Kommunikation zwischen ihnen kann der Abbildung 3.4 entnommen werden.Die Aufrufe erfolgen über einen sogenannten Stub, in dem die Operationen des anzuspre-chenden Web Service als lokale Methoden repräsentiert werden. Der Stub wird mit Hilfeeines Stub-Generators erzeugt, der die zugehörige WSDL-Beschreibung des Web Servicebenötigt. Dies vereinfacht und beschleunigt die Anwendungsentwicklung stark, und stelltdurch die automatisierte Verarbeitung der Web-Service-Beschreibung einen deutlich we-niger fehleranfälligen Ansatz dar. Jedoch ist im Gegensatz zu kSOAP bei der JSR 172 APIauch kein Zugriff auf die XML-Struktur der SOAP-Nachrichten vorgesehen. Der Stub istTeil 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 generier-ten Stubs beizubehalten, wenn man die Implementierung wechselt, z.B. die Anwendungauf einem Endgerät eines anderen Herstellers installiert. Ebenso bietet sich dadurch dieMöglichkeit, zwischen dem Client und dem Web Service ein Gateway zu integrieren, dasdas SOAP-Parsing übernimmt. Das Protokoll zwischen Gateway und der Implementie-rung des JSR 172 könnte dadurch ein optimiertes Binärprotokoll sein, das für die Client-Anwendung jedoch transparent wäre.

3.4.1.2 REST-Web-Services

Der REpresentational State Transfer (REST, siehe [Bay02]) ist eine Architektur, die imWWW schon lange eingesetzt wird. In einem Netzwerk aus Clients und Servern stellendie Server über das HTTP-Protokoll Ressourcen bereit, die durch einen URI eindeutig

51

Page 66: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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üpfungfolgt, erhält er von dem Server die Repräsentation der angefragten Ressource - der Zu-stand des Clients ändert sich damit.

3.4.1.3 Voranalysen

• Push-TestDie Push-Funktionalität ist ein Teil von Punkt 1 der Rahmenbedingungen (Ab-schnitt 3.1.1). Um die korrekte Konfiguration des BES und die Funktionsweise derPush-Registry (siehe Abschnitt 2.4.3.2) auf dem Endgerät zu testen, wurde eine mi-nimale Anwendung implementiert. Code-Beispiele aus dem Developer-Guide vonRIM, Kapitel „Creating client/server push applications“(siehe [RIM05]), konntendabei 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: http://:7777,

8 com.csc.aopatz.bb.test.PushTestMIDlet, *MIDlet-Vendor: CSC

10 MIDlet-Version: 1.0.15

MicroEdition-Configuration: CLDC-1.1

12 MicroEdition-Profile: MIDP-2.0

Quellcode 3.1: JAD der Push-Test-Anwendung

Für die Benutzung der PushRegistry und die Kommunikation über die aufgebauteVerbindung muss die Client-Anwendung (PushTestClient) entsprechende Berech-tigungen für die Klassen besitzen. Dies geschieht über den JAD, der in Abbildung3.1 dargestellt ist. Außerdem muss bei der Installation des MIDlets auf dem Endge-rät der Port reserviert werden, auf dem die PushRegistry eingehende Verbindungenfür die Anwendung entgegen nehmen soll. Dazu bedarf es ebenfalls eines Eintragsim JAD - in diesem Fall wurde Port 7777 gewählt. Für Push-Verbindungen schreibtdie 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

Page 67: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 3. Analyse 3.4. Mobile Client

Endgeräte http:// verwendet werden. Nachdem die Applikation von der Push-Registry gestartet wurde, werden die eingehenden Daten gelesen und auf demDisplay 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 E-Mail-Adresse und der Port des Endgeräts bzw. der Client-Anwendung spezifiziert wer-den. Nachdem der Client von der PushRegistry gestartet wurde, öffnet er die einge-hende Push-Verbindung und liest die einkommenden Daten. Diese werden in einergraphischen Komponente als Text angezeigt.

• Test von JSR 172 mit XI Web ServiceDie mobilen Endgeräte von RIM stellen zur Zeit keine Implementierung der Web-Service-API des JSR 172 zur Verfügung. Daher wurde die Referenz-Implementie-rung (RI) von Sun verwendet. Durch die Testanwendung soll geklärt werden, ob dasWSDL-Dokument des SAP-Web-Service mit dem Stub-Generator aus dem WTKkompatibel ist und ob das Parsing der SOAP-Nachrichten mit der RI funktioniert.Weiterhin muss abgeschätzt werden, inwiefern die RI modifiziert werden muss, umeine Nachricht über eine Push-Verbindung entgegenzunehmen.

Die Testanwendung (sapjsr172test) besteht aus den Packages der Referenz-Imple-mentierung, die mit dem Präfix csc versehen wurden, um Namenskonflikte zu ver-meiden, 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 entge-gen nimmt und dann über den BES an das entsprechende BB-Endgerät übermit-telt. Anhand der WSDL-Beschreibung können die Stubs problemlos generiert wer-den, Voraussetzung ist allerdings, dass primitive Datentypen verwendet werden.So muss beispielsweise der Zeitstempel einer Aktivität vom Typ xsd:date alsxsd:string übermittelt werden. Aus dem Stub wird nur der Code benötigt, derfür das Mapping zwischen XML-Elementen mit entsprechenden Datentypen auf dereinen 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 Bestandteilder RI ist und nicht der API des JSR 172. Das Parsing der SOAP-Nachricht schlägtjedoch fehl. Dieses Resultat ist auch mit dem Beispiel-Web-Service Version desApache Axis2 Frameworks und unmodifiziertem Client-Stub zu beobachten.

53

Page 68: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

3.4. Mobile Client Kapitel 3. Analyse

3.4.1.4 Evaluierung

Neben den folgenden Entscheidungen bezüglich der Kommunikation von mobileCRMdienen die Tests auch zur Verifizierung des Systemaufbaus. Dazu zählt hauptsächlich dieInstallation und Konfiguration des BES und die Aktivierung des BB-Endgeräts. Durch denPush-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 unddem Endgerät getestet.

• Web-Service-Protokoll: REST oder SOAPAuf SOAP basierende Web Services nutzen das REST-Prinzip nicht. Die Ressour-cen und Operationen werden im Rumpf der SOAP-Nachricht statt über den URIspezifiziert. Alle Nachrichten richten sich an einen URI des Service. Dies hat zurFolge, dass ein Proxy für SOAP-Nachrichten nur schwer implementiert und ge-wartet werden kann. Somit entfallen Zugriffsbeschränkungen und Caching durcheinen Proxy. Zudem können auf SOAP basierende Web Services frei Operatio-nen definieren, während Web Services nach dem REST-Prinzip nur die generischenHTTP-Methoden zur Verfügung stellen. Ein weiterer Unterschied ist, dass bei aufREST basierenden Web Services jede Ressource für ihre Repräsentation innerhalbvon HTTP ein spezifisches Protokoll nutzen kann. Bei einer REST-basierten Web-Service-Implementierung entfällt der Overhead von SOAP. Die HTTP-Payload ent-hält nur die zu übertragenden Daten in Form von XML, beispielsweise gemäß einerXSD. Die mobile Anwendung muss die Verarbeitung der XML-Daten jedoch voll-ständig selbst implementieren. Die RI des JSR 172 vereinfacht die Entwicklung andieser 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-basiertenImplementierung. Für beide Varianten ist es jedoch möglich, einen Stub-Generatorzu implementieren. In der neuen Version 2.0 der WSDL-Spezifikation wird auchdie Beschreibung von REST-basierten Web Services möglich. Prinzipiell hat sichSOAP in Kombination mit WSDL jedoch zur Integration von Softwaresystemenweit 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 172Die RI des JSR 172 erfüllt Punkt 5 der Rahmenbedingungen am Besten, da für das

54

Page 69: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 RIdes JSR 172 in Kombination mit dem SAP-XI Web Service nicht funktioniert unddie RI noch instabil ist.

Eine weitere SOAP-Implementierung für mobile Endgeräte ist der Wingfoot-SOAP-Client1. Der Hersteller bietet die Bibliothek jedoch nur in binärer Form an,wodurch Anpassungen für eine eingehende Push-Verbindung nicht möglich sindund man für Erweiterungen, Bugfixes und Support auf den Hersteller angewiesenist. Für die Implementierung von mobileCRM kommt Wingfoot deshalb nicht inBetracht.

Folglich wird mobileCRM mit der kSOAP-Bibliothek implementiert, mit der beiKompatibilitätsproblemen auch auf XML-Ebene gearbeitet werden kann, statt Map-pings zu verwenden. Für den Empfang einer Push-Nachricht mit kSOAP muss zu-nächst der entsprechende Codeabschnitt für die eingehende Verbindung aus der Me-thode call ausgegliedert werden. Daher wurde die Methode receive(Input-Stream istream, SoapEnvelope envelope) der öffentlichen Schnitt-stelle der Klasse HttpTransport hinzugefügt. Im Gegensatz zum Stub-Gene-rator 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-Daten-typen manuell programmiert werden müssen.

3.4.2 Synchronisation und Offline-Modus

Ein wichtiges Merkmal von mobileCRM ist die Realisierung als Smart Client: die Aktivi-tä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 Zwi-schenspeichern das RMS verwendet, das in Abschnitt 2.4.3.4 vorgestellt wurde und Be-standteil von J2ME ist. Eine andere Option zur Umsetzung der Zwischenspeicherung aufBB-Endgeräten gibt es nicht. Jedoch gibt es Produkte diverser Hersteller, die auf demRMS aufsetzend eine beschränkte relationale Datenbank realisieren, was jedoch im Rah-men 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 derSynchronisation zwischen SAP und mobileCRM Probleme bei der Datenkonsistenz auf-treten. Dies ist dann der Fall, wenn zwei oder mehr Benutzer eine bestimmte Aktivität be-

1http://www.wingfoot.com/download_wsoap.html

55

Page 70: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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-basierteKommunikation mit dem SAP-CRM-System transaktionssicher ist. Ein Lost Update kanndurch das SAP-CRM-System nicht verhindert werden. Ein Fallbeispiel für ein solchesProblem folgt und ist in Abbildung 3.5 visualisiert:

• Der Benutzer ändert eine Aktivität A in mobileCRM, die Änderung wird lokal ge-speichert, aber es ist kein Funknetz verfügbar.

• Zwischenzeitlich nimmt die Sekretärin im Unternehmen von einem Kunden einenAnruf entgegen, der eine Änderung in Aktivität A zur Folge hat, beispielsweiseeine Terminänderung. Die modifizierte Aktivität wird durch die direkt an das SAP-System angebundene SAP-GUI im CRM abgespeichert und eine Push-Nachrichtan den BES gesendet, die dort vorgehalten wird, bis der mobile Nutzer erreichbarist.

• Das mobile Endgerät hat wieder Netzempfang und erhält die Push-Nachricht. Dabeiwerden die lokalen Änderungen überschrieben, falls keine speziellen Vorkehrungenin der Anwendungslogik getroffen werden. Eine weitere Möglichkeit (nicht in Ab-bildung enthalten) wäre, dass aufgrund von Race Conditions der mobile Nutzerseine Änderung an das SAP-System überträgt, bevor die Push-Nachricht, die durchdie Änderung der Sekretärin ausgelöst wird, ihn erreicht. In diesem Fall wäre diegetätigte Änderung der Sekretärin im SAP-System überschrieben.

56

Page 71: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 3. Analyse 3.4. Mobile Client

Zur Verhinderung solcher Probleme gibt es verschiedene sogenannte Replikationsstrate-gien (siehe [Rah05]). Unter Replikation versteht man die Vervielfältigung von Daten. Imkonkreten Fall bezeichnet man die Daten im SAP-CRM-System als Primärdaten, und dieKopien auf den BB-Endgeräten als replizierte Daten. Bei den Strategien unterscheidetman zwischen Verfahren, die eine strenge Konsistenz garantieren (synchrone Änderun-gen), und solchen, die nur eine schwache Konsistenz erreichen (asynchrone Änderungen).Für eine strenge Konsistenz, die eine Transparenz der Replikation gewährleistet, ist eineSerialisierung der Änderungen an Daten notwendig. Dies wird in den gängigen Verfahrendurch 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 Datensatzstattfinden, ebenso wie nicht immer alle Replikate konsistent sind. Daher ist eine stren-ge Konsistenz nicht realisierbar. Für mobile Anwendungen eignet sich eine sogenannteMerge-Replikation. Dabei ist die Konsistenz der einzelnen Kopien nicht sichergestellt,und es kann beim Synchronisieren zu Konflikten kommen, die dann automatisiert oderggf. manuell aufgelöst werden müssen.

Um solche Konsistenzprobleme sicher zu erkennen, müssen in dem Fall die Datensät-ze versioniert werden, um unterschiedliche Datenstände identifizieren zu können. Einesichere Vermeidung von Lost Updates ist nur durch eine Transaktion möglich, so dassdie Versionsüberprüfung und das Schreiben des Datensatzes atomar durchgeführt werdenkönnen. Zur Unterscheidung der Datenstände kann bei den Datensätzen im SAP-CRM-System das Attribut DocumentNumber herangezogen werden, das bei jeder Transakti-on mit der Aktivität automatisch inkrementiert wird.

Für die Umsetzung von mobileCRM werden die folgenden zwei Möglichkeiten zur Syn-chronisation 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 be-trachtet, da die Realisierung aufwendiger ist und die Dauer einer einzelnen Transaktiondadurch länger wird. Im schlimmsten Fall müsste eine Transaktion dabei durch einenTimeout abgebrochen werden, falls das BB-Endgerät die Funkverbindung verliert.

Der Ablauf von Synchronisationslösung 1 ist in Abbildung 3.6 dargestellt, der BES wur-de hierbei zur besseren Übersicht nicht dargestellt. Eine lokal als modifiziert markierteAktivität wird dabei an den Web Service im SAP-XI gesendet. In einer dort implemen-tierten Transaktionslogik wird innerhalb einer Transaktion mit dem SAP-CRM-System

57

Page 72: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

3.4. Mobile Client Kapitel 3. Analyse

Abbildung 3.6: Synchronisationslösung 1 für Client-initiiertes Aktivitätsupdate

58

Page 73: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 zuder Aktivität, die abgespeichert werden soll. Falls die Version gleich geblieben ist, kanndie Aktivität ins CRM geschrieben werden, und die Transaktion abgeschlossen werden.Anderenfalls wird die Transaktion abgebrochen, und mobileCRM erhält vom Web Serviceeine Fehlermeldung. Seitens dem SAP-CRM-System wird nach einer Aktivitätsänderungeine Push-Nachricht im SAP-XI veranlasst (siehe Abbildung 3.7), die alle Benutzer vonmobileCRM erhalten, die eine Rolle in der modifizierten Aktivität einnehmen.

Wenn die Push-Nachricht eintrifft, muss die Aktivität auf dem Endgerät überschreibbarsein. Deshalb wird die Markierung vor dem Update bereits auf unmodifiziert gesetzt, sodass 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 sichererkannt werden. Nachdem ein Konflikt festgestellt wurde, muss geprüft werden, ob ersich lösen lässt. Betreffen die Änderungen in beiden Datensätzen nicht die gleichen At-tribute, können die zwei Datenversionen möglicherweise automatisiert zusammengeführtwerden. Bedingung ist jedoch, dass die geänderten Attribute nicht in einer Abhängig-keit zueinander stehen. Weiterhin muss für eine Zusammenführung auch der unmodifi-zierte Datensatz auf dem Endgerät vorhanden sein, um die Änderungen in lokalem undSAP-Datensatz erkennen zu können. Betreffen die Änderungen gleiche Attribute, ist einZusammenführen (oder auch Merging im Englischen) ohne manuellen Eingriff des Be-nutzers nicht möglich. Die Funktionalität des automatischen Mergens ist auch als Teil der

59

Page 74: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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ückge-geben werden muss und der Vorgang dadurch schneller durchgeführt werden kann. DieRealisierung eines Merge-Vorgangs ist nicht Bestandteil des Prototyps mobileCRM.

Der besondere Fall eines Lost-Updates auf Client-Seite kann auftreten, wenn der Benutzereine 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 sindLost-Updates in diesem Szenario prinzipiell möglich. Der Fokus dieser Arbeit liegt nichtbei der Transaktionssicherheit auf SAP-Seite, weshalb für den Prototyp mobileCRM die-ses optimistische Verfahren ausreichend ist. Solange das Endgerät keine Push-Nachrichtvom SAP-System erhält, wird davon ausgegangen, dass die lokale Version der Aktivitätnoch die aktuelle ist. Die modifizierte Aktivität wird ohne weitere Vorkehrungen direkt anden 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 ander Aktivität beteiligten BB-Benutzer aus (siehe Abbildung 3.7). Währenddessen erhältder Benutzer, der das Update durchgeführt hat, eine Rückmeldung vom Web Service undmarkiert die Aktivität lokal als unmodifiziert. Ein Lost-Update kann auftreten, falls einanderer 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ögertenAuslieferung einer Push-Nachricht kann dies auch durch eine verloren gegangene Push-Nachricht hervorgerufen werden. Das Zeitfenster, in dem ein Lost-Update auftreten kann,

60

Page 75: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 Ak-tivität assoziierten BB-Benutzer die entsprechende Push-Nachricht erhalten haben. Diesist in Abbildung 3.9 veranschaulicht. Die SAP-XI und der BES als vermittelnde Systemezwischen Client und SAP-CRM wurden der Einfachheit halber nicht dargestellt.

Ein weiteres Problem ergibt sich speziell für den produktiven Einsatz. Die SAP-GUI öff-net 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 mobilenAnwendung auf die Funktionsweise der SAP-GUI abgestimmt sein. Hierfür ist jedochDetailwissen zur SAP-GUI notwendig. Diese Problemstellung wird für den Entwurf desPrototyps nicht näher betrachtet.

3.4.3 Usability der mobilen Anwendung

Für den erfolgreichen Einsatz einer Anwendung ist die Akzeptanz der End-Anwenderein wichtiger Aspekt. Die Schnittstelle von Mensch zu Maschine sollte möglichst intui-tiv bedienbar sein, so dass der Benutzer die Anwendung als eine Hilfe empfindet undkeinesfalls dadurch ineffizienter arbeitet. Insbesondere bei mobilen Applikationen stelltdies eine besondere Herausforderung dar, weil die Endgeräte nur eingeschränkte Ein- undAusgabemöglichkeiten haben. Im Hinblick auf die zu realisierende Anwendung mobile-CRM ergeben sich dabei folgende Schwerpunkte:

• InternationalisierungDurch die gegebenen Anforderungen, dass die mobile Anwendung ein SAP-CRM-System durch die BlackBerry-Plattform nutzt, ergeben sich als Zielgruppe der An-wendung Mitarbeiter aus mittelständischen, großen oder global agierenden Unter-nehmen, da nur dort die entsprechende Infrastruktur vorhanden ist oder sich die

61

Page 76: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

3.4. Mobile Client Kapitel 3. Analyse

Investition in selbige lohnen würde. Daraus ergibt sich, dass mobileCRM oder dar-auf basierende Anwendungen international einsetzbar sein müssen. Internationali-sierung (I18N) zur Bedienung der Anwendung muss eine Einstellung der Spracheumfassen. Speziell im Kontext von Geschäftsanwendungen müssen dabei auch lan-desspezifische Währungen und Maßeinheiten beachtet werden.

• BedienbarkeitDie Bedienbarkeit - auch Usability genannt - ist entscheidend, wenn es um die Ak-zeptanz und effiziente Arbeitsweise der Benutzer mit der Anwendung geht. Es istvon vornherein zu vermeiden, dass End-Anwender aus Effizienzgründen auf Stiftund Papier oder andere Anwendungen zurückgreifen. Dies sollte ebenfalls nichtaufgrund einer zu komplexen Bedienung der Anwendung passieren. Die Verantwor-tung liegt dabei nicht ausschließlich beim Entwickler, sondern Usability ist schonin der Spezifikation der Anforderungen und im Design zu berücksichtigen. Bei An-wendungen mit großem Funktionsumfang sind ein Benutzerhandbuch und Benut-zerschulungen ebenso notwendig. Der Grundstein dafür wird bei mobileCRM be-reits bei der Datenmodellierung in Abschnitt 3.2.2 gelegt, um die Funktionen unddie Komplexität der Anwendung an das mobile Endgerät anzupassen. Die durchdie mobile Anwendung abzubildenden Funktionen sollen außerdem übersichtlichangeordnet sein. Hierzu kann das Untergliedern von Menüs in Kategorien mit Un-termenüs hilfreich sein. Aufgrund des kleineren Displays kann es sinnvoll sein,Dialogfelder, wie beispielsweise das der SAP-GUI (siehe Abbildung 2.7), oder Vor-gänge auf mehrere Dialoge zu verteilen. Im Gegensatz zu typischen Desktop-GUI-Anwendungen mit Menüleiste und personalisierbarer Werkzeugleiste ist die Be-nutzerschnittstelle von mobilen Endgeräten bereits kontext-sensitiv ausgelegt. Zueiner angezeigten graphischen Komponente werden spezifische Aktionen definiert,die damit durchgeführt werden können. Um die Komplexität der Anwendung ausBenutzersicht zu reduzieren, ist eine weitere Möglichkeit, dem Benutzer Arbeit ab-zunehmen. Dies wäre innerhalb von mobileCRM beispielsweise denkbar mittelsAutovervollständigung und sinnvoller Vorbelegung in Eingabefeldern, oder indemdie Liste der Aktivitäten nach bestimmten Kriterien sortiert und durchsucht werdenkann.

• PerformanceLange Ladezeiten, in denen der Benutzer auf die Anwendung warten muss, sindunbedingt zu vermeiden und beeinflussen die Akzeptanz der Applikation negativ.Infolge der Hardware-Einschränkungen von mobilen Endgeräten ist der Aspekt der

62

Page 77: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 3. Analyse 3.4. Mobile Client

Performance bei Design und Implementierung daher besonders wichtig. Durch dieNutzung eines Web Service kommt erschwerend die Latenz der GPRS-Verbindungund das Parsing von XML hinzu. Um die Leistung des Endgeräts möglichst effizientzu nutzen, werden die in Abschnitt 2.4.3.6 zusammengestellten Optimierungsmög-lichkeiten beachtet.

Ein Performance-Vorteil ergibt sich bereits aus den Rahmenbedingungen Punkt3, nach denen die Anwendung als Smart Client realisiert werden soll. Dadurchist nicht für jede Operation der Anwendung eine Kommunikation mit dem SAP-System notwendig und die Latenz, die der Benutzer erfährt, deutlich geringer.

3.4.4 Logging und Unit-Tests

Für die Rekonstruktion von Fehlern und Debugging kann Logging ein gutes Hilfsmittelsein. In der Java-Welt hat sich unter anderem die Open-Source-Bibliothek log4j etabliert,bei der verschiedene Ausgabeströme, -formatierungen und unterschiedliche Log-Levelunterstützt werden. Mit Microlog1 gibt es eine log4j-ähnliche Implementierung für denEinsatz im J2ME-Umfeld, da log4j selbst nur mit J2SE lauffähig ist. Zusätzlich bietetMicrolog 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 RMSgespeichert wird. Dies ist für mobile Endgeräte sinnvoll, die nicht über eine Konsole imSinne einer Standard-Ausgabe verfügen.

Das weit verbreitete jUnit Test-Framework ist innerhalb von J2ME nicht verwendbar, sodass auf J2MEUnit 2 zurückgegriffen wird. Die API für einen Testcase ist dabei äquiva-lent zu jUnit, jedoch werden Test-Suites aufgrund der fehlenden Reflection-API in J2MEanders aufgerufen, und es gibt einen weiteren TestRunner, der als MIDlet realisiert ist.

1http://microlog.sourceforge.net/2http://j2meunit.sourceforge.net/

63

Page 78: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

3.4. Mobile Client Kapitel 3. Analyse

64

Page 79: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 4

Design

In diesem Kapitel wird das Design für die zu realisierende Anwendung mobileCRMentworfen. Es basiert auf den Anforderungen aus Abschnitt 3.1 und den Design-Entscheidungen, die während der Analyse getroffen wurden. Zunächst wird ein verfei-nerter Architekturüberblick des gesamten Systems gegeben. Der Abschnitt mobileCRM

geht auf die einzelnen Komponenten der mobilen Anwendung ein und erläutert danachderen 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-Entscheidungenergibt 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 beiVodafone bereitgestellt. Ebenso kann für SAP-XI und SAP-CRM auf die am StandortWiesbaden vorhandene Infrastruktur in einer Testumgebung zurückgegriffen werden. Aufeiner 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 konfigu-riert. Die mit 1 und 2 in der Abbildung gekennzeichneten Systembestandteile sind dabeiim Rahmen dieser Arbeit zu entwickeln bzw. zu konfigurieren. Der Schwerpunkt diesesKapitels ist das Design von mobileCRM. Anschließend wird im SAP-XI der zugehörigeWeb Service entworfen.

65

Page 80: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

4.2. mobileCRM Kapitel 4. Design

Abbildung 4.1: Verfeinerter Aufbau der Systemarchitektur

4.2 mobileCRM

Die Anforderungen an die mobile Anwendung mobileCRM wurden bereits in Abschnitt3.1 festgelegt. Weitere Vorgaben für den Client wurden in Abschnitt 3.4 der Analyseherausgearbeitet.

Daraus ergeben sich Teil-Komponenten der Anwendung, die als Java-Packages realisiertwerden 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 derAnwendung gesteuert, weitere Komponenten der Applikation initialisiert und dieeigentlichen Aufgaben der Anwendung an diese delegiert.

• com.csc.bb.mobileCRM.gui

Die graphischen Komponenten der Benutzerschnittstelle, die die LCDUI-API vonJ2ME benutzen, sind in diesem Package enthalten.

• com.csc.bb.mobileCRM.model

Die von der Benutzerschnittstelle dargestellten Daten werden in getrennten Kom-ponenten bereitgehalten, ebenso wie deren Synchronisation mit dem RMS auf demEndgerät und dem Web Service des SAP-Systems.

66

Page 81: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 4. Design 4.2. mobileCRM

• com.csc.bb.mobileCRM.util

In diesem Package befinden sich Klassen für die Internationalisierung und das Log-ging.

Die Tabelle 4.1 zeigt die Komponenten von mobileCRM mit ihren jeweiligen Zu-ständigenkeiten in einer Übersicht. Im nächsten Abschnitt werden allgemeine Design-Prinzipien für mobileCRM besprochen. Die darauf folgenden Unterkapitel sind nach derrechten Tabellenspalte gegliedert und betitelt.

Java-Package Zuständigkeitcom.csc.bb.mobileCRM.gui Benutzerschnittstellecom.csc.bb.mobileCRM.model Model und Backend-Zugriffecom.csc.bb.mobileCRM.util Logging und Internationalisierung

Tabelle 4.1: Übersicht der Komponenten von mobileCRM

4.2.1 Allgemeine Design-Prinzipien

In diesem Abschnitt werden zunächst allgemeine Design-Prinzipien besprochen, die inmehr als einer Komponente von mobileCRM oder komponentenübergreifend Anwendungfinden.

In [Yua06] werden zwei grundsätzlich verschiedene Architektur-Beispiele für eine mobi-le Anwendung gegeben. Die Beispielanwendung Smart Ticket von Sun benutzt zahlreicheInterfaces zur Kapselung. Hinter einer Fassade für das Model findet beispielsweise eineUnterteilung in local und remote Model statt, während letzteres noch ein Chain-Handlingvon einem RMS-Cache und den eigentlich HTTP-Anfragen zu einem Server kapselt. DasGegenbeispiel zu diesem schwergewichtigen Design bildet die iFeedback-Anwendungdes Autors ([Yua06]), die ein sogenanntes screen-flow Design verwendet. Der Autor hatmit dieser Anwendung im Jahr 2002 den University Wireless Developer Contest gewon-nen, der von NexTel, Sun und Motorola durchgeführt wurde. In einer MVCComponentwerden dabei graphische Elemente eines anzuzeigenden Screens zusammengefasst, unddie dazu spezifisch erforderliche Programm-Logik für Benutzerinteraktion und Kommu-nikation mit Backend-Systemen ebenso in dieser Komponente implementiert. Für die Na-givation von einem Screen zum nächsten gibt es keinen zentralen Controller, sondern jedeMVC-Komponente ist selbst dafür zuständig, bei welchen Benutzerinteraktionen eine an-dere Komponente angezeigt werden muss. Von dieser Klasse wird dann eine neue Instanz

67

Page 82: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

4.2. mobileCRM Kapitel 4. Design

angelegt und diese auf dem Display zur Anzeige gebracht - die Kontrolle liegt somit beider neuen Komponente. Da ein graphisches Element nicht mehrfach angezeigt werdenkann (es ist nur ein Display vorhanden), sind die Attribute aller Komponenten statischund werden somit nicht mit jeder Instanz neu erzeugt.

Die leichtgewichtige Architektur bietet klare Vorteile in Bezug auf Performance (siehedazu Abschnitt 2.4.3.6). Durch den reduzierten Umfang an Klassen wird weniger flüch-tiger und nicht-flüchtiger Speicher für die Anwendung benötigt, ebenso wird wenigerDelegation notwendig. Auf der anderen Seite geht dies zu Lasten der Erweiterbarkeit undTestbarkeit der Anwendung. Insbesondere kann der Code für Backend-Zugriffe nicht sau-ber wiederverwendet werden.

Für mobileCRM kommt eine Variante des MVC Design Pattern zum Einsatz, auchDocument-View-Architektur genannt, die einen bestmöglichen Kompromiss aus den un-terschiedlichen Design-Ansätzen darstellen soll. Die graphischen Elemente sind dabeiView und Controller in einem, und die Navigation von einer zur nächsten Komponen-te erfolgt ähnlich wie bei dem iFeedback-Beispiel. Dafür sind statische Klassenattributenotwendig, damit der gegenseitige direkte Zugriff auf Instanzen möglich ist. In mobile-CRM wird dies durch das Singleton Design Pattern (siehe [GHJV95] S. 127) realisiertund auf alle Klassen angewendet, für die auf Anwendungsebene nur eine Instanz benö-tigt wird. Hierdurch wird die Neuinstanziierung von Objekten minimiert und die GarbageCollection weniger in Anspruch genommen. Es sei jedoch darauf hingewiesen, dass diesbei umfangreicheren Anwendungen und weiteren Workflows innerhalb der Anwendungzu einem zu hohen Speicherverbrauch führen kann, da einmal erzeugte Komponentenfür weitere Benutzungen im Speicher vorgehalten werden. Die Kommunikation mit RMSund SAP-System wird in einem Model gekapselt, auf das alle graphischen Komponentenzugreifen. Die folgenden Abschnitte gehen auf das konkrete Design der Benutzerschnitt-stelle (View) und des Modells (Document) ein.

4.2.2 Benutzerschnittstelle

Die Benutzerschnittstelle besteht hauptsächlich aus graphischen Komponenten, die dieabstrakte Klasse BasicScreen erweitern. Abbildung 4.2 gibt eine Übersicht aller Klas-sen 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 dieMethode initData() individuell überschreibt. Benötigt ein Screen vor der Initiali-

68

Page 83: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 4. Design 4.2. mobileCRM

Abbildung 4.2: Klassen der Benutzerschnittstelle (View)

69

Page 84: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

4.2. mobileCRM Kapitel 4. Design

sierung noch Daten, so kann dies über zusätzliche Set-Methoden geschehen, die vorinitData() aufgerufen werden müssen. Dies ist beispielsweise bei der Klasse Show-ActivityForm der Fall, der man zunächst eine Aktivitäts-ID übergeben muss, bevordie entsprechenden Daten aus dem Model transferiert werden können.

Da ein Screen auch den Controller-Part des MVC-Designs übernimmt, wird das InterfaceCommandListener implementiert, und die Methode commandAction(Commandcmd, Displayable disp) muss in jeder Unterklasse entsprechend überschriebenwerden. Dort können Benutzerinteraktionen verarbeitet und dementsprechend Vorgän-ge im Screen ausgelöst werden oder andere Screens aufgerufen werden, die wiederumzuvor initialisiert werden müssen. Damit die GUI während solcher Vorgänge nicht blo-ckiert, werden Aufrufe im Model durch den ModelController gekapselt und in ei-nem anderen Thread ausgeführt. Vom Model angefragte Daten werden asynchron vomModelController an die entsprechende GUI-Komponente übergeben. Dafür muss sie dasInterface AsyncDataHandler implementieren, den generischen Parameter der Me-thode updateData(Object data) zu dem erwarteten Datentyp anpassen (Casting)und dann adäquat verarbeiten. Während eines Vorgangs im Model wird auf dem Dis-play ein Wartebildschirm angezeigt, der in der Klasse StatusBar implementiert ist.Zuvor muss mittels setNextScreen(BasicScreen nextScreen) jedoch ange-geben werden, welcher Screen nach Abschluß des Vorgangs angezeigt werden soll. DieStatusanzeige kann modellgetrieben aktualisiert werden, so dass der Benutzer eine Rück-meldung erhält, was im Hintergrund geschieht. Dafür wird im ModelController undin StatusBar die Schnittstelle ProgressObserver implementiert. So kann vomModel 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 nurMethoden zu Operationen mit den Datensätzen definiert, und die Klasse Model, dieModelFacade implementiert und zusätzlich noch die Kommunikation mit dem Con-troller umsetzt.

Für einen kompletten Übergang von einem Screen zum nächsten ist also auch das Mo-del involviert, weshalb ein Sequenzdiagramm eines solchen Vorgangs erst nach dem Ab-schnitt zum Model folgt. Der Einstiegspunkt der Benutzerschnittstelle ist das Hauptmenü,in dem ein Vorgang ausgewählt werden kann, angelehnt an die Anwendungsfälle der Ap-plikation. Eine Übersicht der einzelnen Screens von mobileCRM zeigt Abbildung 4.3.

70

Page 85: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 Benutzereinstel-lungen angepasst werden. Die zugehörige Implementierung befindet sich in der KlasseMainMenu. Die Liste aller lokal auf dem Endgerät vorhandenen Aktivitäten zeigt derScreen ActivityList an, der intern List aus dem LCDUI-Framework für die Dar-stellung 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 im-plementiert, weil für die Testumgebung keine Konfiguration notwendig ist. Im Fehlerfallkann eine Instanz von BasicAlert angezeigt werden. Vor der Anzeige können ein Feh-lertext und ein eigener CommandListener übergeben werden. Bereits vorimplemen-tiert sind die Fälle, in denen nach dem Fehler-Dialog der nächste Screen angezeigt sowiedass die Anwendung für kritische Fehler beendet wird. Ist Letzteres nicht der Fall, so mussvor der Anzeige des Dialogs setNextScreen(BasicScreen nextScreen) auf-gerufen werden.

Der ModelController erweitert java.lang.Thread, um die Model-Aufrufe ineinem von der GUI getrennten Thread auszuführen. Dabei muss ein Aufruf im GUI-

71

Page 86: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

4.2. mobileCRM Kapitel 4. Design

Thread auf einen Aufruf im Model-Thread abgebildet werden. Der objektorientierte An-satz ist zunächst, für jeden ModelController-Aufruf im GUI-Thread eine anonyme Klasseanzulegen, die ModelAction (siehe Quellcode 4.1) erweitert. Dieses sogenannte Com-mand Design Pattern findet sich in [GHJV95] S. 233. Diese Vorgehensweise impliziertfür jede Methode des Models eine weitere Klasse und verstößt damit gegen Prinzipi-en 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 optio-naler Parameter werden in der Handler-Methode gesetzt und in Attributen des ModelCon-trollers gespeichert, und der Model-Thread aufgeweckt, der anhand der ID die zugehörigeHandler-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 Modelabstrakt zu halten, wurde das Threading und die damit verbundene asynchrone Kommu-nikation im ModelController im GUI-Package implementiert. Obwohl Model und Mo-delController die gleichen Methoden für Operationen mit den Model-Komponenten, dieim Interface ModelFacade zusammengefasst sind, implementieren müssen, kann derModelController dieses Interface nicht implementieren, da sich die Methodensignaturenaufgrund der asynchronen Aufrufe unterscheiden.

public interface ModelAction {

2 void setExecuteParam(Object param);

void execute();

4 }

Quellcode 4.1: Interface zur Umsetzung des Command Pattern

4.2.3 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 dasModel außerdem noch im RMS des mobilen Endgeräts für den Offline-Modus abgespei-chert. Die Model-Schicht besteht aus Klassen für die Datenhaltung und den Datenaus-tausch mit Backend-Systemen. Diese einzelnen Komponenten werden durch eine einzi-ge Schnittstelle nach dem Facade Design Pattern (siehe [GHJV95] S. 185) nach außenhin gekapselt, so dass Änderungen an Sub-Komponenten keinen Einfluß auf die View-

72

Page 87: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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-Systemfindet über die Schnittstelle der Klasse SAPmanager statt, die alle weiteren Details imPackage com.csc.bb.mobileCRM.model.backend.sap kapselt.

Klassen, die abstrakte Entitäten aus der Anwendungsdomäne enthalten, werden auchBusinessObjects (BO) genannt. Dabei gibt es im Fall von mobileCRM im Prinzip nurdie 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 dieSchnittstelle der BOs in mobileCRM gibt Abbildung 4.4.

In der Klasse ActivityBO sind dabei alle mit dem SAP ausgetauschten Daten ei-ner Aktivität in Form von Attributen enthalten. Einige Daten, die in mehreren GUI-Komponenten benötigt werden, wurden in die Klasse ActivityEntryBO ausgeglie-dert. Damit die BOs alle serialisierbar sind und die Daten auf Konsistenz überprüft werdenkönnen, ist jedes BO Nachfahre der abstrakten Klasse BasicBO, die eine abstrakte Me-thode validate() vorsieht, die jedes BO entsprechend implementieren muss. Dadurchkann jedes BO auf seine Datenkonsistenz hin überprüft werden. Die Serialisierung erfolgtdurch Implementierung der dafür entworfenen Schnittstelle Serializable. Diese wirdvom RMSmanager angesprochen, und ein BO ist dafür verantwortlich, all seine Attributein den übergebenen Ein- bzw. Ausgabe-Strom zu serialisieren bzw. wieder zu deseriali-

73

Page 88: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 dieRecordStores. Die zugehörige UML-Darstellung findet sich in Abbildung 4.5.

Für die BOs ActivityBO und ActivityEntryBO werden zur Serialisierung mit-tels RMSmanager zwei unterschiedliche RecordStores verwendet. Das Schreiben einerAktivität impliziert gleichzeitig einen neuen ActivityEntryBO-Datensatz, so dassbeide Identifikatoren gleich sind. Um die Liste der Aktivitäten (Screen Nr 2 in Abbil-dung 4.3) anzuzeigen, müssen so nicht alle ActivityBOs gelesen werden, sondern es istausreichend, nur die ActivityEntryBOs auszulesen, welche deutlich kleiner sind. Wei-terhin können in ActivityEntryBO-Datensätzen Verwaltungsinformationen gespei-chert werden wie beispielsweise, ob eine gespeicherte Aktivität auf dem Endgerät be-reits modifiziert wurde oder noch im Original-Zustand ist. Bei der Synchronisation mitdem SAP-System müssen so ebenfalls nicht alle ActivityBOs ausgelesen werden. Die öf-fentliche Schnittstelle sieht Methoden zum Laden, Speichern und Löschen einer Aktivi-tä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 Daten-konsistenz zu gewährleisten, sind alle öffentlichen Methoden synchronized, so dasskonkurrierende Zugriffe auf das RMS immer seriell ablaufen. Der RMSmanager ist nachdem Singleton Design Pattern entworfen. Dies spart Referenzen und Delegation zwischenModel und dem PushReceiver, schränkt die Funktionalität der Klasse jedoch nicht ein, da

74

Page 89: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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-Verbindungenwarten. Um Benutzerinteraktionen nicht zu stören, wird diese Funktionalität in einem ei-genen Thread umgesetzt. Die Klasse PushReceiver erweitert java.lang.Threadund nimmt auf dem angegebenen Port blockierend in einer Endlos-Schleife Verbindungenentgegen. 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 SAPmanagerstatt (siehe Abbildung 4.5). Um eine Instanz zu erzeugen, werden zunächst die URL desWeb 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 erwar-tet und ein ActivityBO zurückgibt. Mit der Methode getActivities() erhält maneinen 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 entsprechendeBO an die Methode updateActivity(ActivityBO activity) übergeben.

4.2.4 Abbildung der Anwendungsfälle

Anhand von Sequenzdiagrammen wird das Zusammenspiel der Komponenten für die inder Analyse festgelegten Anwendungsfälle verdeutlicht (vgl. 3.1.2).

4.2.4.1 Server-initiiert

• AktivitätsänderungDieser Use-Case bezieht sich auf Änderungen einer Aktivität im SAP-CRM-System, die durch einen Client wie mobileCRM (siehe Aktivität modifizieren unterClient-initiierte Anwendungsfälle) oder der SAP-GUI durchgeführt werden. DieserVorgang 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 PushReceivereinen eigenen Thread startet und auf eingehende Push-Verbindungen wartet, die

75

Page 90: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 Ver-bindung wird an den SAPmanager übergeben, wo die ankommenden SOAP-Daten gelesen und das Parsing durchgeführt werden. Die resultierende Instanz einesActivityBOwird vom PushReceiver im RMS über den RMSmanager abgespei-chert. Abschließend wird der erfolgreiche Eingang einer Push-Nachricht über dasAsyncEventHandler-Interface an den ModelController als Event über-mittelt, und dem Benutzer wird ein entsprechender Informationsdialog angezeigt.

4.2.4.2 Client-initiiert

• Aktivitäten auflisten

Ausgehend vom Hauptmenü von mobileCRM wird die Methode initData() derActivityList-Instanz aufgerufen (siehe Abbildung 4.7). Während der Initiali-sierung soll der Warte-Screen StatusBar mit der Methode show() angezeigtwerden, 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 graphi-schen Komponenten (MainMenu und ActivityList) beenden sich, und derKontrollfluss des GUI-Threads liegt wieder beim LCDUI-Framework. Damit imModelController hinterlegt ist, welche GUI-Komponente die Daten angefordert hat,

76

Page 91: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 4. Design 4.2. mobileCRM

Abbildung 4.7: Sequenzdiagramm zum Anwendungsfall Aktivitäten auflisten

77

Page 92: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

4.2. mobileCRM Kapitel 4. Design

Abbildung 4.8: Sequenzdiagramm zum Anwendungsfall Aktivität anlegen

muss diese zuvor setCaller(this) am ModelController aufrufen. Der ange-stoßene Worker-Thread arbeitet die Anfrage durch den Aufruf von handleGet-ActivityEntries() ab. Dabei wird die Aufgabe an das Model und von dortaus zum RMSmanager delegiert, der alle Aktivitäten als ActivityEntryBO-Objekte ausliest und in einem java.util.Vector zurückgibt. Auch in diesemFall wird die Statusmeldung des Warte-Screens (StatusBar) wieder vom Modelaktualisiert. Für den Transport der ausgelesenen Daten vom ModelController

(Worker-Thread) zur GUI-Komponente, die das Interface AsyncDataHandlerimplementiert, wird die Methode updateData(Object data) genutzt. Ab-schließ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 gra-phischen Komponente ShowActivityForm wurde in Abbildung 4.8 zur besse-ren Übersicht auf die wesentlichen Vorgänge beschränkt. Das Sequenzdiagrammbeginnt an der Stelle, nachdem der Benutzer die entsprechenden Daten eingegebenhat 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

Page 93: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 MethodeupdateActivity erfolgreich aufzurufen, was jedoch nur bei einer Funkverbin-dung des Endgeräts gelingt. Andernfalls wird die Aktivität beim nächsten Synchro-nisationsvorgang zum SAP übertragen. An dieser Stelle kommt das modified-Attribut der Aktivität zum Tragen, woran erkannt wird, dass die Aktivität noch nichtsynchronisiert wurde. Abschließend wird der nächste Screen angezeigt, was in die-sem Fall die ActivityList ist.

• Aktivität modifizierenDieser 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 begonnenwird. Wie das Laden der Aktivität und das Initialisieren der graphischen Kompo-nente stattfindet, lässt sich im Use-Case Aktivität anzeigen (Abbildung 4.10) nach-vollziehen. 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 Me-thode commandAction in der Instanz von ActivityList, der Benutzer hatalso den Menü-Eintrag zum Löschen ausgewählt. Nach dem Vorgang im Mo-del soll wieder die Aktivitätsliste angezeigt werden, weshalb zunächst set-NextScreen(this) aufgerufen wird, bevor der StatusBar auf dem Dis-play angezeigt wird. Im Hintergrund wird nun die asynchrone Methode delete-Activity vom ModelController mit der RecordID der zu löschenden Ak-tivität als Parameter aufgerufen. Nachdem dort der Worker-Thread aufgewecktwurde, kehrt der Kontrollfluss des GUI-Threads wieder zurück in die graphi-sche Komponente ActivityList, die ihre graphische Repräsentation anpasst(nicht in Abbildung dargestellt). Die Methode commandAction() wird verlas-sen, und Benutzereingaben können so wieder durch das LCDUI-Framework be-arbeitet werden, beispielsweise zum Abbrechen des Vorgangs. Während der Be-arbeitung im Model kann eine Statusmeldung über die ProgressObserver

Schnittstelle im ModelController mit der Methode updateProgress(-

int percentage, String status) bis zur GUI propagiert werden. DasLöschen der Aktivität wird vom Model durch Aufruf der Methode delete-

79

Page 94: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

4.2. mobileCRM Kapitel 4. Design

Abbildung 4.9: Sequenzdiagramm zum Anwendungsfall Aktivität löschen

80

Page 95: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 4. Design 4.2. mobileCRM

Abbildung 4.10: Sequenzdiagramm zum Anwendungsfall Aktivität anzeigen

Activity(int recordId) der RMSmanager-Instanz veranlasst. Wenn derVorgang im Worker-Thread beendet ist, ruft der ModelController die MethodeshowNextScreen() des StatusBar auf, was in diesem Fall zur Folge hat, dassabschließ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, wirdinitData() der graphischen Komponente zum Anzeigen einer Aktivität auf-gerufen. Damit der asynchrone Datentransfer vom Model zur GUI-Komponenteüber das AsyncDataHandler-Interface erfolgen kann, muss sich die Kompo-nente zuerst beim ModelController mit setCaller(this) registrieren.Danach wird der Aufruf getActivity(activityId) über den ModelCon-

81

Page 96: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 Vorgangszum Warte-Screen propagieren. Das eigentliche Auslesen der Aktivität wird an denRMSmanager delegiert, der anhand der activityId den Datensatz aus demRMS auslesen kann, und die Daten als ActivityBO-Instanz zurück gibt. ImWorker-Thread des ModelControllers wird die Aktivität an die aufrufende GUI-Komponente mittels updateData übergeben. Abgeschlossen wird der Anwen-dungsfall durch anzeigen der initialisierten ShowActivityForm-Instanz.

• Aktivitätenliste anfordern

Der in Abbildung 4.11 dargestellte Anwendungsfall beginnt durch Auswahl imHauptmenü, 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 ha-ben sollen, beispielsweise open. Der Aufruf wird an den SAPmanager delegiert,der eine SOAP-Anfrage abschickt, das Parsing der Antwort durchführt und als Re-sultat einen Vector mit ActivityBO-Instanzen zurückliefert. Diese Aktivitätenwerden im Model einzeln über den RMSmanager lokal abgespeichert. Nachdemdieser Vorgang beendet ist, wird wieder das Hauptmenü angezeigt.

82

Page 97: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 demBenutzer der Warte-Screen angezeigt, und der Vorgang an das Model bzw. denWorker-Thread delegiert. In der Methode synchronizeActivities() wer-den zunächst über den RMSmanager alle modifizierten Aktivitäten ausgelesen.Für jede dieser Aktivitäten wird die Methode updateActivity aufgerufen, inder die Kommunikation mit dem Web Service auf SAP-Seite stattfindet. Nach er-folgreichem Update einer Aktivität wird im RMS der Status auf unmodifiedgesetzt. Der Vorgang wird durch erneute Darstellung des Hauptmenüs abgeschlos-sen.

4.3 Integrationsszenarien in SAP-XI

Hier werden die Integrationsszenarien und die dazugehörigen Komponenten aus demSAP-XI aufgeführt und erläutert. Die Arbeiten zur Integration im SAP-XI wurden durchden Betreuer (Herrn Thomas Schneider) von Seiten der Firma CSC durchgeführt und

83

Page 98: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 zwi-schen BB-Endgerät und XI sowie die Auswahl der benötigten BAPIs im SAP-CRM sindin enger Abstimmung mit der Analyse und dem Design der mobilen Anwendung entstan-den.

Anwendungsfälle werden im SAP-XI durch Integrationsszenarien abgebildet. Einem Inte-grationsszenario sind verschiedene Anwendungskomponenten zugeordnet. Diese sind imSLD zu pflegen, die Komponente von RIM (BES) muss dort aufgenommen werden. Deneinzelnen Anwendungskomponenten werden im Designprozess ein oder mehrere Actionszugeordnet. Die Anwendungsszenarien für die SAP-BB-Integration definieren jeweils nureine Action pro Anwendungskomponente. In den Actions werden die Message-Interfacesfestgelegt, aus denen XI ein WSDL-Dokument generiert. Zwischen den Actions sind dieMappings definiert, die für die Transformation der eigentlichen Nachrichten notwendigsind (siehe Abbildung 4.13). Für ein Mapping gibt es in XI zwei Abstraktionsebenen. Zumeinen das Interface Mapping, welches festlegt zwischen welchen Interfaces ein Mappingstattfinden soll. Und dann das eigentliche Mapping der Nachrichten (Message-Mapping).Für ein synchrones Interface Mapping wie im Fall der SAP-BB-Integration werden je-weils zwei Message-Mappings benötigt - eins für die Anfrage und eins für die Antwort.

Für die in Abschnitt 3.1.2 beschriebenen Anwendungsfälle sind im SAP-XI die in Tabelle4.2 dargestellten Integrationsszenarien definiert. Dabei werden die Anwendungsfälle Ak-

tivität anlegen, Aktivität modifizieren und Daten synchronisieren nur auf dem Endgerätunterschieden, 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 lo-kal im RMS des Endgeräts statt und haben keine Auswirkungen auf das SAP-System.

84

Page 99: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 Integrationsszenarienbeschrieben. Die aus den Szenarien erzeugten WSDL-Dokumente wurden für die Imple-mentierung verwendet und befinden sich im Projektverzeichnis von mobileCRM auf derCD-ROM zu dieser Arbeit.

Integrationsszenario BeschreibungActionPush Push einer neuen oder geänderten Aktivität auf das BB-GerätChangeActivity Änderung oder Neuanlage einer Aktivität auf dem BB-Gerät

und Update der Daten im SAP-CRMGetActivityList Holen einer Aktivitätenliste aus dem SAP-CRM

Tabelle 4.2: Übersicht der Integrationsszenarien

85

Page 100: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

4.3. Integrationsszenarien in SAP-XI Kapitel 4. Design

Objekttyp Objekt BeschreibungIntegrationszenario ActionPush Definiert das Integrationszenario für

die Push Funktionalität von Aktivitä-ten

Action ActivityPushCRM Definiert den serverseitig initiiertenAnwendungsfall Pushen einer Aktivi-tät

Action ActionPush Definiert den clientseitigen Anwen-dungsfall Empfangen eines Aktivität

Message-Interface ActionPush_In Schnittstelle zwischen SAP-XI undBB-Endgerät für Push-Nachricht

RFC-Message-Interface

ZACTIVITY_PUSH Schnittstelle zwischen SAP-CRMund XI um eine Aktivität zu pushen

Message-Typ ActionPushRequest XSD zur Definition einer Push-Nach-richt zum BB-Endgerät

Message-Typ ActionPushResponse XSD zur Definition der Antwort vomBB-Server auf einen PushRequest

RFC-Message-Typ ZACTIVITY_PUSH Request-Datentyp, welcher die Akti-vität beinhaltet

RFC-Message-Typ ZACTIVITY_PUSH.-Response

Response-Datentyp als Antwort aufeinen Aktivitäts-Push

Datentyp ActionPushRequestDa-tatype

Datentyp innerhalb einer Push-Nach-richt. Beinhaltet den Datentyp Activi-ty

Datentyp ActionPushResponse-Datatype

Datentyp eines Response auf eine Pu-sh-Nachricht

Datentyp Activity Kapselt eine Aktivität und wird imActionPushRequestDatatype verwen-det

Interface-Mapping ActionPushMapping Definiert das Mapping vom Aus-gangs-Interface ZACTIVITY_PUSHauf das Ziel-Interface ActionPush_In

Message-Mapping ActionPushRequest-Mapping

Definiert das Mapping des Requestsvon der Ausgangs-Nachricht ZACTI-VITY_PUSH auf die Ziel-NachrichtActionPushRequest

Message-Mapping ActionPushResponse-Mapping

Definiert das Mapping des Responsesvon der Ausgangs-Nachricht Action-PushResponse auf die Ziel-NachrichtZACTIVITY_PUSH_RESPONSE

Tabelle 4.3: Integrationsszenario ActionPush

86

Page 101: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 4. Design 4.3. Integrationsszenarien in SAP-XI

Objekttyp Objekt BeschreibungIntegrationszenario ChangeActivity Definiert das Szenario für das Erzeugen

und Ändern von Aktivitäten im CRMAction ChangeActivityActi-

onDefiniert den clientseitig initiierten An-wendungsfall für das Erzeugen und Än-dern einer Aktivität

Action ChangeActivityActi-onCRM

Definiert den serverzeitigen Anwen-dungsfall für das Verarbeiten einer Ak-tivitätenänderung oder einer Neuanlagevon einer Aktivität

Message-Interface ChangeActivity_Out Schnittstelle zwischen dem Endgerätund XI für den Dienst ChangeActivity

RFC-Message-Interface

CRMXIF_ORDER-_SAVE

Schnittstelle zwischen XI und SAP-CRM für den Dienst ChangeActivity

Message-Typ ChangeActivityRe-quest

XSD zur Definition der Request-Nachricht zwischen BB-Endgerät undXI für das Erzeugen oder Ändern einerAktivität

Message-Typ ChangeActivityRe-sponse

XSD zur Definition der Response-Nachricht vom XI auf einen ChangeAc-tivityRequest

RFC-Message-Typ CRMXIF_ORDER-_SAVE

XSD zur Definition der Request-Nachricht zwischen XI undCRM für den RFC-Aufruf CRM-XIF_ORDER_SAVE zum Erzeugen undÄndern einer Aktivität

RFC-Message-Typ CRMXIF_ORDER-_SAVE.Response

XSD zur Definition der Response-Nachricht als Antwort auf den RFC-Aufruf CRMXIF_ORDER_SAVE

Datentyp ChangeActivityRe-questDatatype

Datentyp innerhalb des ChangeActivity-Request. Enthält den Datentyp Activity

Datentyp ChangeActivityRe-sponseDatatype

Datentyp innerhalb des ChangeActivity-Response

Datentyp Activity Kapselt eine Aktivität und wird imChangeActivityRequestDatatype ver-wendet

Interface-Mapping ChangeActivityMap-ping

Definiert das Mapping vom Ausgangs-Interface ChangeActivity_Out auf dasZiel-Interface CRMXIF_ORDER_SAVE

Message-Mapping ChangeActivityRe-questMapping

Definiert das Mapping des Requests vonder Ausgangs- zur Ziel-Nachricht

Message-Mapping ChangeActivityRe-sponseMapping

Definiert das Mapping des Responsesvon der Ausgangs- zur Ziel-Nachricht

Tabelle 4.4: Integrationsszenario ChangeActivity

87

Page 102: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

4.3. Integrationsszenarien in SAP-XI Kapitel 4. Design

Objekttyp Objekt BeschreibungIntegrationszenario GetActivityList Definiert das Integrationszenario für das

holen einer AktivitätenlisteAction RequestActivityList Definiert den clientseitig initiierten An-

wendungsfall für das holen einer Aktivi-tätenliste

Action ProvideActivityList Definiert den serverzeitigen Anwen-dungsfall für das Suchen nach Aktivitä-ten für einen Anwender

Message-Interface RequestActivity-List_Out

Schnittstelle zwischen dem BB-Endge-rät und SAP-XI für den Dienst GetAc-tivityList

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-Nach-richt zwischen BB-Endgerät und XI fürdas holen einer Aktivitätenliste

Message-Typ ActivityListResponse XSD zur Definition der Response-Nach-richt vom XI auf einen ActivityListRe-quest

RFC-Message-Typ CRM_MY_ACTIVI-TIES

XSD zur Definition der Request-Nach-richt zwischen XI und SAP-CRM fürden RFC-Aufruf CRM_MY_ACTIVI-TIES zum Holen einer Aktivitätenliste

RFC-Message-Typ CRM_MY_ACTIVI-TIES.Response

XSD zur Definition der Response-Nach-richt als Antwort auf den RFC-AufrufCRM_MY_ACTIVITIES

Datentyp ActivityListRequest-Datatype

Datentyp innerhalb des ActivityListRe-quest

Datentyp ActivityListRespon-seDatatype

Datentyp innerhalb des ActivityListRe-sponse. Dieser Datentyp beinhaltet eineListe von Aktivitäten in Form des Daten-typs Activity

Datentyp Activity Kapselt eine Aktivität und wird im Acti-vityListResponseDatatype verwendet

Interface-Mapping ActivityGetList Definiert das Mapping vom Ausgangs-Interface RequestActivityList_Out aufdas Ziel-Interface CRM_MY_ACTIVI-TIES

Message-Mapping ActivityGetListRe-questMapping

Definiert das Mapping des Requests vonder Ausgangs- zur Ziel-Nachricht

Message-Mapping ActivityGetListRe-sponseMapping

Definiert das Mapping des Responsesvon der Ausgangs- zur Ziel-Nachricht

Tabelle 4.5: Integrationsszenario GetActivityList

88

Page 103: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 5

Implementierung

Ausgewählte Einzelheiten aus der Realisierung des im Design entworfenen Modells vonmobileCRM 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 einBackend-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. Ab-schließend wird auf die Qualitätssicherung und den Implementierungsaufwand von mo-bileCRM eingegangen.

5.1 Entwicklungswerkzeuge

Für die Implementierung der mobilen Anwendung mobileCRM kommt die Java-Entwick-lungsumgebung Eclipse1 in der Version 3.2 zum Einsatz. Zum Testen der Anwendungwird das in der Analyse ausgewählte Framework J2ME-Unit verwendet, ebenso wie dasLogging-Framework Microlog. Die Definition von Namenskonventionen und eine stati-sche Code-Analyse wird mit dem Eclipse-Plugin Checkstyle 2 durchgeführt. Inhaltlichgeht das Unterkapitel Qualitätssicherung (Abschnitt 5.7) näher auf die Unit-Tests, einenStyleguide 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-1http://www.eclipse.org2http://eclipse-cs.sourceforge.net3http://eclipseme.org

89

Page 104: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

5.1. Entwicklungswerkzeuge Kapitel 5. Implementierung

lator und die Bibliotheken in ein J2ME-Projekt ein. Der Build- und Packaging-Prozesseiner mobilen Anwendung, resultierend in einem JAD und einem JAR, kann durch einvon Eclipse-ME generiertes Ant-Skript automatisiert und konfiguriert werden. Die Er-weiterbarkeit der Skripte wird ausgenutzt, um aus einer MIDlet-Suite gemäß MIDP ei-ne Blackberry-spezifische Anwendung zu generieren. Der Codeausschnitt dazu findetsich 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 spie-len Performance-Optimierungen bei mobilen Anwendungen eine wichtige Rolle, so dassdieser Punkt bereits in Analyse und Design beachtet wurde. Die Optimierungsmöglichen-keiten wurden im Grundlagenabschnitt 2.4.3.6 erläutert. Als Obfuscator bietet sich dieBenutzung von ProGuard1 an, der sich in EclipseME integrieren lässt. Die prinzipielleFunktionsweise lässt sich in der Dokumentation des Projekts nachlesen. Für mobileCRMund die zugehörige Testsuite kommen die in Quellcode-Listing 5.2 dargestellten zusätzli-chen 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 vonReverse-Engineering und zur Reduzierung der Applikationsgröße. Dies ist im Fall vonmobileCRM unerwünscht, da die Implementierung von Logging und Internationalisie-rung auf den ursprünglichen Klassennamen basiert, und wird durch den ersten Pa-rameter verhindert. Der Parameter -defaultpackage ” wurde aus der Standard-Konfiguration von EclipseME entfernt, damit die Package-Struktur im JAR erhalten1http://proguard.sourceforge.net/

90

Page 105: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 5. Implementierung 5.2. SOAP-Parsing

bleibt. Dies ist für das Auffinden der Ressourcen-Dateien notwendig. Mit dem zweitenParameter wird ProGuard erlaubt die Access-Modifier innerhalb von Klassen zu ändern.Dadurch können beispielsweise Attribute als public deklariert werden und Methodenkönnen dann inline implementiert werden. Der Methodenaufruf entfällt also, und derRumpf der Methode wird an die jeweilige Stelle des Aufrufs kopiert, was insbesonde-re bei trivialen Get- und Set-Methoden sinnvoll ist.

Eine weitere Möglichkeit, um die Performance zu verbessern, bietet sich durch dasVerwenden von Präprozessor-Direktiven. EclipseME unterstützt diese Funktion erst seitkurzem, und kommt im Rahmen von mobileCRM daher nicht zum Einsatz. Die Di-rektiven sind in Java-Kommentaren untergebracht, um den Code kompatibel zu hal-ten, so dass er auch ohne Präprozessor compilierbar ist. Durch Einsatz von Preproces-sing kann in bestimmten Situationen überflüssiger Code entfernt werden. So ließe sichfür eine Release-Version sämtlicher Debugging- und Logging-Code entfernen, und auchEndgerät-spezifische Implementierungen realisieren (siehe z.B. Abschnitt Workarounds).In mobileCRM wird dies zumindest teilweise dadurch erreicht, dass das Logging an zen-traler 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 je-den komplexen XML-Datentyp innerhalb der verwendeten SOAP-Nachrichten (sieheMessage-Typen in den Tabellen 4.3, 4.4 und 4.5) gibt es eine gleichnamige Klasse, diefür die (De-)Serialisierung zuständig ist. Dafür wird das KvmSerializable-Interfaceverwendet, das in den Grundlagen in Abschnitt 2.4.3.5 besprochen wurde. Der Aufbauder fünf verschiedenen SOAP-Nachrichten-Typen ist in Abbildung 5.1 dargestellt. Dabeiwird der Zusammenhang zwischen konkreten Instanzen der Klassen aufgezeigt, ähnlichwie 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 einePush-Anfrage an das Endgerät, weshalb die Benennung des Message-Typs als Request

generiert wird. Die Implementierung auf dem BB verarbeitet die Verbindung jedoch alsAntwort, 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 derMethode reveivePush in Quellcode-Listing 5.3 dargestellt. Zunächst müssen die

91

Page 106: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

5.3. RMS-Schnittstelle Kapitel 5. Implementierung

Abbildung 5.1: Aufbau der verschiedenen Nachrichtentypen

Klassen zum (De-)serialisieren der verwendeten Datentypen mit den entsprechendenXML-Elementen assoziiert werden (Mapping). In kSOAP wird mit der Methode call ei-ne SOAP-Anfrage gesendet und die entsprechende Antwort empfangen, jeweils inklusivedem SOAP-Parsing. Für das Lesen und Parsing der empfangenen Push-Nachricht wurdeder entsprechende Code aus der Methode call in die Methode receive ausgelagert,so dass er auch ohne eine Anfrage benutzt werden kann. Nach erfolgreichem Parsing kannauf die erzeugten Objekte über das KvmSerializable-Interface des Resultats mit derMethode getProperty zugegriffen werden.

Die Schnittstellen aus MIDP und CLDC stellen keine Möglichkeit zum Abfragen desaktuellen Funkverbindungsstatus zur Verfügung. Dies wäre für die Methode update-Activity jedoch wünschenswert, um die Methode im Offline-Zustand des Endgerätsdirekt verlassen zu können, statt auf eine Timeout-Rückmeldung des Betriebssystemswarten zu müssen. Für BB-Geräte gibt es eine herstellerspezifische Lösung über die Klas-se net.rim.device.api.system.RadioInfo, die eine Anwendung jedoch nurverwenden kann, wenn sie mit einem kostenpflichtigen Lizenzschlüssel von RIM signiertist.

5.3 RMS-Schnittstelle

Die Schnittstelle des RMSmanager wurde im Design schon vorgestellt (siehe Abschnitt4.2.3). Die MIDP-API für den Zugriff auf RecordStores wurde im Grundlagenteil 2.4.3.4beschrieben. In Quellcode-Listing 5.4 wird beispielhaft eine der Methoden des RMSma-

92

Page 107: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 wer-den von allen Methoden des RMSmanagers wiederverwendet und nach Benutzung ledig-lich geschlossen. Für InputStream-Instanzen lässt sich diese Optimierung nicht vor-nehmen. Beim Speichern eines ActivityEntryBO muss unterschieden werden, ob essich um einen neuen Datensatz handelt (ID ist -1). In dem Fall muss die nächste zu verge-bende ID des RecordStores erfragt werden und im BO gespeichert werden, bevor es dannserialisiert und mit der RMS-Methode addRecord abgespeichert werden kann. Existiertder Datensatz bereits, so wird der alte mit der RMS-Methode setRecord überschrie-ben. Wichtig ist, dass der zu Beginn geöffnete RecordStore immer vor dem Beenden derMethode wieder geschlossen wird, was durch den finally-Block sichergestellt wird.Anderenfalls bleiben die Deskriptoren für den RecordStore geöffnet, auch nach beendendes MIDlets.

Die lesenden Methoden des RMSmanager benutzen einen gemeinsamen Puffer zum Ein-lesen, welcher mit der Methode assertBufferSize(int size) auf die benötigteGröße des zu lesenden Datensatzes angepasst ist. Dies spart CPU-Leistung, da nicht fürjede Operation erneut ein Puffer allokiert wird. Bei Datensätzen, deren Größe stark va-riiert, kann dies zu erhöhtem Speicherverbrauch führen, da der Puffer sich nicht mehr

93

Page 108: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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;

5private void saveActivityEntry(final ActivityEntryBO activityEntry)

7 throws RecordStoreException{

9 final boolean createIfNecessary = true;RecordStore rs = null;

11try {

13 rs = RecordStore.openRecordStore(ACTIVITY_ENTRY_STORE,createIfNecessary);

15if (activityEntry.getRecordId() == -1) {

17 // new record, set id before serializeactivityEntry.setRecordId(rs.getNextRecordID());

19 activityEntry.serialize(m_out);final byte[] data = m_byteOut.toByteArray();

21 // create new recordrs.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 dieDatensatz-Größe nicht stark streut. Dadurch entstehen bei der Wiederverwendung desPuffers in diesem Fall keine Nachteile.

5.4 Multi-Threading

Im Design-Kapitel wurden bereits die drei in mobileCRM verwendeten Threads entwor-fen. Der Hauptstrang (GUI-Thread) ist für die Darstellung der graphischen Komponentenim Package com.csc.bb.mobileCRM.gui zuständig. Die Schnittstelle zum Model,der ModelController, führt lang andauernde Vorgänge im Model in einem anderenThread (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

Page 109: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 5. Implementierung 5.4. Multi-Threading

gehende Push-Verbindungen annimmt und abarbeitet. Im folgenden Abschnitt wird näherauf die Threads im Hintergrund eingegangen, da der Hauptstrang keine Besonderheitenaufweist, die an dieser Stelle betrachtet werden müssen.

5.4.1 Worker-Thread

Der ModelController erweitert java.lang.Thread und bietet die Funktio-nalität der Methoden im Interface ModelFacade. Da der ModelController jedochfür asynchrone Aufrufe gedacht ist, und das Model für synchrone, unterscheiden sichdie Methoden-Signaturen, so dass der Zusammenhang nicht durch class Model-

Controller implements ModelFacade ausgedrückt werden kann. Auf eineweitere Schnittstelle, die AsyncModelFacade heissen könnte, wurde an dieser Stelleverzichtet, um die Anwendung so schlank wie möglich zu halten. Die öffentlichen Me-thoden 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-Threadseriell abgearbeitet werden. Deadlocks können dabei nicht entstehen, da jeder Vorgangim ModelController unabhängig von anderen Vorgängen ist und irgendwann terminiert.

Am Beispiel der Methode getActivity() wird die Funktionsweise des ModelCon-trollers näher erläutert. Die Implementierung für den asynchronen Aufruf aus der GUI-Schicht findet sich in Quellcode-Listing 5.5.

1 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, welcheMethode im Model aufzurufen ist. Ein optionaler Parameter vom Typ Object kann andas Attribut m_param zugewiesen werden - in diesem Fall die RecordID der auszulesen-den Aktivität. Nun wird mit notifyAll() der schlafende Worker-Thread aufgeweckt,andere Threads warten nicht auf die ModelController-Instanz. Der Worker-Thread führtdie Methode run() des ModelControllers aus. Dort wird in einer Endlos-Schleife je Zy-klus ein Vorgang im Model durchgeführt, und der Thread wartet bis zum nächsten Aufruf.

95

Page 110: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 aufgeru-fen, 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 andie aufrufende GUI-Komponente übergeben. Dies setzt voraus, dass diese vor demAuruf von getActivity zunächst beim ModelController mittels setCaller(-

AsyncDataHandler caller) registriert wird. Als Abschluß eines Vorgangs wirdder Folge-Screen des StatusBar angezeigt.

Zum Beenden des Worker-Threads (siehe Quellcode-Listing 5.7) wird die Abbruchbe-dingung der Schleife in run() erfüllt, und der Worker-Thread aufgeweckt, so dass dieMethode verlassen wird und der Thread sich beendet. Wenn der Worker-Thread geradeaktiv ist, beendet er sich erst nach Abschluß des Vorgangs im Model. Der Push-Receiverim Model wird auch durch den ModelController beendet.

96

Page 111: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 datam_blocking = false;

17 inputStream = streamConnection.openInputStream();

19 // parse SOAP messagefinal 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

5.4.2 Push-Thread

Der Thread zum Empfangen neuer Push-Nachrichten ist in der Klasse PushReceiverimplementiert. 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 war-tet. Dabei wird die Art des Protokolls und der Port in Form einer URL angegeben. DieBB-Endgeräte benötigen für TCP-Verbindungen auf Port 8888 die URL http://8888,während es beim Emulator von Sun socket://8888 ist. Die MIDP Spezifikationschreibt nicht vor, welche Protokolle auf einem Endgerät für eingehende Verbindungenunterstützt werden müssen. Nachdem das Connection-Objekt vorhanden ist, werden ineiner Endlosschleife Verbindungen entgegen genommen und verarbeitet, bis der Threadbeendet werden soll. Mit der Methode acceptAndOpen() wartet das Connection-Objekt blockierend auf eine eingehende Verbindung. Die Methode kehrt zurück, wenn ei-ne Push-Verbindung aufgebaut ist. Für die weitere Verarbeitung wird der InputStreamdes Connection-Objekts zum Einlesen und Deserialisieren der SOAP-Nachricht an denSOAP Parser (SAPmanager) übergeben. Das resultierende ActivityBO-Objekt wird

97

Page 112: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

5.5. Logging und Internationalisierung Kapitel 5. Implementierung

im RMS gespeichert, und der Datenstrom geschlossen. Falls die Abbruchbedingung nichtgesetzt wurde, wird dann auf weitere Push-Verbindungen gewartet.

Die Methode stop() (siehe Quellcode-Listing 5.9) zum Beenden des Push-Threadssetzt die Abbruchbedingung auf true, und falls der Thread gerade beim Warten aufPush-Verbindungen blockiert, wird noch die Connection-Instanz durch close() ge-schlossen. Dadurch kehrt acceptAndOpen() zurück, und run() wird in jedem Fallbeendet.

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 vonProperty-Dateien an, wie sie in J2SE bekannt sind. Für jede Sprache wird dabei eine ei-gene Datei angelegt, in der der Key ein Bezeichner für eine Ressource wie beispielsweisedie Beschriftung einer Titelleiste ist, und der Wert die zugehörige Beschriftung in der ent-sprechenden Sprache. Ein Überblick der Klassenhierarchie für Internationalisierung undLogging findet sich in Abbildung 5.2.

Die Dateien werden im JAR der Anwendung hinterlegt, worauf dann mit der generischgehaltenen Klasse PropertyFileReader zugegriffen werden kann - J2ME stellt auchdiese Funktion nicht standardmäßig bereit. Mit der statischen Klasse I18nResourceswerden die Konventionen für Dateipfade und -namen der der Sprachdateien sowie fürdie Bezeichnung der Ressourcen festgelegt. Die Sprachdateien liegen innerhalb des JARsin /resources/i18n/ und tragen als Dateinamen die Sprachkennung nach ISO 639Code mit der zusätzlichen Endung .property, also beispielsweise de.property für

98

Page 113: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 Sunbenutzt dabei RFC 4646 (z.B. de-DE), während die BB-Endgeräte die Kennung nach ISO639 (z.B. de) verwenden. Da aus dem String nach RFC 4646 der Code gemäß ISO 639 ex-trahiert werden kann, wurde dieser als kleinster gemeinsamer Nenner für die Sprachken-nung gewählt, die die Methode loadResources(String locale) erwartet. Dieentsprechende Property-Datei wird eingelesen, und die Key-Value-Paare werden in einerHashtable-Instanz gehalten. Der Bezeichner einer Ressource beginnt mit dem Klas-sennamen 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 wirddie Methode getString(Object obj, String resource) bereitgestellt, wo-bei obj das Objekt ist, das die Ressource anfragt, und resource der Folge-String. Solldie Methode innerhalb einer statischen Methode aufgerufen werden, so kann statt demObjekt auch eine Instanz der Klasse Class übergeben werden. Da die Umwandlung einerObjekt- oder Class-Instanz in den Klassennamen allgemeingültig ist und auch für dasLogging benötigt wird, wurde diese Funktion in die Klasse StringUtils ausgelagert.Ein typischer Aufruf der Methode innerhalb des Hauptmenüs MainMenu könnte also fol-gendermaßen aussehen: I18nResources.getString(this, "title"). Dabeiwird aus der entsprechenden Sprachdatei bzw. der Hashtable der Wert für den Key Main-

99

Page 114: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

5.6. Workarounds Kapitel 5. Implementierung

Menu.title ausgelesen.

Für das Logging wird die in der Analyse ausgewählte Bibliothek Microlog (siehe Ab-schnitt 3.4.4) verwendet. Um den kompletten Code der mobilen Anwendung nicht vonden Microlog-Klassen abhängig zu machen, wird eine eigene Wrapper-Klasse Log einge-fü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 Klassenna-me mit geloggt, in der die Meldung verursacht wurde. Weiterhin sind optionale Infor-mationen wie die Zeit der Nachrichtenausgabe in Millisekunden und Informationen zumausführenden Thread zuschaltbar. Damit die Meldungen aufgrund des Multithreadingssich nicht gegenseitig beeinträchtigen, sind alle Logging-Methoden synchronized.

5.6 Workarounds

In diesem Abschnitt werden implementierungsspezifische Probleme besprochen, die imZusammenhang mit der Hersteller-Implementierung von MIDP stehen.

5.6.1 javax.microedition.midlet.MIDlet

Die Spezifikation der MIDP-API sieht innerhalb der Methode startApp() vor, dassim schweren Fehlerfall notifyDestroyed() aufgerufen wird, um das MIDlet zu be-enden. Handelt es sich nur um einen temporären Fehler, der beim nächsten Start der An-wendung möglicherweise nicht mehr auftritt, so soll stattdessen eine MIDletState-ChangeException geworfen werden. Der Codeausschnitt in Quellcode-Listing 5.10führt auf dem BB-Endgerät und dem Simulator zu einer Ausnahme in der Implementie-rung 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 nach-vollzogen werden. Die entsprechende Log-Ausgabe des Endgeräts findet sich in Quellco-delisting 5.11. Erwähnt sei an dieser Stelle noch, dass dieser Fehler mit der Referenzim-plementierung im Emulator von Sun (Bestandteil des WTK) nicht auftritt.

100

Page 115: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 Feh-lern innerhalb von startApp() stattdessen immer eine MIDletStateChange-

Exception geworfen. Dadurch wird die Anwendung ebenso beendet, der oben be-schriebene Fehler tritt jedoch nicht auf.

5.6.2 javax.microedition.lcdui.Gauge

Mit der Klasse Gauge kann dem Benutzer ein Fortschritt angezeigt werden. Dabei kannunterschieden werden, ob der Vorgang definierte Einzelschritte hat oder nicht, und obdie Anwendung gerade aktiv ist oder sich in einem Wartezustand befindet. Der Code-ausschnitt in Quellcode-Listing 5.12 initialisiert die Darstellung für einen Vorgang mitundefiniert vielen Einzelschritten in einem arbeitenden Zustand. Die Darstellung auf demEndgerät ist meist als drehende Sanduhr realisiert, während definierte Einzelschritte alsFortschrittsbalken dargestellt werden. Sobald der Konstruktor mit den beschriebenen Pa-rametern aufgerufen wird, ist die CPU des Rechners ausgelastet, auf dem der Emulatorläuft. Beim Emulator des WTK ist dies nicht der Fall. Auf dem Endgerät kann darüber kei-ne Aussage getroffen werden, da es keine Überwachungsmöglichkeit gibt, jedoch scheintder Fehler dort nicht aufzutreten, die Benutzbarkeit der Anwendung ist im Gegensatz zumEmulator nicht eingeschränkt. Als Workaround für den Simulator kann die Erzeugung derGauge-Instanz auskommentiert werden, was lediglich eine graphische Einbuße ist unddie 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

Page 116: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

5.6. Workarounds Kapitel 5. Implementierung

5.6.3 Statische PushRegistry-Verbindungen im JAD

Verbindungen, die für die Funktion eines MIDlets zwingend und dauerhaft erforderlichsind, können nach der MIDP-Spezifikation statisch über einen Eintrag im JAD registriertwerden (siehe [MW06] Seite 89). Das BlackBerry-Endgerät (7100v) bricht die Installa-tion einer MIDlet-Suite jedoch nicht spezifikationsgemäß ab, wenn der zu registrierendePort bereits von einer anderen Applikation verwendet wird. Schwerwiegender ist jedochdas Problem, dass die AMS die statische Registrierung entfernt, falls die Anwendung aufdem registrierten Port eine Server-Verbindung öffnet, ohne dass eine eingehende Push-Verbindung verfügbar ist. Eine erneute Registrierung ist nicht möglich, wenn das statischeRegistrierungsverfahren über den JAD genutzt wurde. Das Entfernen von statischen Ein-trä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 ei-ner Server-Verbindung notwendig ist. Dieses Problem kann umgangen werden, indem dieVerbindung für Push-Nachrichten dynamisch registriert wird. Der Nachteil der dabei ent-steht ist, dass die Anwendung einmalig gestartet werden muss, bevor Push-Nachrichtenempfangen werden können.

5.6.4 Initialisierung von statischen Attributen

Ein ClassLoader in Java ist dafür verantwortlich, die zur Ausführung benötigten Klas-sen einzulesen. Dabei werden auch statische Attribute der zu ladenden Klassen initia-lisiert. Nach dem Beenden einer Anwendung auf einem mobilen Endgerät würde manmöglicherweise erwarten, dass die statischen Variablen oder gar der gesamte Classloa-der von der Garbage-Collection aus dem Speicher entfernt werden. Bei den Implemen-tierungen des BB-Endgeräts und des BB-Simulators ist dies jedoch nicht der Fall, beierneutem Starten einer Anwendung sind die Variablen noch mit den vormaligen Werteninitialisiert. Als minimale Testanwendung dient ein MIDlet mit einem statischen Zählervom Typ int. Um Fehler zu umgehen, werden statische Variablen, insbesondere bei denSingleton-Klassen, vor Beenden der Anwendung zurückgesetzt, so dass die Variablensauber hinterlassen werden, und die dann nicht mehr referenzierten Instanzen entferntwerden können.

102

Page 117: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 5. Implementierung 5.7. Qualitätssicherung

5.7 Qualitätssicherung

5.7.1 Styleguide

Mit dem bereits erwähnten Eclipse-Plugin Checkstyle (siehe Abschnitt 5.1) wird derQuellcode von mobileCRM anhand von Regeln überprüft. Diese werden durch ein XML-Dokument spezifiziert (checkstyle-config.xml), das auch über den Konfigurati-onsdialog in Eclipse erstellt werden kann. Neben der Benutzung der parametrisierbarenStandard-Module gibt es auch die Möglichkeit, eigene Checkstyle-Module zu entwickeln.Im Folgenden werden nur einige ausgewählte Regeln beschrieben, die nicht Bestandteilder üblichen Java-Konventionen sind:

• Attribute beginnen mit dem Präfix m_ (von Member-Variable), um Attribute vonlokalen Variablen optisch unterscheiden zu können, und um Shadowing zu vermei-den, 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- undOutOfMemoryExceptions gefangen würden.

• Die Verschachtelung von try-Blöcken ist nicht zugelassen, bei if maximal biszu einer Tiefe von 2. Dies verbessert die Wartbarkeit des Codes und verringert dieFehleranfälligkeit.

• Referenzen, die nicht modifiziert werden, sollten als final deklariert werden. Da-durch kann die JVM Optimierungen bei der Ausführung vornehmen.

• Klassen mit ausschließlich statischen Methoden sollten Konstruktoren als pri-vate deklarieren. Die nicht zweckgemäße Instanziierung solcher Klassen ist somitunterbunden.

Alle weiteren Regeln können der Konfiguration von Checkstyle entnommen werden. Inder Summe tragen sie zu einem einheitlichen, konsistenten Programmierstil bei, und hel-fen Programmierfehler zu vermeiden sowie Best-Practices durchzusetzen.

103

Page 118: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

5.7. Qualitätssicherung Kapitel 5. Implementierung

Abbildung 5.3: Kiviat-Graph der Metriken von mobileCRM

5.7.2 Software-Metriken

Die Kenngrößen einer statischen Codeanalyse wurden mit dem Werkzeug SourceMoni-

tor1 ermittelt. Die wichtigsten Kenngrößen sind in Abbildung 5.3 dargestellt. Alle weite-ren Messwerte finden sich auf der CD-ROM zu dieser Arbeit. Dabei ist zu sagen, dass dieKomplexität, Anzahl der Statements in einer Methode und vergleichbare Messgrößen er-höht sind. Dies ist darauf zurückzuführen, dass bestimmte Vorgänge mit allen Attributeneiner Aktivität durchzuführen sind. Das Aufsplitten dieser Methoden wäre semantischjedoch nicht sinnvoll und würde die Fehleranfälligkeit des Codes auch tendenziell ehervergrößern.

5.7.3 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 ma-nuell 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

1http://www.campwoodsw.com/sourcemonitor.html

104

Page 119: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 5. Implementierung 5.8. Implementierungsaufwand

Datei Lines Of CodeMobileCrmMIDlet.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 wurdenTests angelegt, die mit lokalen Datenströmen arbeiten, damit die Datenkommunikati-on verifiziert werden kann, und die Tests ohne SAP-System und Netzwerkverbindungdurchgefü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 mitgetestetwerden kann.

Die Klasse SAPmanager wurde zur Testbarkeit so erweitert, dass eine Verbindung über-geben werden kann, anstatt eine HTTP-Verbindung zu erzeugen. Um diese Möglichkeitauch auf Ebene des SOAP-Parsers zu haben, wurde die kSOAP Bibliothek um eine über-ladene Methode call erweitert, die eine ServiceConnection der kSOAP-API ent-gegennimmt. Die Testdaten liegen als SOAP-Nachrichten in Form von XML-Dateienvor, die jeweils eingelesen werden, und in einen Datenstrom konvertiert werden, der andie modifizierte Implementierung der ServiceConnection (MyServiceConnection)übergeben werden kann. Die Instanz der ServiceConnection wird an den SAP-manager übergeben, der das SOAP-Parsing übernimmt. Das Ergebnis kann mit einerActivityBO-Instanz aus der Klasse ActivityTestData verglichen werden. Umeine eingehende Push-Verbindung zu testen muss diese ServiceConnection nicht verwen-det werden, da die Methode direkt einen InputStream entgegen nimmt.

Die Klasse RMSmanager kann auch im Emulator getestet werden, so dass spezielleVorkehrungen für das Testen nicht zu treffen sind. Die Methoden werden mit Testdatenaus der Klasse ActivityTestData getestet, so dass die Ergebnisse verifiziert werdenkönnen.

5.8 Implementierungsaufwand

Dieser Abschnitt gibt den Implementierungsaufwand von mobileCRM in Lines Of Code

(LOC) inklusive Kommentarzeilen an.

105

Page 120: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

5.8. Implementierungsaufwand Kapitel 5. Implementierung

Datei Lines Of CodeActivityList.java 183AsyncDataHandler.java 11BasicAlert.java 140BasicScreen.java 38MainMenu.java 109ModelController.java 385SettingsMenu.java 84ShowActivityForm.java 495StatusBar.java 108

Tabelle 5.2: LOC des Package com.csc.bb.mobileCRM.gui

Datei Lines Of CodeActivityBO.java 733ActivityEntryBO.java 154AsyncEventHandler.java 11BasicBO.java 53Model.java 242ModelFacade.java 17ProgressObserver.java 9SAPUserBO.java 59

Tabelle 5.3: LOC des Package com.csc.bb.mobileCRM.model

Datei Lines Of CodeRMSmanager.java 441Serializable.java 23

Tabelle 5.4: LOC des Package com.csc.bb.mobileCRM.model.backend.rms

Datei Lines Of CodeActionPushRequest.java 49Activity.java 480ActivityList.java 60ActivityListRequest.java 86ActivityListResponse.java 48ChangeActivityRequest.java 115ChangeActivityResponse.java 54PushReceiver.java 122SAPmanager.java 275

Tabelle 5.5: LOC des Package com.csc.bb.mobileCRM.model.backend.sap

106

Page 121: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 5. Implementierung 5.8. Implementierungsaufwand

Datei Lines Of CodeApplicationException.java 58I18nResources.java 60Log.java 149PropertyFileReader.java 96StringUtils.java 57

Tabelle 5.6: LOC des Package com.csc.bb.mobileCRM.util

Datei Lines Of CodeActivityTestData.java 141AllTests.java 34MobileCRMtestrunner.java 18MyServiceConnection.java 54RMSmanagerTests.java 82SAPmanagerTests.java 226

Tabelle 5.7: LOC des Package com.csc.bb.mobileCRM.tests

Datei Lines Of CodemobileCRM 5253mobileCRMtestsuite 555Gesamt 5808

Tabelle 5.8: LOC von mobileCRM und mobileCRMtestsuite

107

Page 122: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 Aussa-gen über die Praxistauglichkeit der in der Systemarchitektur dieser Arbeit kombiniertenKomponenten treffen zu können. Weiterhin können dadurch die primären leistungsbe-grenzenden 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 ausinitiiert wird, Request und Response beinhaltet, und die Nutzlast vom SAP-CRM in Rich-tung des BBs variabel ist. Die Testimplementierung ruft die Methode SAPmanager-.getActivities auf, und die Nutzlast kann über die im SAP-CRM verfügbaren Ak-tivitäten gesteuert werden. Dadurch wird für jede einzelne Messung eine Verbindung auf-und abgebaut, was jedoch erwünscht ist, um einen realistischen Testfall zu haben. ZurTestumgebung ist zu sagen, dass SAP-CRM, SAP-XI, BES und deren Netzwerkverbin-dung nur durch den Test-Client benutzt wurden, so dass die Ergebnisse nicht durch andereBenutzer verfälscht werden.

Dies sind optimale Voraussetzungen, so dass in der Praxis eher mit höheren Latenz-zeiten zu rechnen ist. Auf der anderen Seite ist das Testsystem auf nicht so leistungs-fähiger Hardware installiert, wie es in Produktivsystemen üblich ist. Zu der Auslas-tung des Mobilfunkanbieters und der RIM-Infrastructure kann keine Aussage getroffenwerden. Für die Performance-Tests wurden zunächst innerhalb der kSOAP-BibliothekZeitnahmen in den Code implementiert. Dies geschieht durch Aufruf der MethodeSystem.currentTimeMillis(), die eine Auflösung von 10 Millisekunden hat.Daraus folgt, dass die ermittelten Durchschnittswerte im schlimmsten Fall eine Ungenau-igkeit von 10ms haben. Durch den niedrigsten in allen Messreihen ermittelten Wert von

108

Page 123: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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 derZeitdifferenzen zwischen Messpunkten und die Ausgabe erfolgt erst nach Abschluss einereinzelnen Messung, während einer Messung finden keine Log-Ausgaben statt. Das mobi-le Endgerät befand sich bei allen Messreihen am selben Ort, so dass der Funk-Empfangvergleichbar ist, der im Übrigen eine gute Signalstärke (-55dBm) aufwies. Der Messauf-bau und die Bezeichnung der einzelnen gemessenen Teilstrecken sind in Abbildung 5.4dargestellt. Die Verbindung zwischen XI und SAP-CRM ist dabei lokal, da beide Anwen-dungen auf einem Host installiert sind.

Die Auswertung der Messgröße Request Parsing wird den Messreihen vorangestellt, dadiese Zeitspanne unabhängig von der im Response übertragenen Nutzlast ist und im Ver-gleich zu anderen Messwerten nicht ins Gewicht fällt. Unter Request Parsing ist die Se-rialisierung 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 denersten beiden Messreihen dargestellt. Der größte gemessene Wert beträgt 240ms und diePayload ist bei allen Messreihen vergleichbar.

5.9.1 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 1zunächst der minimale Testfall betrachtet, bei dem nur eine Aktivität vom SAP-CRM

109

Page 124: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

5.9. Performance-Bewertung Kapitel 5. Implementierung

Gesamtzeit Resp. Parsing Antwortzeit XIArithmetisches Mittel 5540 2097 3266 308Minimum 4580 1930 2310 188Maximum 26680 2980 24510 766Standardabweichung 2168 106 2176 83

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örigeAntwort vollständig empfangen und durch das Parsing wurde, sowie die Zeitberechnungstattgefunden hat und ausgegeben wurde. Nach der Ausgabe wird der Test-Thread nochpauschal zwei Sekunden pausiert, so dass die Vorgänge im Betriebssystem, die mit derAusgabe zu tun haben, gänzlich abgeschlossen sind und einen nächsten Testlauf nichtbeeinträchtigen. Die Messergebnisse sind graphisch in Abbildung 5.6 dargestellt. Die sta-tistischen Kenngrößen können Tabelle 5.9 entnommen werden.

Die Gesamtzeit wurde in der modifizierten kSOAP-Bibliothek gemessen. Die Zeitnah-me erfolgte dabei vor Deserialisieren der Anfrage und nach dem erfolgreichen Parsingder Antwort. Durch einen weiteren Messwert vor dem Parsing lässt sich dessen Dauerermitteln. Die Antwortzeit berechnet sich aus der Gesamtzeit abzüglich der Parsing-Zeitvon Request und Response. Dem Performance-Monitoring von XI lassen sich die Zei-ten für die Bearbeitungszeit der einzelnen Requests entnehmen. Diese Zeit umfasst dieVerarbeitung im SAP-XI, die Übertragung zum SAP-CRM und dessen Verarbeitung so-wie den Rücktransport und die erneute Bearbeitung des XI. Dabei sei noch einmal darauf

110

Page 125: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

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-CRMauf einem Host installiert sind. Von einem Ausreißer im statistischen Sinne wird in denfolgenden Messreihen gesprochen, wenn ein Wert nicht im Intervall des Durchschnittsplus/minus der zweifachen Standardabweichung liegt.

5.9.2 Messreihe 2

Diese Messreihe wurde unter den gleichen Voraussetzungen wie Messreihe 1 durchge-führt, allerdings mit 14 Aktivitäten als Nutzlast, um das Verhalten der einzelnen Sys-temkomponenten bei größeren Datenmengen zu testen. Die Darstellung der Messwer-te in Abbildung 5.7 zeigt, dass bei dieser zweiten Messreihe starke Schwankungen beider Datenübertragung vorhanden sind. Eine der 100 durchgeführten Messungen brachsogar durch eine Timeout-Exception ab, weshalb nur 99 Messwerte vorhanden sind. Inder Konsolen-Ausgabe des Endgeräts konnten bei der erhöhten Nutzlast deutlich mehrGarbage-Collection-Aufrufe festgestellt werden. Die Zeit für das Parsing des Requests istjedoch sehr stabil, weshalb die Garbage-Collection-Aufrufe nicht als Begründung für dieAusreißer der Antwortzeit in Frage kommen. Die Antwortzeiten des SAP-XI sind kon-stant gering, und die Ursache der Schwankungen ist daher vermutlich zwischen dem BESund dem BB-Endgerät zu suchen, denn die CPU-Auslastung auf dem BES ist gering unddie Internetanbindung ausreichend dimensioniert.

111

Page 126: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

5.9. Performance-Bewertung Kapitel 5. Implementierung

Gesamtzeit Resp. Parsing Antwortzeit XIArithmetisches Mittel 24595 14449 9950 600Minimum 18770 13880 4140 281Maximum 113750 16240 98310 1406Standardabweichung 12189 421 12098 211

Tabelle 5.10: Statistische Kenngrößen zu Messreihe 2 (Einheit [ms])

Abbildung 5.8: Messreihe 3: Zehn Aktivitäten als Payload

5.9.3 Messreihe 3

Innerhalb der Messreihe 3 wurden ebenfalls 100 Anfragen vom Endgerät über XI andas 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 wenigerals 14 Aktivitäten verhalten. Die Darstellung der gemessenen Werte ist Abbildung 5.8 zuentnehmen, die statistischen Kenngrößen finden sich in Tabelle 5.11. Es zeigt sich, dassdie Schwankungen der Antwortzeit deutlich geringer ausfallen als in Messreihe 2.

Resp. Parsing Antwortzeit XIArithmetisches Mittel 10631 4844 383Minimum 10060 3650 250Maximum 11620 8150 1094Standardabweichung 331 582 100

Tabelle 5.11: Statistische Kenngrößen zu Messreihe 3 (Einheit [ms])

112

Page 127: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 5. Implementierung 5.9. Performance-Bewertung

Messung Parsing Antwortzeit XI BES1 3900 5850 988 48622 3980 5310 877 44333 3670 4140 1144 29964 3930 3640 628 30125 3870 6310 933 5377

Tabelle 5.12: Daten aus Messreihe 4 (Einheit [ms])

5.9.4 Messreihe 4

Diese Messreihe wurde manuell durchgeführt, wobei je Messung drei Aktivitäten aus demSAP-CRM übertragen wurden. Weiterhin wurden alle Datagramme, die den Testvorgangbetreffen, auf dem BES aufgezeichnet. Die gemessenen Werte sind in Tabelle 5.12 dar-gestellt. Die Spalte XI wurde anhand manueller Auswertung der aufgezeichneten Paketeerrechnet. Die Zeit umfasst dabei Übertragung der Daten vom BES zum SAP-XI, von dortweiter zum SAP-CRM und zurück bis zum BES, sowie die Verarbeitungszeit im SAP-XIund im SAP-CRM. Die gemessenen Zeiten der XI-Verarbeitung sind also nicht mit denenaus den vorangegangenen Messreihen vergleichbar. Die Spalte BES bezeichnet die Über-tragungszeit des Requests vom Endgerät zum BES zuzüglich derjenigen des Responsesvom BES zum Endgerät. Sie berechnet sich aus der Antwortzeit abzüglich der gemesse-nen Zeit des XI. Alle anderen Spalten stammen aus der Aufzeichnung des Clients.

Wie in Abschnitt 2.1.1 beschrieben wurde, findet die Übertragung zwischen einem BB-Endgerät und dem BES verschlüsselt und komprimiert statt. Durch die aufgezeichnetenPakete kann die Komprimierungsrate bestimmt werden, was an der ersten Messung vorge-nommen wurde. Die zwischen SAP-XI und BES ausgetauschte, unverschlüsselte Nutzlastbeträgt dabei 4757Byte. Die verschlüsselte und komprimierte Nutzlast zwischen BES undder RIM-Infrastructure beträgt hingegen nur 1945Byte, was einer Komprimierungsratevon 59,11% entspricht.

5.9.5 Bewertung

Der Vergleich der Ergebnisse aus den vorangegangenen Messreihen erlaubt Rückschlüsseauf die Performance und die Skalierbarkeit der Komponenten, aus denen das Gesamtsys-tem aufgebaut ist.

Zum SAP-XI lässt sich sagen, dass es auf den Umsatz von großen Datenmengen ausgelegtist. Die durchschnittliche Verarbeitungszeit zwischen Messreihe 2 mit einer Aktivität und

113

Page 128: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

5.9. Performance-Bewertung Kapitel 5. Implementierung

Messreihe 3 mit zehn Aktivitäten als Nutzlast unterscheidet sich nur um 75ms (19,6%).Die erhöhte Nutzlast hat also nur eine sehr geringe Auswirkung auf die Antwortzeit. Beiden absoluten Werten der XI-Messungen ist zu beachten, dass SAP-XI und SAP-CRMim gegebenen Testszenario auf der selben Maschine arbeiten. Dadurch verringert sich ei-nerseits die Übertragungzeit zwischen beiden Systemen, andererseits jedoch konkurrierensie um gemeinsame Ressourcen wie Speicher und CPU.

Auf die Dauer des SOAP-Parsings hat die Verzehnfachung der Nutzlast jedoch deutlicheAuswirkungen. Zwischen Messreihe 1 mit 2097ms Response-Parsing-Zeit und Messreihe3 mit 10631ms ergibt sich eine Verfünffachung der Dauer. Dass sich die Dauer nichtproportional zur Nutzlast geändert hat, könnte darauf zurückzuführen sein, dass der XML-Parser und die SOAP-Mappings zunächst initialisiert werden müssen, was zusätzlich (einevom Umfang der Nutzlast unabhängige) Zeit in Anspruch nimmt. Der Peak der Parsing-Zeit in Messreihe 1 könnte seine Ursache in Vorgängen auf Betriebssystem- oder VM-Ebene haben, wie beispielsweise die Garbage-Collection.

Die durchschnittliche Antwortzeit zwischen den Messreihen mit einer und zehn Aktivi-täten als Nutzlast unterscheidet sich nur um den Faktor 1,5, obwohl die Zehnfache Nutz-last übertragen wurde. Dieser sehr geringe Faktor lässt sich vermutlich auf den Auf- und-Abbau der TCP/IP Verbindung zurückführen, die unabhängig von der Größe der über-tragenen Nutzlast Zeit in Anspruch nimmt. Bei einer Verbindung mit hoher Latenz undÜbertragung von geringer Nutzlast macht die Summe der für den Verbindungsauf- und-abbau notwendigen Datagramme einen erheblichen Anteil der Gesamtübertragungszeitaus.

Die Gesamtzeit aus Messreihe 2 (rund 25 Sekunden) kann einem Benutzer sicherlichnicht zugemutet werden. Jedoch ist für den Praxiseinsatz Messreihe 1 besser anwendbar,da der Benutzer auf Dauer nur einzelne Aktivitäten als Push-Nachricht empfängt oderals Update zum SAP-System sendet. Messreihe 2 und 3 wären also nur für die initia-le Synchronisation aller Aktivitäten relevant. Von den rund 5 Sekunden der Gesamtzeitaus Messreihe 1 entfallen im Schnitt 3 Sekunden auf die Antwortzeit, wobei die Zeit desSAP-XI und SAP-CRM mit rund 0,3 Sekunden sehr gering ausfällt. Aufgrund der bereitsangewendeten Komprimierung der Nutzlast könnte die Antwortzeit durch Verwendungeines Binärprotokolls statt SOAP nur minimal verbessert werden. Der Spielraum für ei-ne Optimierung beschränkt sich beim untersuchten Testaufbau also auf die 2 Sekunden,die das SOAP-Parsing in Anspruch nimmt. Dafür biete sich zwei Möglichkeiten: Die Im-plementierung weiter optimieren, beispielsweise durch Profiling oder durch den Einsatzleistungsfähigerer Hardware auf Client-Seite könnte die Zeit für das Parsing reduziertwerden. Die Entwicklungsumgebung von RIM bietet jedoch nur für den Emulator ei-

114

Page 129: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 5. Implementierung 5.9. Performance-Bewertung

ne Profiling-Funktion an, nicht für die Endgeräte. Durch bessere Hardware könnte stattGPRS auch UMTS für die Übertragung der Daten zum Einsatz kommen, was die Ant-wortzeit verbessern würde.

115

Page 130: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

5.9. Performance-Bewertung Kapitel 5. Implementierung

116

Page 131: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 6

Zusammenfassung

Die vorliegende Arbeit entstand als externe Diplomarbeit bei der Firma CSC Deutsch-land Solutions GmbH in Wiesbaden. Das Ziel bestand darin, ein Konzept zur Integrationzwischen einem SAP-System und einem mobilen BlackBerry-System zu entwerfen undzu realisieren. Der dabei entstehende möglichst praxisnahe Prototyp soll die Realisierungzukünftiger ’Real World’-Anwendungen erleichtern. Aus dieser Anforderung resultiertedie Randbedingung, dass ein Web Service als Bindeglied zwischen dem SAP-System undder BlackBerry-Lösung operieren soll. Darauf aufbauend sollte der Entwurf aus Benutzer-und auch aus Infrastruktur-Sicht für den Einsatz in Unternehmen geeignet sein. Weiterhinsollte die Applikation für das mobile Endgerät als Smart-Client realisiert werden. Dabeiwerden die übertragenen Daten lokal auf dem Endgerät zwischengespeichert, wodurchein Offline-Modus und Performance-Gewinne ermöglicht werden.

Für die Realisierung der Arbeit wurde als abzubildener Anwendungsfall im SAP-Systemdas Aktivitätsmanagement eines SAP-CRM-Systems (Customer Relationship Manage-ment) ausgewählt. Dabei wurde prototypisch ein Client für ein mobiles BlackBerry-Endgerät umgesetzt. Die Nachrichten-orientierte Middleware SAP-XI dient als Web-Service-Schnittstelle zwischen dem CRM-System und dem BlackBerry Enterprise Ser-ver, der für die Kommunikation zwischen Unternehmensanwendungen und den mobilenEndgeräten zuständig ist. Die Vorteile von SAP-XI liegen in der zentralen Konfigurati-on der Kommunikation zwischen den zu integrierenden Anwendungen, und es ist kei-ne anwendungsspezifische Implementierung eines Web Service notwendig. Mit diesemAnsatz können weitere Anwendungen leichter und übersichtlicher, da weniger stark ge-koppelt, miteinander verknüpft werden. Die mobile Anwendung (mobileCRM) für dasBlackBerry-Endgerät wurde in J2ME entwickelt, für die Kommunikation mit dem WebService über SOAP kam die Bibliothek kSOAP zum Einsatz, die der Analyse entspre-

117

Page 132: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 6. Zusammenfassung

chend der Referenz-Implementierung der JSR 172 API von Sun vorgezogen wurde. DieDaten aus dem SAP-System werden auf dem Endgerät mit der RMS-API aus J2ME zwi-schengespeichert, wodurch auf den Flash-Speicher des Geräts zugegriffen werden kann.Die dabei unter Umständen auftretenden Synchronisationsprobleme zwischen Daten aufClients und dem SAP-CRM-System wurden theoretisch untersucht und Realisierungs-möglichkeiten zur Lösung vorgestellt. Bei der Abbildung der Attribute eines Datensat-zes im SAP-CRM-System auf das mobile Endgerät wurden die technisch notwendigenund die für den mobilen Einsatz wichtigsten Attribute übernommen. Diese können imPrototyp durch die implementierten Anwendungsfälle verarbeitet werden. Welche Attri-bute benötigt werden ist anwendungsspezifisch und hängt von den abzubildenden Ge-schäftsprozessen bzw. dem Einsatzgebiet der Anwendung ab. Der Schwerpunkt der Im-plementierung lag auf dem Entwurf einer einfach zu erweiternden Architektur und aufder Kommunikation über SOAP. Ersteres wurde durch den Einsatz eines Document-ViewArchitektur-Ansatzes in mobileCRM erreicht, und kann so als Basis für Erweiterungendienen. Bei der SOAP-Kommunikation empfängt und verarbeitet die Anwendung Push-Updates vom SAP-System, sendet Updates vom Client in umgekehrter Richtung, undeine Liste aller Aktivitäten kann manuell in einem bidirektionalen Vorgang angefordertwerden. Das Design der GUI stand nicht im Vordergrund. Im Rahmen der Implementie-rung hat sich herausgestellt, dass für Anwendungen mit mehr Dialogfeldern und kom-plexerem Informationsfluss auf jeden Fall eine zentrale Steuerung des Übergangs voneiner graphischen Komponente (Screen) zur nächsten ratsam ist. Weiterhin empfiehlt sichfür mobile Anwendungen allgemein, den Programmcode und den Build-Prozess so fle-xibel und konfigurierbar wie möglich zu halten. Dies ist darin begründet, dass der CodeEndgerät-spezifisch angepasst werden muss, beispielsweise aufgrund von notwendigenWorkarounds, und den unterschiedlichen Features und APIs, die ein Endgerät zur Verfü-gung stellt.

Bei den durchgeführten Performance-Messungen hat sich ergeben, dass die meiste Zeitbei der Übertragung zwischen BES und dem Endgerät sowie dem Parsing der SOAP-Nachrichten verloren geht. Letztere Größe ist im Gegensatz zur Übertragung deutlichervon der Nutzlast abhängig. Die Dauer für die Übertragung von 10 Aktivitäten kann bereitsnicht mehr als benutzerfreundlich eingestuft werden, auch wenn sie für mobile Gerätenicht ungewöhnlich ist. In den Anwendungsfällen von mobileCRM wird jedoch im alltäg-lichen Einsatz bei einem Aktivitätsupdate vom Endgerät zum SAP-System und umgekehrtnur eine einzelne Aktivität übertragen, da die Synchronisation kontinuierlich durchgeführtwird, sofern eine Funknetzabdeckung verfügbar ist. Die Dauer des Parsings macht dabeica. 2 Sekunden aus. Daraus ergibt sich, dass SOAP-basierte mobile Lösungen für den

118

Page 133: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 6. Zusammenfassung

Einsatz in ähnlichen Szenarien wie dem in dieser Arbeit vorgestellten erwartungsgemäßnur dann geeignet sind, wenn die Nutzlast der einzelnen Anwendungsfälle nicht zu großist. Der Vorteil einer solchen Lösung gegenüber möglicherweise performanteren aber pro-prietären Binärprotokollen ist, dass Web Services eine plattformunabhängige und offeneSchnittstelle definieren, und teilweise in Unternehmensanwendungen bereits vorhandensind.

Für einen produktiven Einsatz von mobileCRM sollte der Prototyp insbesondere in Be-zug auf die Usability optimiert werden. Eine graphisch ansprechendere und übersichtli-chere Darstellung könnte beispielsweise durch Benutzen des Frameworks J2ME Polish1

(für den kommerziellen Einsatz kostenpflichtig) erreicht werden. Notwendigerweise zuimplementierende Erweiterungen der Benutzerschnittstelle sind Suchmasken, beispiels-weise für die Suche von Aktivitäten nach bestimmten Kriterien, und das Auflösen einesNamens in die entsprechende Personalnummer, so wie es die SAP-GUI auf PCs bietet.Durch eine kategorisierte Darstellung der Attribute einer Aktivität können möglicherwei-se mehr Attribute trotzdem übersichtlich in die mobile Anwendung übernommen werden.Weiterhin kann die vom Benutzer wahrgenommene Latenz eines Netzwerk-Vorgangs wiez.b. einem Aktivitätsupdate verkürzt werden, indem dieser Prozess im Hintergrund statt-findet, und der Benutzer weiter arbeiten kann. Eine Rückmeldung könnte der Anwendererhalten, indem eine nicht zu bestätigende Meldung in einem Statusbereich eingeblendetwird.

Die an diese Diplomarbeit gestellten Vorgaben, wie sie im ersten Abschnitt der Zusam-menfassung aufgeführt wurde, konnten alle umgesetzt werden. Die Praxistauglichkeit desentstandenen Prototyps mobileCRM wurde weiterhin auf verschiedene Aspekte hin ana-lysiert. Diese Arbeit kann als Machbarkeitsstudie angesehen werden, und dient der FirmaCSC als Demonstrationssystem für Akquisetermine Die Umsetzung einer ansprechendengraphischen Benutzeroberfläche wie zuvor empfohlen ist dafür jedoch Vorraussetzung.

Für die Weiterentwicklung der Methodik konnten in dieser Arbeit verschiedene Ansät-ze identifiziert werden. Für die Realisierung weiterer Anwendungen im Projektgeschäftder Firma CSC ist ein Stub-Generator für die SOAP-Kommunikation ein zeitsparenderFaktor, insbesondere wenn die Web-Service-Beschreibungen komplexer werden. EineMöglichkeit könnte dabei die Realisierung oder Lizensierung eines Stub-Generators fürkSOAP sein. Weiterhin könnte ein Tool für die Generierung einer graphischen Darstel-lung auf Basis eines WSDL-Dokuments entwickelt werden, ähnlich der Funktionalitätdes MDS Studio von RIM. Denkbar wäre auch die Integration der Aktivitäten in die

1http://www.j2mepolish.org/

119

Page 134: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 6. Zusammenfassung

PIM-Anwendungen (Kalender und Adressbuch), so dass alle Informationen für den Be-nutzer zentral einsehbar sind. Jedoch müsste dabei auch die Synchronisation von PIM-Anwendungen zu mobileCRM gewährleistet sein.

Auf der Grundlage der in dieser Arbeit vorgestellten Ergebnisse können noch weitereStudien durchgeführt werden und insbesondere zur Verfeinerung der angestrebten Me-thodik wären noch weitere Studien empfehlenswert. Zunächst wäre zu prüfen, wie starksich die Leistung der Systemarchitektur mit einem leistungsfähigeren BB-Endgerät ver-bessern lässt. Das BB-Modell Pearl weist beispielsweise 16MB SRAM (statt 4MB imverwendeten Gerät) und eine leistungsfähigere CPU auf, was die Parsing-Dauer deut-lich reduzieren könnte. Weiterhin sind Modelle mit UMTS verfügbar, wodurch die Über-tragungszeit sich vermutlich verkürzen ließe. Auch aus Sicht der Bedienbarkeit könnennoch andere Endgeräte wie beispielsweise auch PDAs evaluiert werden, insbesondere fürdie Dateneingabe. Neben Hardware-Verbesserungen können auch Engpässe in der Imple-mentierung der einzelnen Bestandteile von mobileCRM durch Profiling weiter optimiertwerden. Für Anwendungsfälle mit höherer Nutzlast oder höherer Priorität einer geringenLatenz kann ein Binärprotokoll zwischen SAP-XI und BB-Endgerät entwickelt werden.Ebenfalls wäre für den produktiven Einsatz zu testen, wie sich die Performance der ein-zelnen Systemkomponenten bei massiver, paralleler Nutzung verhält.

In der Einleitung wurde bereits aufgezeigt, dass der Einsatz mobiler Anwendungen imVergleich zur großen Verbreitung und den immer besseren Fähigkeiten der mobilen End-geräte noch sehr gering ist. Die Weiterführung der Untersuchungen, die mit dieser Arbeiteingeleitet wurden, sind daher von wissenschaftlichem Interesse und haben nicht zuletztbetriebswirtschaftliche Bedeutung für die Firma CSC, in der weitere Untersuchungen be-reits fest eingeplant sind.

120

Page 135: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 7

Literaturverzeichnis

[Bay02] BAYER, Thomas. REST Web Services. http://www.oio.de/public/xml/rest-webservices.htm. 2002

[BEZ04] BUCK-EMDEN, Rüdiger ; ZENCKE, Peter: mySAP CRM - Kundenbezogene

Geschäftsprozesse mit SAP CRM 4.0. Galileo Press GmbH, 2004

[BPE] BPEL4WS. Business Process Execution Language for Web Services Version

1.1

[DMT06] DMTF. Common Information Model (CIM). http://www.dmtf.org/standards/cim/. 2006

[EY03] ELLIS, Jon ; YOUNG, Mark. JSR 172: J2ME Web Services 1.0. http:

//jcp.org/en/jsr/detail?id=172. 2003

[Gei05] GEIGER, Philipp. Mobilfunk Deutschland 2010. http://www.solon.

de/download_secure/Solon_Mobilfunk_%202010.pdf. 2005

[GHJV95] GAMMA, Erich ; HELM, Richard ; JOHNSON, Ralph ; VLISSIDES, John: De-

sign Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995

[HL04] HAUSER, Tobias ; LÖWER, Ulrich M.: Web Services - Die Standards. GalileoComputing, 2004

[MW06] MILIKICH, Mike ; WARDEN, James. JSR 118: Mobile Information Device

Profile 2.0. http://jcp.org/en/jsr/detail?id=118. 2006

121

Page 136: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Kapitel 7. Literaturverzeichnis

[Rah05] RAHM, Erhard. Replizierte Datenbanken. http://dbs.uni-leipzig.de/skripte/MRDBS/PDF2/kap7.pdf. 2005

[RIM05] RIM. BlackBerry Java Development Environment - BlackBerry Application

Developer Guide Volume 1: Fundamentals. 2005

[RIM06a] RIM. BlackBerry Enterprise Server für Microsoft Exchange - Funktionen und

technischer Überblick. 2006

[RIM06b] RIM. BlackBerry Enterprise Solution - Sicherheit. www.blackberry.com.2006

[RIM06c] RIM. BlackBerry MDS Studio - Feature and Technical Overview. 2006

[SA03] SAP-AG. SAP Schulungsunterlagen, SAP01 SAP-Überblick. 2003

[Sch04] SCHMATZ, Klaus-Dieter: Java 2 Micro Edition - Entwicklung mobiler An-

wendungen mit CLDC und MIDP. dpunkt.verlag, 2004

[Sch05] SCHMIDT, Michael. Der Pusher - Blackberries Sicherheits-Architektur.http://www.heise.de/security/artikel/64996. 2005

[SO04] STUMPE, Jens ; ORB, Joachim: SAP Exchange Infrastructure. Galileo PressGmbH, 2004

[Tai03] TAIVALSAARI, Antero. JSR 139: Connected Limited Device Configuration

1.1. http://jcp.org/en/jsr/detail?id=139. 2003

[W3C00] W3C. Simple Object Access Protocol (SOAP) 1.1. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/. 2000

[W3C01] W3C. Web Services Description Language (WSDL) 1.1. http://www.

w3.org/TR/2001/NOTE-wsdl-20010315. 2001

[W3C06] W3C. Web Services Description Language (WSDL) 2.0. http://www.

w3.org/TR/2006/CR-wsdl20-20060327. 2006

[Win99] WINER, Dave. XML-RPC. http://www.xmlrpc.com/spec. 1999

[Yua06] YUAN, Michael J.: Enterprise J2ME: Developing Mobile Java Applications.Prentice Hall Ptr, 2006

122

Page 137: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Anhang A

Abkürzungen

A

AMS Application Management Software.

B

BB BlackBerry.

BES BlackBerry Enterprise Server.

BO Business Object.

BPEL Business Process Execution Language.

C

CA Certification Authority.

CDC Connected Device Configuration.

CIM Common Information Model.

CLDC Connected Limited Device Configuration.

CRM Customer Relationship Management.

123

Page 138: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Anhang A. Abkürzungen

D

DA Discovery Application.

DOM Document Object Model.

E

EAI Enterprise Application Integration.

J

J2SE Java 2 Standard Edition.

JAD Java Application Descriptor.

JAR Java Archive.

JAX-RPC Java API for XML-based RPC.

JAXP Java API for XML Processing.

JCP Java Community Process.

JDE Java Development Environment.

JSR Java Specification Request.

JVM Java Virtual Machine.

JWS Java Web Start.

K

KVM Kilo Virtual Machine.

L

LBS Location Based Services.

LCDUI Lowest Common Denominator User Interface.

LOC Lines Of Code.

124

Page 139: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Anhang A. Abkürzungen

M

MDS Mobile Data System.

MEP Message Exchange Pattern.

MIDP Mobile Information Device Profile.

MOM Message-oriented Middleware.

MVC Pattern Model View Controller Pattern.

O

OTA Over The Air.

P

PIM Personal Information Management.

PLM Product Lifecycle Management.

R

REST REpresentational State Transfer.

RI Referenz Implementierung.

RIM Research in Motion.

RMS Record Management System.

S

SAP MI SAP Mobile Infrastructure.

SAP XI SAP Exchange Infrastructure.

SAX Simple API for XML.

SCM Supply Chain Management.

125

Page 140: Design und Implementierung einer mobilen, Workflow ... · orientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch der eingebundenen Fremdsysteme. Dadurch

Anhang A. Abkürzungen

SLD System Landscape Directory.

SOA Service-orientierte Architektur.

SOAP Simple Object Access Protocol.

SPI Service Provider Interface.

SRM Supplier Relationship Management.

W

W3C World Wide Web Consortium.

WSDL Web Service Description Language.

WTK Wireless Toolkit.

126