Datenaustausch mit mobilen Benutzern
Die Bereitstellung von Daten für mobile Benutzer und das Sammeln von Daten von mobilen Benutzern gehört zu den wichtigsten Aspekten vieler Anwendungen. Die meisten Anwendungen, die auf die Unterstützung mobiler Benutzer ausgerichtet sind, lassen sich in zwei breite Kategorien einteilen:
Kundenbeziehungsmanagement (CRM, Customer Relationship Management) und Automatisierung für den Verkauf (SFA, Sales Force Automation)
Ein Vertriebsmitarbeiter kann beispielsweise eine SFA-Anwendung verwenden, um bei einem Kundenbesuch Bestellungsdaten einzugeben. Diese Daten werden anschließend zurück an einen zentralen Standort übertragen, beispielsweise an die Zentrale eines Unternehmens oder an ein Datenzentrum.
Automatisierung für den Außendienst (FFA, Field Force Automation)
Mitarbeiter im Außendienst (Lieferanten, Wartungsmitarbeiter, Inspektoren usw.) können beispielsweise eine FFA-Anwendung auf einem Handheldgerät verwenden, um Daten an Remotestandorten zu sammeln und von dort aus zu übertragen. Ein Lieferant könnte Daten zu den Paketlieferungen am Lieferstandort eingeben, und diese Daten werden anschließend an den zentralen Standort übertragen.
Beide Anwendungskategorien erfordern sehr ähnliche Replikationsfeatures. Der Hauptunterschied zwischen den Anwendungen liegt darin, ob Daten von mehreren Benutzern aktualisiert werden oder nicht. Diese Frage wird im Abschnitt zu den allgemeinen Anforderungen für dieses Szenario in diesem Thema behandelt.
In den folgenden Diagrammen werden zwei verschiedene Vorgehensweisen für die Übermittlung von Daten an mobile Benutzer dargestellt: Bei der einen Vorgehensweise werden Laptops, bei der anderen Geräte (auf denen Microsoft SQL Server Compact 3.5 SP2 ausgeführt wird) verwendet. Die erste Vorgehensweise wird meist mit SFA- und CRM-Anwendungen verwendet, die zweite Vorgehensweise wird zumeist mit FFA-Anwendungen verwendet. Es können allerdings beide Vorgehensweisen für beide Anwendungskategorien angewendet werden.
Das erste Diagramm veranschaulicht ein Szenario, in dem eine Reihe von Benutzern mit Laptops direkt mit einem zentralen Standort verbunden ist:
.gif "Replizieren von Daten von Verkaufsmitarbeitern zur Zentrale")
Das zweite Diagramm veranschaulicht ein Szenario, in dem Benutzer mit Geräten über Server mit Microsoft Windows Internetinformationsdiensten (IIS, Internet Information Services) mit einem zentralen Standort verbunden sind. Die IIS-Server werden benötigt, wenn SQL Server Compact 3.5 SP2 verwendet wird.
.gif "Replizieren von Daten für Lieferanten")
Beispiele mit Adventure Works Cycles
Adventure Works Cycles ist eine zum Demonstrieren von Datenbankkonzepten und -szenarien erfundene Produktionsfirma. Weitere Informationen finden Sie unter AdventureWorks2008R2-Beispieldatenbanken.
Adventure Works Cycles hat viele Vertriebsmitarbeiter, die viel Zeit im Außendienst verbringen und direkt mit den Hauptkunden des Unternehmens, unabhängigen und vertragsgebundenen Fahrradhändlern, arbeiten. Die Vertriebsmitarbeiter werden in Teams eingeteilt, die einzelnen Regionen zugewiesen sind, sodass jeder Vertriebsmitarbeiter normalerweise seinen eigenen Kundenstamm bearbeitet. Kundendaten können jedoch für mehrere Vertriebsmitarbeiter und Vertriebsleiter freigegeben werden. Die Vertriebsmitarbeiter geben Bestellungsdaten an ihren Laptops ein und übertragen diese Daten gegebenenfalls an die Zentrale.
Adventure Works Cycles wickelt die Lieferung von Teilen und kompletten Rädern über A-1 Shipping ab. Die Lieferanten von A-1 Shipping verwenden alle Geräte, auf denen SQL Server Compact 3.5 SP2 ausgeführt wird. Die Fahrer geben zu jeder Lieferung Daten ein, sobald sie abgeschlossen ist. Die Daten werden auf die Zentrale von A-1 Shipping repliziert und vom Gerät gelöscht. Über ein Kundenextranet werden die Daten anschließend Adventure Works Cycles zur Verfügung gestellt.
Allgemeine Anforderungen für dieses Szenario
CRM-, SFA- und FFA-Anwendungen haben normalerweise folgende Merkmale, die bei einer geeigneten Replikation berücksichtigt werden müssen:
Die Datensynchronisierung sollte programmierbar sein, sodass eine Anwendung auf einem Laptop oder einem anderen Gerät so angepasst werden kann, dass auch Benutzer ohne technisches Wissen die Replikation erfolgreich durchführen können.
Bei den meisten mobilen Anwendungen können Daten an einem zentralen Standort und an Remotestandorten eingegeben und aktualisiert werden. Bei FFA-Anwendungen werden die meisten Daten an Remotestandorten eingegeben.
Remotebenutzer geben an einem Laptop, einem Gerät oder Tablet PC Daten ein bzw. aktualisieren Daten.
Remotebenutzer müssen in der Lage sein, Aktualisierungen unabhängig durchzuführen, ohne dass eine Verbindung mit dem zentralen Standort vorliegen muss.
Da möglicherweise mehrere Benutzer dieselben Daten unabhängig voneinander aktualisieren, können Datenkonflikte auftreten, die gelöst werden müssen.
Einige Daten, wie beispielsweise Daten in Preistabellen für Produkte, sollten nur am zentralen Standort aktualisiert werden.
Benutzer sollten in der Lage sein, Daten bei Bedarf und nicht nur zu geplanten Zeitpunkten zu synchronisieren.
Die Anwendung muss steuern, wie lange ein Remotestandort unsynchronisiert bleiben darf.
Für einige Tabellen ist eine Filterung erforderlich, sodass die einzelnen Benutzer für eine oder mehrere Tabellen verschiedene Daten erhalten. So erhält beispielsweise jeder Vertriebsmitarbeiter nur Kontaktinformationen für seine eigenen Kunden.
Einige Daten müssen als Einheit behandelt werden, wenn sie von Standort zu Standort übertragen werden. Wenn beispielsweise eine Bestellung von einem Remotebenutzer an den zentralen Standort gesendet wird, muss die Kopfzeile der Bestellung vor den Bestellungsdetails übertragen werden.
Gegebenenfalls muss die Anwendung beim Synchronisieren von Daten benutzerdefinierte Geschäftslogik ausführen.
Die Anwendung muss möglicherweise Daten über das Internet und nicht über eine VPN- oder IPSEC-DFÜ-Netzwerkverbindung synchronisieren.
Der Hauptunterschied zwischen CRM- und SFA-Anwendungen und andererseits FFA-Anwendungen liegt in Bezug auf die Replikation darin, ob Daten von mehreren Benutzern aktualisiert werden (Aktualisierungen durch mehrere Benutzer können zu Konflikten führen). Die Menge der Daten, die von mehreren Benutzern aktualisiert werden, hängt vom Ausmaß der Datenfilterung ab. Wenn Daten beispielsweise so gefiltert werden, dass alle Benutzer nur ihre eigenen Daten aktualisieren, treten zwischen den Benutzern keine Konflikte auf:
In CRM- und SFA-Anwendungen werden Daten häufig gefiltert. Einige Daten werden aber nach wie vor an mehreren Orten aktualisiert. Einige Daten werden nur in den Unternehmenszentralen aktualisiert, andere von einem einzigen Remotebenutzer, wieder andere von mehreren Remotebenutzern. Das folgende Diagramm veranschaulicht die für CRM- und SFA-Anwendungen gängige Filterung:
.gif "Filtern für Automatisierungsanwendungen für den Verkauf")
Bei FFA-Anwendungen werden Daten für gewöhnlich hauptsächlich im Außendienst gesammelt und anschließend an Unternehmenszentralen übertragen, ohne dass Konflikte auftreten, da ein einzelner Remotebenutzer nur bestimmte Daten aktualisiert. Das folgende Diagramm veranschaulicht die für FFA-Anwendungen gängige Filterung:
.gif "Filtern für Automatisierungsanwendungen für den Außendienst")
Typ der für dieses Szenario zu verwendenden Replikation
SQL Server verwendet ein Modell, das sich auf Abläufe aus dem Verlagswesen stützt, um die Komponenten des Replikationssystems zu beschreiben. Zu den Komponenten zählen der Verleger, der Abonnent, Veröffentlichungen und Artikel sowie Abonnements. In den ersten beiden oben stehenden Diagrammen fungiert der zentrale Standort als Verleger. Die am zentralen Standort vorhandenen Daten sind die Veröffentlichung, wobei jede Datentabelle einen Artikel darstellt (Artikel können auch andere Datenbankobjekte sein, z. B. gespeicherte Prozeduren). Alle Laptops der Verkäufer und alle Geräte der Lieferanten fungieren als Abonnenten der Veröffentlichung und erhalten Schemas und Daten als Abonnement. Weitere Informationen zu den Komponenten des Systems finden Sie unter Das Replikationsveröffentlichungsmodell (Übersicht).
SQL Server bietet verschiedene Replikationstypen für unterschiedliche Anwendungsanforderungen: die Snapshotreplikation, die Transaktionsreplikation und die Mergereplikation. Für dieses Szenario wird am besten die Mergereplikation implementiert, da hiermit die im vorherigen Abschnitt aufgeführten Anforderungen am besten erfüllt werden. Weitere Informationen zur Mergereplikation finden Sie unter Mergereplikation (Übersicht) und Funktionsweise der Mergereplikation.
Relevante Mergereplikationsoptionen für dieses Szenario
Die Mergereplikation bietet verschiedene Optionen, um die oben in diesem Thema beschriebenen Anforderungen zu erfüllen: Die folgende Liste enthält die einzelnen Anforderungen und die Mergereplikationsoptionen, die auf die jeweilige Anforderung ausgerichtet sind.
Die Datensynchronisierung sollte programmierbar sein.
Die Replikation ist über gespeicherte Prozeduren und Replikationsverwaltungsobjekte (RMO) programmierbar. RMO wird normalerweise für mobile Anwendungen verwendet. Weitere Informationen zur Replikationsprogrammierung finden Sie unter Entwicklerhandbuch (Replikation) und Sales Orders Sample Scenario.
Bei den meisten mobilen Anwendungen können Daten an einem zentralen Standort und an Remotestandorten eingegeben und aktualisiert werden. Bei FFA-Anwendungen werden die meisten Daten an Remotestandorten eingegeben.
Die Mergereplikation ist hierauf ausgerichtet, ohne dass bestimmte Optionen angegeben werden müssen.
Remotebenutzer geben an einem Laptop, einem Gerät oder Tablet PC Daten ein bzw. aktualisieren Daten.
Auf Laptops und Tablet PCs können SQL Server Standard und andere Editionen (einschließlich SQL Server Compact 3.5 SP2) ausgeführt werden, für Pocket PC-Geräte ist jedoch SQL Server Compact 3.5 SP2 erforderlich. Mithilfe der Mergereplikation können Sie Veröffentlichungen und Abonnements erstellen, die von SQL Server Compact 3.5 SP2 verwendet werden können. Weitere Informationen finden Sie unter Replizieren von Daten nach SQL Server Compact.
Remotebenutzer müssen in der Lage sein, Aktualisierungen unabhängig durchzuführen, ohne dass eine Verbindung mit dem zentralen Standort vorliegen muss.
Die Mergereplikation ist hierauf ausgerichtet, ohne dass bestimmte Optionen angegeben werden müssen.
Da möglicherweise mehrere Benutzer dieselben Daten unabhängig voneinander aktualisieren, können Datenkonflikte auftreten, die gelöst werden müssen.
Die Mergereplikation bietet eine Konflikterkennung und -lösung für Fälle, in denen Datenkonflikte erwartet werden. Anwendungen sollten im Optimalfall so entworfen werden, dass Konflikte vermieden werden. Falls dies jedoch nicht möglich ist, können Sie den standardmäßigen Konfliktlösungsmechanismus (Einhaltung der Eingangsreihenfolge) oder eine benutzerdefinierte Konfliktlösung anwenden. Weitere Informationen finden Sie unter Erkennen und Beseitigen von Konflikten bei der Mergereplikation.
Einige Daten, wie beispielsweise Daten in Preistabellen für Produkte, sollten nur am zentralen Standort aktualisiert werden.
Die Mergereplikation liefert nur herunterladbare Artikel für Tabellen, die nur auf dem Verleger aktualisiert sein sollten. Weitere Informationen finden Sie unter Optimieren der Leistung der Mergereplikation durch nur herunterladbare Artikel.
Benutzer sollten in der Lage sein, Daten bei Bedarf und nicht nur zu geplanten Zeitpunkten zu synchronisieren.
Die Replikation umfasst zwei Abonnementtypen: Pushabonnements und Pullabonnements. Pullabonnements eignen sich besser für die bedarfsgesteuerte Synchronisierung. Weitere Informationen zu den Abonnementtypen und zur Planung der Synchronisierung finden Sie unter Abonnieren von Veröffentlichungen und Synchronisieren von Daten.
Die Anwendung muss steuern, wie lange ein Remotestandort unsynchronisiert bleiben darf.
Bei der Mergereplikation können Sie einen Zeitraum für den Abonnementablauf festlegen, um sicherzustellen, dass alle Abonnenten innerhalb eines bestimmten Zeitraums eine Synchronisierung durchführen. Weitere Informationen finden Sie unter Abonnementablauf und -deaktivierung.
Für einige Tabellen ist eine Filterung erforderlich, sodass die einzelnen Benutzer für eine oder mehrere Tabellen verschiedene Daten erhalten. So erhält beispielsweise jeder Vertriebsmitarbeiter nur Kontaktinformationen für seine eigenen Kunden.
Die Mergereplikation ermöglicht eine spalten- und zeilenbezogene Filterung. Zeilenfilter können statisch oder parametrisiert sein. Ein statischer Filter wird nur angewendet, wenn eine Veröffentlichung erstellt wird. Als Ergebnis wird ein Dataset ausgegeben. Ein parametrisierter Filter wird jedes Mal angewendet, wenn ein Abonnent synchronisiert wird. Als Ergebnis werden verschiedene Datasets für die jeweiligen Abonnenten ausgegeben. CRM- und SFA-Anwendungen verwenden häufig parametrisierte Filter, können aber auch statische Filter verwenden. Weitere Informationen finden Sie unter Filtern veröffentlichter Daten für die Mergereplikation.
Einige Daten müssen als Einheit behandelt werden, wenn sie von Standort zu Standort übertragen werden. Wenn beispielsweise eine Bestellung von einem Remotebenutzer an den zentralen Standort gesendet wird, muss die Kopfzeile der Bestellung vor den Bestellungsdetails übertragen werden.
Bei der Mergereplikation können Sie angeben, dass eine Reihe verbundener Tabellen als Einheit verarbeitet werden muss. Diese Einheit wird als logischer Datensatz bezeichnet. Weitere Informationen finden Sie unter Gruppieren von Änderungen an verknüpften Zeilen mithilfe von logischen Datensätzen.
Gegebenenfalls muss die Anwendung beim Synchronisieren von Daten benutzerdefinierte Geschäftslogik ausführen.
Bei Mergereplikationen kann ein Code angegeben werden, der während der Synchronisierung ausgeführt werden soll. Dieser Code kann auf eine breite Palette an Ereignissen reagieren und hat Zugriff auf die zu synchronisierenden Daten. Weitere Informationen finden Sie unter Ausführen der Geschäftslogik während der Mergesynchronisierung.
Die Anwendung muss möglicherweise Daten über das Internet und nicht über eine Standleitung synchronisieren.
Bei der Verwendung von SQL Server Compact 3.5 Service Pack 2 (SQL Server Compact 3.5 SP2) werden Daten über eine HTTP- oder HTTPS-Verbindung synchronisiert. Bei anderen Editionen von SQL Server können Sie die Websynchronisierung verwenden, die HTTPS erfordert. Weitere Informationen finden Sie unter Websynchronisierung für die Mergereplikation.
Schritte für die Implementierung dieses Szenarios
Für die Implementierung dieses Szenarios müssen Sie zunächst eine Veröffentlichung und Abonnements erstellen und anschließend die einzelnen Abonnements initialisieren. Klicken Sie auf die folgenden Links, um weitere Informationen zu den einzelnen Schritten zu erhalten:
Nachdem das Abonnement initialisiert wurde und Daten zwischen dem Verleger und den Abonnenten übertragen werden, müssen Sie möglicherweise in folgenden Themen nachlesen, um Informationen zu allgemeinen Verwaltungs- und Überwachungsaufgaben zu erhalten: