Mobile-Business richtig gemacht

Geschäftsprozesse mobil – mobile Lösungen in bestehende Systeme integrieren
Kommentare

Mobile-Business steht für den Einsatz mobilgestützter Lösungen, mit denen Unternehmen und ihre Mitarbeiter flexibler und effizienter arbeiten können. Für eine gezielte Anbindung in bestehende Systeme sind entsprechende Maßnahmen sowohl auf der technischen als auch auf der Prozessebene notwendig. Welche das sind und welche Herausforderungen dabei auftreten können, beschreibt dieser Artikel.

Die fortschreitende Digitalisierung und die Vernetzung von Systemen wirken sich auf das geschäftliche Umfeld aus. Die Wahrnehmung und der Einsatz von IT in Unternehmen hat sich über die Jahre bedeutend verändert. Wo einst nur informationstechnische Mittel zur Bewältigung einzelner Aufgaben oder Aufgabenbereiche eingesetzt wurden, bilden heute komplexe ERP-Systeme die gesamte Prozesskette elektronisch ab. Mit der enormen Verbreitung von Smartphones und Tablets können Anwender – unabhängig von Zeit und Ort – auf Daten und Dienste zugreifen. Die Verknüpfung von stationärer und mobiler IT eröffnet Unternehmen so neue Möglichkeiten, ihre Geschäftsprozesse zu vereinfachen oder Einsatzfelder auszuweiten. Genauer ist damit die Integration mobiler Endgeräte und Geschäftslösungen (engl.: Mobile Business Solutions, MBS) in bestehende Prozesse und Systeme gemeint. Sie erhöht die Arbeitsproduktivität und bietet „business responsiveness“, also eine fast grenzenlose Handlungs- und Reaktionsfähigkeit eines Unternehmens.

Was passiert jedoch, wenn bestehende Prozesse nicht für die Ausführung in einem mobilen Kontext ausgelegt sind? Gründe dafür sind zum Beispiel externe Einflüsse wie die zur Verfügung stehende Netzkonnektivität und Bandbreite des Mobilfunknetzes, kurz die vorhandene Infrastruktur, oder starre Prozesse, die zum Beispiel nicht auf ein mögliches Online-/Offlineszenario ausgelegt sind. Dies kann bei den üblichen Arbeitsabläufen der Außendienstmitarbeiter der Fall sein. Aus unternehmerischer Sicht bedeutet das ein Umdenken auf der Prozessebene (engl.: Business Process Reengineering, BPR) mit Fokus auf mobile Technologien. Man spricht dann vom Mobile Business Process Reengineering, kurz M-BPR, was die Analyse und das Design von mobilen Geschäftsprozessen (engl.: Mobile Business Processes, MBP), die in bestehende Prozessketten zu integrieren sind, umfasst. Sie sind als „Geschäftsprozesse, die aufgrund mobiler Anteile nicht (vollständig) durch stationäre IT unterstützt werden können“ definiert. Das Resultat der Prozessbetrachtungen in Hinblick auf ihre Mobilität bildet die Grundlage für die spätere technische Anbindung. An dieser Stelle sind Herausforderungen wie die Gewährleistung der Datenkonsistenz auf allen beteiligten Geräten und die Sicherheit der Daten und Kommunikation zu meistern. Geeignete Techniken zur Datenreplikation innerhalb eines heterogenen Umfelds sowie Verfahren zur Erkennung und zum Lösen von Konflikten werden im weiteren Verlauf genauer beschrieben. Übrigens: Wenn Sie sich eingehender mit aktuellen Entwicklungen, Technologien und Strategien im Mobile Business befassen möchten, legen wir Ihnen den Mobile-Business-Track auf der MobileTech Conference ans Herz.

Der Wille ist da

Die Firma Multimedia Solutions veröffentlichte in Kooperation mit der St. Gallen Universität eine Studie zum Einsatz von MBS in deutschsprachigen Unternehmen und Konzernen. Sie ergab, dass 82 Prozent der Befragten in mobilen Anwendungen einen effizienzsteigernden Faktor für den Arbeitsalltag sehen. Ein weiteres Ergebnis der Studie ist die Erkenntnis, dass Unternehmen das Potenzial mobiler Ansätze erkennen, Mobile-Business allerdings durch die fehlende Verantwortlichkeit für das Thema Mobile noch nicht strategisch verankert ist. Oft gibt es beispielsweise keinen „Chief Mobile Officer“, der für eine gezielte Integration in die Organisation zuständig ist; zudem fehle der klare Fokus auf das M-BPR, das oft unerwartetes Potenzial zur Prozessoptimierung oder zur Restrukturierung zum Vorschein bringt.

Auch wenn MBS heute bei vielen Firmen noch nicht vollständig integriert sind, werden für die alltäglichen Aufgaben bereits fast überall mobile Endgeräte eingesetzt. So werden beispielsweise mit Smartphones und Tablets E-Mails beantwortet oder Termine und Ressourcen verwaltet. Dass dabei die gesamte Prozesskette ganzheitlich betrachtet wird, ist jedoch selten der Fall. Es fühlt sich niemand verantwortlich. Mobile-Business allein ist zudem auch kein Erfolgsgarant. Um die Wirtschaftlichkeit sicherzustellen, sollten Unternehmen die möglichen Kosten, Erfolgsfaktoren sowie Barrieren und Scheiterungsgründe genau bewerten.

Ein Auszug aus der Praxis

Als Grundlage der weiteren Ausführungen sollen Techniker im Außendienst dienen, die auf klassische Art und Weise mit Stift und Papier beim Kunden agieren, während andere Prozesse innerhalb der Prozesskette elektronisch mithilfe eines ERP-Systems ablaufen. Dieses Vorgehen ist heutzutage trotz der voranschreitenden Digitalisierung nicht ungewöhnlich. Techniker befinden sich außerhalb der stationären IT und ihres Kontroll- und Steuerungsbereichs und bearbeiten unterschiedliche Kundenaufträge an unterschiedlichen Orten und Zeiten. Abbildung 1 beschreibt eine vereinfachte Prozesskette.

Abb. 1: Prozesskette ohne MBP

Abb. 1: Prozesskette ohne MBP

Bei einer detaillierten Betrachtung lassen sich einige Schwachstellen feststellen. Die papierbasierte Bearbeitung ist generell fehleranfälliger. Oft ist es so, dass Techniker ihre Arbeitsberichte über die Woche sammeln und geschlossen zur weiteren Bearbeitung im Büro einreichen, um Fahrtwege zu minimieren. Ist die Handschrift schwer lesbar, das Dokument eventuell mit Kaffeerändern übersäht oder hat der Techniker Zeiten doppelt gepflegt, können die Daten bei der Übernahme ins ERP-System nicht eindeutig identifiziert werden. Die Innendienstmitarbeiter müssen Rücksprache mit dem Techniker halten, um die Daten anschließend mühselig von Hand ins System zu übertragen. Ist der Techniker nicht greifbar, verzögert sich die Datenpflege zusätzlich. Die Folge: Die Rechnung an den Kunden kann erst zu einem späteren Zeitpunkt fakturiert werden. Mobile Endgeräte und eine entsprechende MBS optimieren diesen Prozess spürbar. In dem angeführten Beispiel wird durch den erhöhten Anteil an Automatismen die Transparenz gegenüber den Kunden erhöht. Beispielsweise können Rechnungen automatisiert erzeugt und verschickt werden, sobald Arbeitsberichte unterschrieben oder Aufträge abgeschlossen sind. Genauso steigt die Aussagekraft gegenüber dem Kunden, da die Arbeitsberichte durch den frühzeitigen Ausschluss von Fehlern an Qualität gewinnen.

Hier kommt das M-BPR zum Tragen. Gilt der bestehende Prozess nach umfassender Analyse nicht als mobil, ist er dementsprechend anzupassen oder neuzugestalten. Eingesetzt werden die klassischen BPR-Werkzeuge mit einem besonderen Fokus auf mobile Technologien. Dabei sind die Möglichkeiten und Grenzen der genutzten Technologie zu berücksichtigen. Das Ergebnis des M-BPR ist der MBP, der sich, wie Abbildung 2 darstellt, in die bestehende Prozesskette integriert.

Abb. 2: Prozesskette mit MBP

Abb. 2: Prozesskette mit MBP

Als Beispiel erhält jeder Techniker anstelle von Stift und Papier ein Tablet. Aus Client-Server-Sicht ist der Techniker der Client, der mit dem Server kommuniziert. Der Server ist Teil der stationären IT und besitzt z. B. die Datenbasis des ERP-Systems, also die Kunden- und Auftragsdaten. Es lässt sich die technische Anforderung ableiten, dass mehreren Clients die gleichzeitige Arbeit auf derselben Datenbasis ermöglicht werden soll, die darum auf allen Geräten konsistent sein muss. Ein entscheidender Faktor ist dabei die Infrastruktur, denn abhängig vom Mobilfunknetz sind die mobilen Geräte in ihrer Bandbreite und Erreichbarkeit eingeschränkt. Um die Datenkonsistenz gemäß der Anforderung zu gewährleisten, benötigt es eine geeignete Synchronisationsstrategie und ein geeignetes Konfliktmanagement.

Datensynchronisation

Die Replikation von Daten ist sicherlich gefragter denn je. Die zunehmende Vernetzung von allem und jedem, auch „Internet der Dinge“ genannt, bringt eine Vielzahl an neuen Kommunikationskanälen und -medien zum Vorschein. Anwender agieren heutzutage mobil, d. h. sie wollen einmal erfasste Daten überall und jederzeit abrufen können – egal ob vom Laptop, Smartphone oder Tablet aus. Diese Verhaltens- und Denkweisen werden von Unternehmen übernommen, um Geschäftsprozesse und -daten über Grenzen hinweg verfügbar zu machen. Bei der Anbindung mobiler Endgeräte und Lösungen an die eigenen Systeme stellt die Interoperabilität des Synchronisierungsprotokolls eine wichtige Anforderung dar. Mit ihrer Hilfe lassen sich die sensiblen Daten auf den unterschiedlichen Plattformen konsistent halten. Es existieren bereits Marktlösungen wie das Microsoft Sync Framework oder das Couchbase Sync Gateway, die die Datenreplikation zwischen den Datenbanken beherrschen. Oft ist es jedoch so, dass sowohl auf Client- als auch auf Serverseite die dazugehörige Software benötigt wird. So funktioniert das Couchbase Sync Gateway nur zwischen zwei Couchbase-Instanzen, beispielsweise mit einem Couchbase-Server und einer Couchbase-Lite-Datenbank für eingebettete Systeme.

Liegt bereits eine feste Firmeninfrastruktur vor, sind möglicherweise unabhängige Implementierungen der Schlüssel zum Erfolg. Wer in diesem Themenbereich recherchiert, erhält viele wissenschaftliche Ausarbeitungen, die die unterschiedlichsten Techniken verwenden. Im Folgenden sollen drei offene Synchronisierungsprotokolle vorgestellt werden, die als Grundlage für die eigene Umsetzung dienen können. Alle Verfahren stützen sich auf dem Prinzip des Optimistic Lockings. Im Gegensatz zum Pessimistic Locking ermöglicht dieses Prinzip einen Parallelbetrieb, damit die betroffenen Daten bei der Benutzung nicht blockiert werden.

Protokoll 1: Hashwertbasierter Synchronisationsalgorithmus (SAMD)

Der Algorithmus „Synchronization Algorithm based on Message Digest“ (SAMD) basiert auf dem Prinzip der Hashwert-Berechnung [1]. Hashwerte werden mittels unidirektionaler Funktionen gebildet, bei der eine beliebig lange Folge zu einer Folge fester Länge umgewandelt wird (siehe Kasten „Hashwertbildung“).

Hashwertbildung

