Implementierungsdetails zum Sales Orders-Beispiel

In diesem Thema werden einige der Implementierungsdetails und Entwurfsentscheidungen für die Adventure Works Sales Orders-Βeispielanwendung beschrieben. Dieses Beispiel, das im Lieferumfang von Microsoft SQL Server enthalten ist, veranschaulicht die Vorteile der Programmierung von Mergereplikationen zwischen Servern und Clients. Weitere Informationen finden Sie unter Readme_Sales Orders-Beispiel für die Mergereplikation.

Übersicht über die Architektur

Die Anwendung selbst ist ein auf Microsoft Windows Forms basierender verwalteter Client, der mithilfe von Microsoft Visual Studio 2005 entwickelt wurde. Diese Clientanwendung greift auf Verkaufsauftragsdaten in einer lokalen Instanz von SQL Server (alle Editionen) zu, indem sie die Datenzugriffsmöglichkeiten von Microsoft .NET Framework 2.0 nutzt. Eine Mergereplikationstopologie wird implementiert, um die Konsistenz der Daten auf dem Computer des Vertriebsmitarbeiters und in der AdventureWorks-Hauptdatenbank am Verwaltungssitz zu gewährleisten. Diese Daten sind partitioniert, sodass jeder Vertriebsmitarbeiter nur die Daten erhält, die er zur Betreuung seiner Kunden benötigt. Die Mergeveröffentlichung wird programmgesteuert mit gespeicherten Replikationsprozeduren konfiguriert. Wenn die Sales Orders-Anwendung zum ersten Mal gestartet wird, erstellt sie programmgesteuert die lokale Datenbank mithilfe von SQL Server Management Objects (SMO) und definiert das Mergepullabonnement mithilfe von Replikationsverwaltungsobjekten (RMO). Das Abonnement wird programmgesteuert mit RMO verwaltet und überwacht.

Replikationsfeatures

Mithilfe der Mergereplikationstopologie können Vertriebsmitarbeiter vor Ort beim Kunden oder auf Reisen mit ihren Vertriebsdaten arbeiten, ohne auf eine Verbindung zur AdventureWorks-Datenbank angewiesen zu sein. Der Vertriebsmitarbeiter stellt in regelmäßigen Abständen eine Verbindung zum Internet her, um Bestelländerungen zum Verleger hochzuladen und Bestelländerungen und aktualisierte Produktinformationen auf den Abonnenten herunterzuladen. Die Mergereplikationstopologie für dieses Beispiel wurde entworfen, um mehrere Abonnenten zu unterstützen, die alle Editionen von SQL Server 2005 oder höher, inklusive SQL Server Express und SQL Server Compact 3.5 SP1, ausführen. Dieser Typ der Mergereplikationstopologie wird unter Datenaustausch mit mobilen Benutzern näher erläutert.

Parametrisierte Zeilenfilter

In der Praxis sollten Vertriebsdaten, die zu den jeweiligen Vertriebsmitarbeitern gehören, mit der SUSER_SNAME-Funktion basierend auf den Anmeldeinformationen in der Employee.LoginID-Spalte horizontal gefiltert werden. Das Filtern kann die Leistung verbessern, die Größe des ursprünglichen Snapshots verringern, das Risiko von konfliktverursachenden Datenänderungen zwischen Abonnenten verringern und die Anwendungslogik vereinfachen. In einer Beispielanwendung ist es jedoch nicht sinnvoll, mithilfe der SUSER_SNAME-Funktion zu filtern. Stattdessen werden im Beispiel die Daten mit der HOST_NAME-Funktion partitioniert. Mit der Replikation haben Sie außerdem die Möglichkeit, die HOST_NAME-Funktion zu überladen, um beliebige Filterkriterien für die Datenpartitionierung festzulegen, und dieses Beispiel verwendet die Klausel WHERE HumanResources.Employee.LoginID = HOST_NAME, um den horizontalen Filter für die Employee-Tabellen-Artikel zu definieren. Mit Verknüpfungsfiltern können diese parametrisierten Zeilenfilter auf andere vertriebsbezogene Tabellen erweitert werden.

Aufgrund der in diesem Beispiel verwendeten Artikelfilteroptionen müssen Sie für jedes Abonnement von dieser Veröffentlichung einen anderen Wert für Hostname angeben. Folgende Employee.EmployeeID-Werte können im Hostname-Schlüssel im Beispiel verwendet werden:

• adventure-works\michael9
• adventure-works\pamela0
• adventure-works\tsvi0
• adventure-works\shu0
• adventure-works\rachel0
• adventure-works\lynn0

Bevor Sie den Hostname-Wert für ein bestehendes Abonnement ändern, müssen Sie das folgende Transact-SQL-Skript jeweils auf dem Abonnenten und dem Verleger ausführen, und dann das Beispiel erneut ausführen, um das Abonnement wiederherzustellen.

Vorbereiten der partitionierten Snapshots

Die Veröffentlichung ist so konfiguriert, dass Abonnenten die Generierung ihres jeweiligen partitionierten Snapshots bei der Initialisierung des Abonnements anfordern können. Sie können diese Snapshots jedoch auch vor der Initialisierung generieren und so diese Verarbeitungskosten vorhersagbar und zu einem vorbestimmten Zeitpunkt erzeugen. Weitere Informationen finden Sie unter Vorgehensweise: Erstellen eines Snapshots für Mergepublikationen mit parametrisierten Filtern (Replikationsprogrammierung mit Transact-SQL).

Schemaoptionen

Artikelschemaoptionen bestimmen, wie ein Datenbankobjekt auf den Abonnenten repliziert wird. Weitere Informationen finden Sie unter Veröffentlichen von Daten und Datenbankobjekten. Die im Beispiel verwendeten Schemaoptionen hängen vom Objekttyp und der Funktionalität ab, die auf dem Abonnenten erforderlich sind.

Programmierbarkeitsobjekte

• Für gespeicherte Prozeduren und benutzerdefinierte Funktionen für den Datenzugriff werden nur Skripts für die Objekterstellungsbefehle erstellt, wie CREATE PROCEDURE und CREATE FUNCTION.

Dies kommt einem @ schema_option-Wert von 0x00001 gleich.

Tabellenobjekte

• Tabellenobjekte werden auf dem Abonnenten erstellt.
• Gruppierte und nicht gruppierte Indizes für Tabellen werden repliziert.
• CHECK- und FOREIGN KEY-Einschränkungen werden repliziert.
• Eindeutige Schlüssel werden repliziert.
• Benutzerdefinierte Datentypen werden auf dem Abonnenten in Basisdatentypen konvertiert.
• Benutzerdefinierte Trigger für Tabellen werden nicht repliziert.
• Schemas, die noch nicht auf dem Abonnenten vorhanden sind, werden erstellt.

Dies kommt einem allgemeinen @ schema_option-Wert von 0x8004EF1 gleich.

Abonnementstatus

In diesem Beispiel wird die SubscriberMonitor-Klasse aufgerufen, um Informationen über den Abonnementstatus anzuzeigen. Diese Klasse ist als Teil dieses Beispiels und auch als eigenständige Überwachung im SubscriberMonitorUtility-Projekt implementiert. Weitere Informationen finden Sie unter Verwenden des Subscriber Monitor-Beispiels.

Websynchronisierung

Die Websynchronisierung für die Veröffentlichung wird bei der Erstellung aktiviert. Um die Websynchronisierung verwenden zu können, müssen Sie jedoch den Assistenten zum Konfigurieren der Websynchronisierung ausführen und Zertifikate für SSL auf dem Webserver und auf dem Abonnenten einrichten. Im Beispiel wird die HTTP-Standardauthentifizierung über eine gesicherte SSL-Verbindung verwendet. Dies ist die empfohlene Vorgehensweise für die Websynchronisierung. Weitere Informationen finden Sie unter Konfigurieren der Websynchronisierung. Wenn die Websynchronisierung im Web Synchronization Options-Formular aktiviert ist und sie eine Anmeldung und ein Kennwort für die HTTP-Standardauthentifizierung angeben, legt die Anwendung die UseWebSynchronization-Eigenschaft für das Abonnement auf true fest und verwendet InternetLogin und InternetPassword, um mithilfe des HTTPS-Protokolls zu synchronisieren. Bei der Verwendung des Beispiels müssen Sie ein Windows-Konto und ein Kennwort angeben, um die Websynchronisierung verwenden zu können. Diese Anmeldeinformationen werden vom Webserver verwendet, wenn dieser eine Verbindung zum Verleger herstellt. Wenn der Merge-Agent keine Verbindung zum Webserver mit HTTPS am von der InternetUrl-Eigenschaft angegebenen Speicherort herstellen kann, wird ein Fehler zurückgegeben.

Benutzerdefinierte Geschäftslogik

Da Bestellungen meistens aufgegeben werden, wenn der Vertriebsmitarbeiter offline ist, kann es vorkommen, dass eine Bestellung für Produkte im Bestellrückstand aufgegeben wird. Aufgrund einer Unternehmensrichtlinie werden die Bestellungen erst ausgeliefert, wenn alle bestellten Artikel verfügbar sind. Wenn eine Bestellung nicht sofort ausgeführt werden kann, wird die Status-Spalte der SalesOrderHeader-Tabelle auf den Wert 3 gesetzt, um anzuzeigen, dass die gesamte Bestellung in Bestellrückstand geht und später ausgeführt wird. In diesem Fall muss die Anwendung den zuständigen Vertriebsmitarbeiter so schnell wie möglich über den Bestellrückstand benachrichtigen, damit dieser den Kunden benachrichtigen kann.

Das Sales Orders-Beispiel implementiert die BusinessLogicModule-Klasse des Microsoft.SqlServer.Replication.BusinessLogicSupport-Namespace und fügt so benutzerdefinierte Geschäftslogik in den Synchronisierungsprozess ein. Bei jeder an den Verleger gesendeten Zeilenänderung der SalesOrderDetail-Tabelle verbindet sich die benutzerdefinierte Geschäftslogik mit dem Verleger und prüft das Inventar mithilfe der ProductInventory-Tabelle auf dieses Element. Wenn die Anwendung feststellt, dass die Bestellmenge die verfügbare Gesamtmenge im Inventar übersteigt, wird die Status-Spalte der SalesOrderHeader-Tabelle auf 3 gesetzt. Die Anwendung schreibt dann eine Nachricht ins Synchronisierungsprotokoll, die die Bestellrückstandssituation erläutert. Da das von der Replikation bereitgestellte Geschäftslogik-Framework zur Implementierung beliebiger von .NET Framework unterstützter Funktionalitäten verwendet werden kann, kann die benutzerdefinierte Geschäftslogik genauso einfach verwendet werden, um ein Dialogfeld auszulösen oder eine automatische E-Mail-Nachricht an den Kunden zu senden.

Die benutzerdefinierte Geschäftslogik implementiert die InsertHandler-Methode und die UpdateHandler-Methode, um Zeileneinfügungen und Aktualisierungen zu behandeln. Die Initialize-Methode ist ebenfalls implementiert. Wenn die benutzerdefinierte Geschäftslogik initialisiert wird, übergibt die Replikation Verlegerinformationen, mit denen programmgesteuert die Verbindungszeichenfolge für das SqlConnection-Objekt mithilfe der SqlConnectionStringBuilder-Klasse generiert wird.

Synchronisierungsstatus

Replikations-Agents können von einem Agentauftrag (asynchron) oder direkt vom Code (synchron) gestartet werden. Einer der Hauptvorteile der synchronen Ausführung von Replikations-Agents ist die Möglichkeit, Agent-Statusmeldungen mithilfe der integrierten Rückruffunktionalität des Agents zu erhalten und anzuzeigen. Im Sales Orders-Beispiel wird das Status-Ereignis (Rückruf) behandelt, indem mit StatusEventHandler Statusmeldungen von zurückgegebenen StatusEventArgs-Objekten abgerufen und angezeigt werden. Außerdem wird eine ganze Zahl zurückgegeben, die den geschätzten Prozentsatz der Fertigstellung der Synchronisierung angibt. Dieser wird dem Benutzer durch einen Fortschrittsbalken angezeigt. Da durch die Hintergrundsynchronisierung die Informationen im Subscription Status-Formular veraltet sein können, kann der Vertriebsmitarbeiter auf die Refresh-Schaltfläche klicken, um die neuesten Sitzungen zu laden.

Synchronisierung bei vorhandener Verbindung

Im Sales Orders-Beispiel werden die Stärken der Mergereplikation bei der Synchronisierung von Daten in einer nicht verbundenen Umgebung veranschaulicht. Es sind jedoch Situationen denkbar, wie beispielsweise während eines Meetings am Verwaltungssitz des Unternehmens, in denen eine Internetverbindung zur Verfügung steht. Dieses Beispiel kann auch dazu verwendet werden, kontinuierlich in einer verbundenen Umgebung zu synchronisieren. Mit der unter Advanced Options aktivierten Synchronize when connected-Option wird ein Timer-Steuerelement aktiviert. Wenn der Zeitgeber das in der Konfigurationsdatei der Anwendung voreingestellte Intervall erreicht, wird das Zeitgeberereignis ausgelöst, und die Anwendung fordert den Windows-Verwaltungsinstrumentations (WMI)-Anbieter (mithilfe des System.Management-Namespace) dazu auf, den Verbindungsstatus des Computers zu überprüfen. Wenn eine Verbindung vorhanden ist, wird das Abonnement im Hintergrund synchronisiert. Um Probleme mit der Dateneingabe zu vermeiden, lässt das Beispiel keine Synchronisierung im Hintergrund zu, wenn ein anderes Formular als das Sales Orders-Formular fokussiert ist. Da im Beispiel eine WMI-Eigenschaft verwendet wird, die in Microsoft Windows 2000 nicht verfügbar ist, ist die Synchronize when connected-Menüoption auf Computern, die unter Windows 2000 ausgeführt werden, nicht aktiviert.

