Hochschule Bonn Rhein Sieg University of Applied Sciences Fachbereich Informatik Department of Computer Science. Master Thesis

Größe: px
Ab Seite anzeigen:

Download "Hochschule Bonn Rhein Sieg University of Applied Sciences Fachbereich Informatik Department of Computer Science. Master Thesis"

Transkript

1 Hochschule Bonn Rhein Sieg University of Applied Sciences Fachbereich Informatik Department of Computer Science Master Thesis im Studiengang Master of Science in Computer Science Konzeption und Implementierung eines mobilen Clients für das Workflow Management System YAWL von Erstbetreuer: Prof. Dr. Andreas Hense Zweitbetreuer: Prof. Dr. Simone Bürsner eingereicht am: 16. September 2011

2 Thema der Arbeit Konzeption und Implementierung eines mobilen Clients für das Workflow Management System YAWL Kurzzusammenfassung Die zunehmende Mobilität der Mitarbeiter und der steigende Kostendruck nährt in Unternehmen den Bedarf einer Integration mobiler Endgeräte in das Geschäftsprozess Management. Ein vergrößertes Tätigkeitsspektrum kann hierdurch in Form IT gestützter Workflows abgebildet werden und entkoppelt deren Ausführung von Ort und Zeit. Im Rahmen dieser Master Thesis wird die Konzeption und Implementierung eines mobilen Clients für das Workflow Management System YAWL vorgestellt. Sowohl die sich ergebenen Erweiterungsmöglichkeiten im Bereich des Workflow Managements werden untersucht als auch die Einschränkungen mobiler Endgeräte berücksichtigt. Die Entwicklung eines Synchronisierungsmechanismus sorgt für den erforderlichen Abgleich lokaler und entfernter Workflow Daten und stellt eine grundlegende Offline Funktionalität sicher. Die Einbeziehung moderner Eingabemethoden, die sich aus dem Funktionsumfang mobiler Endgeräte ergeben, werden im Kontext des Workflow Managements erörtert und praktisch umgesetzt. Des Weiteren wird ein Konzept zur Definition ortsgebundener Prozesstätigkeiten präsentiert und exemplarisch realisiert. Auf der Basis von Standortinformationen kann hierdurch eine optimale Reihenfolge mobil auszuführender Aufgaben ermittelt werden. Stichworte Geschäftsprozess, Geschäftsprozess Management, Workflow, Workflow Management, Workflow Management System, YAWL, Android, Mobile Computing, Mobile Applikation, Kontextsensitivität, Mobilität, Mobile Eingabemethoden, Barcode, QR-Code, Digitale Unterschrift, Ortsgebundene Dienste, Serviceorientierte Architektur, REST, User Interface Design, XML Schema ii

3 Eidesstattliche Erklärung Ich versichere an Eides statt, die von mir vorgelegte Arbeit selbstständig verfasst zu haben. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder nicht veröffentlichten Arbeiten anderer entnommen sind, habe ich als entnommen kenntlich gemacht. Sämtliche Quellen und Hilfsmittel, die ich für die Arbeit benutzt habe, sind angegeben. Die Arbeit hat mit gleichem Inhalt bzw. in wesentlichen Teilen noch keiner anderen Prüfungsbehörde vorgelegen. (Datum, Ort, Unterschrift)

4 Inhaltsverzeichnis 1 Einleitung Motivation Ziele der Arbeit Aufbau der Arbeit Grundlagen Geschäftsprozess Management Vom Geschäftsprozess zum Workflow Workflow Management Exemplarischer Geschäftsprozess Workflow Management mit YAWL Konzepte der Workflow Modellierung Exemplarischer Geschäftsprozess als YAWL Workflow Das Workflow Management System YAWL Charakteristiken mobiler Umgebungen Mobile Computing Eigenschaften mobiler Endgeräte Context Awareness Die mobile Plattform Android Aufbau und relevante Komponenten Eigenschaften der Laufzeitumgebung Der Anwendungsrahmen Relevante Technologien XML Schema Serviceorientierte Architekturen Representational State Transfer Verwandte Arbeiten Stand der Technik Konzeption Analyse Potentiale mobiler Workflows Anforderungen an den mobilen Client: YAC Gliederung des Konzepts und Vorgehensmodell Block 1: Integration des mobilen Clients in die YAWL Infrastruktur Entwicklung der Gesamtarchitektur Synchronisation von Work Items Arbeitsmodi für den Datenabgleich Datenmodell und Konvertierungsprozess Transformation eines XML Schemas in eine Android View Block 2: Mobile Eingabemethoden Kameranutzung Barcode Scanning Berührungssensitive Eingabe: Digitale Unterschrift

5 3.3.4 Suchfunktion Codes als Suchbegriff Block 3: Ortsgebundene Prozesstätigkeiten Block 4: Interne Architektur Block 5: Entwurf der Benutzeroberflächen Der Startbildschirm Synchronisierungsoberfläche Verwaltung der Work Queues Work Item: Datenbearbeitung Suchfunktion & QR Codes Ortsgebundenes Workflow Management Navigationsübersicht Umsetzung Verwendete Bibliotheken Anwendungseinstellungen Layout Wechsel nach Änderung der Geräteorientierung Implementierung eines Services für die Kommunikation mit YAWL Datenbankzugriff mit ORMLite Listenansichten und Adapter Automatisierte Intent Aktionen XML (De )Serialisierung Dynamisches Hinzufügen und Löschen von Datenparametern Nutzung des Barcode Scanners Kamerafunktion: Konvertierung von Fotos Touchscreen Unterschrift Implementierung einer Liste für ortsgebundene Work Items Kartenansicht für ein einzelnes Work Item Parameterübergabe an ein Navigationssystem Umsetzung einer interaktiven Kartenansicht für alle Work Items Ergebnisse Zusammenfassung Exemplarischer Geschäftsprozess als mobiler Workflow Probleme & Ausblick Fazit Literaturverzeichnis 98 Abbildungsverzeichnis 103 Tabellenverzeichnis 105 A Exemplarische Nutzungsszenarien 106 B YAC Screenshots 110 C Informationen zur beiliegenden CD 114 D Installationsanleitung 115 Inhaltsverzeichnis v

6 1 Einleitung 1.1 Motivation Unternehmen sind stetig steigenden Anforderungen an Zeit, Qualität, Kosten und Flexibilität ausgesetzt [Schmelzer und Sesselmann, S. 2]. Um diesen Herausforderungen erfolgreich entgegenzutreten, hat sich das Geschäftsprozess Management als etabliertes Konzept bewährt [Gadatsch, 2009, S. 1]. Es versetzt Unternehmen in die Lage, die eigene Wertschöpfungskette zu optimieren und flexibel auf wechselnde Anforderungen reagieren zu können. Ein essentielles Mittel zur Erreichung dieser Ziele ist der Einsatz eines Workflow Management Systems (WfMS), welches auf der operativen Ebene für die informationstechnische Unterstützung von Prozessen in Form von so genannten Workflows sorgt. Die Ziele, die hierdurch verfolgt werden, sind unter anderem Durchlaufzeiten von Prozessen zu verringern, Transparenz und Qualität zu erhöhen sowie schlussendlich Kosten zu reduzieren. Workflows im oben genannten Sinne sind an eine informationstechnische Verarbeitung gebunden. Im Workflow Management ist man daher stets auf IT-Systeme angewiesen, um Prozesse zur Ausführung zu bringen. Bestimmte Prozesse können daher nur begrenzt in einen Workflow überführt und als solcher rechnergestützt abgehandelt werden, weil sie beispielsweise durch einen hohen Mobilitätsfaktor geprägt sind, der sich mit stationärer Hardware nicht adäquat unterstützen lässt. Die Integration eines mobilen Clients in ein Workflow Management System wirkt dieser Problematik entgegen und verbreitert das Einsatzspektrum um mobile Prozesstätigkeiten jeglicher Art. Durch den Einsatz von Smartphones oder Tablet Computern lassen sich Workflows unabhängig von Ort und Zeit bearbeiten. Essentiell ist hierfür jedoch die Verfügbarkeit einer Software, welche den Restriktionen mobiler Endgeräte Rechnung trägt. Ein zentraler Aspekt im Workflow Management (WfM) ist die Verringerung von Medienbrüchen. Hiermit ist die Datenübertragung von einem informationstragenden Medium in ein anderes gemeint [Feldbrügge und Brecht-Hadraschek, 2008, S. 45]. In einem optimalen Fall werden Medienbrüche durch die Verwendung eines Workflow Management Systems komplett vermieden, indem eine zentrale Datenhaltung zur Verfügung gestellt ist, über die alle Arbeitsprozesse IT gestützt abgehandelt werden. Die Unternehmenspraxis zeigt hier in der Regel ein anderes Bild. An diesem Punkt eröffnet nun das mobile Workflow Management weitere Potentiale. Nicht stationäre Tätigkeiten eines Arbeitsablaufs könnten mit Hilfe eines Smartphones oder Tablet PCs ausgeführt und ohne Umwege direkt online abgeglichen werden. Dies sorgt zum Einen dafür, dass Medienbrüche vermieden werden und steigert zum Anderen die Effizienz der Prozessdurchführung. Die Integration eines mobilen Clients in ein Workflow Management System eröffnet neben dem Faktor Mobilität weitere neuartige Potentiale, welche sich aus dem Funktionsumfang aktueller mobiler Endgeräte ergeben. Es besteht die Möglichkeit auf moderne Eingabemethoden zurückzugreifen, die sich durch stationäre Hardware

7 nicht adäquat einsetzen lassen. Hier ist beispielsweise die integrierte Kamerafunktion zur Aufnahme von Fotos, das Einscannen von Barcodes und QR Codes ( Quick Response ) oder die Nutzung des Touchscreens als Zeichenunterlage zu nennen. Gänzlich neue Perspektiven im Workflow Management ergeben sich in Bezug auf die Einbeziehung und Verarbeitung standortbezogener Informationen. So können beispielsweise spezielle lokale Arbeitsschritte in einem Workflow Management System als ortsgebunden kenntlich gemacht und dann von demjenigen Prozessbeteiligten ausgeführt werden, dessen Entfernung zur angegebenen Position am geringsten ist. Die Möglichkeiten, die sich durch die Nutzung geographischer Dienste im Workflow Management ergeben, sind weitreichend, von großem wirtschaftlichen Interesse und aktuell ein viel diskutierter Forschungsgegenstand. Am Markt hat sich allerdings bisher keine Software durchgesetzt, welche einen ganzheitlichen Ansatz aufweist und ein breites Spektrum im mobilen Workflow Management abdeckt. Unter dem Akronym YAWL existiert ein Open Source Projekt, welches ein komplettes Workflow Management System vorantreibt und zur freien Verfügung stellt. Die Funktionalitäten des YAWL Frameworks reichen von der Workflow Modellierung, über die Steuerung und Ausführung von Workflows bis hin zur Prozessüberwachung. Das System ist jedoch vollständig auf die Benutzung stationärer Desktop Computer zugeschnitten und bietet derzeit keinen Ansatz, welcher die speziellen Anforderungen mobiler Endgeräte berücksichtigt. Der von YAWL verfolgte Architekturstil ist serviceorientiert und eignet sich daher über die bereitgestellten Schnittstellen ideal zur Erweiterung. Auf diese Weise lassen sich auch mobil bestimmte Dienste nutzen, welche die Ausführung von einzelnen Arbeitsschritten als Teil eines Geschäftsprozesses sowie breit gefächerte Workflows auf mobilen Endgeräten unterstützen. Das Betriebssystem Android hat sich in der jüngeren Vergangenheit als Plattform für Mobiltelefone und Tablet PCs etabliert. Dies zeigen die stetig steigenden Marktanteile [Gartner, 2011]. Der offen zugängliche Quellcode sowie das bereitgestellte und gut dokumentierte Software Development Kit (SDK) sorgen für eine gute Zugänglichkeit. Applikationen müssen nicht mehr an konkrete mobile Hardware angepasst werden, sondern werden für die Android Plattform entwickelt, welche die Sicherstellung der Lauffähigkeit übernimmt und für eine Hardware übergreifende Kompatibilität sorgt. Anwendungen lassen sich deshalb auf einer Vielzahl unterschiedlicher Geräte ausführen, was eine universelle Einsetzbarkeit zur Folge hat und dadurch einen breiteren Markt erschließt. 1.2 Ziele der Arbeit Ziel der Arbeit ist die Konzeption und Umsetzung einer mobilen Anwendung auf Basis der Android Plattform, welche sich bestmöglich in die Gesamtarchitektur des YAWL Workflow Management Systems integriert und es möglich macht Workflows mit mobilen Client auszuführen sowie mit einem zentralen YAWL System abzugleichen. Hierbei werden sowohl die besonderen Anforderungen mobiler Endgeräte Berücksichtigung finden, als auch diverse Erweiterungsmöglichkeiten analysiert und umgesetzt. Auf der Seite der Beschränkungen sind zum Einen die Bandbreitenlimitierung mobiler Datennetze sowie die nicht garantierte Netzverfügbarkeit zu nennen. Diesem Problem wird mit einem speziellen Synchronisierungsmechanismus entgegengewirkt, welcher die Offline Funktionalität sicherstellt. 1 Einleitung 2

8 Zum Anderen wird im Rahmen der Konzeption ein Bedienungskonzept entwickelt, welches die Einschränkungen hinsichtlich der Dateneingabe und Datenausgabe mobiler Endgeräte berücksichtigt. Cl Carrier Notificati ea on r Notification Title 1 notification Header description Notification Title 2 notification description Notification notification Notificati Title 3 description on Notification Title 1 notification Header description Abbildung 1.1: Integration von mobilen Endgeräten auf Basis der Android Plattform in generische YAWL Workflows Um die Kopplung der Anwendung mit dem YAWL System zu erreichen, muss zunächst ermittelt werden, welche Service Schnittstellen die Architektur bereithält und wie diese genutzt werden können. Falls die angebotenen Interfaces nicht mit den Anforderungen mobiler Kommunikation vereinbar sind, ist die Entwicklung einer YAWL Erweiterung von Nöten. Abbildung 1.1 zeigt veranschaulichend die im Rahmen der vorliegenden Arbeit zu erreichende nahtlose Integration von mobilen Endgeräten auf Basis der Android Plattform in YAWL Workflows. Ein mobiler Workflow Client eröffnet weitreichende Möglichkeiten, die im Rahmen der vorliegenden Arbeit diskutiert und implementiert werden. Hierzu werden spezielle Anwendungsfälle erarbeitet, welche sich die Funktionen mobiler Endgeräte zu Nutze machen. Dies ist die Einbeziehung der in der Regel vorhandenen Kamera in den Kontext eines Arbeitsprozesses. Die Kamera kann genutzt werden, um Dokumentation auf Basis von Fotos zu betreiben oder um spezielle Barcodes oder QR Codes einzuscannen und zur Verarbeitung weiterzureichen. Des Weiteren wird der Nutzen und die Realisierbarkeit eines Ortskonzepts unter Nutzung geographischer Informationen betrachtet. Hier gilt es zu erörtern, welche Mehrwerte erzielt werden können, wenn spezielle Arbeitsschritte mit einer örtlichen Beschränkung versehen sind und diese in Relation zum eigenen Standort gesetzt werden kann. 1.3 Aufbau der Arbeit Die vorliegende Arbeit gliedert sich in fünf aufeinander aufbauende Kapitel. Nach der Einführung in die Thematik wird im anschließenden Kapitel 2 das für das Verständnis der Arbeit benötigte fachliche und technische Wissen vermittelt. Dieses befasst sich neben Begriffsdefinitionen mit einer Einführung in das Geschäftsprozess Management. Ein konstruierter Arbeitsablauf sorgt für eine praktische Zugänglichkeit und stellt die Zusammenhänge exemplarisch dar. Aufbauend wird das Workflow 1 Einleitung 3

9 Management mit YAWL thematisiert. Im Anschluss wird das zweite große Themengebiet eingeführt. Hierfür werden zunächst mobile Umgebungen charakterisiert und Android als mobile Plattform analysiert. Die zuvor ermittelten Eigenschaften sowie die relevanten Technologien stellen die Basis für die Konzeption dar. Zur Abrundung des Kapitels wird eine Abgrenzung zu thematisch naheliegenden, wissenschaftlichen Veröffentlichungen vorgenommen. Eine kurze Marktübersicht betrachtet bereits verfügbare mobile Workflow Management Lösungen und zeigt deren Grenzen auf. Kapitel 3 beginnt mit einer Analyse der Potentiale, die sich durch mobile Workflows eröffnen und leitet Faktoren ab, die sich in besonderem Maße durch den Einsatz mobiler Endgeräte umsetzen lassen. Die hier erzielten Erkenntnisse sind der Ausgangspunkt für die Anforderungsbestimmung des mobilen Clients. Die folgende Konzeption basiert auf den ermittelten Potentialen und setzt sich aus fünf übergeordneten Blöcken zusammen. Diese sind im Einzelnen: 1. Integration des mobilen Clients in die YAWL-Infrastruktur 2. Mobile Eingabemethoden 3. Ortsgebundene Prozesstätigkeiten 4. Interne Architektur 5. Entwurf der Benutzeroberflächen Um eine Basis für mobile Workflows zu schaffen, muss zunächst die Integration des mobilen Clients in die YAWL-Infrastruktur konzipiert werden. Aufbauend lässt sich das Workflow Management um mobile Eingabemethoden und ortsgebundene Prozesstätigkeiten erweitern. Die bis zu diesem Zeitpunkt erarbeiteten Ergebnisse der Konzeption münden in der Entwicklung einer internen Architektur und sind die Grundlage für den Entwurf der benötigten Benutzerschnittstellen. Das resultierende Konzept findet dann in Kapitel 4 eine praktische Umsetzung. Im Rahmen dieses Abschnitts werden Besonderheiten der technischen Implementierung auf Basis vereinzelter Quellcodeausschnitte beschrieben. Gewählte Lösungsansätze werden basierend auf ihren technischen Details erläutert und begründet. Das abschließende Kapitel 5 befasst sich mit den erzielten Resultaten. Die Arbeit wird zusammengefasst und die erarbeiteten Ergebnisse werden auf Basis des in den Grundlagen beschriebenen, exemplarischen Geschäftsprozesses verdeutlicht. Hiernach wird die Arbeit hinsichtlich bestehender Probleme bewertet und ein Ausblick in Richtung aufbauender Zielsetzungen gegeben. Die Arbeit endet mit einem resümierenden Fazit. 1 Einleitung 4

10 2 Grundlagen Im Rahmen dieses Kapitels werden relevante Themengebiete grundlegend eingeführt. Begonnen wird mit fachlichen Definitionen des Geschäftsprozess Managements, welche anhand eines exemplarischen Arbeitsablaufes veranschaulicht werden. Aufbauend wird das Workflow Management mit YAWL charakterisiert. Hiernach werden die wesentlichen Eigenschaften mobiler Umgebungen erarbeitet, welche in den Erläuterungen zur Plattform Android konkretisiert werden. Ein kurze Besprechung wichtiger Technologien, stellt ein allgemeines Verständnis der behandelten Themengebiete sicher. Das Kapitel wird abschließen mit einer Abgrenzung zu verwandten wissenschaftlichen Arbeiten und verfügbaren Softwareprodukten aus der gleichen Domäne. 2.1 Geschäftsprozess Management Sowohl das Geschäftsprozess Management als auch das Workflow Management stehen im Kontext des Prozess Managements, einem integrierenden Konzept, welches einen Abgleich von Unternehmensstrategie, der organisatorischen Prozessgestaltung und deren technischer Umsetzung mit Kommunikations und Informationssystemen vornimmt [Gadatsch, 2009, S. 1]. Das Geschäftsprozess Management, der deutschen Bezeichnung für Business Process Management (BPM), übernimmt hierbei das Bindeglied zwischen der Unternehmensorganisation und der informationstechnischen Modellierung sowie der Ausführung im Rahmen des Workflow Managements. Abbildung 2.1 veranschaulicht diese Zusammenhänge. Unternehmensorganisation Strategisches Prozessmanagement Prozessanalyse Prozessorganisation Prozessmodellierung Prozessoptimierung Geschäftsprozess-Management Steuerung / Business Rules EAI / SOA Monitoring / Reporting Human Workflow Mangement Informationstechnologie Abbildung 2.1: Geschäftsprozess Management: Bindeglied zwischen organisatorischer und IT Perspektive, [Quelle: Freund und Götzer, 2008, S. 3]

11 YAWL ist als Workflow Management System auf der operativen Ebene anzusiedeln und übernimmt dort eine Unterstützungsfunktion für das Geschäftsprozess Management. Die Begriffe Geschäftsprozess und Workflow liegen eng beieinander und werden im Folgenden getrennt voneinander erläutert. Eine knappe Gegenüberstellung stellt die korrekte Abgrenzung beider Definitionen sicher Vom Geschäftsprozess zum Workflow Geschäftsprozesse Geschäftsprozesse ziehen sich durch alle Bereiche unternehmerischen Handelns, dienen der Wertschöpfung und sind geprägt von der Unternehmensstrategie und motiviert durch die Unternehmensphilosophie [Hartmann, 2002, S. 128]. Gadatsch [2009, S. 41] liefert folgende Definition: Ein Geschäftsprozess beschreibt eine zielgerichtete, zeitlich logische Abfolge von Aufgaben, die arbeitsteilig von mehreren Organisationen oder Organisationseinheiten unter Nutzung von Informations und Kommunikationstechnologie ausgeführt werden können. Ein Geschäftsprozess wird initiiert durch ein Ereignis, sein Ablauf wird beeinflusst über Eingabeparameter ( Inputs ) sowie externe oder interne Ereignisse [Müller, 2005, S. 7]. Die resultierenden Ergebnisse ( Outputs ) sind entweder Produkte oder Dienstleistungen für einen Kunden [Schmelzer und Sesselmann, S. 63]. Ein Beispiel für einen Geschäftsprozess ist die Aufnahme eines Kredits in einer Bank oder die Entwicklung einer Anwendung in einem IT Unternehmen Workflows Der Erfolg eines Unternehmens hängt maßgeblich von der Effizienz seiner Geschäftsprozesse ab. In der Praxis wird daher versucht, möglichst viele Prozessschritte zu automatisieren [Hagen und Stucky, 2004, S. 27f]. An dieser Stelle erhält der Begriff des Workflows seine Relevanz. Ein Workflow ist demnach ein komplett oder teilweise automatisierter, rechnergestützter Teil eines Geschäftsprozesses [Hollingsworth, 1995, S. 6]. Der Workflow übernimmt die automatische Steuerung des Arbeitsablaufs auf operativer Ebene und übergibt die zu erledigenden Tätigkeiten an zuständige Mitarbeiter oder Anwendungsprogramme [Gadatsch, 2009, S. 47]. Zu unterscheiden ist die formale Beschreibung des Arbeitsablaufs durch eine Workflow Sprache, wie beispielsweise Business Process Modelling Notation (BPMN) oder YAWL und der konkreten Ausführung eines Modells in Form einer Workflow Instanz. Der Einsatz von Workflows eignet sich besonders für Prozesse die stets nach einem ähnlichen Schema ablaufen und häufig in einem Unternehmen durchgeführt werden. Workflows werden beispielsweise oft zur Erfassung von Kundendaten oder der Abrechnung von Reisekosten eingesetzt Abgrenzung: Geschäftsprozess und Workflow Wie aus den vorangegangenen Definitionen ersichtlich wird, befassen sich sowohl Geschäftsprozesse als auch Workflows mit der Beschreibung von Arbeitsabläufen. Hierbei beschreiben Geschäftsprozesse auf unternehmensstrategischer Ebene, was zu tun ist. Workflows sind auf operativer Ebene angesiedelt und legen fest wie ein 2 Grundlagen 6

12 Arbeitsablauf auf Basis von Informationstechnologie umzusetzen ist. Die Abgrenzung zwischen Geschäftsprozessen und Workflows ist aufgrund des gleichen Untersuchungsgegenstands teilweise schwierig und kann nicht immer eindeutig bestimmt werden [Gadatsch, 2009, S. 52f]. Tabelle 2.1 zeigt die wesentlichen Unterschiede hinsichtlich der Kriterien Ziel und Gestaltungsebene. Ziel Gestaltungs ebene Geschäftsprozess Analyse und Gestaltung im Sinne gegebener strategischer Ziele Konzeptionelle Ebene mit Verbindung zur Geschäftsstrategie Workflow Spezifikation der technischen Ausführung von Arbeitsabläufen Operative Ebene mit Verbindung zu unterstützender Technologie Tabelle 2.1: Abgrenzung zwischen Geschäftsprozess und Workflow [Siehe Gadatsch, 2009, S. 53] Workflow Management Das Workflow Management beschäftigt sich mit einem breiten Spektrum an Tätigkeiten, welche sich im Weiteren Sinne mit Workflows beschäftigen. Hierzu zählt die Analyse, Modellierung, Simulation, Ausführung, Steuerung und Überwachung von Workflows [Müller, 2005, S. 10f]. Das Workflow Management steht in enger Verbindung mit den Konzepten des Workgroup Computings sowie der Computer Supported Cooperative Work (CSCW). Die Meinungsbildung über die Ziele des Workflow Managements sind laut Gadatsch [2009, S. 54ff] uneinheitlich und gehen teilweise auseinander. Im Folgenden werden daher lediglich die übereinstimmenden Ziele stichpunktartig aufgeführt: Verbesserung der Kundenzufriedenheit (Kundenservice) Verbesserung der Prozessqualität Steigerung der Prozesstransparenz Verkürzung der Durchlaufzeiten Automatisierung der Prozesssteuerung Workflow Management Systeme sind IT Werkzeuge, meist in Form komplexer Softwareprogramme, die das Workflow Management ermöglichen. Diese lassen sich in zwei Bestandteile gliedern: Einer Modellierungskomponente, um Workflows zu generieren und diese visuell darzustellen, sowie einer Ausführungskomponente, um die Prozesssteuerung und deren Überwachung zu gewährleisten [Eggert, 2007, S. 56f]. Die Workflow Management Coalition (WfMC), ein Zusammenschluss verschiedener Universitäten, Institute und Unternehmen, hat ein Referenzmodell veröffentlicht, welches die Bestandteile und Zuständigkeiten eines Workflow Management Systems beschreiben [Hollingsworth, 1995]. Dieses Modell wird in Kapitel 2.2 genauer thematisiert, da die Implementierung der YAWL Architektur in leichter Abwandlung den Vorschlägen der WfMC folgt. 2 Grundlagen 7

13 2.1.3 Exemplarischer Geschäftsprozess Um die in den vorangegangenen Abschnitten beschriebe Thematik des Geschäftsprozess Managements konkreter zu machen, wird im Folgenden ein beispielhafter Arbeitsablauf eingeführt, welcher die Konzepte in einen praktischen Zusammenhang setzt. Das hier beschriebene Beispiel dient im späteren Verlauf der vorliegenden Arbeit dazu, das Spektrum der geschaffenen Möglichkeiten aufzuzeigen, welche durch die Integration mobiler Endgeräte in das Workflow Management entstehen. Start Transportinformation aufnehmen Auftrag bestätigen Schwertransport? nein Mit PKW abholen Lieferung zustellen Ende ja Mit LKW abholen stationär mobil Abbildung 2.2: Beispielhafter Geschäftsprozess aus der Logistikbranche: Abhol und Zustelldienstleitung Abbildung 2.2 zeigt einen beispielhaften Geschäftsprozess, der in Form eines Flussdiagramms dargestellt ist. Der Einfachheit halber wird für die Darstellung auf einen speziellen Beschreibungsstandard verzichtet. Veranschaulicht werden die erforderlichen Arbeitsschritte der Bearbeitung und deren Zusammenhänge. Der Prozess ist einfach und modellhaft gehalten, um die später erläuterten Potentiale mobiler Erweiterungen auf möglichst verständliche Art verdeutlichen zu können. Das Beispiel entstammt als fiktiver Arbeitsablauf aus der Logistikbranche und beschreibt eine Abhol und Zustelldienstleitung. Der Prozess wird von einem Mitarbeiter des ausführenden Unternehmens gestartet und beginnt mit der Aufnahme der Transportinformationen. Hierzu übermittelt der Kunde einem Call Center Mitarbeiter via Telefon den Auftrag. Dieser überführt die Informationen in die zentrale Datenhaltung des Unternehmens und bestätigt dem Kunden den entgegengenommenen Auftrag, beispielsweise in Form einer E Mail. Im Rahmen dieser Tätigkeit wird ein Fahrer bestimmt, der den Transport übernehmen wird. Je nach Größe und Gewicht der Fracht, die bei der Auftragsübermittlung angegeben wurde, wird die Lieferung entweder mit einem PKW oder einem LKW durchgeführt. Der Fahrer steuert den angegebenen Abholstandort der Fracht an und nimmt dort die erforderlichen Zustellinformationen vom Kunden über ein Papierformular entgegen. Nachdem die Lieferung abgeholt ist, kann der Fahrer mit der Zustellung beginnen. Am Zielort bestätigt der Empfänger die ordnungsgemäße Übergabe der Fracht, indem er einen Lieferschein quittiert. Hiermit endet der Prozess erfolgreich. An diesem Arbeitsablauf werden einige charakteristische Merkmale deutlich, die sowohl Geschäftsprozesse als auch Workflows gemeinsam haben. Der Zweck des Prozesses ist die Leistungserbringung für einen Kunden, an der verschiedene Mitarbeiter des Unternehmens beteiligt sein können. Der genaue Arbeitsfluss ist hierbei nicht vorbestimmt, sondern entscheidet sich dynamisch aufgrund vorherrschender Bedingungen während der Ausführung. 2 Grundlagen 8

14 Neben den Gemeinsamkeiten lässt sich an dem gewählten Beispiel auch die Abgrenzung eines Geschäftsprozesses zum Workflow verdeutlichen. Die ersten Arbeitsschritte, begonnen mit der Auftragsannahme über die Bestätigung bis zur Bestimmung des Fahrers sowie dessen Fahrzeug, finden stationär an einem Ort statt. Diese Tätigkeiten lassen sich ohne Weiteres in Form eines Workflows abbilden und IT gestützt ausführen. Die hierauf folgenden Arbeitsschritte müssen vom Fahrer vor Ort beim Kunden sowie beim Empfänger durchgeführt werden. Durch diese mobilen Tätigkeiten wird eine Workflow Ausführung mit stationärer Hardware impraktikabel. Zwar könnte der Fahrer, nach erfolgter Zustellung, die während der Lieferung generierten Dokumente digitalisieren. Hierbei käme es zu einem unerwünschten Medienbruch, der die Durchlaufzeit des Prozesses anstatt zu verkürzen, sogar verlängern würde. In einem solchen Fall würde sich ein IT-gestützter Workflow kontraproduktiv auswirken. Um das Workflow Management auch dort realisieren zu können, wo Prozesse durch einen hohen Mobilitätsfaktor geprägt sind, erarbeitet die vorliegende Arbeit ein praktisches Konzept, welches das Workflow Management System YAWL um einen mobilen Client erweitert. Unter Zuhilfenahme mobiler Endgeräte wird es möglich auch nicht stationäre Tätigkeiten in Workflows auf zielgerichtete Weise einzubinden und dadurch fortwährend von den positiven Eigenschaften des Workflow Managements zu profitieren. Im weiteren Verlauf dieser Arbeit werden Lösungsansätze vorgestellt, die über die Einbeziehung des Faktors Mobilität in das Workflow Management hinausgehen und neuartige Methoden in diesen Kontext einbringen. Die hierdurch zu erzielenden Verbesserungen im Geschäftsprozess Management werden auf Basis des oben genannten Beispiels verdeutlicht. Die Ergebnisse werden in Kapitel 5.2 aufgegriffen und anhand einer erweiterten, mobilen Version des Arbeitsablaufs präzisiert. 2.2 Workflow Management mit YAWL Dieses Kapitel befasst sich mit YAWL als ganzheitlichen Ansatz des Workflow Managements. Hierbei ist es zunächst von Nöten die zugrundeliegende Sprache und deren Konzepte zu betrachten. Hierauf aufbauend wird die Zusammensetzung des YAWL Frameworks erläutert und die Eigenschaften für die Arbeit relevanter Services besprochen. Hierbei stehen besonders Ansatzpunkte zur Kopplung eines mobilen Clients im Vordergrund. YAWL ist ein Akronym und steht für Yet Another Workflow Language. Zunächst spezifiziert YAWL eine auf Petri Netzen basierende Prozessmodellierungssprache. Über die YAWL Foundation wird zudem ein Software Framework entwickelt, welches die formellen Ansätze in ein komplettes Workflow Management System umsetzt. YAWL grenzt sich von anderen meist kommerziellen und proprietären Workflow Management Systemen ab, da es als Open Source Projekt betrieben wird. Der Sourcecode wird unter der GNU Lesser General Public License (LGPL) veröffentlicht und kann damit kostenfrei genutzt sowie erweitert werden. 2 Grundlagen 9

15 YAWL ist dem Ursprung nach ein akademisches Projekt und wird in einer Partnerschaft durch die Eindhoven University of Technology sowie der Queensland University of Technology entwickelt. Das Projekt steht unter der Leitung von Prof. W.M.P van der Aalst und Prof. A.H.M. ter Hofstede. Die Arbeiten an YAWL starteten im Jahre Konzepte der Workflow Modellierung Bevor die Komponenten des YAWL Workflow Management Systems genauer betrachtet werden, sollen zunächst die wesentlichen Charakteristiken der Workflow Modellierungssprache genannt werden. Die zugrundeliegenden theoretischen Konzepte können nur ausschnittsweise erläutert werden. Ziel des Abschnitts soll es sein, ein Grundverständnis zu vermitteln, welches befähigt, YAWL Workflows zu lesen und die maßgebenden Eigenschaften des Prozessflusses nachzuvollziehen zu können. Die Sprache YAWL baut auf dem Konzept der Petri Netze auf, einem weit verbreiteten Konzept zur Modellierung und Analyse von Prozessen allgemeiner Art. Da Petri-Netze zur Workflow Modellierung bestimmte Limitationen aufweisen, sind Erweiterungen von Nöten [van der Aalst, 1998]. Das Resultat ist eine eigene Sprache, welche sich in ihrer Semantik an die Anforderungen zur Spezifikation von Workflows richtet [van der Aalst u. a., 2004]. Die zweite Basis der Sprache YAWL sind die so genannten Workflow Patterns [Workflow-Patterns-Initiative, 2010]. Inspiriert durch die in diesem Rahmen entwickelten Konzepte, flossen Erkenntnisse und Ziele direkt in die YAWL Entwicklung ein. Die Patterns befassen sich mit vier Workflow Perspektiven, welche in Gänze in YAWL umgesetzt sind. Die Perspektiven werden im Einzelnen wie folgt unterschieden: Kontrollfluss, Ressourcen, Daten und Ausnahmebehandlung. Kontrollfluss Die Control Flow Patterns beschreiben Konzepte zur Steuerung von Arbeitsschritten innerhalb eines Workflows [Hofstede u. a., 2009, S. 25]. Im Wesentlichen geht es dabei stets um das Ablaufverhalten innerhalb eines Prozesses. Um den Kontrollfluss zu beschreiben sieht YAWL eine festgelegte Terminologie vor. Abbildung 2.3 zeigt ausschnitthaft die wichtigsten Kontrollflusssymbole. Jeder YAWL Workflow beginnt mit einem Eingangszustand, endet mit einem Endzustand und besteht aus Arbeitsschritten. Es werden atomare Tasks als unteilbare Prozesseinheit und zusammengesetzte Tasks in Form von Sub Workflows unterschieden. Tasks im Allgemeinen werden über Kanten miteinander verbunden, so dass ein gerichteter Graph entsteht. Um komplexere Kontrollflüsse zu modellieren, stehen verschiedene Operatoren zur Verzweigung und Zusammenführung von Prozessbereichen zur Verfügung. Hierbei sorgen die Split Tasks für eine Aufteilung des Kontrollflusses. Es findet entweder eine Parallelisierung oder eine Verzweigung basierend auf einer Bedingung statt. Unterstützt werden die logischen Operatoren AND, OR und XOR. Selbiges gilt auch für das Zusammenführen von Prozessflüssen, den so genannten Join Tasks. Weiterführende Konzepte sind beispielsweise van der Aalst u. a. [2004] zu entnehmen. 2 Grundlagen 10

16 Eingangszustand Initaler Startpunkt Endzustand Abschließender Endpunkt Atomarer Task Unteilbare Einheit des Prozesses Zusammengesetzter Task Sub-Workflow AND-Split Task Start einer nebenläufigen Verzweigung AND-Join Task Taskausführung nach Beendigung aller eingehenden Verzweigungen XOR-Split Task Start einer exklusiven Verzweigung XOR-Join Task Taskausführung nach Beendigung der eingehenden Verzweigungen OR-Split Task Start einer oder mehrerer Verzweigungungen OR-Join Task Taskausführung wartet nur nach Bedarf Abbildung 2.3: YAWL Kontrollflusssymbole, [Quelle: Russell und ter Hofstede, 2009] Daten Die von YAWL umgesetzten Data Patterns beschreiben wie der Datenfluss innerhalb eines Workflows erfolgt. YAWL unterscheidet drei Arten der Sichtbarkeit von Variablen [Hofstede u. a., 2009, S. 64]. Für die vorliegende Arbeit sind hiervon lediglich Netz und Task Variablen von Relevanz. Netz Variablen repräsentieren alle Daten eines Workflows und haben eine globale Gültigkeit für den gesamten Prozess. Task Variablen gehören privat zu einem einzelnen Arbeitsschritt und sind nur lokal innerhalb dieses Tasks gültig. Das Konzept globaler Netz und lokaler Task Variablen bedingt einen Mechanismus, um Informationen zwischen den Variablentypen austauschen zu können. Hierzu kann jede Variable mit den Attributen Input, Output oder Input & Output belegt werden. Input Variablen werden entweder über eine Datenverknüpfung oder durch eine Benutzereingabe gefüllt. Im Gegensatz hierzu sorgt das Output Attribut für die Ausgabe eines Datums, um beispielsweise Informationen einer Task Variable in eine Netz Variable zu schreiben. Auf diese Weise können Informationen Task übergreifend verfügbar gemacht werden. Die hierfür notwendige Verknüpfung der Informationsstrukturen wird mittels XQuery ausgedrückt, einer Abfragesprache für XML Strukturen [W3C, 2011]. Ist eine Variable mit keinem der oben genannten Attribute belegt, ist sie local und damit nur im jeweiligen Kontext verfügbar. Ein Datenaustausch findet in diesem Fall nicht statt. Ressourcen Die von YAWL unterstützten Resource Patterns befassen sich mit der Zuweisung von Arbeitsschritten auf Benutzer oder Rollen. Ein breites Spektrum an Möglichkeiten zur Aufgabenverteilung ist dabei abgedeckt. Um die so genannte Routing Strategy umzusetzen, definiert YAWL ein Organisationsmodell bestehend aus Benutzern, Rollen, Positionen und Gruppen. Innerhalb dieser Strukturen können Aufgaben dynamisch verteilt und zugewiesen werden. Eine nähere Betrachtung dieses Organisationsmodell findet im Rahmen des Abschnitts statt. 2 Grundlagen 11

17 offer Offered: single resource start allocate Suspended suspend resume Created direct start allocate Allocated: single resource complete start Started fail Completed offer Offered: multiple resource allocate start Failed Abbildung 2.4: YAWL Lebenszyklus eines Work Items und mögliche Transitionen [Vgl. Hofstede u. a., 2009, S. 73] Neben dem Routing von Aufgaben deckt die Ressourcenperspektive als einen weiteren Aspekt die Interaktionsstrategie ab. Diese bestimmt auf welche Weise einem Benutzer oder einer Organisationseinheit eine Aufgabe angeboten wird und wie diese angenommen und ausgeführt wird. Jede Tätigkeit eines Workflows hat einen festgelegten Lebenszyklus. Abbildung 2.4 zeigt die Phasen eines Work Items sowie mögliche Transitionen. Im Weiteren Verlauf dieser Arbeit, müssen die jeweiligen Phasen durch einen mobilen Client abgebildet und unterstützt werden. Der Begriff des Work Items nimmt eine besondere Bedeutung für die vorliegende Arbeit ein und wird im Folgenden näher erläutert. YAWL Prozesse bestehen aus einer Anzahl zusammenhängender Tätigkeiten (Tasks). Diese werden im Rahmen der Workflow Modellierung definiert. Dies umfasst den Kontrollfluss, die Daten und Ressourcen. In der Laufzeitumgebung werden aus einem Task ein oder mehrere Work Items erzeugt. Ein Work Item ist demnach eine Instanz eines Tasks [Hofstede u. a., 2009, S. 262f]. Eine Analogie ist der Zusammenhang von Klasse und Objekt in der objektorientierten Programmierung. Der Lebenszyklus eines Work Items beginnt mit der Instanziierung (Created) und wird hieraufhin einem einzelnen Benutzer oder einer Benutzergruppe angeboten (Offered). Die offerierte Aufgabe wird angenommen (Allocated) und kann lediglich durch den zugewiesenen Benutzer ausgeführt werden. Das Work Item wird hieraufhin zur Bearbeitung gestartet (Started). In diesem Status kann die Aufgabe zwischenzeitlich pausiert (Suspended) oder abgebrochen (Failed) werden. Nach ordnungsgemäßer Bearbeitung endet der Lebenszyklus im Status Completed. Einzelne Phasen können im Rahmen dieses Zyklus auch übersprungen beziehungsweise durch das Laufzeitsystem automatisch festgelegt werden [Hofstede u. a., 2009, S. 73f]. Ausnahmebehandlung Eine weitere Gruppe von Patterns befasst sich mit der Ausnahmebehandlung zur Laufzeit eines Prozesses oder einer einzelnen Aufgabe. Die Exception Handling Pattern beschreiben Möglichkeiten zur Behandlung eines Fehlerfalls während des Lebenszyklus. Eine solche Ausnahme könnte beispielsweise eine nicht ausführbare Aufgabe, der Ablauf einer Deadline oder eine nicht verfügbare Ressource sein. 2 Grundlagen 12

18 Je nach Fehlerfall stehen verschiedene Lösungsmechanismen zur Verfügung. Eine genauere Betrachtung dieser Thematik beschreiben Russell und Hofstede [2006] in ihrem Artikel Exception Handling Patterns in Process Aware Information Systems Exemplarischer Geschäftsprozess als YAWL Workflow Die in den vorangegangenen Abschnitten erläuterten YAWL Sprachaspekte, werden an dieser Stelle anhand eines Beispiels zusammengeführt. Hierzu wird auf den in Kapitel thematisierten Geschäftsprozess zurückgegriffen. Der Prozess wird als Workflow in YAWL Notation abgebildet. Die spätere Ausführung kann IT-gestützt über das YAWL Framework erfolgen. Abbildung 2.5 zeigt den resultierenden YAWL Workflow eines Abhol und Zustelldienstes. Transportinformation aufnehmen Auftrag bestätigen Abholung und Lieferung dokumentieren Abbildung 2.5: Beispielhafter Arbeitsprozess als YAWL Workflow Bezug nehmend auf den abzubildenden Geschäftsprozess fällt auf, dass sich lediglich der stationäre Teil des Prozesses adäquat durch YAWL unterstützen lässt. Sowohl die Aufnahme der Transportinformation als auch die Bestätigung des Auftrags lässt sich jeweils als eigenständige Tätigkeit definieren und in einen Kontrollfluss einbetten. Beide Arbeitsschritte werden IT-gestützt durchgeführt. Hierbei haben die ausführenden Mitarbeiter Zugriff auf erforderliche Informationen, die mit dem jeweiligen Work Item verknüpft sind. Benötigte Kundendaten können direkt digital erfasst und weiterverarbeitet werden. Der mobile Teil des Geschäftsprozesses lässt sich durch YAWL nicht unterstützen, da die Fahrer unterwegs keinen Zugriff auf stationäre Rechner haben. Um den Workflow abzuschließen, ist es lediglich möglich, die vom Fahrer ausgeführten Tätigkeit zu dokumentieren, nachdem die Abholung und Zustellung erfolgt ist und der Fahrer im Depot über einen Rechner verfügen kann. Hier könnten beispielsweise Details des Lieferscheins digitalisiert werden. Während des Transports kann der Fahrer die Prozessschritte nicht unmittelbar mit dem Workflow Management System abgleichen. An dieser Stelle versucht nun die vorliegende Arbeit anzusetzen, indem durch einen mobilen YAWL Client die Kluft zwischen mobilen Tätigkeiten und einer elektronischen Workflow Ausführung überbrückt wird. Die Ergebnisse werden durch eine erweiterte Version des gerade besprochenen Workflows verdeutlicht. Hiermit beschäftigt sich Kapitel Grundlagen 13

19 2.2.3 Das Workflow Management System YAWL Architektur Das YAWL Workflow Management System implementiert eine Modellierungs und Ausführungsumgebung für Workflows, welche über die Sprache YAWL spezifiziert sind. Das gesamte Framework ist in Form einer serviceorientierten Architektur strukturiert. Funktionalitäten sind als YAWL Services entworfen und können über bereitgestellte Schnittstellen flexibel kombiniert und erweitert werden. Weiterführende Informationen zum Thema serviceorientierter Architekturen sind zu finden in Abschnitt Um das Kommunikationsmodell innerhalb der Architektur simpel, flexibel und Plattform neutral zu halten, setzt YAWL auf REST [van der Aalst u. a., 2004]. Alle Ressourcen können über eine URL adressiert und durch den Aufruf einer HTTP Methode gelesen oder verändert werden. Die REST Methodik wird in Kapitel detaillierter aufgegriffen. Die ausgetauschten Repräsentationen sind dabei auf XML beschränkt, um die Validität stets gegen das vordefinierte XML Schema (siehe Abschnitt 2.5.1) des Workflows prüfen zu können. Die Komponenten und Schnittstellen der YAWL Architektur basieren auf den Empfehlungen des Workflow Reference Models der WfMC [Hollingsworth, 1995]. Teilbereiche sind den Anforderungen des serviceorientierten Paradigmas angepasst. Die Kernelemente und die bereitgestellten Interfaces sind in Abbildung 2.6 abgebildet. Hierbei sind diejenigen Elemente der Architektur hervorgehoben, die eine Relevanz im Kontext der vorliegenden Arbeit einnehmen. Weitere Komponenten sind der Vollständigkeit halber gräulich angedeutet. YAWL Engine Persisted Data Interface A Interface B Interface X Interface E Process Designer Resource Service Web Service Invoker Worklet Service Process Repository Interface R Web- Services Rules Worklet Repository Other Worklist Handlers Resource Gateway Interface W Work Queue Gateway Admin Users Apps & Codelets Interface O Org Data Abbildung 2.6: Die YAWL Architektur [Basierend auf: YAWL-Foundation, 2010a] 2 Grundlagen 14

20 Die YAWL Core Services bestehen aus den vier Elementen YAWL Engine, Resource Service, Web Service Invoker und Worklet Service. Hinzu kommt noch der Process Designer, der als unverzichtbares Hilfsmittel für die Definition von Workflow Spezifikationen dient. Im Zentrum der Architektur steht die YAWL Engine. Sie übernimmt die Ablaufsteuerung der Workflow Instanzen und ist verantwortlich für das Datenmanagement inklusive der Persistenz. Der Resource Service sorgt im Wesentlichen für die Zuweisung von Aufgaben zu Personen oder Applikationen und stellt eine graphische Nutzungsschnittstelle zur Verfügung. Der Web Service Invoker ermöglicht die direkte Integration externer Web Services in einen YAWL Workflow. Der Worklet Service kann genutzt werden, um Workflows dynamisch zu deren Laufzeit aus so genannten Worklets zusammen zusetzen. Worklets sind meist kleine und simple Sub Prozesse und können sich zu einer komplexeren Prozessinstanz zusammenfügen lassen [Hofstede u. a., 2009, S. 215ff]. Der Aufbau der Architektur erlaubt die Erweiterung des Systems um zusätzliche Custom Services. Diese lassen sich an den bereitgestellten Schnittstellen andocken und können auf diese Weise den Funktionsumfang des Gesamtsystems vergrößern. Das YAWL Entwicklerteam bietet auch bereits einige solcher zusätzlichen Dienste an. Beispielsweise einen SMS oder E Mail Service. Die Entwicklung eigener Funktionalitäten erfolgt in Java. Die Services werden in der YAWL Laufzeitumgebung ausgeführt und können von der Engine und anderen Diensten angesprochen werden. Für die weitere Aufgabenstellung ist der Web Service Invoker und der Worklet Service nicht relevant. Auf eine detailliertere Betrachtung dieser Komponenten wird daher verzichtet. Die folgenden Abschnitte befassen sich mit einer eingehenderen Analyse, der YAWL Engine und des Resource Services. Dies schafft die Grundlage, für die spätere Erstellung eines Erweiterungskonzepts um mobile Clients. Eine knappe Vorstellung des YAWL Editors stellt die Zusammenhänge zwischen der Modellierungs und Ausführungsumgebung sicher und erhöht dadurch das Verständnis für das Gesamtkonzept und die Arbeitsweise mit YAWL Engine Das Herzstück des YAWL Frameworks ist die Engine. Sie übernimmt die Verantwortung für die Ausführung von Prozessinstanzen. Hierzu gehört die Instanziierung von Workflows. Ein gestarteter Workflow wird in der Laufzeitumgebung als Case bezeichnet. Die Engine behält während des gesamten Lebenszyklus die Kontrolle über den Prozess. Sie startet die erforderlichen Arbeitsschritte in Form der Work Items und sorgt für die Ablaufsteuerung und die Persistenz der Daten. Zu beachten ist, dass die Engine keine Erkenntnis über verfügbare Ressourcen hat. Die Engine beschränkt sich in Bezug auf die Perspektiven der Workflow Patterns auf den Kontrollfluss und die Daten. Die Verknüpfung der gestarteten Work Items mit erforderlichen Ressourcen ist den angeschlossenen Custom Services vorbehalten [Hofstede u. a., 2009, S. 241ff]. In der Regel übernimmt dies der Resource Service. Die Engine setzt sich aus differenzierten Zuständigkeiten zusammen, welche im Folgenden nur ausschnittsweise betrachtet werden. Im Zentrum steht die Koordination der gekoppelten Komponenten und die Verwaltung der Kommunikation über interne und externe Schnittstellen. Eine von der Engine betriebene Datenbank enthält alle 2 Grundlagen 15

21 verfügbaren Workflows, die zur Laufzeit instanziiert werden können. Des Weiteren werden die aktiven Prozesse von der Start bis zur Endbedingung gesteuert und vorangetrieben. Alle relevanten Daten und Objekte werden in einer relationalen Datenbank gespeichert. Zur Interaktion mit externen Services unterhält die Engine vier Interfaces (siehe Architekturschaubild 2.6). Jede Schnittstelle übernimmt eine festgelegte Zuständigkeit. Interface A stellt einen Endpunkt bereit, um Workflow Spezifikationen hinzufügen und löschen zu können. Des Weiteren werden Custom Services hierüber registriert beziehungsweise entfernt. Über Interface B findet der Großteil der Kommunikation mit angebundenen Services statt. Es können Workflow Instanzen gestartet, Work Items geladen und beendet sowie Prozessdaten bezogen werden. Das Interface E ermöglicht den Zugang zur Prozessprotokollierung und deren Analyse. Zuletzt dient Interface X zur Ermittlung und Behandlung von Ausnahmefällen (Exceptions) Resource Service Der Ressourcenperspektive kommt eine besondere Relevanz im Workflow Management zu, da Arbeitsschritte stets nur durch zugewiesene Ressourcen ausgeführt werden können. Ein effizienter Mechanismus wird benötigt, um Prozessschritte flexibel zu Personen mit bestimmten Fähigkeiten oder Berechtigungen delegieren zu können. Diese Zuständigkeit übernimmt innerhalb des YAWL Frameworks der Resource Service. Dieser ist als Custom Service implementiert und kommuniziert mit der Engine über die Schnittstellen A und B. Um die Anforderungen aus Ressourcensicht umzusetzen, wird zunächst eine Organisationsstruktur benötigt. Hierfür definiert YAWL ein recht simpel gehaltenes Modell, welches in Abbildung 2.7 gezeigt ist. Abbildung 2.7: Resource Service Modell der Organisationsstruktur [Quelle: Hofstede u. a., 2009, S. 266] Eine Person wird im YAWL Kontext als Participant bezeichnet und kann mit einer Mehrzahl an Capabilities (Fähigkeiten) ausgestattet werden. Des Weiteren übt jeder Workflow Beteiligte verschiedene Rollen ( Roles ) aus und hat bestimmte Positionen ( Positions ) inne. Eine Position kann wiederum einer Organisationseinheit ( Org Group ) angehören. 2 Grundlagen 16

22 Über den Resource Service wird das gerade beschriebene Organisationsmodell betrieben, um Prozessschritte dynamisch einer bestimmten Ressource zu zuordnen. An dieser Stelle wird der Kontrollfluss und die Daten mit den verfügbaren Ressourcen zusammengeführt. Für die gesamte Verwaltung kann eine Web Schnittstelle basierend auf Java Server Faces (JSF) genutzt werden. Auch die komplette Workflow Bearbeitung wird standardmäßig über diesen Service abgehandelt. Hierzu meldet sich der Nutzer am Service an und wird während des gesamten Lebenszyklus seiner zugewiesenen Work Items durch verschiedene Web Masken unterstützt. Jeder Nutzer unterhält verschiedene Work Queues. Diese gruppieren Prozessschritte gleichen Status in verschiedene Arbeitslisten. Zur eigentlichen Bearbeitung eines Arbeitsschrittes werden Ein und Ausgabemasken benötigt über die der Nutzer erforderliche Informationen beziehen oder verändern kann. Hierfür generiert der Resource Service aus dem XML Schema eines Work Items ein User Interface bestehend aus JSF Komponenten. Es werden dynamisch zur Laufzeit für jede Tätigkeit Ein und Ausgabemasken gebaut über die der Nutzer mit dem System interagiert. Um Kommunikation mit externen Services zu realisieren, werden drei Schnittstellen nach außen angeboten. Das Interface O ermöglicht es Organisationsinformationen aus externen Datenquellen einzulesen und mit den von YAWL verwendeten Organisationsstrukturen zu verknüpfen. Interface R wird auch als Resource Gateway bezeichnet und externalisiert Organisationsdaten. Als dritte Schnittstelle stellt das Interface W oder Workqueue Gateway einen Mechanismus bereit, um externen Zugriff auf die verfügbaren Arbeitslisten eines Nutzer zu erlangen. Der gesamte Work Item Lebenszyklus kann hierüber durch externe Komponenten erfolgen. Dies beinhaltet unter anderem auch die Aufgabenbearbeitung. Diese Schnittstelle wird im weiteren Verlauf dieser Arbeit der zentrale Ansatzpunkt zur Kopplung der Android Applikation mit dem YAWL System Editor Zur visuellen Modellierung von Prozessflüssen bietet YAWL einen Editor an. Workflows können hierüber graphisch erstellt, analysiert und exportiert werden. Der Editor ist eine Java Desktop Anwendung und muss mit einer YAWL Engine und einem Resource Service gekoppelt werden [Hofstede u. a., 2009, S. 221ff]. Abbildung 2.8 zeigt den Zusammenhang zwischen der Modellierungs und Laufzeitumgebung im YAWL Framework. YAWL Process Editor Workflow Specification YAWL Runtime Enviroment Visual Process Designer API calls Workflow Engine XML over HTTP Other Services Abbildung 2.8: Zusammenhang: YAWL Prozesseditor und Laufzeitumgebung [Siehe: Hofstede u. a., 2009, S. 222] 2 Grundlagen 17

23 Über ein Application Programming Interface (API) bezieht der Editor Informationen über Ressourcen aus der Laufzeitumgebung, so dass diese direkt in die Modellierung mit einbezogen werden. Im Editor wird der Kontrollfluss entworfen und mit den erforderlichen Daten versehen. Die fertige Workflow Spezifikation wird als XML Schema Dokument exportiert und kann an das Laufzeitsystem übergeben werden. Instanzen dieses Workflows können nun gestartet und durchgeführt werden. Auf die weiteren Details der Modellierungsumgebung wird im Rahmen dieser Arbeit verzichtet. Zusätzliche Informationen sind zu finden in [Hofstede u. a., 2009, S. 221ff]. 2.3 Charakteristiken mobiler Umgebungen Der exemplarische Arbeitsablauf in Abschnitt hat gezeigt, dass bestimmte Prozesse von Mobilität geprägt sein können. Auf welche Weise dies Einfluss auf das Geschäftsprozess Management hat, wird in Kapitel im Detail aufgegriffen. In diesem Abschnitt wird zunächst ein grundlegendes Verständnis vermittelt, was unter einer mobilen Umgebung zu verstehen ist. Im Folgenden werden die wesentlichen Charakteristiken des Mobile Computings und mobiler Endgeräte behandelt sowie der Begriff des Context Awareness eingeführt Mobile Computing Der technologische Fortschritt und die zunehmende Verbreitung mobiler Endgeräte sorgt für eine steigende Relevanz des Mobilitätsaspekts in der Informations und Kommunikationstechnologie. Endgeräte werden trotz steigender Portabilität stets leistungsfähiger. Dadurch ergeben sich maßgebliche Auswirkungen, wann und wo mit einem IT-System interagiert werden kann. Mit diesem Forschungsgegenstand beschäftigt sich das Mobile Computing. Der Begriff Mobile Computing beschreibt eine Obermenge von verschiedenen Forschungsdisziplinen, die sich mit der mobilen, also nicht stationären, Verwendung von Informationstechnologie beschäftigt. Mobile Computing umfasst die Bereiche Ubiquitous, Pervasive, Wearable und Nomadic Computing sowie Mobile und Wireless Communications. Fuchß [2009, S. 13ff] definiert Mobile Computing wie folgt: Das Ziel des Mobile Computings ist es, den Benutzern und dessen Anwendungen mit effektiven rechnerunterstützten Konzepten, Verfahren und Lösungen zu versorgen, die es ihm ermöglichen, in einem heterogenen Umfeld mit stets unsicherer Verbindungslage (private) Daten und Informationen zu lesen und zu bearbeiten, und dies unabhängig von Ort und Zeit. Drei wesentliche Aspekte sind zu nennen, um die Facetten des Mobile Computings zu charakterisieren. Dies ist erstens der Kommunikationsaspekt, welcher sich mit den Netzgegebenheiten, sowie Übertragungsprotokollen und Datenformaten beschäftigt. Zweitens befasst sich der Hardwareaspekt mit mobilen Endgeräten und deren Komponenten. Und drittens legt der Softwareaspekt die Anforderungen und Charakteristiken einer mobilen Anwendung fest. Der Begriff Mobilität lässt sich etwas konkreter untergliedern und nimmt Bezug auf verschiedene Aspekte, die von Mobilität geprägt sein können [Nach Roth, 2005]: 2 Grundlagen 18

24 Endgerätemobilität bezieht sich auf die Tatsache, dass ein Gerät den Ort wechseln kann ohne dabei die Netzverbindung zu verlieren. Das nicht stationäre Gerät kann dabei stets einem Benutzer zugeordnet werden. Sobald ein Benutzer von verschiedenen Orten aus seine Arbeiten erledigt ohne dabei an ein bestimmtes Gerät gebunden zu sein, spricht man von der Benutzermobilität Es gibt Dienste, die an verschiedenen Orten und über unterschiedliche Endgeräte genutzt werden können. Diese Art der Mobilität wird als Dienstmobilität bezeichnet. In der Literatur findet sich die Bezeichnung E Mobility, welche die oben genannten Faktoren der Mobilität unter einem Oberbegriff vereint. E Mobility nimmt konkret Bezug auf die Abwicklung von Geschäftstätigkeiten über das Internet. Die Vorgänge werden entkoppelt von Ort und Zeit und in einen virtuellen Raum verlegt, der unter Nutzung von Maschine zu Maschine Kommunikation Prozesse zur Ausführung bringt. Weiterführende Informationen zu diesem Themengebiet sind zu finden in [Rump u. a., 2005] Eigenschaften mobiler Endgeräte Mobile Umgebungen sind geprägt von den Eigenschaften der zur Verfügung stehenden Endgeräte. Hier herrscht ein breites Spektrum an Hardware, welches bei speziellen Sensoren beginnt, zu Smartphones und Tablet PCs übergeht und bei Notebooks endet. Trotz der Heterogenität der Hardware lassen sich bestimmte Faktoren an allen mobilen Endgeräten festmachen, die sich stets auf die Entwicklung mobiler Lösungen auswirken. Je nach Geräteklasse lassen sich die im Folgenden genannten Aspekte in unterschiedlich starker Ausprägung feststellen [Fuchß, 2009, S. 21ff]: Geringere Ressourcenverfügbarkeit Mobile Endgeräte stellen im Vergleich zu stationären Geräten weniger Ressourcen zur Verfügung. Auch wenn in diesem Bereich die technische Entwicklung nicht halt macht und mobile Endgeräte stetig leistungsfähiger werden, so lässt sich jedoch festhalten, dass Bezug nehmend auf die Punkte Rechenleistung, Speicherkapazität und Darstellungsmöglichkeiten ein teilweise erheblicher Unterschied zu stationärer Hardware besteht. Unsichere Netzwerkverbindung In mobilen Umgebungen wird in der Regel auf drahtlose Netzwerkkommunikation zurückgegriffen. Hierdurch ergibt sich eine geringere Übertragungsrate und eine höhere Latenz im Vergleich zur kabelgebundenen Kommunikation. Bestimmte äußere Einflüsse können sich negativ auf die Verbindung auswirken und so zu Kommunikationsstörungen führen. Höheres Risiko Mobile Endgeräte, die stets mitgeführt werden, erhöhen das Risiko des Verlusts oder der Entwendung. Des Weiteren ist drahtlose Kommunikation mit höheren Sicherheitsrisiken verbunden, da sie leichter abzuhören ist. 2 Grundlagen 19

25 Endliche Energiequelle Üblicherweise werden mobile Endgeräte mit Batterien oder Akkus betrieben. Die Kapazitäten sind begrenzt, was die Dauer der Laufzeit einschränkt. Ein schonender Umgang der Ressourcen ist daher bei mobilen Endgeräten unabdingbar Context Awareness Mobile Endgeräte sind nicht stationär, sondern wechseln ihren Standort. Aus dieser Mobilität ergibt sich eine Veränderung der Umgebung, die sich zu Nutze gemacht werden kann, indem mobile Geräte in die Lage versetzt werden, ein Bewusstsein für deren Umgebung zu entwickeln. Hierbei spricht man von Context Awareness, was ins Deutsche meist mit Kontextsensibilität übersetzt wird. Context Awareness lässt sich als Forschungszweig dem Mobile Computing zuordnen. Mit Kontext sind in diesem Zusammenhang sämtliche Informationen gemeint, die verwendet werden können, um die aktuelle Situation zu charakterisieren. Kontextsensitive Anwendungen müssen zum Einen die aktuellen Umgebungsinformationen erfassen und verwerten sowie zum Anderen dynamisch auf Kontextänderungen reagieren können. Die verbreitetste Ausprägung kontextsensitiver Anwendungen sind ortsgebundene Dienste, die ihre Position über das Global Positioning System (GPS) ermitteln und dem Anwender Funktionalitäten in Abhängigkeit vom aktuellen Aufenthaltsort anbieten. Die so genannten Location based Services können dann beispielsweise zur Navigation genutzt werden. Die sich ergebenden Möglichkeiten sind vielfältig und derzeit ein viel diskutiertes Forschungsgebiet. Weitere Ausprägungen der Sensibilität werden bezeichnet als Situation Awareness, Network Awareness oder Energy Awareness, welche jedoch keine Relevanz für diese Arbeit aufweisen und daher nicht betrachtet werden. Weiterführende Informationen sind unter anderem zu finden in [Vilenica, 2008, S. 12f]. 2.4 Die mobile Plattform Android Im folgenden Abschnitt werden die relevanten Charakteristiken der Android Plattform analysiert. Im Fokus stehen der generelle Aufbau, die zur Verfügung stehenden Komponenten und deren Besonderheiten, welche die Entwicklung mobiler Applikationen kennzeichnen. Android ist ein Betriebssystem für mobile Endgeräte. Das abgedeckte Gerätespektrum reicht vom einfachen Mobiltelefon über Smartphones bis hin zu Netbooks und Tablet Computern. Das Android Projekt ist initiiert von Google und wird vorangetrieben von der Open Handset Alliance, einem breiten Zusammenschluss von Mobilfunkanbietern, Endgeräteherstellern sowie Halbleiter und Software Unternehmen. Das Ziel der Initiative ist die Beschleunigung von Innovationen im Bereich des Mobile Computings [Gargenta, 2011, S. 1]. 2 Grundlagen 20

26 Android ist eine offene Plattform, welche eine strikte Trennung von Hard und Software vorsieht. Dies hat zur Folge, dass eine für Android entwickelte Anwendung auf einer großen Anzahl mobiler Endgeräte lauffähig ist, solange diese für den Betrieb mit Android ausgelegt sind. Für Entwickler bedeutet diese Tatsache, dass sie nicht für ein spezielles Gerät, sondern eine Software Plattform entwickeln und sich dadurch eine größere Zielgruppe erschließt [Becker und Pant, 2010, S. 19]. Als Entwicklungsumgebung wird lediglich das Android SDK benötigt. Für die Hersteller von mobilen Endgeräten hat die Android Plattform den großen Vorteil, dass nur gerätespezifische Treiber bereitgestellt werden müssen. Der gesamte Software technische Funktionsumfang wird durch Android bereitgestellt. Die Open Handset Alliance betreibt Android als Open Source Projekt unter der Apache Lizenz in der Version 2.0. Der Quellcode liegt dadurch offen und kann im Rahmen eigener Entwicklungen eingesehen werden. Die Android Historie geht zurück in das Jahr 2005 und hat seitdem eine rasante Entwicklung genommen, was sich in der zunehmenden Anzahl verfügbarer Endgeräte und den stetig steigenden Marktanteilen ausdrückt [Siehe Gartner, 2011]. Die zuletzt veröffentlichten Android Versionen sind Froyo (Version 2.2, API Level 8) und Gingerbread (Version 2.3, API Level 9). Im Februar 2011 kam mit Honeycomb (Version 3, API Level 11) ein weiteres Release speziell für Tablet Computer hinzu. Die praktische Implementierung dieser Arbeit richtet sich nach API Level 8 und verfolgt damit einen Kompromiss zwischen Kompatibilität und Aktualität Aufbau und relevante Komponenten Android setzt sich aus einer Schichtenarchitektur zusammen, welche sich in fünf Ebenen zerlegen lässt. Bei der Erläuterung der einzelnen Komponenten werden lediglich diejenigen Bestandteile eine genauere Betrachtung finden, welche eine Relevanz im Rahmen der vorliegenden Arbeit haben. Abbildung 2.9 zeigt die Android Architektur. Hervorgehoben sind jeweils die für die spätere Umsetzung benötigten Komponenten. Die unterste Schicht besteht aus einem Linux Kernel in der Version 2.6. Hierüber wird die Verwaltung des Arbeitsspeichers, der Systemprozesse, der Treiber sowie der Netzwerkzugriffe gekapselt [Lee, 2011, S. 3ff]. Die Android Runtime basiert auf der Programmiersprache Java. Eine Vielzahl an Java Kernbibliotheken stehen zur Verfügung. Jede Android Anwendung läuft als eigener Prozess in einer speziellen virtuellen Maschine (VM), der so genannten Dalvik VM. In einer solchen Umgebung kann durch das SDK optimierter Java Code im.dex Format ausgeführt werden. Zusätzlich zu den Java Kernfunktionalitäten werden weitere Bibliotheken angeboten. Wichtig für diese Arbeit ist hierbei die bereitgestellte und leichtgewichtige, relationale Datenbanklösung (SQLite). Im Application Framework befinden sich verschiedene Manager Klassen, deren Funktionalität sich in eigene Entwicklungen integrieren lässt. Hierüber lassen sich unter anderem Activities (siehe Abschnitt ) oder benötigte Ressourcen verwalten. 2 Grundlagen 21

27 Applications Application Framework Activity Manager Window Manager Content Provider View System Package Manager Telephony Manager Resource Manager Location Manager Notification Manager Libraries Surface Manager Media Framework SQLite Application Runtime OpenGL SGL FreeType SSL WebKit Core Libs Android Runtime libc Dalvik VM Linux Kernel Abbildung 2.9: Relevante Komponenten der Android Architektur [Quelle: Android, 2011b] Die oberste Schicht beinhaltet neben einer Menge an Standardanwendungen alle Applikationen, die auf einem Gerät installiert sind. In den folgenden Abschnitten werden einige Komponenten detaillierter betrachtet, die eine Relevanz im späteren Entwicklungsteil der Arbeit haben Eigenschaften der Laufzeitumgebung Wie im vorangegangenen Abschnitt bereits erwähnt, lässt sich die Android komplett in Java programmieren. An dieser Stelle werden nun die Unterschiede zur Standard Java Entwicklung erläutert. Als gravierendste Differenz lässt sich festhalten, dass Java Bytecode in Form von *.class Dateien auf Android Geräten nicht lauffähig ist. Um diesen ausführbar zu machen, wird ein zusätzlicher Kompilierungsschritt benötigt. Android stellt hierfür das Programm dx zur Verfügung. Dieses arbeitet als so genannter Cross Compiler und übersetzt Java in Dalvik Bytecode [Hashimi u. a., 2010, S. 5ff]. Bei dieser Überführung werden spezielle Optimierungen am Code vorgenommen, so dass die Möglichkeiten aktueller Mobilprozessoren optimal genutzt werden. Abbildung 2.10 zeigt zur Verdeutlichung des Prozesses den Weg vom Java Sourcecode bis zum ausführbaren Dalvik Bytecode. Nach der Kompilierung kann eine *.apk Datei erzeugt werden, die den ausführbaren Dalvik Bytecode beinhaltet und sich auf Android Geräten installieren lässt. Die Dalvik VM ist eine virtuelle Maschine, die speziell auf die Anforderungen mobiler Endgeräte ausgerichtet ist. So wird versucht den Betriebssystemprozess möglichst schlank und den Speicherbedarf gering zu halten [Meier, 2010, S. 14ff]. 2 Grundlagen 22

28 Java IDE *.java javac dx *.class Entwicklungsrechner Android-Gerät *.dex Deployment Dalvik VM Abbildung 2.10: Von *.java zu *.dex [Vgl.: Becker und Pant, 2010, S. 22] Jede Android Anwendung läuft in einer separaten VM und ist konform mit dem Sandbox Prinzip [Mosemann und Kose, 2009, S. 3]. Dies hat vor allem vor dem Sicherheitsaspekt Vorteile und zielt auf einen hohen Grad an Robustheit ab [Becker und Pant, 2010, S. 19ff] Der Anwendungsrahmen Der Anwendungsrahmen (Application Framework) kann sinnbildlich als das Rückgrat aller Android Anwendungen angesehen werden. Verschiedene Komponenten und Klassen abstrahieren die zugrundeliegende Hardware und verbergen die Low Level Details vor dem Entwickler [Becker und Pant, 2010, S. 24]. Die wesentlichen Konzepte die Android auf dieser Ebene einführt, lassen sich auf sechs Komponenten reduzieren aus denen jede Android Applikation besteht und die untereinander lose gekoppelt sind [Murphy, 2009, S. 3]: Activities Intents Services Notifications Broadcast Receiver Content Provider Im Folgenden werden die genannten Konzepte gezielt vorgestellt. Um den Umfang zu wahren, werden an dieser Stelle lediglich Activities, Intents und Services näher betrachtet, da im Rahmen der Umsetzung auf diese Konzepte zurückgegriffen wird Activities Der absolute Grundbaustein einer Android Anwendung ist die Activity. Jede Bildschirmseite einer Applikation setzt sich aus verschiedenen View Komponenten zusammen. Diese sind eingebettet in einer Activity, der die Steuerung obliegt und die View mit Daten versorgt. Alle View Elemente lassen sich über die zugrundeliegende Activity manipulieren. Es ist möglich seine View komplett über die Activity zusammen zubauen. In der Regel wird das Layout jedoch über XML Dokumente definiert, die über die Activity geladen werden [Ableson u. a., 2009, S. 59ff]. 2 Grundlagen 23

29 Activity Lebenszyklus oncreate() onrestart() onstart() Sichtbare Phase Vordergrund Phase onresume() onpause() onstop() ondestroy() Abbildung 2.11: Der Lebenszyklus einer Android Activity [Quelle: Ableson u. a., 2009, S. 68] Eine Android Activity hat einen festgelegten Lebenszyklus. Abbildung 2.11 zeigt die Phasen, die durchlaufen werden und die Methoden, welche in den jeweiligen Zyklen aufgerufen werden. Der Start einer Activity wird durch einen so genannten Intent initiiert. Abschnitt befasst sich im Detail mit diesem Konzept. Der Lebenszyklus einer Android Activity lässt sich in drei Phasen einteilen [Ableson u. a., 2009, S. 68ff]. Die Existenz einer Activity beginnt mit der oncreate() Methode, welche von jeder Activity überschrieben werden muss. Hier findet die Initialisierung statt und das View Layout kann geladen werden. In der zweiten Phase ist die Activity aktiv und sichtbar, wird jedoch beispielsweise von einem Dialog überlagert. In der Hauptphase ist die Activity sichtbar und befindet sich im Vordergrund. Jede Phase hält Methoden bereit, welche zu Beginn oder Ende einer Phase aufgerufen werden. Je nach Gegebenheit kann es also für den Entwickler Sinn machen, diese Methoden zu überschreiben, um auf bestimmte Ereignisse reagieren zu können. Mit dem Aufruf der ondestroy() Methode endet der Lebenszyklus und die Activity wird abgeschlossen Intents Eine Android Applikation setzt sich unter anderem aus verschiedenen Activities zusammen. Um diese zu koppeln, werden so genannte Intents eingesetzt. Alle Komponenten einer Anwendung können über Nachrichten miteinander kommunizieren und Daten austauschen. Auf diese Weise wird ein asynchrones und lose gekoppeltes Kommunikationsmodell umgesetzt. Intents stellen den benötigten Mechanismus hierfür bereit [Becker und Pant, 2010, S. 135ff]. Ein Intent kann als eine Umsetzung des Command Entwurfsmusters betrachtet werden. Dieses Pattern ist dokumentiert von Gamma u. a. [1994, S. 233]. Intents können explizit oder implizit eingesetzt werden. Explizite Intents haben einen festgelegten Empfänger, welcher bereits während der Programmierung vom Entwickler festgelegt wird. 2 Grundlagen 24

30 Implizite Intents werden ohne konkreten Empfänger verschickt, so dass es von den laufenden Komponenten und den installierten Anwendungen einer Plattform abhängt, wer einen solchen Intent entgegennimmt [Hashimi u. a., 2010, S. 106ff] Services Services gehören zu den Android Kernkomponenten. Im Unterschied zu Activities laufen Services nur im Hintergrund einer Anwendung und besitzen keine Nutzerschnittstelle. Services werden zur Umsetzung von Funktionalitäten genutzt, die unabhängig von Activities sind. Periodisch wiederkehrende Tätigkeiten können beispielsweise hierüber ausgeführt werden. Activities können bei Bedarf jederzeit auf Services zurückgreifen [Gargenta, 2011, S. 101]. Android bietet zwei unterschiedliche Servicevarianten an. Zum Einen die lokalen Services, welche im selben Prozess wie die Anwendung laufen und zum Anderen die entfernten Services, welche in einem separaten Prozess gestartet werden und über Interprozesskommunikation kontaktiert werden können. Der Funktionsumfang lokaler Services reicht für die spätere Anwendungsimplementierung aus, so dass die folgende Betrachtung sich auf diese Variante beschränkt. Vergleichbar mit dem Lebenszyklus einer Activity durchläuft auch ein Service bestimmte Phasen während seiner Ausführung. Um mit Services zu kommunizieren, benötigt eine Activity eine Service Connection. Hierfür führt Android das Konzept des Binders ein. Attribute und Methoden eines Services können mittels Binder an eine Activity gebunden werden und eröffnen hierdurch einen Kommunikationskanal. Der Zugriff erfolgt über entfernte Methodenaufrufe [Becker und Pant, 2010, S. 163ff]. Um auch asynchrone Kommunikation zu unterstützen, können Activities so genannte Callback Handler registrieren. Services können hierüber aktiv Methoden der Activity aufrufen. Dies kann beispielsweise nach dem Abschluss einer langlaufenden Operation eingesetzt werden. 2.5 Relevante Technologien Im Rahmen dieser Arbeit werden einige technische Grundlagen benötigt. Um ein möglichst breites Verständnis aller Zusammenhänge sicherzustellen, werden in den folgenden Abschnitten relevante Technologien in Kürze vorgestellt XML Schema XML und XML Schema sind integrale Konzepte des YAWL Frameworks. Die extensible Markup Language (XML) ist besonders im Web Bereich ein weit verbreitetes Standardformat zur Codierung und Übertragung von Daten. Je nach Anwendungsfall können XML Dokumente sehr komplex und umfangreich werden. Um XML Strukturen formal zu definieren, entwickelt das World Wide Web Consortium (W3C) eine Empfehlung Namens XML Schema (XSD) [W3C, 2010]. Ein solches Schema beinhaltet Regeln sowie Einschränkungen und legt ein Datenmodell für eine Klasse von XML Dokumenten fest [Vlist, 2002, S. 1ff]. Haupteinsatzzweck ist die Validierung von XML Strukturen. Ein XML Dokument wird gegen ein Schema geprüft, um zu einer Aussage zu kommen, ob es valide ist oder nicht den Anforderungen des Schemas entspricht. Eine solche Aussage beschränkt sich auf die syntak- 2 Grundlagen 25

31 tische Korrektheit und Vollständigkeit. Die Semantik eines Dokuments kann durch XML Schema nicht geprüft werden. Ein zusätzliches Verwendungsgebiet ist die Dokumentation von XML Vokabularen [Skulschus und Wiederstein, 2008, S. 24ff]. Vergleichbar mit gängigen Programmiersprachen bietet XML Schema Definitionsmöglichkeiten für einfache (atomare) und komplexe Datentypen. Die spezifizierten, primitiven Datentypen sind beispielsweise xs:string, xs:integer, xs:float, xs:boolean oder xs:date. Der so bezeichnete xs:simpletype spezifiziert Listen und Mengen (engl. unions ) [Vlist, 2002, S. 44ff]. Reichen die einfachen Ausdrucksmöglichkeiten nicht aus, so können mittels xs:complextype eigene, komplexe Datentypen festgelegt werden. Listing 2.1: Beispiel eines XML Schemas mit validem XML Dokument 1 <! XML Schema > 2 <xs:schema xmlns:xs=" h t t p : //www. w3. org /2001/XMLSchema"> 3 <x s : e l e m e n t name=" n o t i z "> 4 <xs: complextype> 5 <x s : s e q u e n c e> 6 <x s : e l e m e n t name="datum" type=" x s : d a t e "/> 7 <x s : e l e m e n t name="name" type=" x s : s t r i n g "/> 8 <x s : e l e m e n t name=" t e x t " type=" x s : s t r i n g "/> 9 </ x s : s e q u e n c e> 10 </ xs: complextype> 11 </ x s : e l e m e n t> 12 </ xs:schema> <! XML Dokument > 15 <n o t i z x m l n s : x s i=" h t t p : //www. w3. org /2001/XMLSchema i n s t a n c e " 16 xsi: nonamespaceschemalocation=" xsd example. xsd "> 17 <datum> </datum> 18 <name>max Mustermann</name> 19 <t e x t>b e i s p i e l n o t i z</ t e x t> 20 </ n o t i z> Das Listing 2.1 zeigt beispielhaft die Definition eines XML Schemas und einem hierzu validen XML Dokument. Im Schema wird eine Datenstruktur vom Typ notiz spezifiziert. Dies ist ein komplexer Datentyp, der aus einer Sequenz atomarer Elemente besteht. Eine Notiz beinhaltet demnach ein Datum, sowie jeweils einen String für den Namen und den Text. Komplexe Datentypen können beliebig geschachtelt werden. Ein xs:complextype kann wiederum aus einer beliebigen Anzahl weiterer, zusammengesetzter Datentypen bestehen [Skulschus und Wiederstein, 2008]. Durch diese Möglichkeit können Datenbäume von beliebiger Tiefe erzeugt und auch sehr spezielle Domänen abgebildet werden. XML Schema bietet eine Vielzahl weiterer Möglichkeiten, welche in dieser Arbeit jedoch nicht weitergehend ausgeführt werden. YAWL verwendet zur Datenübertragung ausschließlich XML. Der Einsatz von Schemata findet sich an diversen Stellen im Gesamtkontext. Zunächst werden die modellierten Workflows in ihrer vollständigen Form als XML Schema Dokument beschrieben. Aber auch einzelne Arbeitsschritte in Form eines Work Items werden über ein Schema definiert, so dass die 2 Grundlagen 26

32 jeweiligen Datendokumente stets auf Vollständigkeit und Korrektheit überprüft werden können. Ein Grundverständnis von XML Schema ist daher im YAWL Umfeld unerlässlich Serviceorientierte Architekturen Das gesamte YAWL System ist strukturiert in Form einer serviceorientierten Architektur (SOA). Die folgende Betrachtung der wesentlichen Eigenschaften dieses Entwurfsprinzips hilft die im späteren Verlauf der vorliegenden Arbeit besprochene Kopplung der Android Applikation mit YAWL nachzuvollziehen. Betrachtet man aktuelle State of the Art Technologien in der IT, so führt kein Weg an serviceorientierten Architekturen vorbei, einem Entwurfsmuster zum Aufbau einer verteilten System und Anwendungslandschaft. Im Kontext des Geschäftsprozess Managements nehmen serviceorientierte Architekturen einen besonderen Stellenwert ein, denn die Entstehung ist stark Unternehmens getrieben und die positiven Eigenschaften entfalten besonders im Geschäftsprozess Management ihren vollen Wirkungsgrad. Eine serviceorientierte Architektur schließt die Kluft zwischen dem Geschäftsmodell eines Unternehmens und der informationstechnischen Umsetzung [Liebhart, 2007, S. 91]. Alle Komponenten einer serviceorientierten Architektur sind gekapselt in voneinander unabhängige Dienste, die so genannten Services. Diese definieren sich als IT Repräsentation von fachlicher Funktionalität, die durch eine wohldefinierte Schnittstelle beschrieben wird [Josuttis, 2008]. Services kommunizieren Nachrichten basiert über Web Services und arbeiten demnach asynchron [Baun u. a., 2009, S. 18f]. Hierdurch wird eine lose Kopplung erreicht, die es ermöglicht Services flexibel zu orchestrieren. Eine zusammenfassende Definition ist zu finden in [Melzer, 2010, S. 13]: Unter einer serviceorientierten Architektur versteht man eine Systemarchitektur, die vielfältige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wieder verwendbare und offen zugreifbare Dienste repräsentiert und dadurch eine Plattform und Sprachen unabhängige Nutzung und Wiederverwendung ermöglicht. Die Komponenten einer serviceorientierten Architektur werden in drei Zuständigkeiten aufgeteilt. Der Service Anbieter implementiert einen Service und bietet diesen im Netzwerk an. Der Service Nutzer verwendet die Funktionalitäten der Provider, indem er die zur Verfügung stehen Dienste über ein Netzwerk aufruft. Das Service Verzeichnis ist ein spezieller Dienst in dem Provider ihre Services veröffentlichen und Consumer nach Diensten suchen können. Das so genannte SOA Dreieck, welche die gerade beschriebenen Abhängigkeiten visualisiert, ist in Abbildung 2.12 zu sehen [Melzer, 2010, S. 14]. Das Kommunikationsmodell zum Aufbau einer serviceorientierten Architektur ist auf vielfältige Weise möglich. Die gängigsten Konzepte sind Web Services auf Basis von SOAP oder REST. Weiterführende Informationen hierzu sind beschrieben in Abschnitt oder in der Literatur von Singh und Huhns [2005, S. 54ff]. Die durch eine serviceorientierte Architektur gewonnene Flexibilität und gesteigerte Wiederverwendbarkeit von Funktionalitäten macht sich das YAWL System zu Nutze. Alle Systemkomponenten sind als Service implementiert und können flexibel miteinander 2 Grundlagen 27

33 Service- Verzeichnis Suchen / Verweis beziehen Veröffentlichen Service- Nutzer Nutzung / Interaktion Service- Anbieter Abbildung 2.12: Rollen in einer SOA (Dreieck) [Siehe Melzer, 2010, S. 14] kombiniert beziehungsweise verhältnismäßig einfach erweitert werden. Die YAWL Services können über bestimmte Endpunkte (eindeutige Adresse) angesprochen werden und bieten jeweils Schnittstellen zur Nutzung ihrer Funktionalitäten an [Hofstede u. a., 2009, S. 205]. Ein Teil der Services ist für die Kopplung externer Komponenten und Systeme ausgelegt. Ein anderer Teil der Services ist Nutzer-zentriert. Die Interaktion erfolgt über eine graphische Benutzeroberfläche Representational State Transfer Zur Realisierung einer serviceorientierten Architekturen lassen sich verschiedene Kommunikationsmodelle einsetzen. Im Enterprise Bereich haben sich hier besonders Web Services auf Basis von SOAP etabliert. Doch vor allem auf Grund der Einfachheit und Flexibilität setzen immer mehr Unternehmen und Projekte auf RESTful Web Services als Kommunikationskonzept zum Aufbau verteilter Systeme über das World Wide Web (WWW). So folgt beispielsweise YAWL dem REST Paradigma für den Informationsaustausch zwischen Services. Der folgende Abschnitt befasst sich mit den wesentlichen Eigenschaften. REST ist ein Architekturstil und geht zurück auf Roy T. Fielding, der diesen im Jahre 2000 in seiner Dissertation beschrieb [Fielding, 2000, Kapitel 5]. Hierzu generalisierte er die grundlegenden Architekturprinzipien des WWW und formulierte hieraus ein Rahmenwerk einer Ressourcen orientierten Architektur [Webber u. a., 2010, S. 12]. Das Akronym REST steht für REpresentational State Transfer. Beschrieben wird die Art und Weise auf denen Web Standards wie das HyperText Transfer Protocol (HTTP) sowie der Uniform Resource Identifier (URI) oder der Uniform Resource Locator (URL) einzusetzen sind, um verteilte Architekturen über das Web aufzubauen [Richardson und Ruby, 2007, S. 14ff]. Das wichtigste Konzept einer REST Architektur sind Ressourcen. Alle Komponenten sind Ressourcen, welche eindeutig über einen URI adressiert werden können. Eine konkrete Ressource kann wiederum in verschiedenen Repräsentationen, beispielsweise einem XML Dokument, vorliegen. Ressourcen sind hierarchisch angeordnet und der Zugriff erfolgt wahlfrei über HTTP Methoden. Abbildung 2.13 visualisiert diese Zusammenhänge und zeigt stark vereinfacht einen möglichen Kommunikationsablauf. 2 Grundlagen 28

34 HTTP GET yawl Ressource Service- Nutzer POST cases workitems PUT DELETE Repräsentation XML Client: HTTP-Request Server: HTTP-Response GET /yawl/workitems/4711 Host: example.com Accept: text/xml HTTP OK Content-type: text/xml <workitem> <id>4711</id> <name>aufgabe xy</name>... </workitem> Abbildung 2.13: REST basierte Web Service Architektur mit schematischer Ressourcenhierarchie und exemplarischer HTTP Kommunikation HTTP ist integraler Bestandteil der RESTful Web Services [Meir-Huber, 2010, S. 24]. Hinsichtlich der Schnittstellen beschränkt sich dieser Ansatz auf die von HTTP zur Verfügung gestellten Methoden. Dies bedeutet auf der einen Seite eine Einschränkung der Funktionsvielfalt, eröffnet auf der anderen Seite jedoch ein simples Programmiermodell von hoher Flexibilität. Es wird keine Schnittstellendefinition benötigt, da jede Ressource stets die gleichen Operationen unterstützt. Die Semantik der HTTP Methoden ist zusammengefasst in Tabelle 2.2. Methode GET POST PUT DELETE Aktion Abfragen und Lesen einer Ressource. Aktualisierung einer bestehenden Ressource. Erstellung einer neuen Ressource. Löschen einer Ressource. Tabelle 2.2: HTTP Methoden und ihre Funktion im Kontext einer REST Architektur Die eingesetzten Methoden beschränken sich auf eine CRUD Funktionalität (Create, Read, Update, Delete), welche sich auf alle Ressourcen anwenden lässt [Webber u. a., 2010, S. 55ff]. In YAWL sind gemäß diesem Paradigma alle Datenstrukturen als Ressourcen abgebildet. Deren XML Repräsentation lassen sich über die HTTP Methoden abfragen beziehungsweise aktualisieren. Hierfür werden ausschliesslich die Operationen GET und POST verwendet. PUT und DELETE werden nicht unterstützt, da die Neuanlage sowie das Löschen einer Ressource dem Service Anbieter, sprich dem YAWL System, vorbehalten ist [Hofstede u. a., 2009, S. 205ff]. YAWL erweitert die Funktionsvielfalt um diverse Request Parameter. Um diese zu abstrahieren und damit die Verwendung zu erleichtern, stellt das YAWL Framework verschiedene Schnittstellen zur Verfügung. Diese wurden bereits in Abschnitt 2.2 im Detail betrachtet. 2 Grundlagen 29

35 2.6 Verwandte Arbeiten Sowohl aus wissenschaftlicher als auch aus wirtschaftlicher Sicht ist die Integration mobiler Endgeräte in das Workflow Management ein erstrebenswertes Ziel, da sich hierdurch ein weitreichendes Optimierungspotential erschließt. In der Literatur finden sich eine Vielzahl erwähnenswerter Veröffentlichungen. Der folgende Abschnitt versucht einen aktuellen Einblick in dieses Forschungsgebietes zu gewähren. Der Artikel A Workflow Definition Language for Business Integration of Mobile Devices von Werner u. a. [2010] befasst sich mit der Entwicklung einer für mobile Endgeräte simplifizierten Workflow Sprache. Auf deren Basis wird ein System zur mobilen Dokumentation von Versicherungsfällen umgesetzt. Dabei werden unter anderem mobile Sensordaten in das Workflow Management integriert. Pajunen und Chande [2007] beschreiben in ihrer Arbeit Developing a Workflow Engine for Mobile Devices ein Workflow System, welches speziell für die Integration mobiler Geräte ausgelegt ist. Dabei wird im Besonderen der Kommunikationsaspekt betrachtet. Es werden SOAP basierte Web Services eingesetzt und die Business Process Execution Language (BPEL)" zur Prozesssteuerung genutzt. In der Publikation Implicit interaction design for pervasive workflows wird eine Modellierungsmethodik für Workflows vorgestellt, welche implizite Interaktionen in Workflows einbezieht und dadurch versucht die Kluft zwischen realer und digitaler Welt zu überbrücken [Giner u. a., 2011]. Implizite Interaktionen finden ohne konkrete Anforderung des Benutzers statt. Sie können beispielsweise über eine GPS Ortsinformation ausgelöst werden. Pintea und Tivadar [2009] stellen in ihrem Aufsatz Improvements in cardiology workflow in a hospital using mobile software solutions eine Möglichkeit vor, mobile Endgeräte in den Arbeitsalltag einer kardiologischen Klinik zu integrieren. Es werden verschiedene Aspekte behandelt, welche eine Verbesserung der Patientenversorgung mit sich bringen können. Vorgestellte Anwendungsfälle sind beispielsweise die schnellere Verfügbarkeit von Patientendaten oder die Weiterleitung vom Schwesternalarm auf mobile Endgeräte. Der Artikel Modeling Mobile Workflows with BPMN der Autoren Decker u. a. [2010] präsentiert eine Erweiterung der BPMN, um spezielle, mobile Prozesse modellieren zu können. Arbeitsschritte können mit einer Ortsbeschränkung versehen werden. Deren Ausführung wird in Bezug zum aktuellen Aufenthaltsort gesetzt und muss stets in Einklang mit der örtlichen Einschränkung stehen. In der Veröffentlichung Bridging the Gaps towards Structured Mobile SOA von [Papageorgiou u. a., 2009] wird darauf verwiesen, dass sich eine SOA zwar grundsätzlich um mobile Services erweitern lässt, es jedoch hierfür keine standardisierte oder etablierte Lösung gibt. Um dies zu ändern, stellen die Autoren eine Roadmap in drei Schritten vor, um zu einer so genannten Structured Mobile SOA zu gelangen. Die Autoren Pryss u. a. [2011] geben in ihrem Artikel Towards Flexible Process Support on Mobile Devices einen Einblick in das so genannte MARPLE Projekt, welches sich zum Ziel gesetzt hat, die Machbarkeit einer engen Integration von 2 Grundlagen 30

36 Geschäftsprozess Management Technologien mit Mobile Computing Frameworks zu zeigen. Eine leichtgewichtige Process Engine wird entwickelt, welche die Steuerung des mobilen Prozessflusses übernimmt. Besonderes Augenmerk wird der Benutzerunterstützung gewidmet. Einen gänzlich von den bisher vorgestellten Arbeiten abweichenden Ansatz verfolgen Zaplata und Lamersdorf [2010] in ihrem Artikel Towards mobile process as a service. Vorgestellt wird eine Lösung, die als Process as a Service bezeichnet wird. Diese verlagert das Geschäftsprozess Management in die Cloud und macht es mobilen Clients auf diese Weise möglich auf Geschäftsaktivitäten zugreifen zu können. Abschließend lässt sich feststellen, dass im Forschungsgebiet des mobilen Workflow Managements eine rege Aktivität vorherrscht und es ein breites Spektrum an Projekten und Lösungen gibt. Die Erweiterung von YAWL Workflows um mobile Beteiligte auf Basis von Android ist bisher nicht untersucht worden und ist daher Gegenstand der vorliegenden Arbeit. 2.7 Stand der Technik Der Markt für mobile Applikationen wird beherrscht von einer enormen Masse angebotener Lösungen. Grenzt man diese auf Android Anwendungen ein, welche sich mit dem Thema Workflow Management befassen, so wird die Anzahl an fertigen Lösungen rapide eingeschränkt. Zwar lassen sich verschiedene Applikationen zur Aufgaben und Tätigkeitsunterstützung finden, beispielsweise über den Android Market, einer Plattform für Android Software. Die hier verfügbaren Anwendungen bieten aber durchweg keine Möglichkeit, Arbeitsschritte in einen übergeordneten Workflow einzubetten, der zentral koordiniert wird. So ist es zwar möglich, Aktivitäten mit einem mobilen Endgerät zu verwalten und online mit einem Server System abzugleichen. Allerdings sind alle Tätigkeiten für sich abgeschlossen und erfahren keine zentral automatisierte Ablaufsteuerung durch einen übergeordneten Prozessfluss. Die Mächtigkeit eines ganzheitlichen Workflow Managements wird von keinem der angebotenen Lösungen erreicht. Es finden sich jedoch einige wenige Applikationen, welche die Android gestützte Tätigkeitsausführung auf mobilen Endgeräten ermöglichen. Hier ist zunächst die Anwendung OnBase Mobile des Unternehmens Hyland-Software [2011] zu nennen. Nach Angaben des Herstellers reicht der Funktionsumfang der Software von der Bereitstellung eines mobilen Workflow Zugangs, über die Ausführung so genannter Workflow Ad Hoc Tasks, bis hin zur Möglichkeit Arbeitsschritte mit Notizen zu versehen. Die Anwendung lässt sich zwar kostenfrei aus dem Android Market beziehen, sie basiert jedoch auf dem kommerziellen Enterprise Content Management (ECM) und Workflow Management System OnBase ECM Workflow. Es handelt sich dabei um eine proprietäre Lösung, welche mit Lizenzkosten verbunden ist. Ähnlich sieht es auch bei der Applikation Cyberhood Workflow aus, einer Lösung des taiwanesischen Herstellers Kinghood-Technologies [2011]. Die Anwendung erfordert zum Einen den Betrieb einer kostenpflichtigen Server Komponente für die Online Verwaltung und zum Anderen ist die Android Anwendung nur unzureichend bis überhaupt nicht für den deutschen oder englischen Sprachraum lokalisiert. 2 Grundlagen 31

37 Eine weitere Anwendung, die in diesem Kontext erwähnenswert ist, wird unter dem Projektnamen Mobile SAP betrieben und steht unter der Entwicklung der Firma ISEC7 [2011]. Die Applikation ist neben der Android Plattform auch für Blackberry und Apple s ios verfügbar und zielt darauf ab, Funktionalitäten eines SAP Systems auf mobilen Endgeräten bereitzustellen, darunter unter anderem die Komponente Mobility for SAP Workflow. Diese bedingt jedoch den Betrieb eines kostenpflichtigen SAP Systems. Des Weiteren beschränkt sich das Workflow Modul auf speziell von SAP festgelegte Arbeitsprozesse wie beispielsweise Reisekostenabrechnung oder Urlaubsanträge. Eine komplette Lösung, welche das Management von generischen Workflows auf mobilen Endgeräten ermöglicht, wird auf Basis der Android Plattform nicht angeboten und wird daher Gegenstand in der vorliegenden Arbeit thematisiert. 2 Grundlagen 32

38 3 Konzeption Bevor mit der Software Konzeption begonnen werden kann, werden zunächst bestimmte Eigenschaften generischer Prozesse analysiert, die sich in besonderem Maße durch mobile Endgeräte unterstützen lassen. Die ermittelten Erkenntnisse werden in einer groben Anforderungsermittlung und der Vorgehensweise zur Entwicklung des mobilen YAWL Clients verarbeitet. Basierend auf den vorangegangenen Analyseergebnissen, gliedert sich die Konzeption des zu entwickelnden Systems in fünf Blöcke. 3.1 Analyse Potentiale mobiler Workflows Der Planung des mobilen Workflow Managements mit YAWL und Android sind Überlegungen voranzustellen, die sich mit der Fragestellung befassen, welche Arten von Prozessen sich zur mobilen Ausführung in Form eines Workflows eignen und welche Eigenschaften sich besonders durch mobile Endgeräte unterstützen lassen. Hierzu werden im Folgenden bestimmte Aspekte hervorgehoben und deren mobile Charakteristik bestimmt. Dies bildet im weiteren Verlauf die Grundlage für verschiedene Konzepte, die sich speziell unter Einbeziehung nicht stationärer Geräte realisieren lassen. Um die angestrebten Mehrwerte und Ziele eines mobilen YAWL Clients zu konkretisieren, werden exemplarische Szenarien entwickelt. Diese beschreiben Beispiele für einen möglichen Standardablauf und verdeutlichen praktische Anwendungsfälle der mobilen Anwendungsnutzung [Weiterführende Informationen siehe: Pohl, 2008, S. 117ff]. Um eine gute Lesbarkeit des Fließtextes zu gewährleisten, sind die tabellarisch verfassten Szenarien in den Anhang A ausgelagert und werden an den relevanten Stellen referenziert. In einer stark vereinfachender Form lässt sich ein Workflow als IT gestützter Teil eines Geschäftsprozesses zusammenfassen. Eine genauere Definition ist in Abschnitt angegeben. Damit Workflows im Rahmen des Geschäftsprozess Managements ihre volle Wirkung entfalten können, müssen sie bestimmte Eigenschaften erfüllen. Beispielsweise sollte es sich um möglichst häufig wiederkehrende Arbeitsabläufe handeln, die bestenfalls einen hohen Automatisierungsgrad besitzen. Zunächst lässt sich basierend auf diesen Annahmen festhalten, dass der Einsatz von mobilen Endgeräten im Geschäftsprozess Management zu einer breiteren Einsatzmöglichkeit von Workflows und somit IT gestützter Prozessdurchführung beiträgt. Denn für Tätigkeiten, die sich nicht adäquat durch stationäre Hardware unterstützen lassen, ergeben sich durch mobile Geräte neue Möglichkeiten. Im Workflow Management selbst wird ein nicht unerheblicher Teil, der auszuführenden Arbeiten, durch manuelle Tätigkeiten von Personen bestimmt. Durch den Faktor der Mobilität kann ein großes Optimierungspotential erschlossen werden.

39 Die Konzepte des Mobile Computings lassen sich mit dem Workflow Management vereinen und können an verschiedenen Stellen zu einer Effektivitätssteigerung oder erhöhter Prozessqualität beitragen. Es gilt zunächst die Frage zu beantworten, wovon die Mobiltauglichkeit eines Prozesses abhängt. Eine grundlegende Definition ist zu finden in Hartmann [2002, S. 141]: Ein mobiltauglicher Prozess zeichnet sich durch einen möglichst geringen Zusammenhang zwischen den Restriktionen mobiler Endgeräte beziehungsweise denen mobiler Übertragungstechniken und den Prozesstypischen Anforderungen an diese aus. Bei der Bestimmung, wie gut sich ein Workflow mit mobiler Technologie realisieren lässt, gilt es die Anforderungen des Geschäftsprozesses zu ermitteln und diese ins Verhältnis zu den Restriktionen mobiler Endgeräte und kabelloser Übertragungstechnik zu setzen. Die relevanten Einschränkungen spielen gegenwärtig weiterhin eine Rolle, doch der technologische Fortschritt verdrängt diese zunehmend in den Hintergrund. Im Folgenden wird versucht, eine Antwort auf die Frage zu geben, welche konkreten Potentiale sich durch ein mobiles Workflow Management erschliessen Potential: Mobilität Der offensichtlichste Faktor, der sich positiv im Rahmen des Workflow Managements auswirken kann, ist die Mobilität als solche. Die Tätigkeiten eines Arbeitsprozesses sind nicht mehr an Ort und Zeit gebunden, sondern lassen sich theoretisch überall und jederzeit durchführen. Für bestehende Workflows kann eine höhere Flexibilität und eine verkürzte Durchlaufzeit erreicht werden. Müssen beispielsweise bestimmte Ressourcen von einem Vorgesetzten freigegeben werden, muss sich dieser nicht auf die Verwendung eines stationären Geräts beschränken, sondern kann die Freigabe über ein mobiles Endgerät, welches in der Regel ständiger Wegbegleiter ist, direkt erteilen. Die abhängigen Arbeitsschritte können dadurch schneller angegangen werden. Ein exemplarisches Szenario ist in Tabelle A.1 angegeben. Neben der Optimierung bestehender Workflows, finden sich in Unternehmen Geschäftsprozesse, die durch den Faktor Mobilität geprägt sind und bisher nicht praktikabel als Workflows abgebildet werden konnten. Hier erschließt das mobile Workflow Management zusätzliche Potentiale, indem diese Prozesse nun durch IT begleitet und durch ein Workflow Management System gesteuert werden können Potential: Eingabemöglichkeiten Durch mobile Endgeräte eröffnen sich völlig neue Möglichkeiten in Bezug auf die Dateneingabe. Hier ist zunächst die Kamerafunktion zu nennen. Bilder können aufgenommen und direkt mit einem Prozessschritt in Verbindung gebracht werden, beispielsweise um einen Sachverhalt bildlich zu dokumentieren. Ein Beispielszenario ist beschrieben in Tabelle A.2. Weitergehend lässt sich die Kamera verwenden, um Barcodes oder QR Codes zu verarbeiten. Dies ist ein weit verbreiteter Anwendungsfall auf mobilen Endgeräten und lässt sich vielfältig einsetzen. Die codierten Daten werden über die Kamera aufgenommen, dekodiert und sind als alternative Informationseingabemethode zu verstehen. 3 Konzeption 34

40 QR Codes eignen sich hierbei zur Kodierung komplexerer Informationen, wie beispielsweise Texte, Kontaktinformationen oder Kalenderinformationen. Die eingescannten Daten sind sehr schnell erfasst und müssen nicht per Hand eingegeben werden. Tabelle A.3 beschreibt ein mögliches Szenario. Ein weitergehendes Konzept ist direkte Verarbeitung der eingelesenen Code Information auf dem mobilen Gerät. Hierüber lässt sich eine unmittelbare Verknüpfung der eingescannten Daten mit vorliegenden Prozessinformationen realisieren. Vielseitige Anwendungsfälle können hierfür konstruiert werden. In einer Klinik können zum Beispiel Patienten bei ihrer Aufnahme mit einem QR-Code versehen werden, so dass der Arzt diesen Code vor der Behandlung einlesen und ohne zusätzlichen Eingabe oder Suchaufwand an die relevanten Informationen gelangt. Patienten können schneller und effizienter behandelt werden. Ein denkbares Szenario ist angegeben in Tabelle A.4. Neben der Kamera lässt sich das bei mobilen Endgeräten größtenteils verfügbare, berührungsempfindliche Display als zusätzliches Eingabehilfsmittel nutzen. Ein häufiger Anwendungsfall im Unternehmenskontext ist das Unterzeichnen von Dokumenten. Die erforderliche Unterschrift lässt sich direkt auf dem Touchscreen über einen speziellen Stift oder den Finger digital erfassen. Eine unmittelbare Assoziation mit Prozessschritten kann dadurch erwirkt werden. Das Szenario in Tabelle A.5 konkretisiert einen exemplarischen Ablauf zur Erfassung einer berührungssensitiven Unterschrift Potential: Kontextsensitivität Weitreichende Möglichkeiten ergeben sich über die Integration ortsgebundener Informationen in Arbeitsprozessschritte. Hierfür werden Konzepte des Context Awareness (siehe Abschnitt 2.3.3) mit Methoden des Geschäftsprozess Managements kombiniert. In diesem Themengebiet herrscht aktuell ein großes Forschungsinteresse, da die Konzepte klassischer Geschäftsprozesse nicht den neuartigen Anforderungen genügen. Die Kontextinformationen müssen zunächst beschrieben und über die Workflow Modellierung in den Prozess integriert werden [Rosemann und Recker, 2006]. Dies ist die Grundlage für eine Prozessadaption. Das Geschäftsprozess Management passt sich dynamisch an die Gegebenheiten der vorherrschenden Umgebung an. Auf diese Weise kann eine bisher nicht erreichbare Flexibilität im Prozess Management erreicht werden [Rosemann u. a., 2008; Ploesser u. a., 2009]. Kontextinformationen können verschieden geartet sein. Das im Rahmen dieser Arbeit entwickelte Konzept zur Verarbeitung solcher Daten beschränkt sich auf GPS Standortkoordinaten in Form von Längen und Breitengrad. Anwendungsbeispiel für die Nutzung positionsbezogener Informationen gibt es zahlreiche. Zum Beispiel könnten Außendienstmitarbeiter dynamisch zu ihrem aktuellen Standort denjenigen Kunden ermitteln, welcher als nächstes anzusteuern ist. Anreiserouten und Bearbeitungszeiten der jeweiligen Prozessschritte können reduziert werden Anforderungen an den mobilen Client: YAC Die Anforderungen an das zu entwickelnde System leiten sich aus den zuvor definierten Potentialen mobiler Workflows ab. Im Kern steht hierbei die Planung und Umsetzung einer Android Applikation, welche die Interaktion mit einem zentralen YAWL 3 Konzeption 35

41 System ermöglicht. Als Bezeichnung wird für den weiteren Verlauf der Arbeitstitel YAWL Android Client (YAC) verwendet. Der Fokus liegt zunächst auf der Realisierbarkeit eines mobilen YAWL Clients. Aufgrund des Proof of Concept Charakters des Systems wird auf eine ausgedehnte Anforderungsermittlung gemäß etablierter Methoden verzichtet. Um die zu erreichenden Ziele zu konkretisieren beschränkt sich die Anforderungserhebung in diesem Abschnitt auf die funktionalen Eigenschaften und vernachlässigt qualitative Anforderungen [Siehe unter anderem Pohl, 2008]. Im Folgenden werden die zu leistenden Merkmale der Software informell und in textueller Form festgehalten und im Verlaufe des Kapitels konkretisiert. YAC wird mit einem zentralen, Server gestützten YAWL System gekoppelt, so dass die Bearbeitung und Durchführung einzelner Arbeitsschritte mit Android basierten mobilen Endgeräten ermöglicht wird. Die auszuführenden Tätigkeiten sind eingebettet in einen übergeordneten Workflow, der durch das entfernte Workflow Management System gesteuert und kontrolliert wird. Um die Arbeitsfähigkeit auch ohne Netzwerkverbindung zu gewährleisten, wird ein Synchronisierungsmechanismus eingesetzt, der verfügbare Arbeitstätigkeiten lokal speichert und damit eine Offline Bearbeitung der Work Items ermöglicht. Die Synchronisierung erfolgt bidirektional, so dass geladene Datensätze nachdem sie erledigt wurden, zurück ins YAWL System übertragen werden, um dort ihre Auswirkungen zu entfalten. Die Bearbeitung der Work Items erfolgt über eine graphische Benutzerschnittstelle bestehend aus nativen Komponenten der Android Plattform. Der Entwurf des Nutzungskonzepts wird in Abschnitt 3.6 im Detail aufgegriffen und konkretisiert. Eine Erweiterung des YAWL spezifischen Funktionsumfang auf Basis mobiler Eingabemethoden erfolgt exemplarisch. Hierbei werden die folgenden Aspekte berücksichtigt: Die Nutzung der Kamerafunktion zur Aufnahme von Fotos ermöglicht die bildliche Dokumentation der Umgebung und deren Verknüpfung mit Arbeitstätigkeiten. Das Scannen und Verarbeiten von Barcodes und QR Codes dient der schnellen und fehlerfreien Dateneingabe und kann den Anteil manuell eingegebener Daten reduzieren. Eine Eingabe über den Touchscreen ermöglicht die Erstellung von digitalen Unterschriften in visueller Form. Die hierfür generierten Bilddateien lassen sich in den Datensatz eines Work Items einbetten. Die unmittelbare Verknüpfung von eingelesenen QR Codes mit Daten verfügbarer Arbeitstätigkeiten wird realisiert. Das Workflow Management wird erweitert, um ortsgebundene Tätigkeiten. Hierzu werden positionsspezifische Informationen eines Work Items ausgewertet und in Bezug zum aktuellen Standort des mobilen Endgeräts gesetzt. Dies dient als Hilfsmittel für die Ermittlung und Zuweisung von Arbeitsschritten in Abhängigkeit von deren örtlicher Entfernung. 3 Konzeption 36

42 Die im Folgenden thematisierte Planung zur Umsetzung des Systems basiert auf der oben beschriebenen, groben Anforderungsermittlung und konkretisiert diese, zu einem zu realisierenden Konzept, welches den Einklang mit den Projektzielen herstellt Gliederung des Konzepts und Vorgehensmodell Die Gliederung der Systemkonzeption ist abgeleitet aus den Potentialen mobiler Workflows. Es werden fünf zusammenhängende Blöcke identifiziert, die in ihrer Gesamtheit die Planung ausmachen. Abbildung 3.1 veranschaulicht die gewählte Gliederung und deren Zusammenhänge. 3. Ortsgebundene Prozesstätigkeiten 2. Mobile Eingabemethoden 1. Integration des mobilen Clients in die YAWL-Infrastruktur 4. Interne Architektur 5. Entwurf der Benutzeroberflächen Abbildung 3.1: Gliederung der Konzeption in fünf zusammenhängende Blöcke Im Zentrum des Konzepts steht die Integration eines mobilen Clients in die YAWL Infrastruktur, welcher die Ausführung von Workflows auf mobilen Endgeräten ermöglicht. Ausgehend von diesem Fundament, werden ergänzende Eingabemöglichkeiten der Mobilgeräte genutzt, um Zusatznutzen zu generieren. Des Weiteren wird ein Konzept zur ortsgebunden Workflow Durchführung konzipiert, um neuartige Dienste in das Management IT gestützter Geschäftsprozesse zu integrieren und damit ein höhere Dynamik zu erreichen. Die umzusetzenden Aspekte implizieren eine Architektur, welche die internen Komponenten der Android Anwendung und deren Zusammensetzung festlegen. Zum Abschluss der Konzeption werden Benutzeroberflächen entworfen, welche die zu erreichenden Ziele mit den Restriktionen mobiler Endgeräte vereinbaren. Das gewählte Vorgehensmodell im Rahmen der Konzeption und Implementierung orientiert sich lose an den Prinzipien der agilen Softwareentwicklung. Jeder Aspekt, der zuvor stichpunktartig beschriebenen Anforderungsermittlung, wird chronologisch in einen lauffähigen Prototypen umgesetzt und getestet. Inkrementell wird YAC um Funktionalitäten aus den definierten Konzeptblöcken erweitert. Um deren 3 Konzeption 37

43 Korrektheit sicherzustellen, wird in iterativen Zyklen getestet und bei Bedarf eine Überarbeitung des Konzepts sowie der Implementierung vorgenommen. Das Vorgehen gewährleistet eine ergebnisorientierte Arbeitsweise. Sämtliche Schritte finden in reiner Eigenleistung statt, so dass eine Koordination mit weiteren Projektmitgliedern nicht erforderlich ist. 3.2 Block 1: Integration des mobilen Clients in die YAWL Infrastruktur Um YAWL Workflows unabhängig von Ort und Zeit zu machen, wird eine Applikation auf Android Basis entworfen, welche sich vollständig in die Gesamtarchitektur des YAWL Frameworks integriert Entwicklung der Gesamtarchitektur Als einen ersten Schritt im Rahmen der Konzeption wird die erforderliche Integration von YAC über die in Abschnitt 2.2 analysierten Schnittstellen aufgezeigt. Die YAWL Komponenten sind in Form des serviceorientierten Paradigmas miteinander gekoppelt, was eine grundlegende Erweiterungsfähigkeit ermöglicht. Zur Verfügung stehen jeweils mehrere Interfaces auf Seiten der Engine und des Resource Services. Zur Bearbeitung von Prozessschritten, wie es für den mobilen Client vorgesehen ist, eignet sich das Interface B der Engine oder das Workqueue Gateway des Resource Service. Abbildung 3.2 zeigt die verwendeten Schnittstellen und die hierüber geplante Erweiterung der YAWL Architektur. YAWL Engine Interface B Resource Service 1 1 XML over HTTP YAWL Android Client (YAC) Workqueue Gateway Resource Gateway Carrier Notification Header Notification Title 1 notification description Notification Title 2 notification description Notification Title 3 notification description Notification Header Notification Title 1 notification description Clear 1 0..n XML over HTTP 1 0..n XML over HTTP Abbildung 3.2: YAWL Android Client Architektur 3 Konzeption 38

44 Sowohl das Interface B als auch das Workqueue Gateway stellen Methoden bereit, um von außen auf Work Items zugreifen und deren Bearbeitung voran treiben zu können. Das Interface B hat jedoch im Vergleich zum Workqueue Gateway zwei gravierende Nachteile. Zum Ersten ist die Schnittstelle lediglich dahingehend ausgelegt, Work Items zu übergeben und wieder entgegenzunehmen. Die Übergabe muss dabei schon während der Modellierung festgelegt werden. Arbeitsschritte werden dadurch auf eine mobile Ausführung eingeschränkt und könnten nur noch über den speziell zu entwickelnden Custom Service bearbeitet werden. Bearbeitungen über den sonst verwendeten Resource Service werden dadurch ausgeschlossen. Der zweite große Nachteil ergibt sich aus der Tatsache, dass die Engine ausschließlich Hoheit über den Kontrollfluss und die Daten hat. Ein mobiler Client erhält über das Interface B keinen Zugriff auf das mächtige Ressourcenkonzept des Resource Service und müsste somit eigenständig die Zuteilung von Prozessschritten auf verfügbare Akteure implementieren. Das Workqueue Gateway ist eine Erweiterung des Interface B. Es wird vom Resource Service angeboten und bietet Zugriff auf den Aspekt der Ressourcenzuteilung. Die Steuerung des Kontrollflusses und der Zugriff auf Prozessdaten ist hierüber ebenso möglich wie die Verwendung des YAWL Nutzer und Rollenkonzepts. Während der Modellierung von Workflows müssen keine besonderen Einschränkungen beachtet werden. Manuelle Tasks werden wie üblich an den Resource Service delegiert. Dieser übernimmt dann die Zuteilung der Work Items auf verfügbare Nutzer, welche aus der Workflow Definition hervorgeht. Die Bearbeitung kann alternativ über die Web Schnittstelle des Resource Service oder ein mobiles Endgerät erfolgen. YAC erhält Zugriff zum System über die Benutzerzugangsdaten des Resource Service. Hierfür wird das Resource Gateway genutzt über das sich ein Benutzer mit einem Passwort authentifizieren kann. Dadurch ist die Anzahl der integrierten Mobilgeräte beliebig. Innerhalb der Anwendung wird die Nutzerkennung hinterlegt, so dass die Anwendung sich auf die individuellen Aufgaben des jeweiligen Nutzers personalisieren lässt. Die Kommunikation erfolgt wie zwischen allen YAWL Services über HTTP. Ausgetauscht werden dabei XML Dokumente. Die Integration von YAC in die YAWL Architektur erfolgt optimaler Weise über das Workqueue Gateway. Über die Anwendung werden HTTP Request abgesetzt, welche das Workqueue Gateway adressieren. Dieses liefert als Response die angeforderten Informationen codiert über XML. Diese werden auf dem Mobilgerät ausgewertet und können dem User über native Android User Interface (UI) Komponenten präsentiert beziehungsweise von ihm bearbeitet werden. Das Spektrum der Funktionalität, welches mobil genutzt werden kann, wird durch die zur Verfügung stehenden Methoden des Workqueue Gateway beschränkt. Die Schnittstelle stellt jedoch die komplette Bandbreite an Funktionen zur Verfügung, die für eine mobile Workflow Bearbeitung benötigt werden. Kapitel 4.4 befasst sich im späteren Verlauf mit den Details des Interfaces Synchronisation von Work Items Die Tatsache, dass Work Items sowohl über den Resource Service als auch über den mobilen Client bearbeitet werden können, erfordert einen Synchronisierungsmechanismus zwischen beiden Komponenten. Nutzerspezifische Work Items werden auf 3 Konzeption 39

45 das Gerät geladen, dort bearbeitet und können anschliessend in das YAWL System zurück gespielt werden. Hierzu bietet es sich an, die vom Resource Service unterstützten Work Queues zu replizieren und bei erfolgten Änderungen abzugleichen. Bezug nehmend auf die unsichere, kabellose Netzwerkanbindung mobiler Endgeräte sollten Anwendungen, soweit möglich, stets für den Worst Case ausgelegt und entwickelt werden. Datenübertragung sollte minimiert, Übertragungsfehler eingeplant und mit einer trägen Antwortgeschwindigkeit gerechnet werden. Um diesen Anforderungen zu begegnen, setzt YAC ein Synchronisationsverfahren ein, welches auch offline die Arbeitsfähigkeit sicherstellt. Das Aktivitätsdiagramm in Abbildung 3.3 zeigt den Ablauf des Prozesses zur Synchronisierung Nutzer spezifischer Work Items. YAC - Work-Item Synchonisation «Lokale Bearbeitung vorhanden» [ja] Verändertes Work-Item übertragen [nein] Lokale Datenbank zurücksetzen «Work-Item vorhanden» [ja] Work-Item laden [nein] Mobile Erweiterungen vornehmen Persistieren 1. Lokale Änderungen übertragen 2. Datenbank-Reset 3. Verfügbare Work-Items holen Abbildung 3.3: UML Aktivitätsdiagramm: Synchronisierungsprozess Der Synchronisierungsprozess lässt sich grob in drei Phasen gliedern. Zunächst müssen alle Work Items, die sich bereits auf dem Gerät befinden und bearbeitet wurden, zum entfernten YAWL System übertragen werden. Dies geschieht in der ersten Phase, damit im weiteren Verlauf keine getätigten Änderungen verloren gehen. Folgeschritte werden über die Engine gestartet und stehen unmittelbar im Rahmen der dritten Phase zur Aktualisierung bereit. Befinden sich zu diesem Zeitpunkt noch keine Work Items in der Datenbank des Mobilgerätes wird die erste Phase übersprungen. Nachdem alle lokal veränderten Work Items über den Resource Service gesichert sind, wird die lokale Datenbank zurückgesetzt bevor in der dritten Phase alle für den Nutzer verfügbaren Work Items geladen werden. Die Möglichkeiten zur Übertragung von Work Items über das Workqueue Gateway sind hierbei begrenzt. Um Konflikte und Duplikate zu vermeiden, ist ein Zurücksetzen der lokalen Datenbank von Nöten. Eine Liste aller Work Items wird hieraufhin im XML Format 3 Konzeption 40

46 übertragen. Jedes Work Item wird auf dem Mobilgerät in ein Java Objekt überführt. Erforderliche Erweiterungen beziehungsweise Anpassungen werden vorgenommen und in einer relationalen Datenbank auf dem Gerät persistiert. Details zu dem erforderlichen Konvertierungsprozess werden in Abschnitt besprochen. Sind alle Work Items auf diese Weise gespeichert, endet der Synchronisierungsvorgang und die Bearbeitung kann beginnen Arbeitsmodi für den Datenabgleich YAC bietet zwei Arbeitsmodi an, welche unterschiedliche Zeitpunkte festlegen, um veränderte Work Items am Resource Service bekannt zu machen und die Modifikationen zu aktualisieren. Beide Modi setzen einen erfolgreichen, initialen Synchronisierungsvorgang voraus. Im Folgenden werden beide Varianten und deren Unterschiede näher betrachtet. Offline Funktionalität Nach erfolgreicher Synchronisierung befinden sich alle für den Benutzer sichtbaren Work Items auf dem mobilen Endgerät. Um den Restriktionen hinsichtlich Netzverfügbarkeit entgegenzuwirken, wird eine komplette Offline Bearbeitung aller Arbeitstätigkeiten ermöglicht, da die jeweiligen Daten lokal vorliegen. Um dies jedoch zu gewährleisten muss der Lebenszyklus, der standardmäßig durch den Resource Service vorgesehen wird, in der mobilen Applikation abgebildet werden. Hierzu werden die Work Items zunächst gemäß den vier Status (Offered, Allocated, Started und Suspended) gruppiert und ausführbare Aktionen nur in Einklang mit dem jeweiligen Zustand erlaubt (siehe Abbildung 2.4). So kann beispielsweise ein Work Item erst bearbeitet werden, nachdem es akzeptiert und gestartet wurde. Für den Fall der Offline Bearbeitung übernimmt YAC die Herrschaft über den Kontrollfluss. Um bearbeitete Work Items zurück in das YAWL System geben zu können, müssen alle Modifikationen protokolliert und im Zuge der Synchronisierung mit dem Resource Service abgeglichen werden. Hierzu eignet sich die Datenstruktur einer Queue (übersetzt Warteschlange ), die nach dem FIFO Prinzip ( First In First Out ) arbeitet und den chronologischen Ablauf aller Aktionen für jedes Work Item separat protokolliert. Alle Work Items werden mit einer exklusiven Queue versehen und sämtliche Operationen, die sich auf den Lebenszyklus auswirken, werden im Zuge ihrer Ausführung in dieser Datenstruktur eingestellt (enqueue). Dies ist die Grundlage für den Synchronisierungsprozess. Dieser liest alle in der Queue hinterlegten Aktionen aus (dequeue) und ruft die korrespondierende Schnittstellenmethode des Resource Service auf, um die getätigte Änderung bekannt zu machen. Abbildung 3.4 zeigt eine Veranschaulichung dieses Prozesses. Möchte der Benutzer seine erledigte Arbeit ins YAWL System übertragen, so stößt dieser manuell den Synchronisierungsprozess an, sobald Zugang zu einem drahtlosen Netzwerk besteht. Es findet eine Iteration über alle modifizierten Work Items statt. Die zu übertragende Änderung wird in der Queue nachgeschlagen und nach erfolgreicher Übermittlung wird die Aktion aus der Queue gelöscht. Durch die Tatsache, dass der Eintrag erst nach erfolgreicher Übertragung aus der Datenstruktur gelöscht wird, ist dieser Mechanismus robust gegenüber Übertragungsfehlern. Tritt 3 Konzeption 41

47 Sync-Queue Complete Save Start Allocate Accept Lokale Bearbeitung enqueue() Übertragungsprozess dequeue() Abbildung 3.4: Synchronisationsmechanismus auf Basis einer lokalen Queue während der Übermittlung zwischen dem mobilen Endgerät und YAWL ein Fehler auf, so verbleibt diese Aktion in der Queue. Zu einem späteren Zeitpunkt kann der Übertragungsversuch wiederholt werden, ohne das es zu einem Informationsverlust kommt. Der Synchronisierungsmechanismus über eine Queue stellt eine komplette Bearbeitung der Work Items auch ohne Netzverfügbarkeit sicher, jedoch ergibt sich an einer Stelle die Gefahr, dass ein Work Item redundant bearbeitet wird. Dies ist der Fall, wenn sich ein Work Item im Status Offered befindet. Unter Umständen ist der Arbeitsschritt in diesem Zustand mehreren Benutzer oder einer Benutzergruppe angeboten. Entscheiden diese sich für eine Offline Bearbeitung oder sind hierzu gezwungen, weil beispielsweise der Netzzugang gestört ist, so kann dies dazu führen, das ein Work Item von mehreren Nutzern parallel bearbeitet wird. Der Resource Service verhindert diesen Fall normalerweise, indem ein akzeptiertes Work Item aus der Liste der angebotenen Arbeiten gestrichen wird. Ein Akzeptieren, welches nur Offline erfolgt, setzt diesen Kontrollflussmechanismus außer Kraft. Beim Synchronisierungsprozess würde der erste Benutzer das Work Item aktualisieren und abschließen. Diejenigen Benutzer, die zu einem späteren Zeitpunkt ihre Änderungen übermitteln wollen, erhalten eine Fehlermeldung über das Workqueue Gateway. Dieser Problematik kann nur über einen möglichst direkten Abgleich lokaler Änderungen mit dem Resource Service entgegnet werden. YAC sieht hierzu einen optimistischen Übertragungsmodus vor, welcher im folgenden Abschnitt erläutert wird. Live Synchronisation Die Annahme einer gänzlich nicht vorhandenen Netzverfügbarkeit ist zwar im Rahmen des Mobile Computings angebracht, in der Realität tritt dieser Fall jedoch nur noch vereinzelt auf. Um die vollen Potentiale des mobilen Workflow Managements auszuschöpfen, ist ein möglichst zeitnaher Synchronisierungsmechanismus erstrebenswert, welcher getätigte Prozessschritte unmittelbar am Workflow Management System bekannt macht. Dies macht vor allem dann Sinn, wenn es sich bei den Aktionen um eine einzelne Modifikation handelt, bei der kein großes Datenvolumen übertragen werden muss. Einen solchen Ansatz verfolgt der so genannte Live Sync Arbeitsmodus. 3 Konzeption 42

48 Auch dieser Modus bedingt eine initiale Komplett Synchronisierung, um alle verfügbaren Work Items auf das Gerät zu laden. Sobald jedoch eine Aktion lokal in der Queue des Work Items abgespeichert ist, wird unmittelbar versucht, diese Modifikation über ein verfügbares Netzwerk an den Resource Service weiterzureichen. Hierfür ist der Zugang zu einem mobilen Datennetz erforderlich. Ist die Übertragung ins YAWL System erfolgreich, wird der Status des Work Items fortlaufend synchron mit der YAWL Server Instanz gehalten. Schlägt die Übertragung fehl, verbleibt die Aktion in der Synchronisierungsqueue und das Work Item kann in identischer Weise zum Offline Modus weiter bearbeitet werden. Entweder wird bei der nächsten Modifikation ein erneuter Übertragungsversuch der Queue (dann mit zwei oder mehr Einträgen) unternommen oder die komplette Synchronisierung wird von Hand angestoßen, sobald ein zuverlässiges, drahtloses Netzwerk zur Verfügung steht. Der Live Sync Ansatz versteht sich als Kompromiss zwischen direkter Datenübermittlung und unsicherer Netzverfügbarkeit. Die Live Synchronisierung bezieht sich stets nur auf die lokal getätigten Änderungen am Work Item, so dass das zu übertragende Datenvolumen auf ein Minimum reduziert ist. Werden Änderungen unmittelbar an das Workflow Management System weitergegeben, wirkt dies, der im vorangegangenen Abschnitt beschriebenen Problematik, redundanter Bearbeitung einzelner Work Items entgegen. Der Tatsache eventueller Übertragungsfehler wird mit dem Queue Ansatz Rechnung getragen. Für den Fall eines Übermittlungsfehlers wird das spezifische Work Item im Offline Modus betrieben und kann ohne Datenverlust zu einem späteren Zeitpunkt übertragen werden Datenmodell und Konvertierungsprozess Zur Repräsentation eines Prozessschrittes verwendet YAWL intern die Klasse Work- ItemRecord. Diese Datenstruktur sieht alle erforderlichen Attribute zur Abhandlung eines Arbeitsschrittes innerhalb des Resource Services vor. Es bietet sich an, Client seitig eine vergleichbar aufgebaute Klasse zu verwenden, um eine simple Abbildung ( Mapping ) zwischen den Daten zu realisieren. Auf diese Weise können die YAWL Basisattribute auf der Mobilplattform verwendet werden ohne eine komplexe Konvertierung zu durchlaufen. Diese Aufgabe übernimmt die YAC Klasse Mobile- WorkItem. Abbildung 3.5 stellt die Client und Server seitige Klasse gegenüber. Zunächst sind technische Attribute zur internen Verwaltung vorgesehen. Dies ist beispielsweise eine Identifikationsnummer (ID) für den Workflow (Case) und den Prozessschritt (Task). Des Weiteren werden Metadaten verwaltet. So besitzt jede Aufgabe einen Namen, einen Zeitpunkt der Instanziierung, einen Status, einen Initiator sowie zahlreiche weitere Attribute, welche jedoch im Rahmen dieser Arbeit keine Bewandtnis haben. Die eigentlichen fachlichen Daten werden auch auf Java Ebene in XML Strukturen gehalten, welche auf das zugrundeliegende XML Schema eines jeden Workflows zurückzuführen sind. Eine Konvertierung in ein statisches Klassenmodell ist nicht möglich, da jedes Work Item seine eigenen Datenstrukturen definiert. Dies erschwert zwar die Verarbeitung, jedoch wird hierdurch erreicht, generisch zu sein und ein breites Spektrum fachlicher Daten abbilden zu können. XML kann in Java auf verschiedene Arten repräsentiert und verarbeitet werden. Ein gängiges Framework hierfür ist JDOM [jdom.org, 2011]. Ein XML Dokument wird entsprechend seines Aufbaus in eine Baumstruktur abgebildet. Ein Knoten 3 Konzeption 43

49 "Mobile" Parameter int primarykey String caseid String taskid String taskname Date enablementtime String status String resourcestatus String startedby Element datalist Element datalistupdated Element dataschema Element casedata Enum state Queue syncqueue String longitude String latitude float distancetoposition toxml() YAC MobileWorkItem int id String caseid String taskid String taskname String enablementtime String status String resourcestatus String startedby Element datalist Element datalistupdated... toxml() YAWL WorkItemRecord <workitemrecord>... </workitemrecord> MobileResourceMarshaller ResourceMarshaller <workitemrecord>... </workitemrecord> WorkQueueGatewayClient XML over HTTP WorkQueueGateway Abbildung 3.5: Datenmodell eines Work Items und Kommunikationsablauf über das Workqueue Gateway entspricht einem Element und kann beliebige Kindknoten verzweigen. Über den aufspannenden Baum kann beliebig navigiert werden. Das MobileWorkItem verwaltet mehrere solcher JDOM Elemente. Für die Task Daten gibt es eine Datenliste mit den ursprünglichen Werten (datalist) und den Daten, die durch den Benutzer eingegeben oder manipuliert werden (datalistupdated). Zudem werden die Case Daten und das XML Schema des Workflows in JDOM Elementen vorgehalten. Im Vergleich zur Server seitigen Variante des Work Items besitzt das MobileWorkItem zahlreiche Erweiterungen, um auf der Client Seite zusätzliche Funktionalitäten anzubieten. Welche dies genau sind, wird im Verlauf dieser Arbeit noch genauer thematisiert. Im gesamten YAWL System werden sämtliche Datenstrukturen ausschließlich über XML ausgetauscht. Um ein übermitteltes Work Item in ein vorgesehenes Java Objekt zu überführen, verwendet YAWL den so bezeichneter ResourceMarshaller. Dieser nimmt das XML Dokument entgegen, verarbeitet die beinhalteten Informationen und überführt sie in das jeweilige Objekt. Eine identische Komponente wird auch Client seitig benötigt, um die über das Workqueue Gateway gelieferten XML Daten zu einem MobileWorkItem Objekt zu konvertieren. Der hierfür eingesetzt MobileResourceMarshaller basiert daher auf seinem Server Gegenstück und nimmt Anpassungen und Erweiterungen vor. Abbildung 3.5 veranschaulicht den stattfindenden Kommunikationsablauf und Konvertierungsprozess. 3 Konzeption 44

50 3.2.5 Transformation eines XML Schemas in eine Android View Befindet sich ein Prozessschritt in der Bearbeitung durch einen Benutzer, setzt YAWL ein hochdynamisches Konzept ein, um dem Anwender die erforderlichen Daten lesend und schreibend zugänglich zu machen. Die Grundlage bildet das XML Schema eines jeden Work Items. Basierend auf diesem Schema generiert der Resource Service dynamisch Ein und Ausgabemasken in Form von Java Facelets. Diese können über das Web Interface abgerufen sowie die erwarteten Informationen eingegeben und bestätigt werden. Die Daten werden daraufhin über die Parameterliste des Work Items gesichert und an die Engine zurückgegeben. Um Work Items mobil bearbeiten zu können, wird eine vergleichbare Funktionalität benötigt. Das jeweilige XML Schema muss verarbeitet und in eine Android Benutzerschnittstelle überführt werden. Um dies zu realisieren, müssen vorab die über XML Schema definieren Datentypen auf Android UI Komponenten abgebildet werden. Um den Nutzer mit einer graphischen Schnittstelle zu unterstützen, die den Anforderungen mobiler Endgeräte gerecht wird, sieht Android diverse View Komponenten vor, welche Zugriff auf Datenelemente bieten. Die Verhaltensweisen der Komponenten basieren auf den Eigenschaften des jeweiligen Datentyps. Hierdurch wird sichergestellt, dass trotz der dynamischen Generierung, eine gut zu bedienende Benutzerschnittstelle bereitsteht, die auf etablierte Android Konzepte zurückgreift. Abbildung 3.6 zeigt die erforderliche Abbildung von XML Schema Datentypen auf Android View Komponenten. Ein boolescher Wert lässt sich in Form einer CheckBox repräsentieren. Diese können nur aktiviert und deaktiviert werden. Etwas komplizierter wird es bei Datumseingaben, da diese verschiedenen Formate aufweisen können. Um hierfür ein festen Standard zu definieren, stellt Android die DatePicker Komponente bereit. Datumstypen lassen sich hierüber nur in einem eindeutigen Format eingeben. Textuelle Datentypen wie beispielsweise ein xs:strings werden über die Edit- Text Komponente unterstützt. Diese besteht aus einem Eingabefeld und einer On Screen Tastatur, über welche Zeichenketten eingegeben werden. Numerische Datentypen lassen sich über XML Schema in verschiedenen Formaten definieren. xs:integer, xs:long oder xs:float sind nur einige hiervon. Eine dedizierte Komponente sieht Android nicht vor, jedoch lässt sich die EditText Komponente mit dem Attribut InputType.Number betreiben. Die sich öffnende Touchscreen Tastatur besteht in diesem Kontext nur aus numerischen Eingabewerten. Enumerationen oder Auswahllisten werden in XML Schema als Restriction definiert. Für den Benutzer bedeuten diese Typen in der Regel, dass aus einer vorbestimmten Menge an Elementen ein Objekt selektiert werden muss. Für diesen Anwendungsfall nutzt Android die Spinner Komponente. Angezeigt wird lediglich das ausgewählte Element. Soll dies geändert werden, öffnet sich durch einen Klick eine Listenansicht mit allen Objekten, die die zur Auswahl stehen. Diese schließt sich, sobald ein Element ausgewählt wurde. 3 Konzeption 45

51 XSD Datentypen Android-Tag Android-View-Komponente Logischer Datentyp: <xs:boolean> <CheckBox> / Datumstyp: <xs:date> <DatePicker> Nummerische Datentypen: <xs:integer>, <xs:long>,... <EditText android:inputtype= "number"> Input Box Textuelle Datentypen: <xs:string>,... <EditText> Input Box Binärer Datentyp: <xs:base64binary> <ImageButton> Enumeration: <xs:restriction> <Spinner> Selector List View List Item1 List Item2 Abbildung 3.6: Abbildung von XML Schema Datentypen auf Android View Komponenten Auch wenn XML vom Grundsatz her ein Zeichenketten basiertes Format ist, können auch binäre Datentypen in einem Dokument übertragen werden. Dazu wird in der Regel die Base64 Kodierung eingesetzt. Dieses Verfahren konvertiert Binärdaten in ASCII Zeichenfolgen, so dass diese beispielsweise in XML eingebettet und übertragen werden können. Auf diese Weise können unter anderem Bilddateien ausgetauscht werden. Um dies in Form einer Android Komponente zu unterstützen, werden xs:base64binary Datentypen dekodiert und bei Erfolg das resultierende Bild über die ImageButton Komponente dargestellt. Der Button dient des Weiteren dazu interaktiv, beispielsweise über die Kamerafunktion, das Generieren einer neuer Bilddatei anzufordern. Diese Funktionalität wird in Abschnitt genauer betrachtet. Um auch komplexe Datentypen zu unterstützen, macht sich das Konzept zu Nutze, dass sowohl XML Schema als auch Android Views in einer Baum artigen Struktur vorliegen und sich Elemente ineinander verschachteln lassen. Zusammengesetzte Datentypen werden in einer View gruppiert. Die Zusammengehörigkeit wird dann über einen Rahmen kenntlich gemacht. Verschachtelungen betten eine View in eine übergeordnete Hierarchie ein. Komplexe Datenstrukturen können dem Nutzer auf diese Weise in ihrer Zusammengehörigkeit präsentiert werden. Abbildung Konzeption 46

52 XML-Schema notiz Android-View LinearLayout "notiz" person text LinearLayout "person" LinearLayout "text" vorname nachname LinearLayout "vorname" LinearLayout "nachname" TextView "text" EditText "text" TextView "vorname" EditText "vorname" TextView "nachname" EditText "nachname" <xs:element name="notiz"> <xs:complextype> <xs:element name="name" type="xs:string"> <xs:complextype> <xs:element name="vorname" type="xs:string"> <xs:element name="nachname" type="xs:string"> </xs:complextype> </xs:element> <xs:element name="text" type="xs:string"/> </xs:complextype> </xs:element> notiz person vorname name text Abbildung 3.7: Konvertierung eines XML Schema Dokuments in ein Android UI versucht das gesamte Konzept zu veranschaulichen. Prinzipiell ist es über dieses Verfahren möglich, beliebig tiefe Hierarchien zu transformieren und abzubilden. Jedoch sollte beachtet werden, dass mit steigender Komplexität der Datentypen die Übersichtlichkeit auf den limitierten Anzeigemöglichkeiten mobiler Endgeräte leidet. Ein XML Schema Element kann mit bestimmten Einschränkungen (engl. restrictions) belegt werden. Hierdurch kann beispielsweise erlaubt werden, dass ein Element mehrfach in einem Dokument vorkommt. Um die Unter und Obergrenzen zu bestimmen, wie oft ein Element mindestens vorkommen muss, respektive maximal vorkommen darf, können die Attribute minoccurs und maxoccurs verwendet werden. Innerhalb der hier festgelegten Grenzen, muss die Android View also das Hinzufügen beziehungsweise Löschen von Elementen erlauben. Auch diese Funktionalität wird über die Baumstruktur gelöst. Um Elemente hinzuzufügen, wird der entsprechende Vaterknoten innerhalb der View Hierarchie ermittelt, der gesamte Sub Tree repliziert und dem Vaterknoten zugewiesen. Für den Löschvorgang muss lediglich der jeweilige Sub Tree entfernt werden. Die Änderungen nehmen unmittelbar Einfluss auf die Zusammensetzung und Darstellung der View Komponenten. Eine detaillierte Beschreibung dieses Vorgangs wird in Kapitel 4.9 vorgenommen. 3.3 Block 2: Mobile Eingabemethoden Alle bis zu diesem Punkt erarbeiteten Konzepte zielen darauf ab, bestimmte Teile der Funktionalitäten des YAWL Resource Services auf die Android Plattform zu überführen. Im Fokus steht hierbei der Aspekt der Mobilität. Interaktion mit dem YAWL Workflow Management System wird dadurch unabhängig von Ort und Zeit. Um jedoch die vollen Potentiale des mobilen Workflow Managements auszuschöp- 3 Konzeption 47

53 fen, werden in den folgenden Abschnitten erweiternde Konzepte konstruiert, welche aus den besonderen Funktionen und Eigenschaften mobiler Endgeräte entstehen. Diese Vorhaben lassen sich auf stationären Geräten nur sehr schwer und teilweise überhaupt nicht umsetzen. Zunächst werden spezielle Eingabemethoden eingebunden, welche von einem Großteil mobiler Endgeräte unterstützt werden. Die Informationseingabe auf mobilen Endgeräten über berührungsempfindliche Bildschirme gestaltet sich in der Praxis meist wenig komfortabel. Die üblicherweise genutzten On Screen Tastaturen sind klein, so dass die Eingabe sehr gezielt erfolgen muss. Eine haptische Rückmeldung der Eingabe, wird über Touchscreens nicht vermittelt. Die Folge sind häufige Fehleingaben. Jedoch bieten mobile Endgeräte eine Reihe innovativer Eingabemethoden, um der beschriebenen Problematik entgegen zu wirken. Diese werden im Folgenden in den Kontext des Workflow Managements gesetzt, so dass eine Integration der Eingabekonzepte in die Bearbeitung von Arbeitsprozessschritten stattfindet Kameranutzung Mittlerweile werden mobile Endgeräte fast ausnahmslos mit einer Kamera ausgeliefert, um unterwegs Bilder und Videos aufnehmen zu können. Es ist daher naheliegend im Rahmen des mobilen Workflow Managements auf diese Funktion zurück zu greifen. In Anlehnung an das Sprichwort ein Bild sagt mehr als tausend Worte, lassen sich über die Kamera erzeugte Bilddateien an Prozessschritte anhängen, um vorherrschende Umgebungsinformationen zu dokumentieren. Die Anwendungsmöglichkeiten innerhalb des Geschäftsprozess Managements sind vielfältig und abhängig von der Domäne in der ein Workflow platziert ist. Um nur ein Beispiel aus der Versicherungsbranche zu nennen, ist durch das Verfahren die Möglichkeit geschaffen, mobil aufgezeichnete Bilder zur Dokumentation eines Schadensfalls direkt in den Workflow der Fallabwicklung zu integrieren. Hierdurch wird eine Konvergenz der Prozessabwicklung mit dem Dokumenten Management erzielt. Die Planung dieser Funktionalität wird durch die Tatsache erschwert, dass YAWL in der derzeit aktuellen Version keine Unterstützung für binäre Daten vorsieht, um diese an Work Items anzuhängen. Über einen kleinen Umweg lässt sich diese Fähigkeit jedoch auf den mobilen Clients konzipieren, ohne Änderungen am Server seitigen YAWL System vornehmen zu müssen. Grundlage ist der XML Schema Datentyp xs:base64binary. Über diesen lassen sich binäre Bilddaten zwischen YAWL und YAC austauschen. Das im Folgenden geschilderte Vorgehen ist hierfür geplant. Definiert ein Work Item einen Input Parameter als binären Datentyp, so wird dieser im Rahmen der mobilen Bearbeitung mit der Android Komponente ImageButton versehen. Die Komponente übernimmt dabei zwei Zuständigkeiten. Zum Einen können Bilddaten in gängigen Formaten angezeigt werden und zum Anderen wird eine Klick Interaktion angeboten, um die Aktivität der Bilderzeugung beispielsweise über eine Kameraaufnahme zu initiieren. Ist eine Variable mittels Base64 kodiert und mit einer Zeichenkette belegt, wird automatisch ein Dekodierungversuch gestartet. Ist dieser erfolgreich wird das resultierende Bild in Bildschirm angepasster Größe innerhalb des Buttons angezeigt. Ist der String leer oder die Dekodierung fehlerhaft, wird der Button ohne Bild darge- 3 Konzeption 48

54 stellt. Über einen Klick weist der Benutzer die Kamera an ein Bild aufzunehmen. Eine neue Ansicht öffnet sich, in der eine Vorschau das aktuelle Motiv zeigt. Auf einen weiteren Klick wird die Aufnahme ausgelöst. Das Foto wird unmittelbar mittels Base64 kodiert und im vorgesehenen Parameter des Work Items gespeichert. Eine automatische Rückkehr zur ursprünglichen Ansicht findet statt und das neu generierte Bild wird über den Button dargestellt. Im Rahmen des Synchronisierungsprozesses werden die Base64 kodierten Zeichenketten ohne weiteren Aufwand in das zu übermittelnde XML Dokument eingebunden und an den Resource Service zurückgegeben. Server seitig findet aufgrund der fehlenden Unterstützung binärer Datentypen keine Dekodierung statt. Dies ist eine Funktionalität die ausschließlich von YAC unterstützt wird und nur über mobile Clients genutzt werden kann Barcode Scanning Die Kamera Funktion mobiler Endgeräte beschränkt sich nicht nur auf die Aufnahme von Fotos, sondern ermöglicht auch weitergehende Eingabe Konzepte. Ein gängiger Anwendungsfall ist das Einlesen und Verarbeiten von Barcodes oder QR Codes. Hierzu wird die Kamera auf den einzulesenden Code gerichtet. Eine spezielle Software analysiert die gelieferten Bilder und dekodiert die Code Informationen, sobald diese fehlerfrei durch die Kamera aufgezeichnet wurden. Optische Codes als Informationsträger sind in diversen Standards beschrieben. Barcodes bestehen aus verschieden breiten, parallelen Strichen und Lücken und werden daher auch als Strichcode bezeichnet. Die Informationsabbildung erfolgt eindimensional, so dass das codierte Datenvolumen stark limitiert ist und sich meist auf kurze Zahlenfolgen beschränkt. Barcodes werden größtenteils im Handel zur Kennzeichnung von Produkten eingesetzt. Standards in diesem Bereich ist die European Article Number (EAN) oder der Universal Product Code (UPC). Zweidimensionale QR Codes bilden Informationen in der Fläche ab. Sie bestehen aus einer quadratischen Matrix weißer und schwarzer Punkte. In drei Ecken befindet sich ein spezielles Markiererquadrat, um die Orientierung des QR Codes kenntlich zu machen. Prinzipiell lassen sich beliebige Informationen in Form von QR Codes ausdrücken. Je nach Symbolgröße (21x21 bis 177x177 Zeichen) eignen sich QR Codes um komplexere Informationen bis zu Datenvolumen von 4296 alphanumerischen Zeichen zu kodieren [Denso-Wave, 2004]. QR Codes kodieren Zeichenketten. Um die beinhalteten Daten in einer definierten Weise verarbeiten zu können, schlägt das Projekt ZXing eine Liste verschiedener QR Datentypen vor [zxing, 2010]. Tabelle 3.1 zeigt einen Ausschnitt der vorgeschlagenen Datentypen und deren textuellen Aufbaus. Um Barcodes auf der Android Plattform zu verarbeiten, entwickelt das Open Source Projekt ZXing die Anwendung Barcode Scanner. Ist diese Software auf einem Gerät installiert, lässt sich deren Funktionalität in die eigene Anwendung integrieren. Hierzu kann das Einlesen eines Barcodes über einen speziellen Android Intent angefordert werden. Dieser sorgt dafür, dass sich eine Kameravorschau öffnet, welche einen markierten Bereich aufweist, in der der Code platziert werden muss. 3 Konzeption 49

55 Datentyp Textueller Aufbau Beispiel URL [url] E Mail Adresse mailto:[ ] Telefonnummer tel:[number] tel: SMS sms:[number]:[subject] sms:123456:example SMS Geo. Information geo:[lat],[lon],[alt] geo: , ,100 Kontaktinformation MECARD:N:[name]; MECARD:N:Owen,Sean; ADR:[address]; ADR:Example Street 11 in Town; TEL:[number]; TEL: ; [ ];; Tabelle 3.1: QR Code Datentypen Textueller Aufbau und Beispiel Die Applikation erkennt automatisch, um welche Art von Code es sich handelt, dekodiert die eingelesenen Daten und liefert die Information in Form eines Strings an die aufrufende Anwendung zurück. YAC unterstützt die Informationseingabe über Barcodes oder QR Codes auf zwei verschiedene Arten. Beide beziehen sich auf die Eingabe textueller Information in Formularfelder eines Work Items im Rahmen der Bearbeitung. Explizite Eingabe via Barcodes Diese Eingabevariante bezieht sich auf einen explizit vom Nutzer gewählten String Parameter eines Work Items. Dieser wird über die Eingabemaske selektiert. Über das Kontext-Menü der korrespondierenden Android Komponente EditText wird das Scannen eines Codes als Eingabemethode gewählt. Nach einer erfolgreichen Scan Operation beliebiger Codetypen wird der resultierende String ohne weitere Verarbeitung als Wert in das Textfeld eingetragen. Dieser Scan Modus eignet sich, sofern die Code Informationen in unstrukturierter Form, beispielsweise als einfacher Fließtext, vorliegen und keine weitere Auswertung benötigen. Des Weiteren muss dem Nutzer der Eingabeparameter bekannt sein, welcher mit Code Information zu befüllen ist. Unter diesen Bedingungen kann ein solches Verfahren die Dateneingabe wesentlich komfortabler gestalten als die Information von Hand einzugeben. Die Einlese und Verarbeitungsprozedur geschieht in wenigen Sekunden, was dazu führt dass auch komplexe Informationen mit größerem Volumen in kürzester Zeit eingegeben werden können. Dies kann unter Umständen massiv zu einer Verkürzung der Prozessbearbeitung beitragen. Automatische Formularausfüllung mit QR Codes Dieser Barcode Verarbeitungsmodus geht über die Möglichkeiten der expliziten Eingabe hinaus, erfordert jedoch, dass Code Informationen in strukturierter Form vorliegen. QR Codes erfüllen diese Anforderung und sind die Basis für das Verfahren. Strukturierte QR Datentypen setzen sich aus Schlüssel Wert Paaren zusammen, siehe Tabelle 3.1. Diese Eigenschaft kann genutzt werden, um komplette Eingabemasken bestehend aus mehreren Parametern mit einer einzigen Scan Operation zu befüllen. Hierzu wird die eingelesene Zeichenkette nicht unmittelbar ausgegeben, 3 Konzeption 50

56 sondern weiterverarbeitet. Die Schlüssel Wert Paare, welche über ein Semikolon voneinander getrennt sind, werden ermittelt. Anschließend werden die Schlüssel in den erforderlichen Eingabeparametern des Work Items gesucht. Bei Übereinstimmung wird der eingescannte Wert automatisch dem jeweiligen Parameter zugewiesen. Abbildung 3.8 verdeutlicht diesen Vorgang an einem Beispiel. Im Kontext von YAC wird dieses Feature als QR Form Fill bezeichnet. 1. Formular 2. Scannen 3. Verarbeiten 4. Eintragen Enter Contact Information N ADR TEL Scan code MECARD:N:Owen,Sean; ADR:Example Street 11 in Town; TEL: ; Enter Contact Information N Owen, Sean ADR Example Street in Town TEL Scan code Abbildung 3.8: Beispiel der automatischen Formularausfüllung mittels strukturierter QR Code Informationen Das Beispiel orientiert sich am QR Datentyp für Kontaktinformationen. Innerhalb eines Workflow könnte eine Tätigkeit darin bestehen, Daten in dieser Form beispielsweise von einem neuen Kunden zu erheben. In einem ersten Schritt öffnet der Nutzer das entsprechende Eingabeformular des Work Items. Hierüber kann er die Scan Operation starten. Die dekodierte Zeichenkette wird YAC zurückgeliefert und in beinhaltete Schlüssel Wert Paare zerlegt. Im Beispiel ist - ein solches Paar. Da das Work Item einen Eingabeparameter ( ) mit identischer Schlüsselbezeichnung trägt, wird der jeweilige eingescannte Wert zugewiesen. Ein solcher Abgleich wird für alle Schlüssel Wert Paare unternommen. Wird ein Schlüssel nicht in einem Eingabeformular gefunden, so wird seine Information verworfen. Da im abgebildeten Beispiel alle Schlüssel ein entsprechendes Eingabefeld finden, kann die gesamte Maske mit einer einzigen Scan Operation ausgefüllt und so die Bearbeitungszeit erheblich verringert werden. QR Codes weisen die Eigenschaft auf, dass die Datentypen nicht Bestandteil der Standardisierung sind. Die Definition bezieht sich lediglich auf das Verfahren, visuelle Information in Zeichenketten umzuwandeln. Das bedeutet, dass sich ohne weiteres neue, eigene Datentypen festlegen lassen. Im Rahmen der Workflow Modellierung werden hierfür unternehmensintern Konventionen vereinbart, um eine automatische Formularausfüllung über QR Codes zu ermöglichen. Ausführende Personen müssen zur Bearbeitung lediglich den entsprechenden Code scannen, die eingelesenen Daten überprüfen, gegebenenfalls verbessern und abschicken. Das entstehende Optimierungspotential ist je nach Anwendungsfall enorm. 3 Konzeption 51

57 3.3.3 Berührungssensitive Eingabe: Digitale Unterschrift Ein Anwendungsfall, welcher häufig im Unternehmenskontext anzutreffen ist, ist die handschriftliche Unterzeichnung eines Dokuments. Beispielsweise muss ein Bevollmächtigter, der bestimmte Ressourcen freigeben soll, dies mit seiner Unterschrift bestätigen. Diese lässt sich in der Regel eindeutig einer Person zuordnen und kann als eine Identitätsbestätigung angesehen werden. Um entsprechende Geschäftsprozesse möglichst effizient zu machen, werden optimaler Weise zu tätigende Unterschriften im Rahmen eines Workflows in digitaler Form geleistet und unmittelbar in einem Arbeitsschritt integriert. Hierfür eignet sich der Einsatz eines mobilen Endgeräts. Über die berührungssensitive Oberfläche kann eine Unterschrift mit einem speziellen Stift oder mit dem Finger ausgeführt werden. Es findet eine unmittelbare visuelle Digitalisierung statt. Diese Möglichkeit wird von YAC folgendermaßen unterstützt: Zunächst wird ein Parameter über das Work Item benötigt, welcher eine Eingabe im Base64 Format erwartet, da die digitalisierte Unterschrift als Bilddatei gespeichert wird. Über den repräsentierenden ImageButton kann YAC veranlasst werden, die Aktivität zur Eingabe der digitalen Unterschrift zu starten. Innerhalb eines festgelegten Bereichs, kann der Nutzer die Unterschrift direkt auf dem Touchscreen ausführen. Die gezeichneten Pfade werden wahrgenommen und die Ansicht unmittelbar aktualisiert. Die Unterschrift ist für den Nutzer direkt sichtbar. Ist die Unterzeichnung abgeschlossen, wird dies vom Nutzer bestätigt. Der vordefinierte Unterschriftsbereich wird in eine Bilddatei transformiert und mittels Base64 als Zeichenkette kodiert. Die Darstellung im Bearbeitungsformular des Work Items übernimmt der auslösende ImageButton. Die Übermittlung der Bildinformation zum YAWL System erfolgt in identischer Weise zur Kameranutzung (siehe Abschnitt 3.3.1). Die unmittelbare Digitalisierung der Unterschrift sorgt im Rahmen des Geschäftsprozess Managements zu einer Verringerung der Medienbrüche und der Durchlaufzeiten. Die Unterschrift wird nicht, wie sonst meist üblich, auf einem Papierdokument geleistet, sondern steht direkt in digitaler Form zur Verfügung. Dies schafft die Voraussetzung für eine sofortige Assoziation mit einem Prozessschritt und bedeutet einen weiteren Schritt in Richtung papierloses Büro, einem Ziel, dass von vielen Unternehmen im Rahmen des Dokumenten Managements verfolgt wird Suchfunktion Die Darstellungsmöglichkeiten auf mobilen Endgeräten sind limitiert. Je nach Anzahl der zur Verfügung stehenden Work Items beziehungsweise der Komplexität der Prozessdaten kann es für den Nutzer schwierig werden, die Übersicht zu behalten. Dies erschwert und verzögert die Navigation. Hier ist eine Suchfunktion hilfreich. Kennt der Nutzer sein Ziel oder assoziiert er bestimmte Begriffe mit einem zu erledigenden Arbeitsschritt, sorgt die Suchfunktion für eine Eingrenzung der auswählbaren Work-Items und trägt zu einer zielgerichteten Navigation bei. Um diese Funktionalität zu unterstützen, stellt YAC ein Eingabefeld bereit, über das sich ein Suchbegriff eingeben lässt. Hieraufhin werden alle lokal verfügbaren Daten der Work Items auf die eingegebene Zeichenkette hin untersucht. 3 Konzeption 52

58 Über eine spezielle Ansicht stehen lediglich diejenigen Work Items zur Auswahl, deren Daten eine Übereinstimmung mit dem Suchbegriff aufweisen. Auf diese Weise muss sich der Nutzer nicht eigenhändig durch die verschiedenen Listen der zu bearbeitenden Einträge suchen, sondern erfährt eine optimale Unterstützung durch das System Codes als Suchbegriff Eine Suchfunktion kann Nutzern helfen, schneller an das gewünschte Ziel zu gelangen. Hierfür müssen sie jedoch zum Einen wissen, welchen Begriff sie suchen müssen, um die Ergebnismenge ausreichend einzuschränken. Und zum Anderen muss der Eingabeprozess eigenhändig erfolgen. Manuelle Eingaben erfordern je nach Schnelligkeit des Benutzers eine bestimmte Zeitspanne. An dieser Stelle lassen sich mobile Endgeräte in Kombination mit Barcodes oder QR Codes einsetzen, um die manuellen Eingaben zu automatisieren beziehungsweise diese zu beschleunigen. YAC ermöglicht es Barcodes oder QR Codes einzuscannen und die resultierenden Informationen als Suchbegriff zu verwenden. Die im vorangegangenen Abschnitt beschriebene Suchfunktion findet an dieser Stelle eine Wiederverwendung. Die dekodierte Zeichenkette wird als Suchwort eingesetzt. Über dieses Verfahren wird eine unmittelbare Assoziation von Code Informationen mit lokal verfügbaren Work Item Daten erreicht. Ohne Vorwissen zu einem Prozessschritt haben zu müssen und ohne eine eigenhändige Informationseingabe, gelangt der Nutzer zum auszuführenden Arbeitsschritt und der verknüpften Daten. Unter Umständen lässt sich das Workflow Management durch eine solche Methode enorm verbessern. Vorstellbar ist beispielsweise eine Nutzung in Kliniken. Alle Patienten werden bei ihrer Aufnahme mit einem QR Code versehen. Bestimmte Behandlungen laufen nach einem definierten Schema ab, welches sich als Workflow modellieren und IT unterstützt ausführen lasst. Der Arzt kann mit seinem mobilen Endgerät den Code des Patienten scannen und bekommt automatisch Zugang zu den Daten des Patienten und Auskunft darüber, welche Behandlung auszuführen ist. Dies würde eine Entlastung für Ärzte bedeuten und trüge zu einer gesteigerten Patientenversorgung bei. Aber auch in anderen nicht medizinischen Fachbereichen hätte ein solches Verfahren bisher nicht erhobene Potentiale. 3.4 Block 3: Ortsgebundene Prozesstätigkeiten Der dritte Aspekt mobiler Workflows, welcher bisher noch nicht thematisiert wurde, ist die Kontextsensitivität. Im folgenden Abschnitt wird ein Konzept erarbeitet, welches unter Verwendung von YAWL und mobilen Endgeräten einen Mehrwert aus Ortsinformationen generiert. Prozessschritte werden mit Ortsinformationen versehen und können als solche auf Mobilgeräten ausgelesen werden. Über einen integrierten GPS Empfänger kann die eigene Position lokalisiert und damit die Distanz zum Arbeitsschritt ermittelt werden. Zunächst wird die Fragestellung behandelt, welche Arten von Ortsbeschränkungen im Rahmen des Workflow Managements existieren und auf welche Weise diese auf mobilen Endgeräten interpretiert werden können. 3 Konzeption 53

59 Das Ortskonzept, welches in der vorliegenden Arbeit beschrieben und im späteren Verlauf umgesetzt wird, bezieht sich auf Überlegungen von Decker u. a. [2010]. Aus Gründen der Komplexität wird es jedoch leicht vereinfacht und auf die für diese Arbeit relevanten Aspekte reduziert. Abbildung 3.9 zeigt die resultierende Kategorisierung von Ortsbeschränkungen in Form eines Binärbaums. Ortsbeschränkung direkt indirekt Positiv Negativ Automatisch Manuell Positiv Negativ Positiv Negativ Abbildung 3.9: Kategorisierung von Ortsbeschränkungen im Rahmen des Workflow Managements in Anlehnung an [Decker u. a., 2010] Decker u. a. [2010] definieren eine Ortsbeschränkung als eine Angabe zu einem Ort an dem eine Aktivität eines Prozesses ausgeführt werden muss (positiv) oder eine Ausführung nicht erlaubt ist (negativ). Eine Ortsangabe im Workflow Management ist demnach grundsätzlich positiv oder negativ zu interpretieren. Dies wird über die Blätter des abgebildeten Binärbaums kenntlich gemacht. Eine Besprechung mit einem Kunden ist ein Beispiel für eine positive Ortsangabe, da ein solches Treffen nur unter Anwesenheit des Kunden an einem zuvor festgelegten Ort stattfinden kann. Als Gegenbeispiel hierzu kann es Aktivitäten geben, die in einigen Ländern aufgrund von Gesetzen oder Normen verboten sind. Dies wird über eine negative Ortsangabe kenntlich gemacht. Zunächst lassen sich Ortsbeschränkungen über das Kriterium direkt oder indirekt aufteilen. Man spricht von einer direkten Ortsangabe, wenn diese bereits zur Workflow Modellierung feststeht und somit unmittelbar in jeder Workflow Instanz gesetzt ist. Ein Beispiel hierfür wäre ein Fahrer eines Logistikbetriebs, der Lieferungen zunächst stets an eine Zentrale überführen muss. Die Ortsinformation ist für alle Workflow Instanzen unveränderlich und steht bereits während der Instanziierung fest. Eine höhere Dynamik bieten indirekte Ortsbeschränkungen. Die jeweilige Ortsangabe wird hierbei erst im Laufe der Workflow Ausführung im Rahmen eines Prozessschrittes ermittelt und festgelegt. Dies kann entweder automatisch oder manuell erfolgen. Die automatische Bestimmung kann beispielsweise von einem Web Service übernommen werden, der zu einem Kunden entsprechende Adressinformationen über eine Datenbank nachschlägt und diese ohne weiteres Dazutun als Ortsbeschränkung in die Prozessinstanz einträgt. Im Gegensatz dazu könnte dieser Schritt auch von einem unternehmensinternen Mitarbeiter übernommen werden. Hierbei spräche man von einer manuell ermittelten Ortsangabe. 3 Konzeption 54

60 Ortsbeschränkungen sind kumulativ. Das bedeutet, dass mehrere Ortsbedingungen angegeben werden können und diese in ihrer Gesamtheit für die Aktivitätsausführung erfüllt sein müssen. Aus Gründen des Umfangs wird sich die vorliegende Arbeit auf einfache und konkrete Ortsangaben beschränken. Der weitere Verlauf wird sich schwerpunktmäßig auf positive Ortsbeschränkungen stützen, da diese aus Sicht der Optimierung des Workflow Managements größere Potentiale erwarten lassen. Eine Erweiterung um negative Ortsangaben lässt sich jedoch ebenso mit dem folglich beschrieben Konzept realisieren. Nachdem erläutert ist, welche Facetten eine Ortsbeschränkung im Workflow Management hat und welche Bedeutung sie annehmen kann, gilt es zu klären, wie sich diese Informationen in YAWL Workflows integrieren lassen und wie diese dann auf mobilen Endgeräten verarbeitet werden können, um hieraus folglich einen Zusatznutzen zu generieren. Wie bereits in den vorangegangenen Abschnitten geschildert, ist jedes Work Item mit einem Satz fachlicher Daten verknüpft, die für einen lesenden sowie schreibenden Zugriff vorbestimmt sind. Nach erfolgter Synchronisierung liegen diese Informationen lokal auf dem mobilen Endgerät zum Abruf bereit. Um nun Prozessschritte mit Ortsinformationen zu versehen, können diese als Parameter in den Datensatz eines Work Items integriert werden. Hierfür wird eine bestimmte Konvention benötigt, um auf der mobilen Plattform zu erkennen, dass es sich um eine solche Ortsbeschränkung handelt. Dies kann beispielsweise unternehmensintern vereinbart und im Rahmen der Workflow Modellierung umgesetzt werden. Ortsinformationen über GPS werden in Form einer zweielementigen Koordinate angegeben, bestehend aus dem Längen und Breitengrad, welche für die Erdoberfläche festgelegt sind. Liegt eine Ortsbeschränkung für eine Arbeitstätigkeit vor, so lassen sich die Parameter longitude (Längengrad) und latitude (Breitengrad) dem Datensatz des Work Items hinzufügen und können gemäß dieser Konvention auf den Mobilgeräten verwertet werden. Der eigentliche Zusatznutzen zur Optimierung des Workflow Managements ergibt sich jedoch nicht durch die reine Verfügbarkeit einer Ortsbeschränkung, sondern durch deren Interpretation. So lässt sich über den GPS Empfänger eines mobilen Endgeräts der aktuelle Aufenthaltsort ermitteln und diesen in Bezug zur Ortsangabe des Work Items setzen. Die Distanzen zur auszuführenden Arbeit sind ablesbar und aktualisieren sich dynamisch zur eigenen Positionsänderung. Durch diese Möglichkeit lässt sich beispielsweise das Traveling Salesman Problem (TSP) approximieren, einem Anwendungsfall, der in verschiedenen fachlichen Domänen zu finden ist. Hierbei geht es darum, für einen Reisenden, die Route für den Besuch mehrerer Ort so zu wählen, dass die gesamte Reisestrecke inklusive der Rückkehr zum Ausgangsort möglichst gering ist. Das TSP gilt als eines der schwierigsten Optimierungsprobleme in der Kombinatorik und wird in der Praxis nur über Approximationsalgorithmen gelöst. Als Alternative zu einer vorbestimmten Route, eignet sich der Einsatz mobiler Endgeräte und die Nutzung positionsbezogener Dienste. Der Reisende kann hierüber stets ablesen, zu welcher Tätigkeit er die geringste Entfernung hat. Steuert er ausschließlich die Aktivität mit der kürzesten Distanz an, verfolgt er eine so genannte Greedy Strategie, welche als Approximation für das TSP dient. Eine solche Vorgehensweise liefert nicht unbedingt die optimale Lösung. Unter 3 Konzeption 55

61 bestimmten Voraussetzungen kann jedoch gezeigt werden, dass eine obere Grenze für die maximale Abweichung zur optimalen Lösung existiert [Witt, 2008, S. 48ff]. Im besten Fall liefert ein Greedy Vorgehen die optimale Lösung. Im schlechtesten Fall weicht die Lösung maximal um einen bestimmten Faktor von der optimalen Lösung ab. Eine dynamische Bestimmung der Reiseziele über mobile Endgerät hat gegenüber einer vorbestimmten Route den großen Vorteil, dass im Verlaufe der Reise weitere Zielorte hinzukommen beziehungsweise wegfallen können und dies unter Umständen unmittelbar in die aktuell verfolgte Route einbezogen werden kann. Solche Ausnahmefälle sind über das TSP nicht abgedeckt. Der mobile Arbeiter aktualisiert seine Work Items, bevor er sein nächstes Ziel ansteuert und ermittelt, welches die örtlich nächstgelegene Aktivität ist. Aus Perspektive des Workflow Managements trägt ein solches Verfahren zu einer gesteigerten Flexibilität bei und sorgt für eine Dynamisierung kooperativen Arbeitens. Aus Unternehmenssicht lassen sich durch kürzere Wege sowie verringerte Durchlaufzeiten realisieren, was folglich eine Kostenreduzierung herbeiführt. Die Realisierung des oben beschriebenen Ortskonzepts für Work Items ist sehr technisch und wird daher genauer ab Kapitel 4.13 betrachtet. Die Zugänglichkeit zu Work Items mit Ortsbeschränkung unterstützt YAC über zwei verschiedene Ansichten, welche in Abschnitt näher erläutert werden. 3.5 Block 4: Interne Architektur Die interne Architektur einer Android Applikation wird stark vorbestimmt durch die Plattform spezifischen Konzepte und Kopplungsmethoden, welche ausschnittshaft in Kapitel beschrieben sind. Um nur ein Beispiel zu nennen, sieht Android keine eindeutige Trennung der modellierten Domänendaten von der Steuerung und der Präsentation vor. Eine strikte Umsetzung des weit verbreiteten Architekturmusters Model View Controller (MVC) ist somit nicht ohne weiteres möglich [Vgl. Fowler, 2003, S. 365ff]. Android vereint die View und den Controller zu einer Komponente, der Activity, welche alle Präsentationselemente beinhaltet und diese manipulierbar macht. In den durch die Android Plattform gezogenen Grenzen lässt sich eine interne Architektur entwickeln, welche den Anforderungen des Konzepts gerecht wird. Abbildung 3.10 zeigt den relevanten Ausschnitt des gewählten internen Aufbaus der YAC Applikation. Der Aufbau ist untergliedert in drei Schichten mit klaren Zuständigkeiten. Auf oberster Ebene, dem Application Layer befinden sich die benötigten Activities, welche die Aufgaben der Datenpräsentation und Anwendungssteuerung übernehmen. Aus Gründen der Übersichtlichkeit zeigt das oben dargestellte Komponentendiagramm nicht alle umgesetzten Activities, sondern nur einen ausgewählten Teil mit besonderer Relevanz. Der komplette Zusammenhang aller Applikationselemente ist in Kapitel dargestellt. Um den Activities einen einheitlichen Datenzugang zu ermöglichen, befindet sich in der Mitte der Architektur ein DataAccess Layer. Dieser übernimmt zwei Zuständigkeiten. Auf der einen Seite sorgt die Komponente YConnectionService für die Kommunikation mit dem entfernten YAWL System. Die Schnittstellen des 3 Konzeption 56

62 Home Activity Application- Layer Sync Activity WorkList Activity WorkItem Activity EditWorkItem Activity DataAccess- Layer ServiceBinder YConnection Service Database Helper DAO-Interface MobileWorkItem DAO Data- Layer Mobile WorkItem Abbildung 3.10: UML Komponentendiagramm: Interne Architektur YAC Resource Services werden nach Außen gekapselt. Diese sorgen intern für die Synchronisierung lokaler und entfernter Work Items. Die Umsetzung in Form eines Android Services sorgt dafür, dass die Funktionalitäten von verschiedenen Activities zugänglich sind, beispielsweise um die Synchronisationsmodi in diversen Kontexten realisieren zu können. Die Live Synchronisierung lässt sich dadurch von beliebigen Stellen innerhalb der Applikation anstoßen. Auf der anderen Seite des DataAccess Layers befindet sich die Datenbankanbindung. Um Work Items und deren Daten persistent abzuspeichern, nutzt YAC die vom Android Application Framework bereitgestellte SQLite Datenbank. Auf das so genannte Object Relational Mapping (ORM) wird zurückgegriffen, um die Datenbank Ebene zu abstrahieren und den Datenzugriff zu erleichtern. Hierbei findet eine bidirektionale Abbildung zwischen Objekten und relationalen Tabellen statt. Speziell für Android wird das Framework ORMLite angeboten, welches eine grundlegende ORM Funktionalität zur Verfügung stellt [Watson, 2011]. Der reduzierte Funktionsumfang ist den Restriktionen mobiler Endgeräte geschuldet. Für den Einsatzzweck innerhalb der YAC Applikation reicht die Funktionalität jedoch aus. Den Zugriff zur Datenbank gewährleistet ein Data Access Object (DAO), welches SQL Abfragen kapselt und sich über die Komponente DatabaseHelper generieren und referenzieren lässt. Die Implementierungsdetails werden aufgegriffen in Kapitel 4.5. Auf der untersten Ebene der internen YAC Architektur befindet sich der Data Layer. Hier werden alle fachlichen Daten in Form der bereits in Abschnitt diskutierten Datenstrukturen gehalten. 3.6 Block 5: Entwurf der Benutzeroberflächen Nachdem in den vorangegangenen Abschnitten ein allgemeines Konzept erarbeitet wurde, kann an dieser Stelle nun begonnen werden, für die beschriebenen Funktionalitäten ein Benutzerinterface zu entwerfen, welches sich an verschiedenen Design Mustern und Best Practices orientiert. Im Fokus steht hierbei, den Anforderun- 3 Konzeption 57

63 gen des Konzepts gerecht zu werden und den Nutzern der Applikation eine hohe Bedienbarkeit zu zusichern. Im Folgenden werden UI Entwürfe vorgestellt, um die Interaktionsmöglichkeiten aus Nutzersicht zu erläutern Der Startbildschirm Der Begrüßungsbildschirm, auf dem man nach dem Anwendungsstart landet, ist gestaltet nach dem Dashboard Entwurfsmuster [Fulcher u. a., 2010]. Dieser umfasst sieben interaktive Elemente, weist eine klare und eindeutige Symbolik sowie Beschriftung auf und ermöglichst dem Nutzer eine schnelle Orientierung. Ein Dashboard vermittelt eine schnelle Übersicht der wichtigsten Funktionen und bietet unmittelbaren Zugriff hierauf. Der Nutzer kann ohne Umwege zu den gewünschten Zielen navigieren. Abbildung 3.11 zeigt den Dashboard konformen Entwurf des YAC Willkommensbildschirms. Abbildung 3.11: YAC UI Entwurf: Startbildschirm Da ein Dashboard sehr viel Platz benötigt, kann es je nach Orientierung des Geräts zu Darstellungsproblemen kommen. Daher wird jeweils ein Design für den Portrait (Hochformat) und Landscape (Breitbild) Modus vorgesehen, welches sich bei einem Orientierungswechsel automatisch anpasst. Alle weiteren UI Entwürfe, die in den Folgekapiteln diskutiert werden, sind ausschließlich mit Komponenten entwickelt, welche die Fähigkeit besitzen sich eigenständig einem wechselnden Bildformat anzupassen. Diese Verfahrensweise wird in den Android User Interface Guidelines vorgeschlagen [Android, 2011a]. Als erweiternde Dashboard Komponente wird ein Suchfeld ergänzt. Eine Suchfunktion kann unter Umständen Navigationsschritte ersetzen. Die Platzierung auf dem Startbildschirm trägt zu einer maximalen Effektivität der Suchfunktion bei. 3 Konzeption 58

64 3.6.2 Synchronisierungsoberfläche Der Synchronisierungsprozess ist von essentieller Bedeutung für die Arbeitsfähigkeit mit YAC. Ohne lokal verfügbare Work Items ist die Anwendung zwar voll lauffähig, jedoch lassen sich keinerlei Aktionen ausführen. Der Relevanz der Synchronisierung wird über eine separate Oberfläche Rechnung getragen, die Funktionen zugänglich macht, um einen unkomplizierten Datenabgleich mit einem entfernten YAWL Resource Service zu erreichen. Der Entwurf dieser Ansicht ist in Abbildung 3.12 gezeigt. Abbildung 3.12: YAC UI Entwurf: Synchronize Das zentrale Element ist der Sync Button, über welchen der Synchronisierungsprozess gestartet wird. Je nach Menge der zu übertragenden Daten beziehungsweise Geschwindigkeit des Netzwerks nimmt dieser Vorgang eine gewisse Zeit in Anspruch. Bei länger laufenden Operationen ist es wichtig, dem Nutzer ein Feedback zu vermitteln, dass ein Verarbeitungsfortschritt im Hintergrund stattfindet. Hierzu bietet sich der Einsatz eines modalen Prozessdialogs an. Dieser legt sich über die Anwendung, vermittelt dem Benutzer die Aktivität und sorgt dafür, dass während des Prozesses keine weiteren Interaktionen ausgeführt werden können. Dies hilft Fehlverhalten der Applikation zu vermeiden. Nach beendeter Synchronisation schließt sich der Dialog und die Bearbeitungsaktivitäten können angegangen werden. Um dem Nutzer, vor der Datenübermittlung in Richtung des YAWL Systems, die lokalen Modifikationen zu präsentieren, zeigt eine Listenansicht die bearbeiteten Work Items und hebt die Aktionen hervor, die ausgeführt wurden und sich somit in der Sychronisierungsqueue befinden. Stellt der Nutzer hierüber fest, dass er ein Work Item vom Übertragungsprozess ausschließen möchte, weil es beispielsweise zu einer fehlerhaften Bearbeitung gekommen ist, so lassen sich die Work Items separat zurücksetzen. Dies hat zur Folge, dass alle gespeicherten Modifikationen gelöscht 3 Konzeption 59

65 werden und diese nicht zum Resource Service übertragen werden. Der Nutzer erhält die Entscheidungshoheit, welche Arbeitsschritte übermittelt werden. Der Synchronisierungsprozess gewinnt an Flexibilität und weist eine höhere Fehlertoleranz auf Verwaltung der Work Queues Die Work Queues ermöglichen dem Nutzer Zugang zu allen lokal verfügbaren Work Items. Gemäß deren Lebenszyklus werden die Einträge auf 4 Tabs (Offered, Allocated, Started, Suspended) aufgeteilt. Tabs sind ein gängiges UI Konzept, um Inhalte zu organisieren [Tidwell, 2010, S. 68ff]. Die Zugehörigkeit zu einer Tab Oberfläche impliziert dem Nutzer in welchem Status sich ein Work Item befindet und welche Aktionen ausführbar sind. Die Darstellung der Work Items erfolgt für jeden Tab in Listenform, durch die der Nutzer vertikal scrollen kann. Um die abgebildeten Informationen zu komprimieren, wird zu jedem Listeneintrag lediglich der Task Name, die Instanz ID und das Startdatum aufgeführt. Die Work Items werden nach ihrem Startdatum absteigend sortiert. Neue Einträge erscheinen dadurch am Anfang der Liste. Um innerhalb der Liste eine höhere Übersichtlichkeit herzustellen, werden Work Items nach ihrem Starttag gruppiert. Einträge mit identischem Startdatum werden in einem Listenabschnitt zusammengefasst. Die zu erzielende Absonderung wird durch ein Trennelement kenntlich gemacht. Ein Listeneintrag wird in grüner Farbe dargestellt, wenn ein Work Item lokal unverändert ist. Ist ein Eintrag mit roter Farbe markiert, wird dem Nutzer signalisiert, dass an dem entsprechenden Work Item Modifikationen vorgenommen wurden, die bisher nicht mit dem YAWL System synchronisiert wurden. Abbildung 3.13 zeigt auf der linken Seite den Entwurf der Ansicht. Abbildung 3.13: YAC UI Entwurf: Work Queues 3 Konzeption 60

66 Über ein einfaches Anklicken gelangt der Nutzer automatisch zur Bearbeitungsoberfläche. Die Gründe für dieses Vorgehen werden in Abschnitt im Detail beleuchtet. Um alternative Aktionen anzubieten, wird ein Kontextmenü eingesetzt. Ein solches Menü öffnet sich, wenn der Nutzer einen so genannten Long Click auf einen Listeneintrag ausführt. Hierzu wird ein Eintrag angeklickt und für eine kurze Zeit gehalten. Das sich öffnende Kontextmenü legt sich als modaler Dialog über die Ansicht und eröffnet Zugang zu einer separaten Detailansicht mit weiterführenden Informationen des Work Items. Je nach Status kann der Nutzer vorgesehene Operationen ausführen, ohne dafür in die Detailansicht wechseln zu müssen. Zum Beispiel können Work Items im Status Offered über das Kontextmenü unmittelbar akzeptiert werden. Viele dieser Operationen verursachen eine Statusänderung. Um die Work Queues stets konsistent zu halten, wird bei einem Statuswechsel ein Eintrag von der ursprünglichen Liste in die neue Zielliste verschoben. Auf diese Weise findet der Lebenszyklus einer Arbeitstätigkeit Berücksichtigung und mögliche Transitionen werden abgebildet. In der Mitte von Abbildung 3.13 sind die vier möglichen Kontextmenüs und deren Wahlmöglichkeiten dargestellt. Die Detailansicht präsentiert im oberen Bereich die Metadaten der Aktivität bestehend aus Work Item ID, Task Name, Status und Startdatum. Zentral gelegen sind Buttons, um Lebenszyklus Operationen auszuführen. Im unteren Bereich werden in einer Listenansicht die Daten des Work Items aufbereitet. Um die Übersichtlichkeit zu gewährleisten, sind zusammenhängende Datenelemente ein und ausklappbar. Optimiertes Klick Verhalten Das vom YAWL Resource Service umgesetzte Vorgehen zur Manipulation des Work Item Lebenszyklus ist auf eine Web basierte Interaktion ausgelegt und sehr klick intensiv. Der Nutzer muss unter Umstände mehrere Aktionen ausführen, um ein bestimmtes Ziel zu erreichen. Möchte ein Arbeiter beispielsweise ein angebotenes Work Item bearbeiten, so muss er das Angebot zunächst akzeptieren, dann in die entsprechende Work Queue wechseln, dort das Work Item selektieren und kann hieraufhin erst den Bearbeitungsprozess starten. Ein solches Verhalten ist besonders auf mobilen Plattformen problematisch. Eine mobile Anwendung sollte den Nutzer ohne Umwege und mit möglichst geringem Aufwand an sein Ziel bringen. Um dies zu erreichen, verfolgt YAC einen eigenen Ansatz zur Manipulation des Work Item Lebenszyklus. Das Konzept versucht einen reduzierten Klick Aufwand herbeizuführen. Die Planung dieses Ansatz wird in Abbildung 3.14 visualisiert. Die Grundlage des Konzepts ist die Annahme, dass Nutzer, die ein Work Item selektieren, dieses stets bearbeiten möchten, unabhängig von dessen Status. Für jede Phase des Lebenszyklus wird eine Standardoperation festgelegt, die das Work Item in den Status Started überführt und die Bearbeitungsoberfläche geöffnet wird. Führt der Nutzer einen einfachen Klick auf ein Work Item in den verschiedenen Listenansichten aus, gelangt er ohne weitere Umwege automatisch zur Bearbeitungsansicht. Alternative Operationen sind über ein Kontextmenü zugänglich. 3 Konzeption 61

67 Accept & start Offered Allocated Started Accept offer Start Complete Complete Edit Edit Edit Suspend / Unsuspend Edit Edit Suspended Abbildung 3.14: Definition einer Standardoperation zur Verringerung des Klick Aufwands auf mobilen Endgeräten Abbildung 3.14 stellt die Standardoperation mit durchgezogenen Pfeilen und alternative Wege mit gestrichelten Pfeilen dar. Das Verfahren hilft dem Nutzer die auszuführende Klick Anzahl zu reduzieren. Bietet über das Kontextmenü trotzdem Zugang zu alternativen Interaktionen. Insgesamt kann ein höherer Bedienkomfort erreicht werden Work Item: Datenbearbeitung In der vorangegangenen Planung ist die Bearbeitungsoberfläche zur Datenein und ausgabe eines Work-Items schon aus Systemsicht thematisiert. Der folgende Abschnitt fasst die wichtigsten Eigenschaften aus Nutzersicht zusammen und rundet das Gesamtbild dieser Ansicht ab. Die Bearbeitungsoberfläche schafft Zugang zu den Daten, die mit einem Work Item verknüpft sind. Diese Ein und Ausgabeparameter, die intern in Form eines XML Schemas und eines XML Datendokuments vorliegen werden dynamisch zur Laufzeit zu einer Maske generiert, die Datenparameter auf View Komponenten abbildet. Je nach Datentyp wird hierbei auf spezifische Komponenten zurückgegriffen. Abbildung 3.15 zeigt exemplarisch eine resultierende Oberfläche. Über die bereitgestellten View Komponenten sind Datenparameter durch den User manipulierbar. So können erforderliche Werte aufgenommen und erfasst werden. Zusammenhängende Daten werden dem Nutzer über Gruppierungen visualisiert. Der Einsatz verschiedener UI Komponenten hilft den Nutzer bei der Eingabe zu unterstützen und wirkt Fehlbedienung sowie Falscheingaben entgegen. Sollen die bearbeiteten Daten gesichert werden, bietet ein Button am unteren Ende der View Zugang zu dieser Operation. Nach erfolgtem Speichervorgang wird die Ansicht geschlossen und der Nutzer landet auf der vorangegangenen Ansicht. Das Work Item verbleibt in der Work Queue und kann zu einem späteren Zeitpunkt erneut überarbeitet werden. Über den Complete Button wird ein Work Item endgültig abgeschlossen. Dies beinhaltet den Speichervorgang und löscht den Eintrag anschließend aus der Work Queue. 3 Konzeption 62

68 Abbildung 3.15: YAC UI Entwurf: Edit Work Item Die Bearbeitungsansicht nutzt die in Abschnitt beschriebene Funktionalität des Barcode Scanners. Der Button Scan code startet den Prozess zur automatischen Formularausfüllung über QR Codes. Ein Long Click auf ein Textfeld startet den expliziten Barcode Einlesemechanismus Suchfunktion & QR Codes Abschnitt und beschreiben ein Verfahren zur Filterung von Work Items basierend auf deren Daten. Hierzu können manuell Suchbegriffe eingegeben oder QR Codes eingescannt werden. Der Nutzer erhält unmittelbaren Zugriff über den Startbildschrim der Anwendung. Es muss nicht mehr zwangsweise der Weg über die Work Queues gegangen werden, der unter Umständen sehr zeitintensiv werden kann. Dies erleichtert den Zugriff auf anstehende Arbeitstätigkeiten und reduziert den Navigationsaufwand zur Erreichung bestimmter Nutzerziele. Der Entwurf dieser Funktionalität ist in Abbildung 3.16 visualisiert. Das Ergebnis einer Scan oder Suchoperation ist eine speziell aufbereitete Work Item Liste, welche lediglich Work Items enthält, deren Daten eine Übereinstimmung mit dem Suchbegriff aufweisen. Die weitere Funktionalität entspricht den in Abschnitt diskutierten Work Queues. Die Selektion eines Eintrags geleitet den Nutzer zur Datenbearbeitung. Über das Kontextmenü stehen alternative Aktionen zur Auslösung bereit. 3 Konzeption 63

69 Abbildung 3.16: YAC UI Entwurf: QR Code & Search Results Ortsgebundenes Workflow Management Ein zentrales Konzept zur Optimierung des Workflow Managements durch mobile Endgeräte entsteht, wie bereits in Abschnitt 3.4 geschildert, durch die Nutzung kontextsensitiver Informationen in Form von Positionskoordinaten. Den sich ergebenden, vielversprechenden Möglichkeiten begegnet YAC mit zwei Nutzungskonzepten, welche im Folgenden besprochen werden. Listenansicht: Nearby work Um die Bedienkonzepte nicht zu stark von den bisher vorgestellten Entwürfen abweichen zu lassen, wird zunächst eine weitere Listenansicht vorgesehen, welche jedoch auf ortsbezogenen Informationen basiert und sich diesen dynamisch anpasst. Die für diesen Kontext generierte Liste enthält nur Work Items, die versehen sind mit einer Ortsinformation, angegeben über den Längen und Breitengrad. Diese Koordinaten werden in einer zusätzlichen Zeile des Listeneintrags kenntlich gemacht. Sobald das mobile Endgerät seine eigene Position über GPS ermitteln konnte, findet eine Sortierung der Liste statt. Die Entfernung der aktuellen Position zu den Koordinaten der Work Items werden bestimmt. Die Liste wird aufsteigend zu den ermittelten Distanzen sortiert. Somit befindet sich stets das örtlich nächstgelegene Work Item an der Spitze der Liste. Um die Distanzen zu verdeutlichen, findet eine Gruppierung basierend auf Entfernungsbereichen statt. Die vorbestimmten Distanzradien sind 1, 10, 100, 1000 und mehr als 1000 Kilometer. So werden beispielsweise alle Work Items, die sich innerhalb eines Umkreises von einem Kilometer zum aktuellen Aufenthaltsort befinden, zu einer Gruppierung zusammengefasst und als Listenabschnitt kenntlich gemacht. 3 Konzeption 64

70 In periodischen Abständen findet eine Aktualisierung der Liste auf Basis der aktuell bestimmten Position statt. Abbildung 3.17 zeigt auf der linken Seite den Entwurf der Listenansicht Nearby work mit exemplarischen Einträgen. Abbildung 3.17: YAC UI Entwurf: Nearby Work Wie dem Nutzer über die zuvor besprochenen Listenformen bekannt ist, kann über einen einfachen Klick auf den Listeneintrag zur Bearbeitungsoberfläche navigiert werden. Auch das Konzept des Long Click in Verbindung mit einem Kontextmenü findet Einsatz. Über das Menü sind unter anderem die Work Item Details zugänglich. Die Positionsangabe in Form des Längen und Breitengrads sind für den Nutzer in der Regel nicht sonderlich aussagekräftig. Diese lassen sich jedoch über eine Kartenansicht visualisieren. Die so genannte MapView gehört zu den Standardkomponenten auf der Android Plattform und dient exakt dem Zweck einer interaktiven Visualisierung von Ortsinformationen. YAC setzt daher eine solche Ansicht um. Über das Kontextmenü eines selektierten Work Items wählt der Nutzer die Option Show in map und gelangt auf eine Landkartenoberfläche, in der sowohl die eigene Position als auch der Zielort des Work Items eingetragen und beschriftet sind. Um den Zusammenhang hervorzuheben, werden beide Orte über eine Linie miteinander verbunden. Dynamisch zur Positionsänderung des mobilen Geräts aktualisiert sich die Ansicht, so dass der Nutzer erkennt, ob er sich auf den Zielort zu bewegt oder sich von ihm entfernt. In einer solchen Oberfläche kann lediglich die direkte Luftlinie zum Ziel berechnet und genutzt werden. Eine konkrete Navigation, die dem Nutzer den Weg weist, kann hierüber nicht durchgeführt werden. Über das Android Konzept der Intents (siehe Kapitel ) lassen sich Funktionalitäten externer Applikationen aufrufen. Auf diese Weise ist es möglich, ausgehend vom Kontextmenü des selektierten Work Items, die Ziel Koordinaten als Parameter an eine Navigationssoftware zu übergeben, die auf dem Gerät installiert ist. Google Maps Navigation ist hierfür 3 Konzeption 65

71 die Standardanwendung. Hierüber wird automatisch die Route zum Ziel bestimmt und der Nutzer zum Zielort geführt. Nach Erreichen des Ziels kann unmittelbar zum selektierten Work Item zurückgesprungen und die Bearbeitung ohne Umwege begonnen werden. Auf diese Weise integriert YAC externe Funktionalitäten und nutzt ein breites Spektrum an Möglichkeiten der Android Plattform, um einen reibungslosen Arbeitsfluss und eine optimale Unterstützung der ausführenden Workflow Beteiligten zu gewährleisten. Kartenansicht: Workitem map Die zuvor thematisierte Listenansicht der Arbeitsprozessschritte in der näheren Umgebung vermittelt dem Nutzer nur indirekt einen Gesamtüberblick seiner eigenen Position zu den in Reichweite befindlichen Work Items. Für ausgewählte Zielorte wurde bereits eine Kartenansicht vorgestellt, um die örtlichen Gegebenheiten eines einzelnen Work Items zu visualisieren und die korrespondierende Distanz darzustellen. Das im Folgenden vorgestellte Konzept kombiniert eine Übersicht aller verfügbaren Work Items mit der Darstellungsweise auf Basis einer Landkarte. Abbildung 3.18 präsentiert den Entwurf dieser Oberfläche. Abbildung 3.18: YAC UI Entwurf: Work Item Map Die so bezeichnete Work Item Map ist eine Ansicht im Kartenformat basierend auf dem Google Dienst Maps. Die Oberfläche markiert im Zentrum die eigene über GPS ermittelte Position sowie alle auf dem Gerät befindlichen Work Items. Diese werden gemäß ihrer Ortskoordinaten am entsprechenden Standpunkt auf der Karte eingetragen. Dem Nutzer wird ein direkter, visueller Eindruck vermittelt, wie viele auszuführende Aktivitäten sich in seiner Umgebung befinden. Der Kartendienst bietet zudem die Möglichkeit des Zoomens. Die Granularität reicht von der Abbildung der globalen Weltkarte bis hinunter zur Darstellung einzelner Straßen und Ortsgegebenheiten. Der Nutzer kann beliebig zwischen diesen Detailstufen wechseln und holt sich hierüber auch einen Gesamteindruck der verfügbaren Arbeitsaktivitäten. Die Ansicht aktualisiert sich in fortlaufenden Abständen, um die eigene Position stets aktuell zu halten. 3 Konzeption 66

72 Die Oberfläche dient nicht nur der Vermittlung der örtlichen Arbeitsverteilung, sondern ist zudem interaktiv. Die in der Karte eingezeichneten Work Items sind über einen Klick auswählbar. Ein sich öffnender, modaler Dialog leitet direkt zur Bearbeitungsoberfläche, so dass die zu erledigende Tätigkeit begonnen werden kann. Dies erspart dem Nutzer den Umweg über eine der zuvor besprochenen Oberflächen und entspricht dem Gesamtprinzip der Anwendung mit möglichst geringem Aufwand zur Work Item Bearbeitung zu gelangen Navigationsübersicht Im Rahmen der Planung sind in den vorangegangenen Abschnitten diverse Konzepte und deren UI Entwürfe erläutert worden. Um die Konzeption abzuschließen und den erforderlichen Überblick herzustellen, werden alle Bestandteile in einen Gesamtzusammenhang gebracht. Hierzu dient die in Abbildung 3.19 dargestellte Navigationsübersicht der YAC Applikation. Home Work Queues Barcode Scan Search Work-Item Map Nearby Work Synchronize Preferences 4 Tabs: Offered, Allocated, Started, Suspended WorkItem List ZXing - "Barcode Scanner" Search Result List MapView Navigation Starts Navigation software e.g. "Google Maps Navigation" Work-Item Details Edit Work- Item ZXing - "Barcode Scanner" Scan code Take picture Sign Abbildung 3.19: YAC: Navigationsübersicht aller Applikationskomponenten Die Übersicht zeigt alle Anwendungsoberflächen und deren zugrundeliegende Funktionalität. Es ist abzulesen, wie ausgehend vom Einstiegspunkt der Applikation zu den verschiedenen Ansichten navigiert werden kann. Die gräulich schraffierten Elemente sind Funktionen externer Anwendungen, welche YAC integriert beziehungsweise unmittelbar aufrufbar sind. Alle in schwarz abgebildeten Elemente sind Komponenten, welche speziell für YAC und damit im Rahmen der vorliegenden Arbeit geplant und umgesetzt sind. Die Pfeile repräsentieren eine direkte Navigationsmöglichkeit über eine Komponente der Benutzeroberfläche. Die Verwendung bestimmter Funktionalitäten sorgt für die Transition zwischen den Oberflächen. Zudem hat der Nutzer stets die Möglichkeit über den Android Back Button zur vorangegangenen Ansicht zurückzuspringen. 3 Konzeption 67

73 4 Umsetzung Nachdem im vorangegangenen Kapitel das Gesamtkonzept des YAC Prototyps erarbeitet wurde, wird in diesem Kapitel die konkrete Umsetzung thematisiert. Hierzu werden erwähnenswerte Implementierungsdetails besprochen. Vereinzelte Quellcode Ausschnitte werden in ihren Kontext gesetzt und erläutert. Allen Überlegungen voran gilt die Voraussetzung einer erreichbaren und konfigurierten Instanz des YAWL Systems. Benötigt werden die Kern Services bestehend aus der Engine und des Resource Services, siehe hierzu Abschnitt Maßnahmen zur Inbetriebnahme und Konfiguration der erforderlichen YAWL Komponenten werden in Anhang D schrittweise erläutert. Weiterführende Informationen sind zu finden in [YAWL-Foundation, 2010a,b]. 4.1 Verwendete Bibliotheken YAC setzt zur Umsetzung bestimmter Funktionalitäten einige Bibliotheken voraus. Diese werden im Wesentlichen dazu benötigt, die Interaktion zwischen YAC und der entfernten YAWL Instanz zu realisieren. Hierfür wird Client seitig auf vereinzelte Klassen des YAWL Frameworks zurückgegriffen. Aufgrund der speziellen Rahmenbedingungen der Android Plattform, besprochen in Abschnitt 2.4, sind teilweise bestimmte Bibliotheken nicht ohne Weiteres lauffähig. Im Folgenden werden die eingesetzten Libraries stichpunktartig genannt und die Maßnahmen erläutert, die für den Betrieb in einer Android Laufzeitumgebung vorgenommen wurden: yawl-2.1-android-lib.jar Diese Bibliothek ist speziell für YAC zusammengestellt und beinhaltet YAWL Klassen, die auf der Client Seite benötigt werden. Diese sind aus dem Quelltext der YAWL Version 2.1 extrahiert. Um YAC schlank zu halten, wird keine Standard YAWL Bibliothek eingesetzt, sondern lediglich auf die essentiellen Klassen zurückgegriffen. Die Bibliothek besteht aus den Schnittstellenklassen ResourceGatewayClient und WorkQueueGatewayClient und deren Abhängigkeiten. Um eine einfache Datenkonvertierung zu erreichen, werden einzelne Klassen als Transportformat bereitgestellt. Dies sind unter anderem die Klasse Participant zur Repräsentation eines YAWL Benutzers sowie die Datenstruktur WorkItemRecord als Ausgangspunkt für die lokale Abbildung eines Work Items (siehe Abschnitt 3.2.4). jdom.jar JDOM ist eine API zur Verarbeitung von XML in Java. Alle Elemente eines XML Dokuments lassen sich mittels JDOM in Java einlesen, zugreifen, manipulieren und ausgeben [Siehe jdom.org, 2011]. YAC setzt diese Bibliothek ein, um sämtliche XML Strukturen zu verarbeiten, die vom YAWL Resource Service geliefert werden.

74 slf4j-android.jar Die Simple Logging Facade for Java (SLF4J) dient der Abstraktion verschiedener Logging Frameworks und wird von YAC benötigt, da die lokal eingesetzten YAWL Klassen ein alternatives Logging betreiben, als dieses standardmäßig von Android unterstützt wird. Weiterführende Informationen zur Funktionsweise von SLF4J sind anschaulich beschrieben in [slf4j.org, 2011]. log4j-over-slf4j.jar Diese Bibliothek dient dem Betrieb von Apache Logging for Java (Log4j) über die SLF4J. Log4j ist eine weit verbreitete Java Logging API und wird von den lokal betriebenen YAWL Klassen benötigt. orm-lite-core.jar YAC verwendet das Persistenz Framework ORMLite zur Abstraktion des lokalen Datenbankzugriffs. Diese Bibliothek liefert die hierfür unabdingbaren Klassen [Siehe Watson, 2011]. orm-lite-android.jar Um ORMLite auf der Android Plattform zu betreiben, werden spezielle Zusatzklassen benötigt, die über diese Library ausgeliefert werden. 4.2 Anwendungseinstellungen Spezifische Einstellungsparameter sollte eine Anwendung stets konfigurierbar halten, um ein gewisses Maß an Anpassungsfähigkeit sicher zustellen. Da das Justieren von Applikationsparametern ein weit verbreiteter Anwendungsfall ist, bietet das Android Framework hierfür einen standardisierten Mechanismus an, die so genannten SharedPreferences. Je nach gewählter Zugriffsberechtigung stehen die Konfigurationsparameter nur in der eigenen Anwendung oder global im gesamten System zur Verfügung. Um SharedPreferences für den Benutzer zugänglich zu machen, wird eine spezielle XML basierte Layout Definition verfasst. Der PreferencesScreen beinhaltet verschiedene Kategorien und Einstellungsparameter. Das Design wird dann zur Laufzeit in eine Maske überführt, die es dem Nutzer möglich macht, Veränderungen einzelner Parameter vorzunehmen. Abbildung 4.1 zeigt die in diesem Prozess stattfindende Konvertierung einer Layout Definition im XML Format in eine Android Nutzermaske. YAC sieht auf diese Weise verschiedene Konfigurationsparameter vor. Dies ist zum Einen die Server Adresse des YAWL Systems in Form einer URL und zum Anderen die Zugangsberechtigung bestehend aus Benutzername mit Passwort. Diese ist erforderlich für die Anwendung als solche ( Client App Account ) sowie den Benutzer des Resource Service ( User Account ). Des Weiteren kann der Nutzer an dieser Stelle die Live Sync Funktionalität aktivieren. Listing 4.1: Anwendungsinterner Zugriff auf Einstellungsparameter 1 S haredpreferences s h a r e d P r e f e r e n c e s = g e t S h a r e d P r e f e r e n c e s 2 ( "de. msponer. android. yac_preferences ", MODE_PRIVATE) ; 3 S t r i n g serverbaseurl = s h a r e d P r e f e r e n c e s 4. g e t S t r i n g ( " p r e f s _ s e r v e r _ u rl ", " http : / / example. com : 80/ " ) ; 4 Umsetzung 69

75 <PreferenceScreen xmlns:android="http://schemas.android.com/ apk/res/android"> <PreferenceCategory label_server"> <EditTextPreference server_url" android:key="prefs_server_url" android:defaultvalue="http://example.com/"/> </PreferenceCategory> <PreferenceCategory user_credentials"> <EditTextPreference android:key="prefs_username" android:defaultvalue="mspone2s" /> <EditTextPreference android:key="prefs_password" android:defaultvalue="mspone2s" android:password="true" /> </PreferenceCategory> <PreferenceCategory client_settings"> <CheckBoxPreference android:key="prefs_livesync" android:defaultvalue="0" /> </PreferenceCategory> </PreferenceScreen> Abbildung 4.1: YAC Preferences: Android spezifischer Einstellungsbildschirm Der anwendungsinterne Zugriff auf die Werte der Einstellungsparameter erfolgt wie in Listing 4.1 gezeigt. Zunächst wird das Objekt SharedPreferences über eine spezielle Activity Methode referenziert. Hierüber kann durch Angabe eines Schlüssels der jeweilig gesetzte Wert erfragt werden. Hat bisher keine Konfiguration stattgefunden, so wird über einen zweiten Parameter ein Standardwert angegeben. Die Anwendungskonfiguration über SharedPreferences bietet verschiedene Vorzüge. Zum Ersten handelt es sich um ein standardisiertes Android Konzept. Über den Zugriffsmechanismus ist ein anwendungsglobaler Zugriff gewährleistet. Die graphische Benutzeroberfläche wird automatisch aus der XML Definition generiert und ermöglicht die Plattform gerechte Manipulation über Standard UI Komponenten. Zuletzt übernimmt Android die Persistenz der vorgenommenen Konfiguration und sorgt für eine dauerhafte Datenspeicherung. 4.3 Layout Wechsel nach Änderung der Geräteorientierung Das Dashboard der Startoberfläche muss aufgrund seines Platz raubenden Designs in einer horizontalen und einer vertikalen Variante definiert werden, da sonst, je nach Orientierung des Geräts, nicht alle Element der View korrekt dargestellt werden. Um dies zu realisieren, wechselt YAC nach einem Orientierungswechsel automatisch das angezeigte Layout und stellt fortlaufend eine korrekte Darstellung sicher. Nach jedem Orientierungswechsel des Geräts, wird eine Activity durch den entsprechenden Android Manager neu generiert und durchläuft dabei den vorgesehen Lebenszyklus. Details hierzu werden erläutert in Abschnitt Umsetzung 70

76 Dies kann man sich zu Nutze machen, indem die Lebenszyklusmethode oncreate() überschrieben wird, um dort zu ermitteln, welche Orientierung aktuell vorherrscht. Auf dieser Basis lässt sich dynamisch das passende Layout der View festlegen. Der Quellcodeausschnitt 4.2 zeigt, wie YAC diesen Sachverhalt umsetzt. Listing 4.2: Bestimmung des Layout basierend auf der aktuellen Geräteorientierung 1 WindowManager winman = 2 ( WindowManager ) getsystemservice ( Context.WINDOW_SERVICE) ; 3 i f (winman!= null ) { 4 int o r i e n t a t i o n = winman. g e t D e f a u l t D i s p l a y ( ). g e t O r i e n t a t i o n ( ) ; 5 i f ( o r i e n t a t i o n == S u r f a c e.rotation_0 6 o r i e n t a t i o n == S u r f a c e.rotation_180) { 7 // P o r t r a i t 8 setcontentview (R. layout. home_vert ) ; 9 } 10 else i f ( o r i e n t a t i o n == S urface.rotation_90 11 o r i e n t a t i o n == S u rface.rotation_270) { 12 // Landscape 13 setcontentview (R. layout. home_hori ) ; 14 } 15 } Über den WindowManager des Android Frameworks lässt sich die aktuelle Orientierung ermitteln. Hierbei müssen vier Rotationen unterschieden werden. Wird das Gerät in einem Winkel von 0 oder 180 Grad gehalten, wird ein vertikales Layout (Portrait) geladen. Befindet sich das Gerät hingegen in einer Neigung von 90 oder 270 Grad, so liegt das Querformat vor und ein horizontales Layout (Landscape) wird gewählt und dargestellt. 4.4 Implementierung eines Services für die Kommunikation mit YAWL Die Kommunikation mit dem YAWL System wird als eine Hintergrundaktivität in Form eines Android Services gekapselt. Dies übernimmt die YAC Klasse YConnectionService, welche keine eigene Benutzeroberfläche besitzt, jedoch von allen Activities der Anwendung nutzbar ist. Hauptaufgabe ist die Abwicklung der Kommunikation zur Synchronisierung zwischen YAWL und YAC. Da es sich hierbei um langlaufende Operationen mit ungewissem Zeitbedarf für die Bearbeitung handelt, werden vereinzelte Methoden in einem separaten Worker Thread ausgelagert. Dies sorgt dafür, dass die Anwendung nicht blockiert. Die Kommunikation zwischen Activity und Service findet asynchron statt. Hierbei kommen die Android Konzepte Binder und CallbackHandler zum Einsatz. Mit den Details hierzu befasst sich Kapitel Um die Anwendung stets reaktiv zu halten, lagert der Service die Methode in einen Thread aus und informiert den Benutzer über die laufende Aktivität. Hierzu wird ein ProgressDialog eingesetzt. Sobald die Methode durchgelaufen ist, verschickt der Service über den Callback- Handler eine Nachricht an die aufrufende Activity. Diese schließt hieraufhin das Dialogfenster und informiert den Nutzer, ob die Synchronisation erfolgreich war oder es zu einem Fehler gekommen ist. Auf die Details der Kommunikation mit einem 4 Umsetzung 71

77 Android Service wird an dieser Stelle verzichtet, da es sich um eine generische Vorgehensweise handelt. Eine sehr anschauliche Darstellung der Abläufe ist zu finden in Becker und Pant [2010, S. 168ff]. Die auf diese Weise implementierte Funktionalität, sorgt für eine lose Kopplung von Activity und Synchronisationsservice und ist unter anderem die Grundlage für die Realisierbarkeit der Live Sync Funktionalität, die von verschiedenen Stellen innerhalb der Applikation zugreifbar sein muss. Verwendung des Workqueue Gateways Das Workqueue Gateway bietet den vollen Funktionsumfang, um eine Synchronisierung zwischen YAC und dem YAWL Resource Service zu bewerkstelligen. Vor dem eigentlichen Datenaustausch muss zunächst der Kommunikationskanal initialisiert werden. Listing 4.3 zeigt das hierfür erforderliche Vorgehen. Listing 4.3: Initialisierung der Workqueue Gateway Verbindung 1 S t r i n g clientappaccount = 2 s h a r e d P r e f e r e n c e s. g e t S t r i n g ( " prefs_client_app_account ", "YAC" ) ; 3 S t r i n g clientapppassword = 4 s h a r e d P r e f e r e n c e s. g e t S t r i n g ( " prefs_client_app_password ", "YACpswd" ) ; 5 S t r i n g workqueuegatewayurl = 6 serverbaseurl + " r e s o u r c e S e r v i c e / workqueuegateway " ; 7 WorkQueueGatewayClient workqueuegateway = 8 new WorkQueueGatewayClient ( workqueuegatewayurl ) ; 9 S t r i n g handle = 10 workqueuegateway. connect ( clientappaccount, clientapppassword ) ; 11 boolean connected = workqueuegateway. s u c c e s s f u l ( handle ) ; Jede Anwendung, die über das Workqueue Gateway interagieren möchte, benötigt einen speziellen Applikations Account, bestehend aus einem Zugangsnamen und dem dazugehörigen Passwort. Diese Informationen werden aus den Android Einstellungen bezogen (siehe Abschnitt 4.2). Zudem wird die Basis URL des Servers mit einem Suffix versehen, welcher das Workqueue Gateway adressiert. Hieraufhin kann ein Objekt der Klasse WorkQueueGatewayClient aus den YAWL Bibliotheken initialisiert und mittels connect() Methode die Verbindung zur entfernten Schnittstelle aufgebaut werden. Ist der Vorgang erfolgreich, erhält man einen so genannten Handle. Dieser muss folglich bei jedem Aufruf einer Workqueue Gateway Methode als Parameter übergeben werden. Über die Zeichenfolge des Handles wird Server seitig die Autorisierung eines jeden Aufrufs überprüft. Nach erfolgreicher Initialisierung stehen über das Objekt WorkQueueGateway- Client eine Vielzahl verschiedener Methoden für den Zugriff und die Manipulation von Work Items zur Verfügung. Diese kapseln jeweils die stattfindende HTTP Kommunikation, so dass YAC nicht direkte HTTP Requests generieren und absetzen muss, sondern diese gemäß Black Box Prinzip über die genutzte Schnittstelle verborgen werden. Der WorkQueueGatewayClient wertet intern die übergebenen Methodenparameter aus, setzt eine entsprechende HTTP Anfrage inklusive Request Parameter ab und liefert nach erfolgtem HTTP Response einen Ergebnis String zurück. Dieser wird dann von YAC verarbeitet. 4 Umsetzung 72

78 Methode Parameter Beschreibung getqueuedwork Items() getworkitem DataSchema() getcasedata() getworkitem() acceptoffer() deallocate Item() skipitem() startitem() updateworkitem Data() completeitem() suspenditem() String userid, int queue, String handle String workitemid, String handle String caseid, String handle String workitemid, String handle String userid, String workitemid, String handle String userid, String workitemid, String handle String userid, String workitemid, String handle String userid, String workitemid, String handle String workitemid, String data, String handle String userid, String workitemid, String handle String userid, String workitemid, String handle unsuspenditem() String userid, String workitemid, String handle Liefert alle verfügbaren Work Items eines bestimmten Status für einen Benutzer. Queue 0: Offered, Queue 1: Allocated, etc. Liefert das XML Schema zu einem Work Item. Liefert die Daten (Netz Variablen) zu einem Case. Liefert ein spezifisches Work Item. Der angegebene Benutzer akzeptiert das angebotene Work Item. Der angegebene Benutzer überführt das akzeptierte Work Item zurück in die Offered Queue. Der angegebene Benutzer lässt die Bearbeitung des zugewiesenen Work Items aus. Der angegebene Benutzer startet ein spezifisches Work Item. Der angegebene Benutzer aktualisiert die Daten eines spezifischen Work Items. Der angegebene Benutzer beendet die Bearbeitung eines spezifischen Work Items. Der angegebene Benutzer schiebt die Bearbeitung eines spezifischen Work Items auf. Der angegebene Benutzer hebt die Ruhezustand eines spezifischen Work Items auf. Tabelle 4.1: Verwendete Methoden des Workqueue Gateways und Beschreibung der Funktionalität 4 Umsetzung 73

79 Eine Übersicht, der auf diese Weise genutzten Methoden, ist in Tabelle 4.1 gezeigt. Angegeben ist jeweils der Methodenname des WorkQueueGatewayClients, die erforderlichen Eingabeparameter und eine kurze Beschreibung der Funktionalität. Die Verwendung der Workqueue Gateway Schnittstellen erfolgte bisher in abstrahierter Form. Um den Einsatz konkreter und verständlicher zu machen, wird in den beiden folgenden Abschnitten jeweils ein wichtiger Anwendungsfall besprochen, welcher auf der Nutzung des Workqueue Gateways basiert. Abfragen aller verfügbaren Work Items Im Rahmen der Synchronisierung müssen in der dritten Phase, beschrieben in Kapitel 3.2.2, alle verfügbaren Work Items zu einem gegebenen Benutzer geladen werden. Die konkrete Implementierung dieses Sachverhalts ist in Listing 4.4 zu sehen. Listing 4.4: Laden aller verfügbaren Work Items 1 MobileResourceMarshaller mobresmarshaller = 2 new MobileResourceMarshaller ( ) ; 3 for ( int queue = 0 ; queue < 4 ; queue++) { 4 S t r i n g queuedworkitemsstring = 5 workqueuegateway. getqueuedworkitems ( userid, queue, handle ) ; 6 Set<WorkItemRecord> queuedworkitems = 7 mobresmarshaller. unmarshallworkitemrecords ( queuedworkitemsstring ) ; 8 9 i f ( queuedworkitems!= null ) { 10 for ( WorkItemRecord w i r : queuedworkitems ) { 11 insertworkitem ( wir ) ; 12 } 13 } 14 } Im Zentrum steht die Workqueue Gateway Methode getqueuedworkitems(). Diese liefert zu einer Benutzeridentität alle verfügbaren Work Items eines speziellen Status, welcher über den Integer Parameter queue angegeben wird. Hierbei steht 0 für die Lebenszyklusphase Offered, 1 steht für Allocated, 2 für Started und 3 für Suspended. Die Iteration von 0 bis 3 sorgt dafür, dass alle Work Items unabhängig von deren Status abgeholt werden. Der Rückgabewert der Methode ist eine XML Struktur, die alle Work Items einer Queue beinhaltet und als Zeichenkette kodiert ist. Der MobileResourceMarshaller, siehe Abschnitt 3.2.4, sorgt für die Dekodierung und erzeugt eine Menge spezifischer Java Objekte. Über diese wird im Anschluss iteriert. Alle ausgelesenen Work Items werden in der lokalen Datenbank des mobilen Endgeräts gesichert. Details zur persistenten Speicherung werden aufgegriffen in Abschnitt 4.5. Live Synchronisation eines Work Items Der optionale Synchronisierungsmodus Live Sync sieht den Abgleich eines einzelner Work Items mit dem entfernten YAWL System vor, um eine möglichst zeitnahe Datenübertragung zu gewährleisten. Um diese Funktionalität umzusetzen, ist ein spezieller Prozess von Nöten, welcher in Listing 4.5 in seinen Einzelheiten aufgeführt ist. 4 Umsetzung 74

80 Listing 4.5: Live Sync eines Work Items 1 S t r i n g submittedid = submitmodifiedworkitem ( wi ) ; 2 daoworkitem. d e l e t e ( wi ) ; 3 i f (! wi. getresourcestatus ( ). e q u a l s ( MobileWorkItem. statuscomplete ) ) { 4 S t r i n g workitemstring = 5 workqueuegateway. getworkitem ( submittedid, handle ) ; 6 WorkItemRecord unmarshalworkitem = 7 mobresmarshaller. unmarshallworkitemrecord ( workitemstring ) ; 8 9 i f ( unmarshalworkitem!= null ) { 10 insertworkitem ( unmarshalworkitem ) ; 11 } 12 } In einem ersten Schritt wird der zu aktualisierende Eintrag über die Methode submitmodifiedworkitem() zum entfernten Resource Service übertragen und dort verarbeitet. Die hieraus resultierenden Veränderungen am Work Item können im Anschluss erfragt werden. Zuvor muss jedoch die veraltete Version aus der lokalen Datenbank gelöscht werden. Wird das Work Item über die zu übermittelnde Veränderung nicht abgeschlossen und somit in den Status Complete überführt, so wird über die ID ein aktueller Status des Eintrags bezogen, dekodiert und lokal gesichert. Abgeschlossene Work Items werden Server seitig durch die Engine gelöscht. Eine Auffrischung der lokalen Version ist daher nicht möglich. 4.5 Datenbankzugriff mit ORMLite Ein weiterer wichtiger Schritt im Rahmen der Umsetzung ist die Persistenz. Der Zugriff auf eine relationale SQLite Datenbank erfolgt über das ORM Framework ORMLite. Um dies zu verwenden, muss eine so genannte DatabaseHelper Klasse implementiert werden. Was hierbei im Detail zu beachten ist, wird im Weiteren nicht genauer betrachtet. Eine anschauliche Beschreibung des generischen Vorgehens ist zu finden in [Watson, 2011]. Wie die Hilfsklasse erzeugt und wozu diese benötigt wird, ist in Listing 4.6 gezeigt. Listing 4.6: Erzeugung eines DAO für mobile Work Items 1 OrmLiteSqliteOpenHelper dbhelper = OpenHelperManager. gethelper ( this ) ; 2 Dao<MobileWorkItem, I n t e g e r > mobileworkitemdao = 3 dbhelper. getdao ( MobileWorkItem. class ) ; Die Helper Klasse lässt sich in jeder Activity über den OpenHelperManager erzeugen und referenzieren. Sie dient der Generierung eines DAOs, welches den Zugriff auf die zugrundeliegende Tabelle realisiert. Für alle Entitäten einer relationalen Datenbank lassen sich DAOs erzeugen. Im oben gezeigten Fall handelt es sich um ein DAO für die Modellklasse MobileWorkItem. Abfragen sind in verschiedenen Ausprägungen über Methoden gekapselt. Der Umgang mit einem solchen DAO lässt sich am Besten an einem Beispiel verdeutlichen. 4 Umsetzung 75

81 So liefert die Methode queryforeq(string fieldname, Object value) alle Einträge einer Tabelle, die in der angegebenen Spalte einen bestimmten Wert aufweisen. Dies entspricht einem SQL Bedingung WHERE spalte = wert. Quellcodeausschnitt 4.7 zeigt exemplarisch eine Abfrage über das DAO, welche alle Work Items liefert, die sich im Status Offered befinden. Listing 4.7: Beispiel einer simplen Abfrage über das Work Item DAO 1 List <MobileWorkItem> o f f e r e d L i s t = 2 mobileworkitemdao. queryforeq ( " r e s o u r c e S t a t u s ", " Offered " ) ; Über das DAO lassen sich auch komplexere Datenbankabfragen absetzen. Hierfür stellt ORMLite den QueryBuilder zur Verfügung. Über ein solches Objekt lassen sich Abfragen aus einer beliebigen Anzahl von Elementen und Bedingungen zusammensetzen. Listing 4.8 zeigt exemplarisch die Verwendung solcher zusammengesetzter Abfragen. Sollten auch diese Möglichkeiten nicht ausreichen, so können zudem Standard SQL Queries abgesetzt werden. Listing 4.8: Beispiel einer zusammengesetzten Abfrage über das Work Item DAO 1 S t r i n g searchpattern = " example " ; 2 QueryBuilder<MobileWorkItem, Integer > querybuilder = 3 mobileworkitemdao. querybuilder ( ) ; 4 querybuilder. where ( ) 5. l i k e ( "taskname", searchpattern ) 6. or ( ) 7. l i k e ( " d a t a L i s t S t r i n g ", searchpattern ) 8. or ( ) 9. l i k e ( " datalistupdatedstring ", searchpattern ) ; PreparedQuery<MobileWorkItem> query = querybuilder. prepare ( ) ; 12 List <MobileWorkItem> r e s u l t L i s t = mobileworkitemdao. query ( query ) ; Das oben aufgeführte Beispiel verwendet den QueryBuilder, verknüpft LIKE Klauseln auf unterschiedliche Spalten disjunktiv miteinander und setzt diese Abfrage als PreparedQuery über das DAO ab. Im obigen Beispiel werden diejenigen Work Items als Liste geliefert, deren Spalten taskname, dataliststring oder datalistupdatedstring die Zeichenkette example beinhalten. Diese Art der Abfrage wird im Rahmen der Suchfunktion benötigt, siehe Abschnitt Damit die gerade thematisierten Anfragen überhaupt erst Ergebnisse liefern können, muss die Datenbank mit Inhalten gefüllt sein. Hierfür setzt ORMLite, wie viele andere ORM Frameworks auch, auf das Konzept von Annotationen. Die Entitätsklassen des Datenmodells werden mit speziellen Anweisungen versehen und dadurch automatisch über die ORM Schicht persistent gespeichert. Dabei findet eine bidirektionale Verknüpfung von Objekten zu Einträgen der relationalen Tabellen statt. Listing 4.9 zeigt ausschnitthaft die annotierte Datenmodellklasse MobileWork- Item. 4 Umsetzung 76

82 Listing 4.9: Ausschnitthafte Entitätsklasse mit Annotationen 2 public c l a s s MobileWorkItem implements Comparable<MobileWorkItem >, 3 S e r i a l i z a b l e { ( generatedid = true ) 5 private int primarykey ; DatabaseField 7 private S t r i n g taskname ; 8 //... 9 } Die Entitätsklasse muss mit der Annotation DatabaseTable versehen werden, um auszudrücken, dass diese Klasse mit einer Tabelle verknüpft werden soll. Die Spalten einer solchen Tabelle werden über die Annotation DatabaseField angegeben, welche an den Attributen der Klasse platziert wird. Über Parameter können Spalten noch mit bestimmten Eigenschaften versehen werden. So gibt die gezeigte Option generatedid = true an, dass es sich um eine Identitätsspalte handelt, deren Werte von der Datenbank automatisch generiert werden. Auf diese Weise lässt sich in feiner Granularität festlegen, welche Informationen in die Persistenzschicht übernommen werden und auf welche Weise dies geschieht. Das Hinzufügen eines Work Items in die Datenbank erfolgt wiederum über das DAO. Die Methode create() erwartet ein Entitätsobjekt als Eingabeparameter und speichert diesen in der vorgesehenen Tabelle. Operationen zum Löschen und Aktualisieren werden vom DAO auf vergleichbare Weise angeboten. 4.6 Listenansichten und Adapter YAC setzt in verschiedenen Activities die so genannte ListView Komponente ein, um betreffende Work Items in Listenform zu präsentieren. Beispielsweise existieren vier verschiedene Listenansichten zur Abbildung der Work Queues, siehe Kapitel Der Ansicht liegt stets eine Listen basierte Datenstruktur zugrunde. Um diese möglichst generisch zu halten, setzt Android Adapterklassen ein. Im einfachsten Fall ist dies ein BaseAdapter. Ein Solcher hat Zugriff auf die Daten und liefert der ListView die zu präsentierenden Informationselemente. Die Vorgehensweise folgt dem Adapter Designmuster beschrieben von Gamma u. a. [1994, S. 139ff]. Der Zusammenhang der Android Bestandteile Activity, ListView und Base- Adapter ist grau schraffiert in Diagramm 4.2 abgebildet. Durch die Adapter Strategie wird Flexibilität gewonnen. Die Elemente einer List- View lassen sich über den Einsatz der Adapter in verschiedenen Arten anordnen und zusammenstellen. Auf diese Weise nutzt YAC für die Darstellung der Work Queues in der WorkListActivity einen anderen Adapter (WorkItemAdapter) als in der Abbildung ortsgebundener Work Items. Die hier verwendete LocalizedWorkListActivity wird mit Hilfe des LocalizedWorkItemAdapter gebildet. Die übergeordnete ListView ist hierbei stets dieselbe Komponente. Um den Adapter auf einen bestimmten Datentyp festzulegen, muss die generische Klasse ArrayAdapter erweitert und mit der zugrundeliegenden Datenstruktur getypt werden. Der ArrayAdapter ist eine Kind Klasse von BaseAdapter und 4 Umsetzung 77

83 Activity contentview : View oncreate() : void ListView adapter : BaseAdapter BaseAdapter getview() : View WorkListActivity contentview : View oncreate() : void Localized WorkListActivity contentview : View oncreate() : void WorkItemAdapter mobileworkitemlist : List<MobileWorkItem> getview() : View ArrayAdapter <MobileWorkItem> getview() : View Localized WorkItemAdapter mobileworkitemlist : List<MobileWorkItem> getview() : View Sectioned WorkListAdapter sections : List<Section> getview() : View addsection(string, adapter) : void getitem(int) : Object getcount() : int getviewtypecount(int) : int getitemid(int) : long Abbildung 4.2: UML Klassendiagramm: Zusammenhang von Activity, List View und Listen Adaptern speziell für die Umsetzung von Listen oder Feldern in View Elementen gedacht. Im Kontext von YAC ist dies stets eine Liste von einem oder mehreren MobileWork- Item s. Die Hervorhebung bestimmter, zusammengehöriger Listeneinträge in einer Untergliederung ist durch die ListView Komponente standardmäßig nicht vorgesehen. Um Work Items, wie im Rahmen der Konzeption geplant nach ihrem Startdatum zu gruppieren, ist ein zusätzlicher Implementierungsschritt von Nöten. Hierfür ist der SectionedWorkListAdapter umgesetzt. Dieser versorgt die übergeordnete ListView mit einer Liste von Sektionen. Jede Sektion besteht wiederum aus einem Adapter, der die zusammengehörigen Work Item Einträge in Form einer Unterliste verwaltet. Der genaue Aufbau und die hierfür erforderliche Implementierung einer untergliederten ListView nach Startdatum der Work Items ist gezeigt in Quellcodeausschnitt Listing 4.10: Aufbau einer Work Item Liste mit Untergliederung auf Basis des Startdatums 1 List <List <MobileWorkItem>> s e c t i o n L i s t = 2 new ArrayList<List <MobileWorkItem >>() ; 3 4 List <MobileWorkItem> templist = new ArrayList<MobileWorkItem >() ; 5 templist. add ( workitemlist. get ( 0 ) ) ; 6 int previndex = 0 ; 7 8 for ( int i = 1 ; i < workitemlist. s i z e ( ) ; i++){ 9 MobileWorkItem item = workitemlist. get ( i ) ; 10 Date itemdate = item. getenablementdate ( ) ; 11 Date prevdate = templist. get ( previndex ). getenablementdate ( ) ; i f ( itemdate. getdate ( ) == prevdate. getdate ( ) ) { 14 // Add item to e x i s t i n g l i s t 15 templist. add ( item ) ; 16 previndex++; 17 } 18 else { 19 4 Umsetzung 78

84 20 // Create a new l i s t and s t a r t a new s e c t i o n 21 s e c t i o n L i s t. add ( templist ) ; 22 templist = new ArrayList<MobileWorkItem >() ; 23 templist. add ( item ) ; 24 previndex = 0 ; 25 } 26 } 27 for ( List <MobileWorkItem> l i s t : s e c t i o n L i s t ) { 28 workitemadapter. addsection ( DateFormat. getlongdateformat ( this ) 29. format ( l i s t. get ( 0 ). getenablementdate ( ) ), 30 new WorkItemAdapter ( this, R. layout. list_item_queues, l i s t ) ) ; 31 } Zuerst müssen zusammengehörige Work Items ermittelt werden. Hierzu findet eine Iteration über alle zu gliedernden Elemente statt. Die erforderliche Sortierung wird in einem vorangegangenen Schritt vorgenommen und wird hier nicht weiter thematisiert. Einträge mit identischem Startdatum werden in einer Unterliste (templist) zusammengefasst und sektionsweise (sectionlist) gespeichert (Zeile 1 bis 25). Nachdem alle Work Items kategorisiert sind, liefert der Prozess eine Liste bestehend aus Listen zusammengehöriger Work Items. Die jeweiligen Kategorien werden nun dem SectionedWorkItemAdapter übergeben (Zeile 26-30). Das Datum wird in der späteren Darstellungsweise als besonderes Listenelement hervorgehoben und sorgt für die Visualisierung der Gliederung. 4.7 Automatisierte Intent Aktionen Android Activities, die in ihrem Zusammenspiel eine komplette Applikation ausmachen, sind untereinander lose über Intents gekoppelt. Diese Intents sorgen für den Informationsaustausch zwischen Activities. Dieses Plattform spezifische Konzept macht sich YAC zunutze, um basierend auf einer so genannten Intent Action eine automatisierte Operation zu veranlassen. Die Verfahrensweise kommt in der Klasse WorkItemActivity zum Einsatz, welche unter anderem den Lebenszyklus eines Work Items vorantreibt. Listing 4.11 zeigt exemplarisch den Kommunikationsablauf für den Aufruf einer Lebenszyklusoperation basierend auf automatisierten Intent-Aktionen. Listing 4.11: Initiierung automatischer Aktionen über Intents 1 // Sender / Invoker ( e. g. T a b A l l o c a t e d A c t i v i t y ) 2 I n t e n t workitemintent = new I n t e n t ( this, WorkItemActivity. class ) ; 3 workitemintent. s e t A c t i o n ( WorkItemActivity.START_INTENT) ; 4 s t a r t A c t i v i t y F o r R e s u l t ( workitemintent, getrequestcode ( ) ) ; 5 6 // Receiver ( WorkItemActivity ) 7 I n t e n t c a l l i n g I n t e n t = g e t I n t e n t ( ) ; 8 S t r i n g i n t e n t A c t i o n = c a l l i n g I n t e n t. getaction ( ) ; 9 i f ( i n t e n t A c t i o n. e q u a l s (START_INTENT) ) { 10 startworkitem ( ) ; 11 } 4 Umsetzung 79

85 Im oben angegebenen Beispiel betrachtet der Nutzer ihm angebotene Work Items über den entsprechenden Tab der Work Queues Ansicht. Durch die Selektion eines Eintrags wird der Start der WorkItemActivity initiiert und über den Intent die auszuführende Aktion übergeben (Zeile 2-4). Auf der Empfangsseite soll eine unmittelbare Statusänderung am Work Item vorgenommen werden. Um dies zu realisieren, wird im Rahmen der Activity Initialisierung der aufrufende Intent verarbeitet und soweit vorhanden sofort die jeweilige Aktion ausgewertet und durchgeführt (Zeile 7-11). Die Verwendung dieser Methodik erlaubt es Activities mit eindeutigen Zuständigkeiten zu definieren und deren Funktionalitäten flexibel nach Außen anzubieten. Dies sorgt für eine saubere Kapselung von Funktionen, hilft Coderedundanzen zu vermeiden und erhöht die Wiederverwendbarkeit ganzer Activities beziehungsweise einzelner Methoden. 4.8 XML (De )Serialisierung Die in Kapitel konzipierte, bidirektionale Abbildung des XML Schema in eine entsprechende Android View bedingt zur Umsetzung einen zusätzlichen Verfahrensschritt. Zum Einen müssen die Informationen des Schemas mit denen des XML Datendokuments zusammen geführt werden und zum Anderen ist es erforderlich eine eindeutige Beziehung zwischen den View Komponenten und den Elementen der XML Struktur herzustellen. Bevor nun die Daten eines Work Items über entsprechende Android UI Komponenten eingesehen und bearbeitet werden können, werden zuvor sowohl das XML Schema als auch die XML Daten durch einen so genannten Deserializer geschickt. Dies übernimmt die YAC Klasse WorkItem- ElementEntryDeserializer und folgt in seiner Verfahrensweise dem Vorgehen der YAWL Klasse DynFormFieldAssembler, die ein vergleichbares Ziel auf Basis von Web Komponenten verfolgt. Im Zuge des Deserialisierungsprozesses werden alle Elemente des XML Schemas inklusive der definierten Eigenschaften ausgelesen, eine Korrespondenz zu den Werten des XML Datendokuments hergestellt und in einer neuen baumartigen Datenstruktur abgelegt. Diese resultierende YAC Klasse wird als WorkItemElementEntry bezeichnet und ist, ausgerichtet auf die Android Plattform, vergleichbar zur Klasse DynFormField des YAWL Resource Services. Das WorkItemElementEntry repräsentiert einen Knoten im XML Dokumentbaum. Mögliche Verzweigungen werden dahingehend aufgelöst, dass ein solches Objekt wieder eine Liste von Kindelementen haben kann und stets ein Vaterelement definiert ist. Das Resultat entspricht eindeutig dem Aufbau aller Elemente des XML Schemas. Ein WorkItemElementEntry speichert, neben seinen Vater und Kindknoten, den Namen und den Wert des Elements sowie dessen Datentyp. Des Weiteren ist ein Attribut vorgesehen, in dem sich die Identifikationsnummer der korrespondierenden View Komponente ablegen lässt. Abbildung 4.3 zeigt in der Mitte einen Ausschnitt des Aufbaus. Nach der Deserialisierung erhält die Activity Klasse EditWorkItemActivity, welche zuständig für die Bearbeitung von Work Item Daten ist, eine Referenz auf den Wurzelknoten des Datenbaums. Zur Initialisierung der View Komponenten muss nun die gesamte Datenstruktur rekursiv durchlaufen werden, um alle Elemente des 4 Umsetzung 80

86 XML Schema int id WorkItemElementEntry XML Data Deserializer String name String value String datatype int viewid WorkItemElementEntry parent View/ Edit Save Edit WorkItem Activity User XML Data Serializer List<WorkItemElementEntry> subelemententrylist... Abbildung 4.3: (De )Serialisierungsprozess der XML Daten Baums auswerten zu können. Für jeden besuchten Knoten wird basierend auf dessen Datentyp die View Komponente erzeugt, mit dem, soweit vorhanden, vordefinierten Wert belegt und die Id der Android Komponente im vorgesehenen Attribut des WorkItemElementEntry abgespeichert. Sind alle Elemente des Baums besucht, entspricht die resultierende Android View genau den Vorgaben des XML Schemas und der Nutzer kann mit der Dateneingabe beginnen. Listing 4.12: Ausschnitt der rekursiven Aktualisierung von Work Item Daten 1 private void c o l l e c t V a l u e s ( List <WorkItemElementEntry> l i s t ) { 2 for ( WorkItemElementEntry entry : l i s t ) { 3 i f ( entry. getdatatype ( )!= null ) { 4 S t r i n g value = "" ; 5 i f ( entry. getdatatype ( ). e q u a l s ( " xsd : boolean " ) ) { 6 CheckBox checkbox = ( CheckBox ) findviewbyid ( entry. getviewid ( ) ) ; 7 i f ( checkbox!= null ) { 8 value = S t r i n g. valueof ( checkbox. ischecked ( ) ) ; 9 } 10 } 11 // e l s e i f (... ) {... } entry. setvalue ( value ) ; 14 } 15 i f ( entry. getsubelemententrylist ( )!= null ) { 16 c o l l e c t V a l u e s ( entry. getsubelemententrylist ( ) ) ; 17 } 18 } 19 } Sollen die manipulierten Daten abgespeichert werden, muss der zuvor beschriebene Deserialisierungsprozess in entgegengesetzter Reihenfolge durchlaufen werden. Zunächst werden ausgehend vom Wurzelknoten und unter Nutzung von Rekursion alle WorkItemElementEntry s besucht. Über die View Id, die über den Knoten gespeichert ist, kann der aktuell gesetzte Wert über die korrespondierende Android Komponente ermittelt werden. Dieser wird als neuer Wert im WorkItemElement- Entry gesetzt. Endet die Rekursion sind alle Datenelemente mit den Werten der UI Komponenten aktualisiert. Listing 4.12 zeigt die Implementierung der Rekursion 4 Umsetzung 81

87 und exemplarisch das Aktualisieren eines booleschen Datentyps. Andere Datentypen werden auf identische Weise aktualisiert und werden aus Gründen der Übersichtlichkeit nicht separat aufgeführt. Nach Beendigung des Aktualisierungsvorgangs, muss die Baumstruktur durch den WorkItemElementEntrySerializer geschickt werden, um aus den Verflechtungen der Baumelemente wiederum ein XML Dokument zu erzeugen und dies über das entsprechende Work Item persistent zu speichern. 4.9 Dynamisches Hinzufügen und Löschen von Datenparametern Datenelemente, die mit den Attributen minoccurs oder maxoccurs belegt sind, dürfen unter Umständen mehrfach in einem XML Dokument auftauchen. YAC unterstützt diese Eigenschaft, indem, innerhalb der festgelegten Grenzen, Parameter dynamisch hinzugefügt beziehungsweise gelöscht werden können. Da alle Datenelemente auf der Bearbeitungsebene als WorkItemElementEntry in einer Baumstruktur vorgehalten werden, orientiert sich die Implementierung dieser Funktionalität an der Vorgehensweise einer Einfüge oder Löschoperation in einer Baumartigen Datenstruktur. Eine einleitende Veranschaulichung des umgesetzten Verfahrens ist anhand zweier Beispiele gezeigt in Abbildung 4.4. Work-Item Element Entry Tree A AddWorkItemElementEntryListener B C A + D1 D2 D3 B C E1 F1 E2 F2 E3 F3 minoccurs = 1 maxoccurs = 5 D1 D2 A E1 F1 E2 F2 - B D1 C RemoveWorkItemElementEntryListener E1 F1 Abbildung 4.4: Hinzufügen und Löschen eines Datenparameters Sowohl das Hinzufügen als auch das Löschen eines Datenelements wird ausgelöst durch den Benutzer über entsprechende Buttons, welche im Rahmen des View Generierungsprozesses erzeugt und den jeweiligen Komponenten zugeordnet werden. Hierbei werden stets die gesetzten Grenzen beachtet. Ist eine Unter oder Obergrenze für das Auftauchen eines Elements erreicht, wird der jeweilige Button deaktiviert. 4 Umsetzung 82

88 Speziell entwickelte Listener Klassen übernehmen schließlich die Umsetzung der Einfüge und Löschoperation, welche durch die Anwahl eines Buttons aufgerufen werden. Die Klasse AddWorkItemElementEntryListener implementiert das Android OnClickListener Interface und sorgt als solches für den Einfügeprozess von Datenparametern. Das zu replizierende Element wird inklusive aller angehängter Kindeinträge geklont und dem Vaterknoten zugewiesen. Die benötigten View Komponenten werden in Folge dessen erzeugt, dem übergeordneten Layout hinzugefügt und stehen dem Nutzer unmittelbar zur Verfügung. Um dies am oben gezeigten Beispiel konkret zu machen, wünscht sich der User ein drittes Erscheinen des Parameters D, der in der gesamten XML Struktur ein bis fünf Mal vorkommen darf. Die Instanz D2 wird hierzu geklont und dem Vaterknoten C zugeordnet. Dieser Vorgang zieht ebenso die Replikation von E2 und F2 nach sich, die den neu entstehenden Parameter D3 als Vater erhalten. Nach Abschluss des Vorgangs existieren drei Instanzen des Parameters D sowohl auf der Ebene der XML Datenstruktur in Form von WorkItemElementEntry s als auch auf Basis von Android View Komponenten, die durch den Nutzer gesteuert und im Rahmen der Serialisierung verarbeitet werden. Der Löschmechanismus verläuft nach folgendem Prinzip: Die Klasse RemoveWork- ItemElementEntryListener setzt den Prozess zur Entfernung eines Parameters in Gang. Der zu löschende Eintrag wird inklusive aller Kindknoten entfernt und die korrespondierende View Gruppierung wird dem übergeordneten Layout entnommen. Im obigen Beispiel bestätigt der Nutzer den Löschvorgang von Parameter D2. Dieser wird einschließlich seiner Kinder E2 und F2 aus der Datenstruktur entnommen und die verknüpften View Elemente entfernt. Im Rahmen der Serialisierung steht das XML Element nicht mehr zur Verfügung und fehlt somit im resultierenden Dokument Nutzung des Barcode Scanners Für das Einscannen von Barcodes und QR Codes wird wie in Kapitel erwähnt die Applikation Barcode Scanner des ZXing Projekts verwendet. Ist diese auf der mobilen Plattform installiert, ist ihre Integration über Android Intents möglich. Dieser ruft die Scanner Applikation auf und sobald diese einen Code erkannt hat, wird das Ergebnis an die aufrufende Anwendung zurückgeliefert. Um sicherzustellen, dass der Barcode Scanner verfügbar ist, wird ein so genannter Intent- Integrator eingesetzt. Bevor der Intent abgeschickt wird, prüft dieser, ob die Barcode Scanner Applikation installiert ist. Ist dies nicht der Fall, wird der Benutzer über einen Dialog hingewiesen, dass eine zusätzliche Software Installation von Nöten ist. Wird dieser Dialog bestätigt, findet eine automatische Weiterleitung in den Android Market statt. Hier lässt sich der Barcode Scanner mit wenig Aufwand installieren. Verweigert der Nutzer die Installation, so kann die Funktionalität der Barcode Verarbeitung nicht verwendet werden. Listing 4.13 zeigt sowohl den Aufruf des Scanners als auch die Entgegennahme des Resultats. 4 Umsetzung 83

89 Listing 4.13: Aufruf des Barcode Scanners und Auswertung der Resultate 1 I n t e n t I n t e g r a t o r. i n i t i a t e S c a n ( HomeActivity. this ) ; 2 3 protected void o n A c t i v i t y R e s u l t ( int requestcode, int resultcode, 4 I n t e n t data ) { 5 switch ( requestcode ) { 6 case I n t e n t I n t e g r a t o r.request_code: { 7 i f ( resultcode!= RESULT_CANCELED) { 8 I n t e n t R e s u l t scanresult = I n t e n t I n t e g r a t o r. p a r s e A c t i v i t y R e s u l t ( 9 requestcode, resultcode, data ) ; 10 i f ( scanresult!= null ) { 11 S t r i n g c o n t ents = scanresult. getcontents ( ) ; 12 // Do something } 14 } 15 break ; 16 } 17 } 18 } Nach erfolgter Scan Operation durch den Barcode Scanner, gibt dieser das Ergebnis wiederum in Form eines Intents an die aufrufende Activity zurück. Für diese Art der Rückgabe sieht Android die Methode onactivityresult() vor, um das Resultat abzufangen und zu behandeln. Über einen Request Code lässt sich die Anwendung ermitteln, welche den Operationsaufruf initiiert hat. Der Result Code gibt an, ob die ausgeführte Aktion erfolgreich durchgeführt werden konnte oder ob ein Abbruch stattgefunden hat. Die Ergebnisdaten befinden sich im zurückgelieferten Intent und lassen sich in wenigen Schritten auslesen und weiterverarbeiten. Diese Integration der Barcode Scanner Funktionalitäten lässt an beliebigen Stellen innerhalb eigener Entwicklungen durchführen. Die Vorgehensweise geschieht dabei stets in der gerade erläuterten Art und Weise. Die Möglichkeiten der Weiterverarbeitung sind dagegen frei wählbar. Dies ist die Vorraussetzung zur Realisierung des Features QR Form Fill. Implementierung der Funktionalität: QR Form Fill Ein interessantes Feature von YAC ist das so bezeichnete QR Form Fill. Hierbei wird ein strukturierter QR Code verwendet, um mehrere Formularfelder einer Eingabemaske auszufüllen. Die Konzeption hierzu ist zu finden in Kapitel Für die Umsetzung dieser Funktionalität muss zunächst die resultierende Zeichenkette des dekodierten Codes in seine Bestandteile zerlegt werden. Diese Aufgabe übernimmt die YAC Klasse QRCodeDecoder, welche als Rückgabe eine HashMap liefert, bestehend aus allen Schlüssel Wert Paaren, die dem Code zu entnehmen sind. Die ermittelten Werte müssen ihrem Schlüssel entsprechend in die vorgesehenen Datenfelder des Work Items überführt werden. Das erforderliche Vorgehen wird in Listing 4.14 beschrieben. 4 Umsetzung 84

90 Listing 4.14: Automatische Formularausfüllung über QR Codes 1 Map<String, String > scanresultmap = 2 QRCodeDecoder. getresultsmap ( s c a n R e s u l t s ) ; 3 applyscanresults ( workitemelemententryroot. getsubelemententrylist ( ), 4 scanresultmap ) ; 5 6 private void applyscanresults ( 7 L i s t <WorkItemElementEntry> subelemententrylist, 8 Map<String, String > scanresultmap ) { 9 for ( WorkItemElementEntry item : subelemententrylist ) { 10 i f ( scanresultmap. containskey ( item. getname ( ) ) ) { 11 item. setvalue ( scanresultmap. get ( item. getname ( ) ) ) ; 12 EditText t e x t = ( EditText ) findviewbyid ( item. getviewid ( ) ) ; 13 t e x t. settext ( item. getvalue ( ) ) ; 14 } 15 i f ( item. getsubelemententrylist ( )!= null ) { 16 applyscanresults ( item. getsubelemententrylist ( ), scanresultmap ) ; 17 } 18 } 19 } Die Methode applyscanresults() nimmt eine Liste von WorkElementEntry s und die HashMap der Scan Resultate entgegen und iteriert über alle Elemente der Datenliste. Für den Fall, dass die Bezeichnung eines Datenparameters mit einem Key der Map übereinstimmt wird der passende Wert des Schlüssels als Datum für das Work Item übernommen und die korrespondierende UI Komponente aktualisiert, um die Änderungen nach außen sichtbar zu machen. Beinhaltet der Datenparameter eine verzweigte Unterliste, wird derselbe Vorgang rekursiv für alle Kindelemente durchgeführt. Hierdurch werden alle Datenparameter auf mögliche neue Werte aus der HashMap überprüft und es wird möglich, im optimalen Fall, das komplette Eingabeformular mit einer einzigen QR Code Scan Operation auszufüllen. Findet ein eingescannter Wert keinen passenden Parameter wird er verworfen. Erforderliche Werte, die sich nicht in der Map befinden, müssen manuell vom Benutzer eingetragen werden Kamerafunktion: Konvertierung von Fotos YAC bietet die Möglichkeit über die Kamera des mobilen Endgeräts Fotos aufzunehmen und an Work Items anzuheften. Die Vorgehensweise zur Nutzung der Kamera ist über das Android Framework festgelegt und wird in diesem Kontext nicht genauer betrachtet. Die erforderlichen Schritte sind verständlich beschrieben in [Meier, 2010, S. 375ff] oder [Every, 2010, S. 23ff]. Von größerem Interesse ist in diesem Zusammenhang die Weiterverarbeitung des Fotos, nachdem dieses aufgenommen und in Form einer Bitmap an die aufrufende Activity zurückgegeben wurde. Siehe hierzu Listing Umsetzung 85

91 Listing 4.15: Verkleinerung einer Bitmap und String Kodierung mittels Base64 1 Matrix matrix = new Matrix ( ) ; 2 matrix. p o s t S c a l e ( scalewidth, s c a l e H e i g h t ) ; 3 4 Bitmap resizedbitmap = Bitmap. createbitmap (mbitmap, 0, 0, 5 width, height, matrix, true ) ; 6 ByteArrayOutputStream bos = new ByteArrayOutputStream ( ) ; 7 resizedbitmap. compress ( CompressFormat.JPEG, 50, bos ) ; 8 byte [ ] bitmapdata = bos. tobytearray ( ) ; 9 10 S t r i n g base64binary = Base64. encodetostring ( bitmapdata, 0) ; Der erste Schritt ist die Reduzierung der Bildgröße auf ein passendes Maß. Fotos mit mehreren Megapixeln müssen für die Darstellung auf mobilen Endgeräten verkleinert werden. Diese und weitere Zuständigkeiten übernimmt die Klasse BitmapResizer. Zunächst wird die verfügbare Displayauflösung ermittelt und über eine Matrix der Skalierungsfaktor für das Foto festgelegt. Die ursprüngliche Bitmap (mbitmap) wird dann über die Methode createbitmap() zu einer neuen, verkleinerten Version (resizedbitmap) generiert. Um ein geringes Datenübertragungsvolumen zu erreichen, sollten Bilder mit einer adäquaten Komprimierung versehen werden. Daher wird in einem nächsten Schritt das verkleinerte Foto mit einer JPEG Kodierung versehen. Hierbei kommt ein ByteArrayOutputStream zum Einsatz, in den die Bitmap überführt wird. Da YAWL bisher keine binären Datentypen unterstützt, findet in diesem Schritt eine Zeichkettenkodierung des Fotos im Base64 Format statt. In dieser Form kann das Bild als Work Item Datenparameter an den YAWL Resource Service übergeben werden. Eine Darstellung innerhalb von YAC ist in diesem Format ohne weiteres möglich Touchscreen Unterschrift Neben der Fotogenerierung über die Kamerafunktion unterstützt YAC eine zweite Möglichkeit Bilddateien zu erzeugen und diese an Work Items anzuhängen. Über den Touchscreen können Zeichenbewegungen wahrgenommen, visualisiert und in Form einer Bitmap festgehalten werden. Um dies zu realisieren, wird die selbst entwickelte View Komponente SigningView benötigt. Eigene View Komponenten werden von der Android Klasse View abgeleitet. Um auf Berührungsereignisse reagieren zu können, muss die Methode ontouchevent() überschrieben werden. Diese wird stets aufgerufen, sobald ein so genanntes MotionEvent über den Touchscreen ausgelöst wird. Wie dies genutzt wird um Unterschriften zu generieren, zeigt der Quellcodeausschnitt public boolean ontouchevent ( MotionEvent e v e n t ) { 2 Path path = new Path ( ) ; 3 i f ( event. getaction ( ) == MotionEvent.ACTION_DOWN) { 4 path. moveto( event. getx ( ), event. gety ( ) ) ; 5 path. lineto ( event. getx ( ), event. gety ( ) ) ; 6 g r a p h i c s. add ( path ) ; 7 } else i f ( event. getaction ( ) == MotionEvent.ACTION_MOVE) { 8 path. lineto ( event. getx ( ), event. gety ( ) ) ; 9 } else i f ( event. getaction ( ) == MotionEvent.ACTION_UP) { 10 path. lineto ( event. getx ( ), event. gety ( ) ) ; 11 } 4 Umsetzung 86

92 12 13 for ( Path path : g r a p h i c s ) { 14 canvas. drawpath ( path, paint ) ; 15 } 16 i n v a l i d a t e ( ) ; 17 return true ; 18 } Zunächst wird ein Path Objekt erzeugt, welches den auf dem Touchscreen gezogenen Kantenzug abbildet. Der Pfad startet an denjenigen Koordinaten an denen die erste Berührungsinformation registriert wird. Die betreffenden X und Y Koordinaten werden über das MotionEvent bezogen. Da eine Unterschrift aus mehreren Kantenzügen bestehen kann, wird die Unterschrift in ihrer Gesamtheit als eine Liste von beliebig vielen Path Objekten repräsentiert. Sobald ein neuer Kantenzug beginnt wird dieser in die Liste hinzugefügt. Um die registrierten Pfade für den Benutzer sichtbar zu machen, wird ein Canvas Objekt eingesetzt. Dieses wird im Hintergrund mit einer Bitmap verknüpft, welche die Bildinformationen des Canvas abspeichert. Über die Methode invalidate() wird die View neu aufgebaut und damit die Änderungen visualisiert. Das Erzeugen und Kodieren der Bilddaten aus einer zugrundeliegenden Bitmap erfolgt in identischer Weise wie im vorangegangenen Abschnitt beschrieben. Über den BitmapResizer wird eine passende Größe bestimmt, die Komprimierung vorgenommen und die Konvertierung ins Base64 Format durchgeführt Implementierung einer Liste für ortsgebundene Work Items Nutzung LocationManager und LocationListener Für die Ermittlung des eigenen Standort über GPS stellt Android den Location- Manager zur Verfügung, welcher über das Application Framework bereitsteht, als Systemdienst im Hintergrund läuft und bei Bedarf referenziert werden kann. Details zur Ansiedlung dieser Komponente werden in Kapitel angegeben. Der LocationManager folgt dem Entwurfsmuster Observer [siehe Gamma u. a., 1994, S. 293ff], welches auch häufig unter der Bezeichnung Publish and Subscribe zu finden ist. Der LocationManager ist in diesem Kontext das beobachtete Subjekt und die Activities übernehmen die Rolle der Beobachter. Über den LocationManager registriert sich die jeweilige Activity Klasse für periodische Standortaktualisierungen und gibt hierbei an, in welcher Frequenz Benachrichtigungen zur ermittelten Position erfolgen sollen. Dies wird über ein minimales Zeitintervall und eine minimale Positionsdifferenz angegeben. Listing 4.16 (Zeile 1-4) fordert den LocationManager auf, die Ortsbestimmung im Abstand von zehn Sekunden durchzuführen und diese zu übermitteln, wenn die Differenz zur letzten Position größer als 100 Meter ist. 4 Umsetzung 87

93 Je geringer beide Werte gesetzt werden, desto genauer kann eine Lokalisierung vorgenommen werden. Allerdings steigt dadurch auch die Leistungsaufnahme des Geräts stark, was sich negativ auf den Akkuverbrauch ausschlägt und damit der Betriebsdauer verringert. Ein Kompromiss der beiden Faktoren Genauigkeit und Leistungsaufnahme Rechnung trägt ist daher zu wählen. Listing 4.16: Update der Liste über den Location Listener 1 LocationManager locationmanager = 2 ( LocationManager ) getsystemservice ( Context.LOCATION_SERVICE) ; 3 locationmanager. requestlocationupdates ( LocationManager.GPS_PROVIDER, , 100, this ) ; 5 6 public void onlocationchanged ( Location l o c a t i o n ) { 7 this. c u r r e n t L o c a t i o n = l o c a t i o n ; 8 s e t u p L i s t ( l o c a t i o n ) ; 9 } Um nun auf eingehende Ortsinformationen reagieren zu können, muss eine Activity das Interface LocationListener implementieren. Dieses sieht Schnittstellen vor, die vom LocationManager genutzt werden. Um die aktuelle Position mitzuteilen, wird die Methode onlocationchanged() aufgerufen und ein Location Objekt übergeben. Dieses enthält nun die Information über den derzeitigen Standort, welcher im Folgenden genutzt wird, um die Liste der ortsgebundenen Work Items zu aktualisieren, siehe Quellcode Auszug 4.16, Zeile 6 bis 8. Erzeugung und Sortierung der ortsgebunden Work Item Liste Nachdem der eigene Standort ermittelt ist, kann in einem Folgeschritt die Realisierung einer ortsbezogenen Work Item Liste (siehe Konzeption in Abschnitt 3.4 und 3.6.6) erfolgen. Hierzu werden alle Work Items aus der Datenbank geladen, die je eine Variable für den Längen und Breitengrad besitzen. Die resultierende Liste wird gemäß der ermittelten Entfernungen zur aktuellen Position sortiert. Für jedes Work Item wird die Distanz zum Aufenthaltsort berechnet. Die hierfür eingesetzte Methode ermittelt die Entfernung in Metern basierend auf dem World Geodetic System (WGS) [siehe US Department of Defense, 1994]. Listing 4.17: Erzeugung und Sortierung der ortsgebundenen Arbeitsliste 1 List <MobileWorkItem> workitemlist = 2 new QueryHelper ( this ). queryforalllocalizedworkitems ( ) ; 3 i f ( c u r r e n t L o c a t i o n!= null ) { 4 for ( MobileWorkItem workitem : workitemlist ) { 5 Location l o c = new Location ( " WorkItemLocationInformation " ) ; 6 l o c. setlongitude ( Double. parsedouble ( workitem. getlongitude ( ) ) ) ; 7 l o c. s e t L a t i t u d e ( Double. parsedouble ( workitem. g e t L a t i t u d e ( ) ) ) ; 8 workitem. s e t D i s t a n c e T o P o s i t i o n ( c u r r e n t L o c a t i o n. distanceto ( l o c ) ) ; 9 } 10 } 11 C o l l e c t i o n s. s o r t ( workitemlist, new MobileWorkItemDistanceComparator ( ) ) ; 4 Umsetzung 88

94 Für die Sortierung wird ein spezielles Comperator Objekt eingesetzt. Die Work Items werden aufsteigend zu ihrer Entfernung zum aktuellen Standort sortiert. Das Work Item mit der kürzesten Distanz befindet sich danach an erster Position der Liste. Der genaue Ablauf der Erzeugung und Sortierung ist dargestellt in Listing Kartenansicht für ein einzelnes Work Item Einzelne Work Items sowie der aktuelle Standort lassen sich in eine interaktive Landkarte einzeichnen und dadurch visuell in Verbindung zueinander setzen. Diese Zuständigkeit übernimmt die Klasse WorkItemMapActivity, welche von der Android Klasse MapActivity abgeleitet ist. Die Ansicht besteht aus einer einzigen Komponente der MapView. Diese lässt sich steuern über den so genannten MapController. In diesem Zusammenhang sind die Overlay Objekte von besonderem Interesse, da hierüber spezielle Punkte auf der Landkarte markiert werden können. Wie genau diese genutzt werden, um zum Einen die eigene Position und zum Anderen die Position des Work Items zu kennzeichnen, zeigt Listing Listing 4.18: Hinzufügen und Aktualisieren der eigenen und der Work Item Position 1 // My current l o c a t i o n 2 MyLocationOverlay mylocationoverlay = 3 new MyLocationOverlay ( this, this. mapview) { 4 public synchronized void onlocationchanged ( L o c a t i o n newlocation ) { 5 GeoPoint myposition = new GeoPoint ( 6 ( int ) ( newlocation. g e t L a t i t u d e ( ) 1E6), 7 ( int ) ( newlocation. getlongitude ( ) 1E6) ) ; 8 mapcontroller. animateto ( myposition ) ; 9 } ; 10 } ; // Work Item l o c a t i o n 13 WorkItemLocationOverlay workitemlocationoverlay = 14 new WorkItemLocationOverlay ( taskname, workitemgeopoint ) ; 15 mapview. getoverlays ( ). add ( workitemlocationoverlay ) ; Zur Markierung des eigenen Standorts auf einer MapView stellt das Android Framework die Klasse MyLocationOverlay zur Verfügung. Diese implementiert das LocationListener Interface. Durch das Überschreiben der Methode on- LocationChanged() kann periodisch auf Standortaktualisierungen reagiert werden. Genauere Informationen hierüber sind zu finden in Abschnitt Das erzeugte Overlay wird der MapView hinzugefügt. Sobald eine Positionsinformation eintrifft, werden die Koordinaten des Overlays aktualisiert und über den MapController und der Methode animateto() auf der Karte platziert. Die Position des Work Items wird über das WorkItemOverlay auf der MapView kenntlich gemacht. Diese Klasse benötigt den Task Namen sowie die Koordinaten als Eingabeparameter. Die Markierung auf der Karte wird durch einen Punkt eingezeichnet, der mit dem Task Namen betitelt ist. Eine direkte Verbindungslinie zwischen der eigenen und der Work Item Position wird gezogen. 4 Umsetzung 89

95 Die genaue Vorgehensweise zur Definition eigener abgeleiteter Overlay Klassen und deren Verwendung wird im Folgenden nicht genauer beschrieben. Eine anschauliche Herangehensweise ist beschrieben in [Becker und Pant, 2010, S. 329ff] Parameterübergabe an ein Navigationssystem Das Aufrufen von Google Maps zur Nutzung der Navigationsfunktionalität geschieht wie auf der Android Plattform üblich über Intents. Zunächst müssen sowohl die eigenen als auch die Zielkoordinaten des Work Items bekannt sein. Die Breiten und Längengrade beider Positionen werden jeweils in Form einer Zeichenkette durch ein Komma separiert. Listing 4.19 zeigt die erforderliche Formatierung. Listing 4.19: Aufruf von Google Maps Navigation inklusive Parameterübergabe 1 S t r i n g mylocation = 2 c u r r e n t L o c a t i o n. g e t L a t i t u d e ( ) + ", " + 3 c u r r e n t L o c a t i o n. getlongitude ( ) ; 4 S t r i n g d e s t i n a t i o n = 5 s e l e c t e d I t e m. g e t L a t i t u d e ( ) + ", " + 6 s e l e c t e d I t e m. getlongitude ( ) ; 7 I n t e n t n a v i I n t e n t = new I n t e n t ( I n t e n t.action_view, 8 Uri. parse ( " http : / / maps. g oogle. com/maps?" + 9 " saddr=" + mylocation + "&daddr=" + d e s t i n a t i o n ) ) ; 10 s t a r t A c t i v i t y ( n a v i I n t e n t ) ; Die Koordinaten der eigenen Position (saddr) und des Ziels (daddr) werden als Request Parameter einer URI kodiert und an Google Maps adressiert. Die URI wird dem Intent übergeben und verschickt. Plattform intern wird der Intent zur Applikation Google Maps geleitet. Diese nimmt die Parameter entgegen, berechnet die exakte Route und startet die Navigation Umsetzung einer interaktiven Kartenansicht für alle Work Items Neben der Visualisierung der örtlichen Differenzen eines ausgewählten Work Items zum eigenen Standort auf einer interaktiven Landkarte, ist eine vergleichbare Ansicht umgesetzt. Jedoch mit der Erweiterung, dass zum Einen alle ortsgebundenen Work Items auf der Karte verzeichnet und diese zum Anderen auswählbar sind. Das genaue Konzept dieser View ist zu finden in Abschnitt Die Vorgehensweise für den Aufbau und die regelmäßige Aktualisierung der Karte ist vergleichbar mit dem in Abschnitt 4.14 beschriebenen Prozess. Hierbei wird jedoch über alle ortsgebundenen Work Items iteriert und eine Markierung mittels Overlay vorgenommen. Hierauf wird in diesem Abschnitt nicht erneut Bezug genommen, sondern die Möglichkeit erläutert, Einträge auf der Landkarte auswählbar zu machen, um unmittelbar mit der Datenbearbeitung beginnen zu können. Der Quellcodeausschnitt zeigt das hierfür erforderliche Überschreiben der ontap() Methode. 4 Umsetzung 90

96 Listing 4.20: Verwendung anklickbarer Map Overlays 1 protected boolean ontap ( int index ) { 2 f i n a l MobileWorkItemOverlay mobileworkitemoverlay = 3 this. workitemoverlays. get ( index ) ; 4 A l e r t D i a l o g. Builder b u i l d e r = new A l e r t D i a l o g. Builder ( this. context ) ; 5 b u i l d e r. s e t T i t l e ( mobileworkitemoverlay. g e t T i t l e ( ) ) 6. setmessage ( mobileworkitemoverlay. getsnippet ( ) + "\n" + 7 " S t a r t e d i t i n g?" ) 8. s e t C a n c e l a b l e ( f a l s e ) 9. s e t I c o n (R. drawable. androidmarker ) 10. s e t P o s i t i v e B u t t o n ( "Yes", 11 new D i a l o g I n t e r f a c e. OnClickListener ( ) { 12 public void onclick ( D i a l o g I n t e r f a c e dialog, int id ) { 13 I n t e n t workitemintent = 14 new I n t e n t ( context, WorkItemActivity. class ) ; 15 workitemintent. putextra ( "PRIMARY_KEY", 16 mobileworkitem. getprimarykey ( ) ) ; 17 workitemintent. setaction ( WorkItemActivity.EDIT_INTENT) ; 18 context. s t a r t A c t i v i t y ( workitemintent ) ; 19 } 20 }) 21. setnegativebutton ( "No", new D i a l o g I n t e r f a c e. OnClickListener ( ) { 22 public void onclick ( D i a l o g I n t e r f a c e dialog, int id ) { 23 d i a l o g. c a n c e l ( ) ; 24 } 25 }) ; 26 A l e r t D i a l o g d i a l o g = b u i l d e r. c r e a t e ( ) ; 27 d i a l o g. show ( ) ; 28 return true ; 29 } Die Klasse TappableWorkListOverlay erweitert die Oberklasse Itemized- Overlay, einer speziellen Android Klasse bestehend aus mehreren Overlay Elementen. In diesem Fall wird eine Liste von mehreren MobileWorkItemOverlay s verwaltet. Das Überschreiben der ontap() Methode macht es möglich auf die Selektion eines Overlay Elements zu reagieren. Über den Index wird das angeklickte Work Item geladen und ein Dialog gestartet, in dem der Nutzer den Start der Bearbeitungsphase bestätigen muss. Wird der Dialog positiv beantwortet, wird unmittelbar die WorkItemActivity über einen entsprechenden Intent gestartet. Bei einem Abbruch des Dialogs, landet der Nutzer wieder auf der Kartenansicht. 4 Umsetzung 91

97 5 Ergebnisse Das folgende Kapitel befasst sich mit den erzielten Ergebnissen dieser Arbeit. Hierzu werden zunächst die wesentlichen Kernpunkte zusammengefasst. Die neu geschaffenen Möglichkeiten werden anhand eines exemplarischen Geschäftsprozesses in Form eines mobilen Workflows veranschaulicht. Anschließend werden Probleme der entwickelten Lösungen erörtert und ein Ausblick hinsichtlich möglicher, aufbauender Arbeiten gegeben. Ein resümierendes Fazit wird die Arbeit abschließen. 5.1 Zusammenfassung Das Geschäftsprozess Management hat sich in der Unternehmenspraxis als Methode zur Erschließung von Optimierungspotentialen etabliert. Auf der operativen Ebene werden Workflow Management Systeme eingesetzt, um Geschäftsprozesse ITgestützt abzubilden und als Workflows zur Ausführung zu bringen. Dieses Vorgehen ist auf die Nutzung stationärer Rechnersysteme ausgelegt. Durch den stetig steigenden Kostendruck, die erhöhten Flexibilitätsanforderungen und die wachsende Mobilität der Mitarbeiter entsteht in Unternehmen der Bedarf einer Integration mobiler Endgeräte in den Kontext des Workflow Managements. Die vorliegende Arbeit befasst sich mit der Konzeption und Implementierung eines mobilen Clients auf Basis der Android Plattform für das Workflow Management System YAWL. Im Fokus der Betrachtungen stehen auf der einen Seite die vielfältigen Erweiterungsmöglichkeiten im Bereich des Workflow Managements und auf der anderen Seite die Berücksichtigung der Restriktionen, welche mit mobilen Endgeräten einhergehen. Die allgemeine Analyse der Erweiterung von Workflow Management Systemen hinsichtlich der Einbeziehung mobiler Endgeräte, leitet drei übergeordnete Faktoren ab, die Mehrwerte auf diesem Gebiet generieren. Diese Potentiale liefern die folgende Gliederung: Mobilität Durch die Möglichkeit mobile Tätigkeiten in einen übergeordneten Workflow einzubeziehen, erzielt man für bestehende Prozesse eine Entkopplung der Bearbeitung von Ort und Zeit. Zur Erschließung neuer Prozesse erweitert sich das Einsatzspektrum des Workflow Managements. Arbeitsschritte, die bisher nicht mit stationären Rechner zu unterstützen sind, können auf mobilen Endgeräten durchgeführt und nach Beendigung unmittelbar über verfügbare drahtlose Netzwerke übermittelt werden. Der Faktor Mobilität trägt im Allgemeinen zu einer Verbesserung der Prozessqualität und einer Verkürzung der Durchlaufzeiten bei.

98 Eingabemethoden Mobile Endgeräte bieten ein breites Spektrum an modernen Eingabemethoden, welche über die Funktionalitäten stationärer Hardware hinausgehen. Es eröffnen sich im Workflow Management zusätzliche Möglichkeiten, die ohne mobile Technologien nicht realisierbar sind. Die gezieltere Unterstützung, während der Prozessausführung, wirkt sich positiv auf die Bearbeitungszeiten aus. Durch das gesteigerte Funktionsspektrum wird die Qualität der Prozesse verbessert. Ortsgebundene Prozesstätigkeiten Völlig neue Perspektiven im Workflow Management ergeben sich durch die Einbeziehung standortbezogener Informationen, welche sich in vielfältiger Weise verarbeiten lassen. Beispielsweise können Prozesstätigkeiten mit einer Ortsbindung versehen werden, die hilfreich ist, um eine optimale Bearbeitungsreihenfolge festzulegen. Das Workflow Management gewinnt in seiner Gesamtheit an Flexibilität und hilft Prozesskosten zu verringern. Alle drei genannten Faktoren fließen in die im Rahmen der vorliegenden Arbeit entwickelte, mobile Applikation YAWL Android Client (YAC) ein, sind der Ausgangspunkt für die Konzeption und finden eine praktische Implementierung. Die Basis bildet die Integration von YAC in die YAWL Infrastruktur. Hierfür wird die Kopplung über bereitstehende Schnittstellen realisiert und ein robuster Synchronisierungsmechanismus entwickelt. Dieser ermöglicht es zum Einen die Offline Funktionalität sicherzustellen und bietet zum Anderen die Option der Live Synchronisation, um erledigte Prozesstätigkeiten möglichst zeitnah am zentralen YAWL System bekannt zu machen. Ein Konvertierungsprozess wird eingesetzt, um die über XML Schema spezifizierten Arbeitsschritte, so genannte Work Items, in eine graphische Benutzeroberfläche umzusetzen. Dabei werden sämtliche Elemente gemäß ihres Datentyps einer repräsentierenden, interaktiven View Komponente zugewiesen. Hierdurch wird die Bearbeitung generischer Datenstrukturen über anforderungsgerechte Android Konzepte möglich. Unter Ausnutzung des breiten Funktionsumfangs mobiler Endgeräte, erhalten spezielle Eingabemethoden Einzug in die Bearbeitung von Workflows. YAC unterstützt die Aufnahme von Fotos über die Kamerafunktion, das Einscannen von Barcodes sowie die Verwendung des Touchscreens als Zeichenunterlage, beispielsweise zur Entgegennahme einer digitalen Unterschrift. Des Weiteren können QR Codes als Grundlage einer Suchfunktion eingesetzt werden, um gezielt spezielle Tätigkeiten zu ermitteln. Um die weitreichenden Möglichkeiten geographischer Informationen im Workflow Management zu demonstrieren, können Arbeitsschritte mit einer örtlichen Beschränkung versehen werden. YAC verarbeitet diese Ortsbindung und setzt diese in Relation zum aktuellen Aufenthaltsort. Dadurch können räumliche Entfernungen zu auszuführenden Tätigkeiten berechnet werden, die einem mobilen Arbeiter helfen können, seine nächsten Ziele zu ermitteln. 5 Ergebnisse 93

99 Die Entwicklung einer internen Architektur sorgt für eine nahtlose Integration der Anwendung in den Gesamtkontext der Android Plattform. Der Entwurf und die Umsetzung benötigter Benutzeroberflächen auf Basis etablierter Designmuster stellt einen hohen Bedienungskomfort sicher. 5.2 Exemplarischer Geschäftsprozess als mobiler Workflow In Kapitel wird ein exemplarischer Geschäftsprozess vorgestellt, der eine Abhol und Zustelldienstleistung eines Logistikunternehmens beschreibt. Im weiteren Verlauf dieser Arbeit wird der Ablauf in einen Workflow überführt, um eine IT gestützte Durchführung über das YAWL Workflow Management System zu erfahren, siehe Abschnitt Im Folgenden wird eine erweiterte Version dieses Prozesses präsentiert, anhand dessen ein Großteil der neu geschaffenen Möglichkeiten veranschaulicht wird. Abbildung 5.1 zeigt die resultierende Version des Beispiel Workflows unter Nutzung des mobilen Clients YAC. Mit PKW abholen Transportinformation aufnehmen Auftrag bestätigen Lieferung zustellen Mit LKW abholen Legende: YAC - Funktionalitäten Kamera / Foto-Funktion Touch- Unterschrift QR-Scan & Verarbeitung Lokalisierung / Ortsbeschränkung Abbildung 5.1: Beispiel Workflow in YAWL Notation unterstützt durch den mobilen Client YAC Zunächst kann festgehalten werden, dass sich sowohl stationäre als auch mobile Tätigkeiten des Geschäftsprozesses als Workflow abbilden lassen, um als solcher ausgeführt zu werden. Die Grundlage hierfür schafft der mobile Client YAC, der den Fahrern auch unterwegs Zugriff auf das zentrale YAWL System über ein mobiles Endgerät gewährt. Somit können alle Fahrer jederzeit und überall die auszuführenden Transportaktivitäten inklusive der beinhalteten Daten einsehen. Da es sich bei einer Abholung um eine ortsgebundene Tätigkeit handelt, ist YAC im Stande über GPS die Entfernung eines Fahrers zu den anzusteuernden Standorten zu berechnen. 5 Ergebnisse 94

100 Über eine Liste kann schnell ermittelt werden, welche Fahrt die kürzeste Distanz aufweist. Die Kartenansicht aller Abholungen verschafft einen Überblick der potentiellen Ziele. Basierend auf diesen Erkenntnissen weist sich ein Fahrer die räumlich nächstgelegene Lieferung zu und macht dies über die Live Synchronisation unter Nutzung eines drahtlosen Netzes unmittelbar am entfernten YAWL System bekannt. Um zum Ziel geführt zu werden, startet der Fahrer über eine YAC Oberfläche ein installiertes Navigationssystem. Die Koordinaten werden dabei automatisch übermittelt. Somit kann ohne weiteren Aufwand die Route berechnet und die Navigation begonnen werden. Am Ort der Abholung angekommen, werden Informationen des Kunden und des Lieferziels komfortabel und ohne großen Zeitaufwand über den QR Code Scanner eingelesen. Um den Zustand des Lieferobjekts zu dokumentieren, kann ein Foto über die Kamerafunktion des mobilen Endgeräts geschossen werden. Die anschließende Auslieferung lässt sich wiederum navigationsgestützt durchführen. Zur Bestätigung, dass während des Transportweges die Fracht nicht beschädigt wurde, nimmt der Fahrer am Zielort ein weiteres Fotos auf. Der Adressat unterzeichnet die Übergabe direkt auf dem Touchscreen mit seiner Unterschrift und erkennt hiermit die ordnungsgemäße Lieferung an. Im Anschluss kann der Fahrer durch die Synchronisierung, die generierten Daten an das YAWL System übermitteln und damit den Prozess abschließen. 5.3 Probleme & Ausblick Die Bereitstellung einer Offline Funktionalität stellt auf der einen Seite die fortwährende Arbeitsfähigkeit der mobilen Clients sicher. Auf der anderen Seite entsteht jedoch die Gefahr der Dateninkonsistenz und dadurch bedingt eine redundante Ausführung von Prozessschritten. Dieser Fall tritt ein, sobald ein mobiler Client mit der Bearbeitung offener Work Items beginnt und das Akzeptieren der Tätigkeit nicht unmittelbar zum YAWL System übermittelt. Da im Status Offered das Work Item unter Umständen mehreren Teilnehmern angeboten wird, können sich mehrere Clients mit der Erledigung derselben Aufgabe befassen. Der einzige Lösungsansatz besteht darin, Statusänderungen möglichst zeitnah am zentralen YAWL System bekannt zu machen, um die risikobehaftete Zeitspanne zu minimieren. YAC setzt hierfür einen optimistischen Arbeitsmodus ein, der versucht, lokale Änderungen live zu synchronisieren. Diese Lösung kann seine Wirkung jedoch nur unter der Voraussetzung eines verfügbaren drahtlosen Netzwerks und einer fehlerfreien Datenübertragung entfalten. Die Ausdrucksmöglichkeiten eines XML Schema sind sehr vielfältig, was die Abbildung von Schema Elementen auf View Komponenten in Spezialfällen sehr komplex werden lässt. YAC orientiert sich im aktuellen Stand an den gängigen Datentypen und Konstrukten und ist dadurch in der Lage einen Großteil existierender XML Schema Definitionen korrekt abzubilden. In Einzelfällen finden bestimmte Attribute oder Konstrukte keine Berücksichtigung, was die Work Item Bearbeitung behindern kann. Um dieser Problematik entgegenzuwirken, kann das Abbildungsspektrum erweitert werden, um auch weniger häufig verwendete Attribute korrekt umzusetzen. 5 Ergebnisse 95

101 In der gegenwärtigen Version besitzt YAC keine Funktionalität Workflows zu startet, um dadurch Prozesse zu initiieren. Derzeitig beschränkt sich YAC auf bereits laufende Workflows. Diese werden entweder von anderen Nutzern oder direkt vom YAWL System ausgelöst. Für die Zukunft ist es erstrebenswert, den Funktionsumfang dahingehend zu erweitern, dass direkt über den mobilen Client Workflows in Gang gesetzt werden können. Hierzu könnten unter anderem erneut mobile Eingabemethoden eingesetzt werden. Dies würde zusätzliche Anwendungsgebiete erschließen und zu einer weiteren Flexibilisierung im Workflow Management beitragen. Um dies zu bewerkstelligen, sind jedoch weitreichende Arbeiten von Nöten. Zunächst muss ein Client seitiges Konzept die Nutzerberechtigung sicherstellen, die zur Initiierung neuer Cases erforderlich ist. Zusätzliche Interaktionskomponenten und Kommunikationsmechanismen sind umzusetzen. Des Weiteren ist in diesem Kontext die so genannte Admin Queue zu berücksichtigen, da bestimmte Work Items durch Nutzer mit Administratorrechten freigegeben und auf Nutzer oder Gruppen verteilt werden müssen. Aufbauende Arbeiten sind vor allem im Bereich der ortsgebundenen Dienste zu verfolgen, da die vorliegende Arbeit lediglich einen Teilbereich der Möglichkeiten anhand eines verbreiteten Anwendungsfall behandelt. Um nur ein Beispiel zu nennen, ist es denkbar, die mobilen Clients dahingehend zu erweitern, dass diese in periodischen Abständen ihren aktuellen Aufenthaltsort an das YAWL System übermitteln. Dort werden zentral alle Standortinformationen ausgewertet, um basierend auf festzulegenden Metriken, eine ortsgebundene Tätigkeit automatisiert einem optimalen Teilnehmer zuweisen zu können. Hierfür sind Erweiterungen am YAWL System vorzunehmen. Ein speziell konzipierter Custom Service könnte diese Zuständigkeit übernehmen. Die unmittelbare Verknüpfung binärer Daten mit Work Items ist bisher von YAWL nicht vorgesehen. Um trotzdem Bilddateien generieren und in Workflows einbetten zu können, setzt YAC ein Konzept um, welches nur Client seitig genutzt werden kann. Im YAWL System liegen übermittelte Fotos lediglich in Zeichenketten kodierter Form vor. Eine Server seitige Dekodierung findet derzeit nicht statt. Für zukünftige Versionen von YAWL ist eine native Unterstützung binärer Datentypen wünschenswert, so dass ausgetauschte Bilddaten auf beiden Seiten ohne weitere Aufwände verwertbar sind. 5.4 Fazit Alle definierten Ziele, die zu Beginn des Projekts festgelegt wurden, konnten erarbeitet werden. Die Integration eines mobilen Clients in die YAWL Infrastruktur ist realisiert und somit das Basis Vorhaben erreicht. Über dies hinausgehend ist die Verwendung diverser, mobiler Eingabemethoden im Rahmen des Workflow Managements exemplarisch aufgezeigt und konkret implementiert. Um den Funktionsumfang mobiler Endgeräte flächendeckend auszuschöpfen, ist ein Konzept zur Nutzung ortsgebundener Prozesstätigkeiten vorgestellt und praktisch umgesetzt. Die Vereinigung des Workflow Managements und des Mobile Computings gestaltet sich sehr facettenreich und erfordert Fachwissen aus einer Vielzahl verschiedener Domänen. Die zu lösenden Probleme sind komplex und fordernd. 5 Ergebnisse 96

102 Die vielversprechenden Ansätze und Möglichkeiten, die sich erschließen lassen, rechtfertigen die erforderlichen Anstrengungen jedoch. Der Faktor Mobilität eröffnet im Workflow Management ein bisher nicht ausreichend untersuchtes Optimierungspotential. Durch die enormen wirtschaftlichen Interessen herrscht allerdings eine rege Forschungsaktivität in diesem Bereich. Es ist davon auszugehen, dass zunehmend interessante Lösungen auf den Markt drängen. Für das Workflow Management System YAWL versteht sich die vorliegende Arbeit als eine Grundsteinlegung. Bestehende Konzepte werden erweitert, um den Aspekt der Mobilität und den hiermit einhergehenden Chancen und Risiken. 5 Ergebnisse 97

103 Literaturverzeichnis [van der Aalst 1998] Aalst, Wil M. P. van der: The Application of Petri Nets to Workflow Management. In: Journal of Circuits, Systems, and Computers 8 (1998), Nr. 1, S [van der Aalst u. a. 2004] Aalst, Wil van der ; Aldred, Lachlan ; Dumas, Marlon ; Hofstede, Arthur ter: Design and Implementation of the YAWL System. In: Persson, Anne (Hrsg.) ; Stirna, Janis (Hrsg.): Advanced Information Systems Engineering Bd Springer Berlin / Heidelberg, 2004, S URL [Ableson u. a. 2009] Ableson, W.F. ; Collins, C. ; Sen, R.: Unlocking Android: a developer s guide. Manning, 2009 (Manning Pubs Co Series). ISBN [Android 2011a] Android: User Interface Guidelines. android.com/guide/practices/ui_guidelines/index.html:, Letzter Zugriff: September 2011 [Android 2011b] Android: What is Android? com/guide/basics/what-is-android.html:, Letzter Zugriff: September Developers Documentation [Baun u. a. 2009] Baun, C. ; Kunze, M. ; Nimis, J. ; Tai, S.: Cloud Computing: Web-basierte dynamische IT-Services. Springer, 2009 (Informatik Im Fokus) [Becker und Pant 2010] Becker, A. ; Pant, M.: Android 2: Grundlagen und Programmierung. Dpunkt.Verlag GmbH, 2010 [Decker u. a. 2010] Decker, Michael ; Che, Haiying ; Oberweis, Andreas ; Stürzel, Peter ; Vogel, Matthias: Modeling Mobile Workflows with BPMN. In: Proceedings of the 2010 Ninth International Conference on Mobile Business / 2010 Ninth Global Mobility Roundtable. Washington, DC, USA : IEEE Computer Society, 2010 (ICMB-GMR 10), S ISBN [Denso-Wave 2004] Denso-Wave: QR-Code Standardization. November [Eggert 2007] Eggert, S.: Enterprise content management. Gito, ISBN [Every 2010] Every, S.V.: Pro Android Media: Developing Graphics, Music, Video, and Rich Media Apps for Smartphones and Tablets. Apress, ISBN [Feldbrügge und Brecht-Hadraschek 2008] Feldbrügge, R. ; Brecht- Hadraschek, B.: Prozessmanagement leicht gemacht: Geschäftsprozesse analysieren und gestalten. Redline Wirtschaft, 2008 (Leicht gemacht). ISBN

104 [Fielding 2000] Fielding, R. T.: Architectural Styles and the Design of Networkbased Software Architectures, University of California, Irvine, Dissertation, 2000 [Fowler 2003] Fowler, Martin: Patterns für Enterprise-Application- Architekturen. mitp-verlag, ISBN [Freund und Götzer 2008] Freund, J. ; Götzer, K.: Vom Geschäftsprozess zum Workflow: Ein Leitfaden für die Praxis. Hanser Fachbuchverlag, 2008 [Fuchß 2009] Fuchß, T.: Mobile Computing: Grundlagen und Konzepte für mobile Anwendungen. Hanser, Carl, ISBN [Fulcher u. a. 2010] Fulcher, Richard ; Nesladek, Chris ; Palmer, Jim ; Robertson, Christian: Android UI Design Patterns. May Google IO 2010 [Gadatsch 2009] Gadatsch, A.: Grundkurs Geschäftsprozess-Management: Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker. Vieweg+Teubner Verlag, ISBN [Gamma u. a. 1994] Gamma, E. ; Helm, R. ; Johnson, R. ; Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994 (Addison-Wesley professional computing series). ISBN [Gargenta 2011] Gargenta, M.: Learning Android. O Reilly Media, 2011 (O Reilly Series). ISBN [Gartner 2011] Gartner: Gartner Says 428 Million Mobile Communication Devices Sold Worldwide in First Quarter 2011, a 19 Percent Increase Year-on-Year. May [Giner u. a. 2011] Giner, Pau ; Cetina, Carlos ; Fons, Joan ; Pelechano, Vicente: Implicit interaction design for pervasive workflows. In: Personal and Ubiquitous Computing 15 (2011), S URL /s ISSN [Hagen und Stucky 2004] Hagen, C.R. ; Stucky, W.: Business-Process- und Workflow-Management: Prozessverbesserung durch Prozess-Management. B.G. Teubner, 2004 (Lehrbuch Informatik). ISBN [Hartmann 2002] Hartmann, D.: Geschäftsprozesse mit Mobile Computing. Vieweg, ISBN [Hashimi u. a. 2010] Hashimi, S.Y. ; Komatineni, S. ; MacLean, D.: Pro Android 2. Apress, 2010 (Apress Series) [Hofstede u. a. 2009] Hofstede, A.H.M. ; Aalst, W.M.P. ; Adams, M. ; Russell, N.: Modern Business Process Automation: YAWL and Its Support Environment. Springer, 2009 [Hollingsworth 1995] Hollingsworth, D.: Workflow Management Coalition - The Workflow Reference Model / Workflow Management Coalition. URL Januar Forschungsbericht Literaturverzeichnis 99

105 [Hyland-Software 2011] Hyland-Software: Workflow Software Integration. Letzter Zugriff: September hyland.com/onbase-and-ecm/onbase-platform-modules/ business-process-automation/workflow.aspx [ISEC7 2011] ISEC7: Mobile SAP. Letzter Zugriff: September http: //www.isec7.com/en/products/mobile-sap [jdom.org 2011] jdom.org: JDOM. Letzter Zugriff: September http: //www.jdom.org [Josuttis 2008] Josuttis, N.: SOA in der Praxis: System-Design für verteilte Geschäftsprozesse. Dpunkt.Verlag GmbH, 2008 [Kinghood-Technologies 2011] Kinghood-Technologies: Cyberhood Workflow. Letzter Zugriff: September enwebsite/index.php [Lee 2011] Lee, W.M.: Beginning Android Application Development. John Wiley & Sons, ISBN [Liebhart 2007] Liebhart, D.: SOA goes real: Service-orientierte Architekturen erfolgreich planen und einführen. Hanser, ISBN [Meier 2010] Meier, R.: Professional Android 2 Application Development. John Wiley & Sons, ISBN [Meir-Huber 2010] Meir-Huber, M.: Cloud Computing: Praxisratgeber und Einstiegsstrategien. Software + Support, 2010 [Melzer 2010] Melzer, I.: Service-orientierte Architekturen mit Web Services: Konzepte- Standards- Praxis. Spektrum Akademischer Verlag, 2010 [Mosemann und Kose 2009] Mosemann, H. ; Kose, M.: Android. Hanser, ISBN [Murphy 2009] Murphy, M.L.: The Busy Coder s Guide to Android Development. Commonsware, LLC, 2009 [Müller 2005] Müller, J.: Workflow-based Integration: Grundlagen, Technologien, Management. Springer, 2005 (Xpert. press Series). ISBN [Pajunen und Chande 2007] Pajunen, Lasse ; Chande, Suresh: Developing Workflow Engine for Mobile Devices. In: Enterprise Distributed Object Computing Conference, IEEE International 0 (2007), S ISSN [Papageorgiou u. a. 2009] Papageorgiou, Apostolos ; Eckert, Julian ; Repp, Nicolas ; Steinmetz, Ralf: Bridging the Gaps towards Structured mobile SOA. December URL / [Pintea und Tivadar 2009] Pintea, R. ; Tivadar, L.S.: Improvements in cardiology workflow in a hospital using mobile software solutions. In: Applied Computational Intelligence and Informatics, SACI 09. 5th International Symposium on, may 2009, S Literaturverzeichnis 100

106 [Ploesser u. a. 2009] Ploesser, Karsten ; Peleg, Mor ; Soffer, Pnina ; Rosemann, Michael ; Recker, Jan C.: Learning from Context to Improve Business Processes. In: BPTrends 6 (2009), January, Nr. 1, S URL [Pohl 2008] Pohl, K.: Requirements Engineering: Grundlagen, Prinzipien,Techniken. Dpunkt.Verlag GmbH, ISBN [Pryss u. a. 2011] Pryss, Rüdiger ; Tiedeken, Julian ; Kreher, Ulrich ; Reichert, Manfred: Towards Flexible Process Support on Mobile Devices. In: Information Systems Evolution Bd. 72. Springer Berlin Heidelberg, 2011, S URL ISBN [Richardson und Ruby 2007] Richardson, L. ; Ruby, S.: Web Services mit REST. O Reilly, 2007 (Safari Books Online) [Rosemann und Recker 2006] Rosemann, Michael ; Recker, Jan C.: Contextaware Process Design: Exploring the Extrinsic Drivers for Process Flexibility. In: Latour, Thibaud (Hrsg.) ; Petit, Michael (Hrsg.): 18th International Conference on Advanced Information Systems Enginnering. Proceedings of Workshops and Doctoral Consortium., Namur University Press, 2006, S URL [Rosemann u. a. 2008] Rosemann, Michael ; Recker, Jan C. ; Flender, Christian: Contextualisation of business processes. In: International Journal of Business Process Integration and Management 3 (2008), July, Nr. 1, S URL [Roth 2005] Roth, J.: Mobile Computing: Grundlagen, Technik, Konzepte. Dpunkt-Verl., 2005 (Dpunkt Lehrbuch). ISBN [Rump u. a. 2005] Rump, J. ; Balfanz, D. ; Porak, A. ; Schröter, W.: Electronic Mobility: Thesen und Empfehlungen. In: e-mobility - Mobile Arbeitswelten, 2005 [Russell und Hofstede 2006] Russell, Nick ; Hofstede, Arthur H. M. T.: Exception Handling Patterns in Process-Aware Information Systems [Russell und ter Hofstede 2009] Russell, Nick ; Hofstede, Arthur ter: Surmounting BPM challenges: the YAWL story. In: Computer Science - Research and Development 23 (2009), S URL s ISSN [Schmelzer und Sesselmann ] Schmelzer, H.J.S.W. ; Sesselmann, W.: Geschäftsprozessmanagement in der Praxis. Hanser. ISBN [Singh und Huhns 2005] Singh, M.P. ; Huhns, M.N.: Service-oriented computing: semantics, processes, agents. Wiley, ISBN [Skulschus und Wiederstein 2008] Skulschus, M. ; Wiederstein, M.: XML Schema. Comelio GmbH, ISBN [slf4j.org 2011] slf4j.org: SLF4J user manual. Letzter Zugriff: September Literaturverzeichnis 101

107 [Tidwell 2010] Tidwell, Jenifer: Designing Interfaces. O Reilly Media, 2010 (O Reilly Series). ISBN [US Department of Defense 1994] US Department of Defense (Veranst.): World Geodetic System (WGS) [Vilenica 2008] Vilenica, A.: Interaktive Geschäftsprozesse im Mobile Computing: Entwurf und Implementierung benutzer-zentrischer Arbeitsprozesse im Mobile Business. VDM Verlag, ISBN [Vlist 2002] Vlist, E.V.: XML Schema. O Reilly, 2002 (O Reilly Series). ISBN [W3C 2010] W3C: XML Schema. Januar [W3C 2011] W3C: XQuery 1.0: An XML Query Language (Second Edition). Januar URL [Watson 2011] Watson, Gray: ORMLite Package. docs/ormlite.pdf:, Stand: September 2011 [Webber u. a. 2010] Webber, J. ; Parastatidis, S. ; Robinson, I.: REST in Practice: Hypermedia and Systems Architecture. O Reilly Media, 2010 (O Reilly Series) [Werner u. a. 2010] Werner, Martin ; Verclas, Stephan A. W. ; Linnhoff- Popien, Claudia: A Workflow Definition Language for Business Integration of Mobile Devices. In: Mobile Wireless Middleware, Operating Systems, and Applications Bd. 48. Springer Berlin Heidelberg, 2010, S URL ISBN [Witt 2008] Witt, Kurt-Ulrich: Approximative Graphen-Algorithmen - Eine erste Einführung. Mai 2008 [Workflow-Patterns-Initiative 2010] Workflow-Patterns-Initiative: Workflow Patterns URL [YAWL-Foundation 2010a] YAWL-Foundation: YAWL - Technical Manual YAWLTechnicalManual2.1.pdf:, 2010 [YAWL-Foundation 2010b] YAWL-Foundation: YAWL - User Manual pdf:, 2010 [Zaplata und Lamersdorf 2010] Zaplata, Sonja ; Lamersdorf, Winfried: Towards mobile process as a service. In: Proceedings of the 2010 ACM Symposium on Applied Computing. New York, NY, USA : ACM, 2010 (SAC 10), S ISBN [zxing 2010] zxing: BarcodeContents - A rough guide to standard encoding of information in barcodes. Juni wiki/barcodecontents Literaturverzeichnis 102

108 Abbildungsverzeichnis 1.1 Integration von mobilen Endgeräten auf Basis der Android Plattform in generische YAWL Workflows Geschäftsprozess Management: Bindeglied zwischen organisatorischer und IT Perspektive Beispielhafter Geschäftsprozess aus der Logistikbranche: Abhol und Zustelldienstleitung YAWL Kontrollflusssymbole YAWL Lebenszyklus eines Workitems Beispielhafter Arbeitsprozess als YAWL Workflow Die YAWL Architektur Resource Service Modell der Organisationsstruktur Zusammenhang: YAWL Prozesseditor und Laufzeitumgebung Relevante Komponenten der Android Architektur Von *.java zu *.dex Der Lebenszyklus einer Android Activity Rollen in einer SOA (Dreieck) REST basierte Web Service Architektur mit schematischer Ressourcenhierarchie und exemplarischer HTTP Kommunikation Gliederung der Konzeption in fünf zusammenhängende Blöcke YAWL Android Client Architektur UML Aktivitätsdiagramm: Synchronisierungsprozess Synchronisationsmechanismus auf Basis einer lokalen Queue Datenmodell eines Work Items und Kommunikationsablauf über das Workqueue Gateway Abbildung von XML Schema Datentypen auf Android View Komponenten Konvertierung eines XML Schema Dokuments in ein Android UI Beispiel der automatischen Formularausfüllung mittels strukturierter QR Code Informationen Kategorisierung von Ortsbeschränkungen im Rahmen des Workflow Managements UML Komponentendiagramm: Interne Architektur YAC YAC UI Entwurf: Startbildschirm YAC UI Entwurf: Synchronize YAC UI Entwurf: Work Queues Definition einer Standardoperation zur Verringerung des Klick Aufwands auf mobilen Endgeräten YAC UI Entwurf: Edit Work Item YAC UI Entwurf: QR Code & Search Results YAC UI Entwurf: Nearby Work YAC UI Entwurf: Work Item Map YAC: Navigationsübersicht aller Applikationskomponenten

109 4.1 YAC Preferences: Android spezifischer Einstellungsbildschirm UML Klassendiagramm: Zusammenhang von Activity, List View und Listen Adaptern (De )Serialisierungsprozess der XML Daten Hinzufügen und Löschen eines Datenparameters Beispiel Workflow in YAWL Notation unterstützt durch den mobilen Client YAC B.1 YAC Screenshot: Home-Screen (Dashboard) in vertikaler und horizontaler Orientierung B.2 YAC Screenshot: Preferences B.3 YAC Screenshot: Synchronisierung B.4 YAC Screenshot: Work-Queues und Kontextmenü B.5 YAC Screenshot: Work-Item Details und Oberfläche zur Datenbearbeitung B.6 YAC Screenshot: Darstellung einer Fotoaufnahme und Oberfläche für Unterschriften B.7 YAC Screenshot: Nearby Work: Listen und Kartenansicht B.8 YAC Screenshot: Work Queue Map und Auswahldialog Abbildungsverzeichnis 104

110 Tabellenverzeichnis 2.1 Abgrenzung zwischen Geschäftsprozess und Workflow HTTP Methoden und ihre Funktion im Kontext einer REST Architektur QR Code Datentypen Textueller Aufbau und Beispiel Verwendete Methoden des Workqueue Gateways und Beschreibung der Funktionalität A.1 Szenario Mobilität: Bewillige Hardware Anschaffung A.2 Szenario Kameranutzung: Prüfe Schadensfall A.3 Szenario QR-Codes als Eingabemethode: Erfasse Kontaktdaten A.4 Szenario QR-Codes als Eingabemethode: Behandle Patient A.5 Szenario Berührungssensitive Unterschrift: Genehmige Urlaubsantrag A.6 Szenario Ortsbeschränkte Tätigkeit: Hole Lieferung C.1 Inhalt der beiliegenden CD

111 A Exemplarische Nutzungsszenarien Name Akteure Ablauf Bewillige Hardware Anschaffung Manager 1. Der Manager befindet sich auf Dienstreise und ist vor Ort bei einem Kunden. 2. Der Manager startet YAC auf seinem Smartphone. 3. Über ein verfügbares drahtloses Netz synchronisiert er YAC mit dem entfernten YAWL System. 4. Der Manager betrachtet die ihm zugewiesenen Arbeitstätigkeiten. 5. Er wählt den Task zur Freigabe einer Hardware Anschaffung. 6. YAC präsentiert die relevanten Daten und benötigten Eingabefelder. 7. Der Manager bewilligt die Anschaffung und trägt sein Kürzel in das hierfür vorgesehene Eingabefeld ein. 8. Er schließt das Work-Item ab. 9. Das System baut unmittelbar eine Verbindung zum YAWL System auf und propagiert die getätigten Änderungen. Hierauf folgende Prozessschritte werden durch das YAWL System gestartet. Tabelle A.1: Szenario Mobilität: Bewillige Hardware Anschaffung

112 Name Akteure Ablauf Prüfe Schadensfall Versicherer, Schadensmelder 1. Der Versicherer ist vor Ort beim Schadensmelder, um einen angezeigten Schaden zu prüfen. 2. Der Versicherer startet YAC und öffnet die ihm zugewiesenen Arbeitstätigkeiten. 3. Über die angezeigten Daten erfährt er, welcher Schaden gemeldet wurde. 4. Der Versicherer prüft die Sachlage vor Ort und bestätigt die Angaben des Schadensmelders. 5. Der Versicherer dokumentiert die örtlichen Gegebenheiten durch die Aufnahme eines Fotos, welches durch YAC mit der Prozesstätigkeit verknüpft wird. 6. Der Versicherer beendet die Prüfung. 7. YAC übermittelt das abgeschlossene Work Item inklusive des aufgenommenen Fotos zum YAWL System. Tabelle A.2: Szenario Kameranutzung: Prüfe Schadensfall Name Akteure Ablauf Erfasse Kontaktdaten Mitarbeiter, Kunde 1. Der Mitarbeiter ist im Außendienst tätig und aktuell auf Kundenakquise. 2. Der Mitarbeiter öffnet YAC und ein entsprechendes Work Item zur Eingabe von Kundendaten. 3. Der Kunde stellt seine Kontaktinformationen in Form eines QR Codes (beispielsweise auf seiner Visitenkarte) zur Verfügung. 4. Der Mitarbeiter startet den QR Scanner über YAC und liest die Codedaten ein. 5. YAC verarbeitet die Informationen und speichert die resultierenden Werte automatisch in den vorgesehenen Eingabefeldern. 6. Der Mitarbeiter beendet das Work Item. 7. YAC überträgt das Work Item mit den Kundendaten zum YAWL System. Tabelle A.3: Szenario QR-Codes als Eingabemethode: Erfasse Kontaktdaten A Exemplarische Nutzungsszenarien 107

113 Name Akteure Ablauf Behandle Patient Arzt, Patient, Empfangsmitarbeiter 1. Der Empfangsmitarbeiter erzeugt im Rahmen der Klinikaufnahme einen eindeutigen QR Code zur Identifizierung des Patienten. 2. Der Empfangsmitarbeiter startet den Workflow zur Behandlung des Patienten. 3. Der Arzt startet YAC auf seinem Tablet-PC. 4. Er öffnet den QR-Code Scanner und liest während seiner Patientenvisite den Code am Bett des Patienten ein. 5. YAC verknüpft die eingescannten Information mit verfügbaren Work Items. 6. YAC präsentiert dem Arzt die Daten des Patienten und die auszuführende Behandlung. 7. Der Arzt dokumentiert die geleisteten Maßnahmen über YAC und schließt das Work Item ab. 8. YAC überträgt das Work Item zurück zum YAWL System. Tabelle A.4: Szenario QR-Codes als Eingabemethode: Behandle Patient Name Akteure Ablauf Genehmige Urlaubsantrag Manager, Mitarbeiter 1. Der Manager startet YAC auf seinem Tablet-PC. 2. Er synchronisiert YAC und wählt die ihm zugewiesene Tätigkeit Genehmige Urlaubsantrag. 3. YAC öffnet die Bearbeitungsoberfläche. 4. Der Manager öffnet die Ansicht zur Eingabe seiner eigenhändigen Unterschrift. 5. Der Manager führt mit einem speziellen Stift oder seinem Finger seine Unterschrift auf dem Touchscreen des Tablet-PCs aus. 6. YAC digitalisiert die detektierten Bewegungen zu einem Bild. 7. Der Manager bestätigt die Beendigung der Eingabe. 8. YAC verknüpft das digitale Bild mit dem Eingabeparameter des Work Items. 9. Der Manager beendet das Work Item. 10. YAC überträgt das Work Item inklusive der Bilddaten zum YAWL System. Tabelle A.5: Szenario Berührungssensitive Unterschrift: Genehmige Urlaubsantrag A Exemplarische Nutzungsszenarien 108

114 Name Akteure Ablauf Hole Lieferung Fahrer 1. Der Fahrer eines Logistikunternehmens öffnet YAC. 2. Er startet den Synchronisierungsprozess. 3. Er wählt die Oberfläche für ortsgebundene Tätigkeiten. 4. YAC ermittelt den aktuellen Aufenthaltsort und berechnet die Entfernungen zu allen verfügbaren Aufgaben. 5. Der Fahrer weist sich die Tätigkeit Hole Lieferung mit der kürzesten Distanz zu. 6. YAC startet die Navigation und führt den Fahrer zum ausgewählten Ziel. 7. Der Fahrer nimmt die Lieferung entgegen und bestätigt dies über YAC. 8. YAC übermittelt den Vorgang an das YAWL System und schließt damit die Prozesstätigkeit ab. Tabelle A.6: Szenario Ortsbeschränkte Tätigkeit: Hole Lieferung A Exemplarische Nutzungsszenarien 109

115 B YAC Screenshots Home-Screen Abbildung B.1: YAC Screenshot: Home-Screen (Dashboard) in vertikaler und horizontaler Orientierung Preferences Abbildung B.2: YAC Screenshot: Preferences

116 Synchronisierung Abbildung B.3: YAC Screenshot: Synchronisierung Work-Queues Abbildung B.4: YAC Screenshot: Work-Queues und Kontextmenü B YAC Screenshots 111

117 Work-Item Details und Datenbearbeitung Abbildung B.5: YAC Screenshot: Work-Item Details und Oberfläche zur Datenbearbeitung Kamera-Aufnahme und Touch-Unterschrift Abbildung B.6: YAC Screenshot: Darstellung einer Fotoaufnahme und Oberfläche für Unterschriften B YAC Screenshots 112

118 Master-Thesis Nearby Work Abbildung B.7: YAC Screenshot: Nearby Work: Listen und Kartenansicht Work Queue Map Abbildung B.8: YAC Screenshot: Work Queue Map und Auswahldialog B YAC Screenshots 113

Mobile Geschäftsprozesse: ein Android-Client für YAWL

Mobile Geschäftsprozesse: ein Android-Client für YAWL Mobile Geschäftsprozesse: ein Android-Client für YAWL Andreas Hense andreas.hense@h-brs.de Wirtschaftsinformatik A. Hense () Mobile Geschäftsprozesse: ein Android-Client für YAWL 2011 1 / 27 Agenda I 1

Mehr

1 YAWL Yet Another Workflow Language

1 YAWL Yet Another Workflow Language 1 YAWL Yet Another Workflow Language Das YAWL Workflow-Management-System wurde von Wil van der Aalst und seinem Team an der Eindhoven University of Technology entwickelt. Das System ist in seiner jetzigen

Mehr

Umsetzung von Geschäftsprozessen: Workflow-Managementsysteme. Knut Hinkelmann

Umsetzung von Geschäftsprozessen: Workflow-Managementsysteme. Knut Hinkelmann Umsetzung von Geschäftsprozessen: Knut Hinkelmann Das BPMS *) Paradigma Wo liegt unsere Wertschöpfung? Produkte Strategische Entscheidungen Wie erstellen wir unsere Produkte? Geschäftsprozesse Re-Engineering

Mehr

Mobile Geschäftsprozesse: ein Android-Client für YAWL

Mobile Geschäftsprozesse: ein Android-Client für YAWL Mobile Geschäftsprozesse: ein Android-Client für YAWL Andreas Hense andreas.hense@h-brs.de Wirtschaftsinformatik A. Hense () Mobile Geschäftsprozesse: ein Android-Client für YAWL 2011 1 / 28 Agenda I 1

Mehr

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

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

Mehr

Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN)

Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN) Geschäftsprozessmanagement: in»business Process Modelling Notation«(BPMN) Eugen Labun Fachhochschule Gießen-Friedberg Fachbereich MNI Institut für Softwarearchitektur Serviceorientierte Architekturen bei

Mehr

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

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

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

Workflow Management: Workflow (1)

Workflow Management: Workflow (1) Workflow Management: Workflow (1) Abgrenzung: Geschäftsprozeß Vorgang (Aktivität) Arbeitsablauf (Workflow) Arbeitsschritt (Work Item) Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Workflow Systeme mit der Windows Workflow Foundation

Workflow Systeme mit der Windows Workflow Foundation Studiengang Electronic Business (EB) Diplomarbeit (280000) Workflow Systeme mit der Windows Workflow Foundation externe Betreuung durch Christoph Müller vorgelegt bei Prof. Dr. Michael Gröschel von Hans-Martin

Mehr

Geschäftsprozesse & Workflow: WfMC Referenzmodell

Geschäftsprozesse & Workflow: WfMC Referenzmodell Seminar E-Services WS 02/03 Geschäftsprozesse & Workflow: WfMC Referenzmodell Jacqueline Tran & Marco Glier Gliederung 1. Workflow 2. Workflow Managementsysteme (WfMS) 3. Workflow Management Coalition

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

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

Mehr

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

Prozessautomatisierung Vom Geschäftsprozess zum IT-Prozess Benjamin Brunner SOA Architect OPITZ CONSULTING Bad Homburg GmbH

Prozessautomatisierung Vom Geschäftsprozess zum IT-Prozess Benjamin Brunner SOA Architect OPITZ CONSULTING Bad Homburg GmbH Prozessautomatisierung Vom Geschäftsprozess zum IT-Prozess Benjamin Brunner SOA Architect OPITZ CONSULTING Bad Homburg GmbH Agenda Warum Prozessautomatisierung? Prozessautomatisierung in einer SOA Von

Mehr

BPM für IBIS BAT 23.06.2006. Jean-Marc Terrettaz, RTC

BPM für IBIS BAT 23.06.2006. Jean-Marc Terrettaz, RTC BPM für IBIS BAT 23.06.2006 Jean-Marc Terrettaz, RTC Inhalt Das Projekt Technologieauswahl & Produktevaluation Entwicklungsmethodik Integration in IBIS Fazit RTC AG NtrlPpt_10355,A,2 Seite 2 Ausgangslage

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Seminar XML und Datenbanken. Thema: Workflow

Seminar XML und Datenbanken. Thema: Workflow Seminar XML und Datenbanken Thema: Workflow Betreuer: Markus Bon Bearbeiter: Kristof Barklage Gliederung (1) Grundlagen (2) Workflow Management Coalition (3) XML Process Definition Language (XPDL) (4)

Mehr

Automatisierung Vom definierten Geschäftsprozess zum automatisiert ablaufenden Workflow

Automatisierung Vom definierten Geschäftsprozess zum automatisiert ablaufenden Workflow Automatisierung Vom definierten Geschäftsprozess zum automatisiert ablaufenden Workflow Konzepte und Ansätze der Workflow-Automatisierung und deren technischer Grundlage Joachim Brunold 25.02.2010 Version

Mehr

White Paper. Embedded Treiberframework. Einführung

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

Mehr

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

Vertiefte Grundlagen. Übung 2.7. TU Dresden - Institut für Bauinformatik

Vertiefte Grundlagen. Übung 2.7. TU Dresden - Institut für Bauinformatik Bauinformatik Vertiefte Grundlagen Geschäftsprozessmodellierung Übung 2.7 Begriffe Ein Geschäftsprozess beschreibt wiederkehrenden Ablauf. Dieser Ablauf beschreibt, welche Aktivitäten in welcher Folge

Mehr

Geschäftsprozessanalyse

Geschäftsprozessanalyse Geschäftsprozessanalyse Prozessmodellierung weitere Begriffe: workflow business process modelling business process (re-)engineering 2 Was ist ein Prozess? Prozesse bestehen aus Aktionen / Ereignissen /

Mehr

Vorlesung. Modelle für Geschäftsprozesse und Services. Prof. Dr. Karsten Wolf

Vorlesung. Modelle für Geschäftsprozesse und Services. Prof. Dr. Karsten Wolf Vorlesung Modelle für Geschäftsprozesse und Services Prof. Dr. Karsten Wolf Was ist ein Geschäftsprozess? Beispiele: Bearbeitung eines Schadensfalls in einer Versicherung Kreditüberprüfung in einer Bank

Mehr

Business Process Model and Notation BPMN

Business Process Model and Notation BPMN Business Process Model and Notation BPMN BPMN ist ein Standard der Object Management Group OMG zur graphischen Notation von Geschäftsprozessen Aktueller Standard: BPMN 2.0 (http://www.omg.org/spec/bpmn/2.0/)

Mehr

Business Process Management schlägt die Brücke zwischen Geschäftsprozessen und Service-orientierter Architektur

Business Process Management schlägt die Brücke zwischen Geschäftsprozessen und Service-orientierter Architektur Business Process Management schlägt die Brücke zwischen Geschäftsprozessen und Service-orientierter Architektur Migration & Integration Day 2007 6-Feb-07, München Marcus J. Armbruster Principal Mentor

Mehr

Analysen sind nur so gut wie die Datenbasis

Analysen sind nur so gut wie die Datenbasis Analysen sind nur so gut wie die Datenbasis Datenaufbereitung und Sicherung der Datenqualität durch den kontextbasierten MIOsoft Ansatz. Daten gelten längst als wichtiger Produktionsfaktor in allen Industriebereichen.

Mehr

ITSM Infoday 2013. Mit Business Process Service Management zu mehr Flexibilität, Transparenz und Stabilität. Peter Brückler

ITSM Infoday 2013. Mit Business Process Service Management zu mehr Flexibilität, Transparenz und Stabilität. Peter Brückler ITSM Infoday 2013 Mit Business Process Management zu mehr Flexibilität, Transparenz und Stabilität Peter Brückler Copyright 2013 NTT DATA EMEA Ltd. Agenda Der Druck auf Unternehmen Business Process Management

Mehr

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

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

Mehr

Using Workflows to Coordinate Web Services in Pervasive Computing Environments

Using Workflows to Coordinate Web Services in Pervasive Computing Environments Using Workflows to Coordinate Web Services in Pervasive Computing Environments Vortrag im Rahmen des Seminars SOA 2005 im Fachbereich Informatik angefertigt von Volker Henke Agenda 1. Ubiquitous Computing

Mehr

Die nächste Revolution in der modelgetriebenen Entwicklung?

Die nächste Revolution in der modelgetriebenen Entwicklung? Die nächste Revolution in der modelgetriebenen Entwicklung? Me Johannes Kleiber Software Engineer bei FMC Johannes.Kleiber@fmc-ag.com Themen Überblick Window Workflow Foundation Workflows modellieren WF

Mehr

Mobile Application Development

Mobile Application Development Mobile Application Development Android: Einführung Jürg Luthiger University of Applied Sciences Northwestern Switzerland Institute for Mobile and Distributed Systems Lernziele Der/die Kursbesucher/in kann

Mehr

Workflowmanagement. Business Process Management

Workflowmanagement. Business Process Management Workflowmanagement Business Process Management Workflowmanagement Workflowmanagement Steigern Sie die Effizienz und Sicherheit Ihrer betrieblichen Abläufe Unternehmen mit gezielter Optimierung ihrer Geschäftsaktivitäten

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 374

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 374 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 374 Eignung von Verfahren der Mustererkennung im Process Mining Sabrina Kohne

Mehr

Geschäftsprozessmodellierung essmodellierung mit BPEL

Geschäftsprozessmodellierung essmodellierung mit BPEL Geschäftsprozessmodellierung essmodellierung mit BPEL Autor: Stefan Berntheisel Datum: 8. Januar 2010 Stefan Berntheisel Hochschule RheinMain Fachseminar WS 09/10 Agenda Grundlagen Business Process Execution

Mehr

Content Management Systeme

Content Management Systeme Content Management Systeme Ein Vergleich unter besonderer Berücksichtigung von CoreMedia und TYPO3 Bachelorthesis im Kooperativen Bachelor Studiengang Informatik (KoSI) der Fachhochschule Darmstadt University

Mehr

Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten

Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten Referenzprozessmodell zur erfolgreichen Durchführung von CRM - Projekten Eine große Anzahl von CRM- Projekten scheitert oder erreicht die gesetzten Ziele nicht. Die Ursachen hierfür liegen oftmals in der

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

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

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

Mehr

SOA und Prozessmanagement: Herausforderung und aktuelle Arbeiten

SOA und Prozessmanagement: Herausforderung und aktuelle Arbeiten SOA Prozessmanagement: Herausforderung aktuelle Arbeiten Projekt-Kurzvorstellung beim Gründungstreffen des EMISA-Arbeitskreises Entwicklung agiler, prozessorientierter Informationssysteme Reiner Siebert,

Mehr

Process Engineering VU 1 Workflow Management Beate List

Process Engineering VU 1 Workflow Management Beate List Process Engineering VU 1 Workflow Management Beate List Institut für Softwaretechnik und Interaktive Systeme Technische Universität Wien Favoritenstr. 9-11 / 188, A-1040 Wien email: list@wit.tuwien.ac.at

Mehr

Konfigurationsmanagement für mobile Einheiten

Konfigurationsmanagement für mobile Einheiten Konfigurationsmanagement für mobile Einheiten Prof. Dr. Andreas Hense Wirtschaftsinformatik A. Hense Konfigurationsmanagement für mobile Einheiten 1 / 31 Agenda I 1 Einleitung Hintergrund Umfeld Konkrete

Mehr

Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant

<Insert Picture Here> Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant Oracle Business Process Analysis Suite Gert Schüßler Principal Sales Consultant 1 Geschäftsprozesse Zerlegung am Beispiel Kreditvergabe Antrag aufnehmen Antrag erfassen Schufa Kunden

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

Luca Piras SharePoint Specialist it-function software GmbH

Luca Piras SharePoint Specialist it-function software GmbH Luca Piras SharePoint Specialist it-function software GmbH Agenda Fazit & Ausblick BPM Vision Lösungsideen SharePoint & WfM Workflow Baukasten Die Business Process Management Vision Problemstellungen Komplexität

Mehr

IVY. White Paper. Microsoft Dynamics NAV Workflow Controller Powered by Xpert.ivy

IVY. White Paper. Microsoft Dynamics NAV Workflow Controller Powered by Xpert.ivy White Paper IVY Microsoft Dynamics NAV Workflow Controller Powered by Xpert.ivy Business Process Management (BPM) unterstützt den gesamten Lebenszyklus von Geschäftsprozessen. BPM-Lösungen liefern Technologie

Mehr

Vorlesung Wintersemester 2011/12. Konzepte und Anwendung von Workflowsystemen. Kapitel 5: Workflow Nets

Vorlesung Wintersemester 2011/12. Konzepte und Anwendung von Workflowsystemen. Kapitel 5: Workflow Nets Vorlesung Wintersemester 2011/12 Konzepte und Anwendung von Workflowsystemen Kapitel 5: Workflow Nets Lehrstuhl für Systeme der Informationsverwaltung, Prof. Böhm Institut für Programmstrukturen und Datenorganisation

Mehr

Agenda. Vorstellung Business Process Management und IT Umsetzungsbeispiel

Agenda. Vorstellung Business Process Management und IT Umsetzungsbeispiel Vom Prozess zur IT Agenda Vorstellung Business Process Management und IT Umsetzungsbeispiel Das Unternehmen Seit etwa 30 Jahren Anbieter von Business Communication Lösungen Planung und Realisierung von

Mehr

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

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

Mehr

Die Windows Workflow Foundation in Microsoft.NET 3.0

Die Windows Workflow Foundation in Microsoft.NET 3.0 Die Windows Workflow Foundation in Microsoft.NET 3.0 Klaus Rohe (klrohe@microsoft.com) Developer Platform & Strategy Group Microsoft Deutschland GmbH Agenda Was ist Windows Workflow Foundation? Microsoft

Mehr

Elektronische Zustellung WKO / AustriaPro. Status Arbeitspakete 17.09.2014 PL.O.T

Elektronische Zustellung WKO / AustriaPro. Status Arbeitspakete 17.09.2014 PL.O.T Elektronische Zustellung WKO / AustriaPro Status Arbeitspakete 17.09.2014 PL.O.T Agenda Übersicht und Inhalt PL.O.T Arbeitspakete Details zu den Arbeitspaketen AP 3 - Fachlich / Usecases AP 4 - Fachlich

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

A Platform for Complex Event Processing

A Platform for Complex Event Processing A Platform for Complex Event Processing Einführung Business Process Technology Prof. Dr. Mathias Weske Matthias Kunze Nico Herzberg Business Process Technology Seit 2001 Untersuchung realer Probleme des

Mehr

Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses

Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses Gunter Grieser, Simon Spielmann, Guido Schuh, Boris Kötting, Ralf Leonhard AGENDA Das Projekt Unser

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 378 Umsetzung ausgewählter Supply-Chain-Operations-Reference-Metriken durch das

Mehr

Inhaltsverzeichnis. Jakob Freund, Klaus Götzer. Vom Geschäftsprozess zum Workflow. Ein Leitfaden für die Praxis ISBN: 978-3-446-41482-2

Inhaltsverzeichnis. Jakob Freund, Klaus Götzer. Vom Geschäftsprozess zum Workflow. Ein Leitfaden für die Praxis ISBN: 978-3-446-41482-2 Inhaltsverzeichnis Jakob Freund, Klaus Götzer Vom Geschäftsprozess zum Workflow Ein Leitfaden für die Praxis ISBN: 978-3-446-41482-2 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41482-2

Mehr

BPM Lösungen nur etwas für Großkonzerne und Industrie?

BPM Lösungen nur etwas für Großkonzerne und Industrie? BPM Lösungen nur etwas für Großkonzerne und Industrie? BPM Vision 2005 / Messe Karlsruhe 08.06.2005 bis 09.06.2005 José Iglesias Geschäftsführer vitegris gmbh Agenda Begrüßung Business Process Management

Mehr

Bringen Sie Ihre Prozesse mit helic Process auf Touren. BITMARCK Kundentag 04. November 2014 Kathrin Rautert, Comline AG

Bringen Sie Ihre Prozesse mit helic Process auf Touren. BITMARCK Kundentag 04. November 2014 Kathrin Rautert, Comline AG Bringen Sie Ihre Prozesse mit helic Process auf Touren BITMARCK Kundentag 04. November 2014 Kathrin Rautert, Comline AG Bringen Sie Ihre Prozesse mit helic Process auf Touren Prozessmanagement Workflow-Management-Systeme

Mehr

Geschäftsbereich Mobile Services Was ist Android?

Geschäftsbereich Mobile Services Was ist Android? Geschäftsbereich Mobile Services Was ist Android? Hinter Hoben 149 53129 Bonn www.visionera.de Ansprechpartner: Arno Becker arno.becker@visionera.de +49 228 555 1111 +49 160 98965856 Einleitung Android

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Lehrstuhl für Datenbanken und Informationssysteme

Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Lehrstuhl für Datenbanken und Informationssysteme Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Lehrstuhl für Datenbanken und Informationssysteme Seminar im Sommersemester 2009 Business Process Management und Workflow-Technologie:

Mehr

Uptime Services AG Brauerstrasse 4 CH-8004 Zürich Tel. +41 44 560 76 00 Fax +41 44 560 76 01 www.uptime.ch. ARTS Workflow.

Uptime Services AG Brauerstrasse 4 CH-8004 Zürich Tel. +41 44 560 76 00 Fax +41 44 560 76 01 www.uptime.ch. ARTS Workflow. Uptime Services AG Brauerstrasse 4 CH-8004 Zürich Tel. +41 44 560 76 00 Fax +41 44 560 76 01 www.uptime.ch ARTS Workflow Funktionalitäten 22.05.2014 Sie möchten Informationen in Ihrem Betrieb anderen Stellen

Mehr

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Konzeption und prototypische Implementierung eines Knowledge-Servers mit Adaptern zur Integration

Mehr

SECTINO. Security for Inter-Organizational Workflows

SECTINO. Security for Inter-Organizational Workflows SECTINO Security for Inter-Organizational Workflows Framework zur Modellierung und Realsisierung sicherheitskritischer organisationsübergreifender Workflows Kooperation Research Group Quality Engineering

Mehr

Wachstumsförderung mit CRM

Wachstumsförderung mit CRM Wachstumsförderung mit CRM Computerwoche CRM Initiative Feb. 2007 Dr. Wolfgang Martin Analyst, Mitglied im CRM-Expertenrat und Research Advisor am Institut für Business Intelligence Wachstumsförderung

Mehr

Architektur und Implementierung von WfMS

Architektur und Implementierung von WfMS Vorlesung Wintersemester 2010/11 Workflow-Management-Systeme Kapitel 12: Architektur und Implementierung von WfMS Lehrstuhl für Systeme der Informationsverwaltung, Prof. Böhm Institut für Programmstrukturen

Mehr

Schriftenreihe des Fachbereiches Wirtschaft Sankt Augustin

Schriftenreihe des Fachbereiches Wirtschaft Sankt Augustin Schriftenreihe des Fachbereiches Wirtschaft Sankt Augustin Andreas Gadatsch, Thilo Knuppertz, Sven Schnägelberger Geschäftsprozessmanagement - Eine Umfrage zur aktuellen Situation in Deutschland Band 9

Mehr

BPM im Kontext von Unternehmensarchitekturen. Konstantin Gress

BPM im Kontext von Unternehmensarchitekturen. Konstantin Gress BPM im Kontext von Unternehmensarchitekturen Konstantin Gress Agenda 1 Worum geht s BPM, EA und SOA im Überblick 2 Link zwischen EA und BPM 3 Link zwischen SOA und BPM 4 Wie spielt das zusammen? 5 Q&A

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Aufgaben und Lösungshinweise zum Lehrbuch

Aufgaben und Lösungshinweise zum Lehrbuch Aufgaben und Lösungshinweise zum Lehrbuch UVK Verlagsgesellschaft mbh 204 Aufgaben zu Kapitel 4 Aufgabe : (Grundlagen von IT-Services) Nennen Sie vier Kriterien, die für die Gebrauchstauglichkeit eines

Mehr

itp Prozess Dokumentation > 100% BPMN

itp Prozess Dokumentation > 100% BPMN Business Edition erweitert BPMN um Dokumentations- und Simulationsfunktionen - positioniert seine Business Edition des Process Modelers als Prozessmodellierungs- und Dokumentationswerkzeug für Geschäftsanalysten.

Mehr

Software Innovations BPM M2M BRM

Software Innovations BPM M2M BRM Intelligente Geräte. Intelligente Prozesse. Intelligent vernetzt. So starten Sie erfolgreiche Projekte im Internet of Things and Services. Die IoTS Edition im Überblick Software Innovations BPM M2M BRM

Mehr

Microsoft Office SharePoint 2007

Microsoft Office SharePoint 2007 Inhalt 1 Erstellen von Workflows für Microsoft Office SharePoint 2007 15 June 2009 Sebastian Gerling Sebastian.gerling@spiritlink.de COPYRIGHT 2003 SPIRIT LINK GMBH. ALL RIGHTS RESERVED Inhalt 1 Dipl.

Mehr

Client/Server-Systeme

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

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor auf Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

App-Entwicklung mit Titanium

App-Entwicklung mit Titanium Masterstudienarbeit Betreuung Prof. Dr. M. von Schwerin 1 Gliederung 1.Motivation 2.Aufgabenstellung 3.Projektbeschreibung 4.Projektstatusbericht 5.Fazit und Ausblick 2 1.Motivation Verbreitung von Smartphones

Mehr

Diplomarbeit von Lars Gohlke. University of Applied Sciences Brandenburg

Diplomarbeit von Lars Gohlke. University of Applied Sciences Brandenburg Diplomarbeit von Lars Gohlke University of Applied Sciences Brandenburg Inhalt Motivation Skype SOA in 5 Schritten Anwendung + Demo Seite 2 Motivation Kommunikation einfach - schnell preiswert - verläßlich

Mehr

Whitepaper Eingangsrechnungsbearbeitung mit Workflowunterstützung

Whitepaper Eingangsrechnungsbearbeitung mit Workflowunterstützung Whitepaper Eingangsrechnungsbearbeitung mit Workflowunterstützung Inhalt 1. Workflow-Management-Systeme im Überblick 2 1.1. SAP Business Workflow 3 2. Eingangsrechnungsbearbeitung mit Workflowunterstützung

Mehr

Testfragen PRINCE2 Foundation

Testfragen PRINCE2 Foundation Testfragen PRINCE2 Foundation Multiple Choice Prüfungsdauer: 20 Minuten Hinweise zur Prüfung 1. Sie sollten versuchen, alle 25 Fragen zu beantworten. 2. Zur Beantwortung der Fragen stehen Ihnen 20 Minuten

Mehr

PFlow-Editor Entwicklung und Implementierung eines Modellierungswerkzeugs für ein Peer-to-Peer Production Workflow Management System

PFlow-Editor Entwicklung und Implementierung eines Modellierungswerkzeugs für ein Peer-to-Peer Production Workflow Management System PFlow-Editor Entwicklung und Implementierung eines Modellierungswerkzeugs für ein Peer-to-Peer Production Workflow Management System Fortgeschrittenenpraktikum bei Prof. Dr. Martin Wirsing vorgelegt von:

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Fachliche Prozessmodellierung BPMN 2.0. HU Berlin, 27. Mai 2009

Fachliche Prozessmodellierung BPMN 2.0. HU Berlin, 27. Mai 2009 Fachliche Prozessmodellierung BPMN 2.0 HU Berlin, 27. Mai 2009 Die zwei Seiten des BPM Organisationslehre Ablauforganisation bis 1990 Business Process Reengineering - BPR (Orga-) Geschäftsprozess- Management

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP. Ralf Ackermann Daimler AG, ITM MBC Powertrain

Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP. Ralf Ackermann Daimler AG, ITM MBC Powertrain Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP Ralf Ackermann Daimler AG, ITM MBC Powertrain Agenda Ausgangslage EAM Tool-Landschaft bei Daimler planningit

Mehr

smarter mobile Einbindung von mobilen Endgeräten in Geschäftsprozesse Wo? -Kongress GeoMobility - 7. und 8. Dezember 2011

smarter mobile Einbindung von mobilen Endgeräten in Geschäftsprozesse Wo? -Kongress GeoMobility - 7. und 8. Dezember 2011 smarter mobile Einbindung von mobilen Endgeräten in Geschäftsprozesse Wo? -Kongress GeoMobility - 7. und 8. Dezember 2011 1 Agenda 1 Wer wir sind? 2 Grundlagen des Geschäftsprozessmanagement 3 Einbindung

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Anforderungen an ein Workflow-Management-System im Gesundheitswesen am Beispiel des Gesundheitsnetzes prosenior. prosenior.

Anforderungen an ein Workflow-Management-System im Gesundheitswesen am Beispiel des Gesundheitsnetzes prosenior. prosenior. Anforderungen an ein Workflow-Management-System im Gesundheitswesen am Beispiel des Gesundheitsnetzes M. Sc. Katja Gippert Versorgungsnetz der Knappschaft Bahn-See Behandlung anhand von IV-Pfaden Programm

Mehr

Wirtschaftlichkeitsanalyse von Cloud Computing aus der Sicht internationaler Unternehmen. Masterarbeit

Wirtschaftlichkeitsanalyse von Cloud Computing aus der Sicht internationaler Unternehmen. Masterarbeit Wirtschaftlichkeitsanalyse von Cloud Computing aus der Sicht internationaler Unternehmen Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SO A Fraunhofer-Institut für Softwareund Systemtechnik ISST Dr. Ulrich Springer Dr. Bernhard Holtkamp Dortmund, 20.01.2009

Mehr

7. Analyse-Phase: Datenmodellierung Software Engineering

7. Analyse-Phase: Datenmodellierung Software Engineering 7. Analyse-Phase: Datenmodellierung Software Engineering Hochschule Darmstadt Haardtring 100 D-64295 Darmstadt Prof. Dr. Bernhard Humm Hochschule Darmstadt, 20. November 2006 Einordnung in den Kontext

Mehr

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/)

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Enterprise Continuum Wiederverwendung von Unternehmensarchitekturen Modul

Mehr

Geschäftsprozessmanagement. Prof. Dr. Knut Hinkelmann

Geschäftsprozessmanagement. Prof. Dr. Knut Hinkelmann Geschäftsprozessmanagement Geschäftsprozesse im Kontext Alter, Steven: Information Systems The Foundation of E-Business, 4. Auflage, Prentice Hall, New Jersey, 2002 2 Drei Gesichtspunkte auf das Unternehmen

Mehr

ARISTAFLOW. Workflow-Funktionen in seiner Software kommen von AristaFlow. AristaFlow BPM Plattform

ARISTAFLOW. Workflow-Funktionen in seiner Software kommen von AristaFlow. AristaFlow BPM Plattform [ ARISTAFLOW [ Die Workflow-Funktionen in seiner Software kommen von AristaFlow. Das leicht zu integrierende Framework zur flexiblen Workflow-Steuerung für jede Anwendung Würden Sie ein Datenbank-Management-System

Mehr

Adaptive Case Management: Modellierung nicht-strukturierter Prozesse und ihre Umsetzung in SharePoint

Adaptive Case Management: Modellierung nicht-strukturierter Prozesse und ihre Umsetzung in SharePoint Adaptive Case Management: Modellierung nicht-strukturierter Prozesse und ihre Umsetzung in SharePoint Knut Hinkelmann Fachhochschule Nordwestschweiz FHNW knut.hinkelmann@fhnw.ch 1 Geschäftsprozesse Definiertes

Mehr