h = H(M)
  • h entspricht dem erzeugten Hashwert fester Länge
  • H entspricht der Hashfunktion
  • M entspricht der Ausgangsfolge beliebiger Länge (Message)

Um die Interoperabilität zu gewährleisten, sollte die Implementierung die folgenden vier Leitfäden einhalten:

  • Keine Benutzung von datenbankanbieterspezifischen Funktionen und Metadaten
  • Ausschließliche Benutzung von ISO-standardisierten SQL-Statements
  • Ausschluss serverseitiger Manipulation des Datenbankschemas
  • Ausschluss von anwendungsspezifischen Restriktionen, z. B. dass eine bestimmte Library verwendet werden muss, um die Synchronisation durchzuführen

Abbildung 3 stellt den Aufbau der Datenbanken eines Clients und des Servers mit einer Datentabelle dar. Für jede weitere Datentabelle wächst die Struktur vertikal.

Abb. 3: SAMD Tabellenstruktur

Abb. 3: SAMD Tabellenstruktur

Jeder Client besitzt lediglich die Businessdaten innerhalb seiner Mobile Client Data Table (MCDT). Der Server verwaltet die Businessdaten in seiner eigenen Database Server Data Table (DSDT). Jedem registriertem Client wird eine Mobile-Device-ID zugeordnet, mit der er eindeutig identifizierbar ist. Zudem erstellt der Server für jeden registrierten Nutzer eine Mobile Client Message Digest Table (MCMDT), die die Hashwerte zu den Client-Business-Daten verwaltet. Um später die Hashwerte vergleichen zu können, besitzt der Server für seine DSDT eine Database Server Message Digest Table (DSDMT), die die Hashwerte der DSDT speichert. Die DSDMT verknüpft alle Hasheinträge mit jedem Client, um festzustellen, welcher Client eine Synchronisation benötigt.

Die eigentliche Synchronisation ist in drei Teilsynchronisationen unterteilt. Synchronisation 1 und 2 entsprechen demselben Vorgehen und dienen zur Aktualisierung der Hashwerttabellen. Dazu werden diese mit den dazugehörigen Datentabellen durch Full Outer Joins bzw. Full Joins verknüpft. Stimmen die Hashwerte nicht mehr überein, wird der Hashwert aktualisiert und das Flag F auf 1 gesetzt. Damit weiß der Algorithmus, dass die Datenzeile eine Aktualisierung benötigt. Für den Join der Tabellen DSDMT und DSDT werden nur die Datenzeilen aus der DSDMT entnommen, die der mitgeschickten Mobile-Device-ID entsprechen. Da die Tabellen MCDT und MCMDT physikalisch getrennt sind, kann auf Serverseite eine temporäre MCDT erzeugt werden, um den Join durchzuführen. Ein Join der Tabellen MCMDT und DCMDT mit der Bedingung, dass das Flag F in der MCMDT oder in der DCMDT auf 1 gesetzt ist, dient als Grundlage für die Synchronisation 3. Sie findet zwischen den Datentabellen statt und löst dabei mögliche Konflikte. Hier lässt sich ein geeignetes Konfliktmanagement integrieren. Abbildung 4 zeigt den Ablauf.

Abb. 4: SAMD-Ablauf

Abb. 4: SAMD-Ablauf

Für den Server bedeutet diese vollständige Verlagerung der Synchronisation einen erhöhten Speicherbedarf und eine längere Berechnungszeit. Der Algorithmus lässt sich jedoch anpassen, indem die Client-Hashtabellen mit in die Clientdatenbank übernommen werden. Diese Variante verwendet beispielsweise die Open-Source-Implementierung doubleganger.

Protokoll 2: Zeitstempelmatrizen (MRDMS)

Die „Mobile Replication Database Management Synchronization“ (MRDMS) [2] arbeitet auf Basis von Unix-Zeitstempeln. Jede Tabelle im Datenbankschema besitzt eine korrespondierende Tabelle mit dem Suffix „_t“ zur Verwaltung der Zeitstempel. So würde die Tabelle „Personal“ die dazugehörige Tabelle „Personal_t“ besitzen, in der jeder Eintrag den Bearbeitungszeitpunkt beinhaltet. Die Zeitstempeltabelle ist um eine Spalte erweitert, die die Art der Operation anzeigt. Dabei steht „1“ für das Einfügen, „-1“ für das Löschen und „0“ für das Aktualisieren von Datenzeilen. Der Client verwaltet eine Variable last_sync_timestamp vom Typ long, die angibt, wann der Client sich das letzte Mal mit dem Server ausgetauscht hat. Sie besitzt initial den Wert „0“. Nach einer erfolgreichen Synchronisierung erhält sie einen neuen Zeitstempel vom Server. Startet der Client einen Synchronisationsvorgang, schickt er dem Server eine so genannte Zeitstempelmatrix, die die lokalen Veränderungen angibt. Zusätzlich sendet der Client die Variable last_sync_timestamp. Listing 1 beschreibt den Aufbau des Austauschformats.

Listing 1: Clientnachricht

last_sync_timestamp:
[
  [
    ["3",t1,t2,0,0]
    ["5",t2,0,t2,0]
  ],
  null,
  [
    ["4",t1,0,0,t1,0,0]
  ]
]

Jeder Eintrag in dem Array entspricht einer Tabelle. Daran lässt sich ablesen, dass die Tabellen 1 und 3 modifiziert wurden. Wenn keine Änderungen stattgefunden haben, ist an der entsprechenden Stelle der Nullwert einzutragen, wie es bei Tabelle 2 zu sehen ist. Die Zeilen 3 und 5 der Tabelle 1 sowie die Zeile 4 der Tabelle 3 sind bearbeitet worden. Die Zeitstempelwerte t entsprechen dem Bearbeitungszeitpunkt der angegebenen Spalte. Dabei signalisiert „0“ wieder keine Veränderung. Der letzte Spaltenwert gibt die Operation an. Möchte der Client ein reines Datenbankupdate erhalten, muss lediglich der last_sync_timestamp an den Server geschickt werden. Der Server vergleicht den erhaltenen Zeitstempel mit seinen Zeitstempeltabellen. Er generiert eine strukturgleiche Matrix, die nach dem folgenden Regeln aufgebaut ist:

  • Benötigt eine Zelle kein Update, d. h. es gab keine Aktualisierung auf Client- oder Serverseite, ersetzt der Server den Ursprungswert von „0“ mit dem Zeichen „@“
  • Besitzt der Server einen neueren Zeitstempel als der Client, ersetzt er den Zeitstempel durch den Wert, den der Client in seine Datenbank übernehmen muss
  • Ist der Clientzeitstempel aktueller, ersetzt der Server den Zeitstempel durch das Zeichen „#“. Dies entspricht der Aufforderung, den lokalen Wert an den Server zu übermitteln

Der aktuelle Serverzeitstempel, der der neue last_sync_timestamp des Clients wird, ist jetzt vorangestellt. Die Antwort des Servers ist in Listing 2 dargestellt.

current_time_at_server:
[
  [
    ["3","#","klm","@","@"]
    ["5","ghi","@","#","@"]
  ],
  null,
  [
    ["4","#","@","@","#","@","@"]
  ]
]

Anschließend aktualisiert der Client seine Datenbank sowie den last_sync_timestamp und schickt eine change_matrix mit den angeforderten Werten zum Server. Dieser aktualisiert ebenfalls seine Datenbank, sodass die Synchronisierung abgeschlossen ist.

Um Inkonsistenzen beim Server zu vermeiden, die bei dem clientseitigen Erstellen von Datenzeilen entstehen können, existiert eine Ausnahmebehandlung bei Insert-Fällen. Der Algorithmus sieht hier vor, dass der Client einen neuen Primärschlüssel für die Datenzeile beantragt. Er wird auf dem Server ermittelt und direkt in die Datenbank eingepflegt. Sobald der Client den Primärschlüssel erhält, entsteht eine geregelte Synchronisierungssituation, die nach dem oben beschriebenen Verfahren lösbar ist. Befindet sich das Mobile Device im Offlinebetrieb, kann dies durch den Einsatz von temporären Primärschlüsseln, z. B. durch negative Primärschlüssel dargestellt, gelöst werden. Der Server muss ihn später als solchen erkennen und kann auf dieselbe Funktionsweise das Problem beheben. Hierfür beschreibt der Algorithmus kein festes Vorgehen.