Bereitstellung

Alle Programmierobjekte, die zum Zugriff auf Daten in der Abonnementdatenbank verwendet werden, wie gespeicherte Prozeduren, benutzerdefinierte Typen und benutzerdefinierte Funktionen, werden ausschließlich auf dem Verleger in der Veröffentlichungsdatenbank erstellt und für den Abonnenten als Artikel veröffentlicht. Wenn das Sales Orders-Beispiel zum ersten Mal auf dem Computer einer Vertriebsperson ausgeführt wird, stellt die Anwendung eine Verbindung zum Verleger her, lädt den ursprünglichen Snapshot herunter und wendet den Snapshot an, zu dem auch die Datenzugriffs-Programmierobjekte des Programms gehören. Nachdem der Snapshot erfolgreich angewendet wurde, lädt die Anwendung die lokalen Daten in das Sales Orders-Formular. Anschließend ist die Anwendung bereit zur Dateneingabe.

Mithilfe des neuen Visual Studio 2005 ClickOnce-Bereitstellungsfeatures können Sie ein Anwendungsinstallationspaket auf einer Website veröffentlichen. Abonnenten können diese Anwendung von der ClickOnce-Bereitstellungssite herunterladen und installieren, und können dann – sofern .NET Framework 2.0 bereits installiert ist – ihre Abonnements remote über ein virtuelles privates Netzwerk (VPN) von einem Standort außerhalb des Verwaltungssitzes aus initialisieren. ClickOnce kann auch Dienstupdates von der Website übermitteln. Weitere Informationen über die ClickOnce-Bereitstellung finden Sie im Thema "Übersicht über die ClickOnce-Bereitstellung" in der Visual Studio 2005-Dokumentation.

Schritt-für-Schritt-Anweisungen zur Installation und Ausführung dieses Beispiels finden Sie unter Readme_Sales Orders-Beispiel für die Mergereplikation.

Benutzeroberflächenelemente

Im Sales Order-Beispiel werden die folgenden Benutzeroberflächenelemente implementiert.

Überlegungen zum Beispiel

In diesem Abschnitt werden Entwurfsüberlegungen, Kompromisse und potenzielle Probleme des Beispiels beschrieben.

Unterstützung für Abonnenten von SQL Server Compact

Eine primäre Entwurfsüberlegung für die Replikationstopologie ist, ob die Veröffentlichung SQL Server Compact 3.5 SP1-Abonnenten unterstützen soll. Da SQL Server Compact 3.5 SP1 nur Datensnapshots im Zeichenmodus unterstützt, hat die Veröffentlichung einige zusätzliche Einschränkungen, die nicht vorhanden wären, wenn Snapshots im systemeigenen Format verwendet würden. Diese können jedoch verwendet werden, wenn alle Abonnenten andere Editionen von SQL Server ausführen. Folgende Einschränkungen gelten:

• Ausführen von Transact-SQL-Skripts vor und nach dem Anwenden des Snapshots. Dies hätte die Erstellung der lokalen Datenbank und beliebiger benutzerdefinierter Typen oder Schemas auf dem Abonnenten mithilfe von Transact-SQL ermöglicht, anstatt SQL Server Management Objects (SMO)-Assemblys zur Laufzeit herunterladen zu müssen.
• Berechnete Spalten. Einige Schlüsselspalten im AdventureWorks Sales Orders-Schema können nicht repliziert werden. Dazu gehören: LineTotal in der SalesOrderDetail-Tabelle sowie TotalDue und SalesOrderNumber in der SalesOrderHeader-Tabelle. Die Anwendung muss eigene Berechnungen durchführen, um Benutzern diese Informationen anzeigen zu können.
• Logische Datensätze hätten verwendet werden können, um sicherzustellen, dass Verkaufspositionen in der SalesOrderDetail-Tabelle nicht ohne die Zeile in der SalesOrderHeader-Tabelle, zu der sie gehören, an den Verleger gesendet werden. Wenn SQL Server Compact 3.5 SP1-Abonnenten unterstützt werden sollen, können logische Datensätze jedoch nicht verwendet werden.

Mergereplikationsleistung

Da die AdventureWorks-Beispieldatenbank dazu entworfen wurde, viele der mit SQL Server implementierten Produktionsdatenbanken zu emulieren, ist das Schema recht komplex und die enthaltenen Daten stark normalisiert. Dieser Normalisierungsgrad kann indexabhängige Vorgänge verbessern, er kann sich aber auch negativ auf die Mergereplikationsleistung auswirken. In diesem Beispiel werden fünf Verknüpfungsfilter benötigt, um den parametrisierten Zeilenfilter von der Employee-Tabelle bis hinunter zur SalesOrderDetail-Tabelle zu erweitern. Die Replikation schließt Features ein, die die Leistung parametrisierter Zeilenfilter, wie z. B. vorausberechnete Partitionen, optimieren. Wenn jedoch ein Problem mit der Mergereplikationsleistung auftritt, sollten Sie die veröffentlichten Tabellen denormalisieren, um die Anzahl der Verknüpfungsfilter auf weniger als drei zu reduzieren. Weitere Informationen finden Sie unter Verbessern der Leistung der Mergereplikation.

Websynchronisierung

Der Ansatz, Benutzern den nahtlosen Wechsel zwischen Websynchronisierung und normaler Synchronisierung mithilfe einer direkten Verbindung zum Verleger zu ermöglichen, hat die Architektur des Beispiels beeinflusst. Im Beispiel wird die MergePullSubscription-Klasse verwendet, um für die Websynchronisierung benötigte Eigenschaften sicher zu speichern und abzurufen, wodurch außerdem die Anwendungslogik vereinfacht wird. Um diese Funktion von der MergePullSubscription-Klasse zu erhalten, muss bei der Erstellung des Abonnements die CreateSyncAgentByDefault-Eigenschaft auf true gesetzt sein. Neben der Zeile in der MSsubscription_properties-Tabelle, mit der Sie diese Eigenschaften auf ein MergePullSubscription-Objekt einstellen können, wird so auch ein Agentauftrag für das Abonnement erstellt. Da die Anwendung die Synchronisierung immer direkt startet und nicht den SQL Server-Agent verwendet, bleibt dieser Auftrag ungenutzt. Der Agentauftrag wird für einen SQL Server Express-Abonnenten nicht erstellt, da der SQL Server-Agent von dieser Edition nicht unterstützt wird, aber die erforderlichen Metadaten werden dennoch erstellt. Wenn die Create-Methode call lautet und CreateSyncAgentByDefault true ist, müssen SynchronizationAgentProcessSecurity-Informationen angegeben werden. Deswegen wird bei der Erstellung des Abonnements das Logon User-Formular angezeigt. Diese Anmeldeinformationen werden von SQL Server gespeichert, aber nie verwendet. Stattdessen wird der Merge-Agent im Kontext des Windows-Benutzers ausgeführt, von dem das Beispiel ausgeführt wird.

Das Beispiel ist dafür ausgelegt, für alle Serververbindungen integrierte Authentifizierung zu verwenden, abgesehen von der Verbindung des Abonnenten zum Webserver während der Websynchronisierung, die die HTTP-Standardauthentifizierung verwendet. Wir empfehlen, keine integrierte Authentifizierung für die Websynchronisierung zu verwenden. In einem Szenario in der wirklichen Welt wird der für die Websynchronisierung verwendete IIS-Server auf einem anderen Computer als dem Verleger oder dem Verteiler bereitgestellt. Aufgrund der Einschränkungen des Windows-Identitätswechsels erfordert dies, dass die an den Webserver weitergegebenen Anmeldedaten der Standardauthentifizierung der Anmeldung am Verleger entsprechen.

Benutzerdefinierte Typen

AdventureWorks umfasst eine Reihe benutzerdefinierter Typen, die als Basistypen auf dem Abonnenten repliziert werden. Wenn diese Typen Common Language Runtime (CLR)-Typen sind, werden sie als CLR-Typen repliziert.

Veröffentlichte AdventureWorks-Objekte

Die folgenden AdventureWorks-Tabellen sowie gespeicherten Prozeduren und benutzerdefinierte Funktionen für den Dateizugriff werden als Artikel in der Mergereplikationstopologie veröffentlicht.

Siehe auch

Konzepte

Sales Orders-Beispielszenario

Hilfe und Informationen

Informationsquellen für SQL Server 2008