Durch den Einsatz der Matrizen entsteht nur ein geringer Synchronisierungsoverhead, wie der minimale Datentransfer und eine niedrige Berechnungszeit zeigen. Daher eignet sich der Algorithmus z. B. für Lösungen, die in schlecht netzangebundenen Arealen eingesetzt werden. Auch die Umsetzung kann über standardisierte Protokolle stattfinden, da sich beispielsweise der Datenaustausch einfach über HTTP in Kombination mit JSON realisieren lässt. Mit MRDMS ist ein Parallelzugriff ohne weitere Vorkehrungen beim eigentlichen Arbeitsvorgang möglich. Aus diesem Grund könnte man dieses Synchronisierungsprotokoll leicht als optimistische Variante einstufen.

Doch es gibt auch eine Kehrseite der Medaille. So sollte das Nachrichtenprotokoll mindestens während der Synchronisierung den Zugriff blocken, um Konflikte zu vermeiden. Ein einfaches Konfliktmanagement ist im Verfahren mit inbegriffen, da schlichtweg das aktuellste Datum gewinnt. Das kann sich abhängig von der Komplexität der Anforderungen positiv, aber auch negativ auswirken. Ein weiteres Problem bei der Verwendung von Zeitstempeln ergibt sich durch die benötigte Synchronisation der Zeiteinstellung auf dem Client und Server. Eine einheitliche Vergleichsbasis ist Voraussetzung für das Arbeiten mit korrekten Zeitpunkten, was zusätzlichen Aufwand bedeutet.

Protokoll 3: Versionsvektoren

Die Synchronisation mittels Versionsvektoren (engl.: logs) ähnelt in ihrem Ablauf der Zeitstempelmatrix. Sie basiert auf einem logbasierten Nachrichtenprinzip, das in [3] beschrieben ist. Es existieren so genannte Aktionen (engl.: Actions), die Veränderungen an Daten festhalten. Jede Aktion beinhaltet eine Operation sowie die dazugehörigen Daten. Im Wesentlichen gibt es wieder drei Operationen: das Hinzufügen, das Löschen und das Aktualisieren. Um die einzelnen Änderungsschritte und somit auch die Synchronisation nachzuvollziehen, sind jedem Versionsvektor mehrere Aktionen zugeordnet. Abbildung 5 stellt den Zusammenhang von Aktionen und Versionsvektoren sowie die Datenstruktur dar.

Abb. 5: Struktur der Versionsvektoren

Abb. 5: Struktur der Versionsvektoren

Jeder Client besitzt eine lokale Versionsnummer und ID. Der Server besitzt neben seiner eigenen auch die Versionsnummern der Clients, die sie nach ihrer letzten erfolgreichen Synchronisation erhalten haben. Jeder Client verwaltet seine Versionstabellen, die beschreiben, welche Veränderungen zur aktuellen Version geführt haben. Auch der Server besitzt diese Tabellen, um Änderungen für die einzelnen Clients festzuhalten. Sie sind wie beim hashwertbasierten Verfahren mit den Client-IDs verknüpft. Bei einer Synchronisationsanfrage schickt der Client seine ID und Versionsnummer zum Server, der anschließend in seiner Versionstabelle die Werte vergleicht. Genauer prüft er, ob der mitgeschickte Wert vom Client größer oder gleich dem hinterlegten Wert für den Client ist und ob dieser kleiner, gleich oder größer der Versionsnummer des Servers ist. Daraus ergibt sich die in Tabelle 1 abgebildete Entscheidungsmatrix in Abhängigkeit zur mitgeschickten Versionsnummer.

Tabelle 1: Entscheidungsmatrix

Tabelle 1: Entscheidungsmatrix

Die getätigten Änderungen sind für die anderen registrierten Clients zu hinterlegen, um festzulegen, welche Schritte die anderen Clients nachholen müssen. Beidseitige Änderungen sorgen dafür, dass eine neue Version für den Client und Server angelegt wird. Nach erfolgreicher Synchronisation kann der Client seine lokalen und der Server seine für den Client hinterlegten Versionsvektoren löschen. Damit lässt sich die Menge der zu speichernden Synchronisationsdaten reduzieren. Der Algorithmus vermeidet durch den Einsatz der Versionsnummer den unnötigen Austausch von Daten und reduziert damit auch den Netzverkehr. Ein eigenes Konfliktmanagement lässt sich ebenfalls integrieren, um Konflikte individuell zu lösen.

Bewertung der Protokolle

Die vorgestellten Protokolle sollten lediglich einen Ausblick geben, welche unterschiedlichen Synchronisationsansätze existieren. Jeder Ansatz kann als Basis genutzt werden, die anhand eigener Anforderungen erweitert werden kann. Tabelle 2 fasst noch einmal alle Protokolle in Bezug auf die Kriterien der Berechnungszeit, der Netzbelastung, der Datenmenge und des Auflösens von Konflikten zusammen.

Tabelle 2: Alle Protokolle im Vergleich

Tabelle 2: Alle Protokolle im Vergleich

Konfliktmanagement

Treten während einer Synchronisation Konflikte auf, müssen diese behandelt werden. Es existieren unterschiedliche Ansätze, wie Konflikte aufzulösen sind. Einige Standardverfahren sind:

  • Client siegt: Werte vom Client werden übernommen
  • Server siegt: Werte vom Server werden übernommen
  • Siegermaske: Eine Maske wird erstellt, die für jede Spalte angibt, von welcher Seite die Daten übernommen werden
  • Letzte Änderung: Die zuletzt geänderten Werte werden übernommen

Reichen die Standardverfahren nicht aus, lassen sich zusätzliche Strategien – etwa durch den Entwickler festgelegte Strategien oder das Lösen von Konflikten über die Benutzeroberfläche durch den Nutzer – anwenden.

Im Folgenden soll ein Algorithmus für das Konfliktmanagement vorgestellt werden, der Konflikte erkennt und versucht, sie automatisiert zu lösen. Dabei finden die oben aufgelisteten Strategien Anwendung. Das Verfahren nach [4] definiert so genannte Unique Constraints (UCs). Sie versichern, dass Spalten innerhalb der Datentabellen keine doppelten Werte besitzen. Im Gegensatz zu Primärschlüsseln kann eine Tabelle mehrere UCs halten, die einen oder mehrere Nullwerte haben können. UCs verwenden Indizes, um eindeutig zu bleiben. Wenn die Clients online arbeiten, lassen sich die Konflikte direkt auflösen. Arbeiten sie jedoch offline, können Unique Constraint Violations (UCVs) auftreten, da Clients veraltete oder nicht vollständige Daten besitzen. Diese gilt es zu erkennen und aufzulösen. Hierfür sind UCVs in zwei Kategorien unterteilt:

  • Merging Type: Beinhaltet alle offline erstellten oder veränderten Datensätze, die im Konflikt zum Server stehen und physisch identisch sind
  • Correcting Type: Beinhaltet alle offline erstellten oder veränderten Datensätze, die physisch unterschiedlich sind, jedoch dieselben Werte in eindeutigen Spalten aufweisen

Das generelle Vorgehen bei Merging Types ist, beide Datensätze in einen neuen zusammenzufügen, während bei Correcting Types beide Datensätze parallel existieren. Dazu muss einer der beiden angepasst werden. Das Auflösen von UCVs vom Typ Merging geschieht in vier Stufen. In der ersten Stufe sind die Datensätze gemäß der oben beschriebenen Strategien zusammenzuführen. Sie können auch im zweiten und dritten Schritt angewendet werden, wenn bei dem Umkopieren und bei dem Korrigieren der referenzierten Datensätze aus anderen Tabellen Konflikte entstehen. Der letzte Schritt umfasst die Speicherung der neuen Daten auf Clientseite. Abbildung 6 beschreibt das Vorgehen, UCs sind dabei kenntlich gemacht.

 

Abb. 6: Behandlung von Merging Types

Abb. 6: Behandlung von Merging Types

 

Abb. 7: Behandeln von Corrrecting Types

Abb. 7: Behandeln von Corrrecting Types

Ist ein UCV vom Merging und Correcting Type, ist ein manuelles Eingreifen durch den Nutzer notwendig; alle anderen Fälle lassen sich automatisiert abdecken. Die Herausforderung steckt in der Identifikation der UCs und ihrer UCVs. Sind sie definiert, lassen sich individuelle Lösungsstrategien innerhalb eines Strategienkatalogs festlegen und implementieren.

Zusammenfassung

Mobile-Business bietet neue Möglichkeiten, Geschäftsprozesse zu vereinfachen und Geschäftsfelder auszuweiten. Für den Einsatz mobilgestützter Lösungen müssen die Geschäftsprozesse mobil gemacht werden, was mithilfe des Mobile Business Process Reengineerings (M-BPR) möglich ist. Im Zuge dessen sollte stets auch der Blick auf die verwendeten Techniken gelenkt werden. Die Betrachtung der Prozessebene bildet die Grundlage für die Bewältigung der technischen Herausforderungen. Mobile-Clients befinden sich im Mobilfunknetz und können deshalb in ihrer Bandbreite und Erreichbarkeit eingeschränkt sein. Daher sollten Prozesse mögliche Online-/Offlineszenarien berücksichtigen. Offene Synchronisierungsprotokolle vereinfachen die Anbindung unterschiedlicher Plattformen an bestehende Systeme und ermöglichen eine konsistente Datenbasis innerhalb eines heterogenen Umfelds. Dazu zählen u. a. SAMD, Zeitstempelmatrizen sowie die Versionsvektoren. Treten Konflikte während der Synchronisierung auf, hilft ein Konfliktmanagement wie der UCV-Algorithmus, sieaufzulösen. Unternehmen müssen anhand von Kennzahlensystemen bewerten, ob sich die Einführung von mobilen Endgeräten und MBS in Bezug auf die Wirtschaftlichkeit lohnt.

Mobile Technology

Mobile TechnologyDieser Artikel ist im Mobile Technology erschienen. Mobile Technology ist der Wegbegleiter für alle, die sich professionell mit der Entwicklung für mobile Devices und den Möglichkeiten, die der Markt des Mobile Business und Marketing bereithält, beschäftigen.

Natürlich können Sie das Mobile Technology über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Mobile Technology ferner im Abonnement oder als Einzelheft erhältlich.

Links & Literatur

[1] Choi, Mi-Young; Cho, Eun-Ae; Ha-Park, Dae; Moon, Chang-Joo; Baik, Doo-Kwon: „A Database Synchronization Algorithm for Mobile Devices“, IEEE Transactions on Consumer Electronics, Vol. 56, No. 2, p. 392 – 298, May 2010

[2] Sethia, Divyashikha; Metha, Swati; Chowdhary, Anant; Bhatt, Kartikeya; Bhatnagar, Siddharth: „MRDMS – Mobile Replicated Database Managament Synchronization“, IEEE International Conference on Signal Processing and Integrated Networks (SPIN) 2014

[3] Feng, JiuLing; Qiao, XiuQuan; Li, Yong: „The Research of Synchronization and Consistency of Data in Mobile Environment“, IEEE International Conference on Cloud Computing and Intelligence Systems (CCIS) 2012
[4] Natschläger, Christine; Kopetzky, Theodorich: „Classifying and Resolving Unique Constraint Violations during Synchronization Processes“, Logistics and Industrial Informatics, 2009, LINDI 2009, 2nd International

Aufmacherbild: Woman Using Her Mobile Phone von Shutterstock / Urheberrecht: LDprod

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -