與行動使用者交換資料

發行項
12/15/2008

許多應用程式的一個主要功能就是為行動使用者提供資料並從行動使用者處收集資料。支援行動使用者的大多數應用程式均可歸類至兩個廣泛的類別：

客戶關係管理 (CRM) 與銷售自動化 (SFA)
例如，業務員可以使用 SFA 應用程式在拜訪客戶時輸入訂單資料。此資料隨後將傳回至中央位置，例如公司總部或資料中心。
職場戰力自動化 (FFA)
例如，現場員工 (運貨司機、維護人員、監督人員及其他人員) 可以透過手持式裝置中的 FFA 應用程式從遠端位置收集和傳送資料。運貨司機可以在運貨地點輸入有關運送貨物的封裝資料，此資料隨後將傳送回中央位置。

這兩類應用程式所需的複寫功能非常類似。它們的主要差別在於資料是否由多個使用者更新。此問題將在本主題的＜此狀況的一般需求＞一節中進行描述。

下圖說明如何使用兩種不同方法將資料傳遞給行動使用者，亦即使用膝上型電腦和其他裝置 (執行 Microsoft SQL Server 2005 Compact Edition) 的使用者。第一種方法通常用於 SFA 與 CRM 應用程式，第二種方法通常用於 FFA 應用程式。但是，兩種方法均可用於任一類別的應用程式。

第一個圖表說明的狀況是，一組使用膝上型電腦的使用者直接連接到中央站台：
第二個圖表說明的狀況是，使用裝置的使用者透過 Microsoft Windows Internet Information Services (IIS) 伺服器連接中央站台。使用 SQL Server 2005 Compact Edition 時需要 IIS 伺服器。

Adventure Works Cycles 範例

Adventure Works Cycles 是虛構的製造公司，用於示範資料庫概念與案例。如需詳細資訊，請參閱＜範例和範例資料庫＞。

Adventure Works Cycles 擁有一個龐大的銷售團隊，他們將大量的現場工作時間花費在了與公司主要客戶 (獨立及特許經營的自行車經銷商) 的直接接洽上。銷售團隊中的人員被指派到各個地區，且每個業務員通常只負責其自己的客戶。但是，客戶資料在業務員與業務經理之間共用。業務員可以在其膝上型電腦中輸入訂單資料，並在方便時將此資料傳送回中央辦事處。

Adventure Works Cycles 利用「A-1 運輸」來運輸其自行車零配件與整件。「A-1 運輸」的運貨司機都使用執行 SQL Server 2005 Compact Edition 的裝置。司機可在運貨完成後輸入每次運送貨物的資料。這些資料會複寫到「A-1 運輸」中央辦事處，並從裝置中刪除。隨後這些資料便可透過客戶外部網路供 Adventure Works Cycles 使用。

這個狀況的一般需求

CRM、SFA 和 FFA 應用程式通常具有下列特性，適當的複寫方案必須提出因應對策：

資料同步處理進行程式設計，以便膝上型電腦或裝置中的應用程式可以進行自訂以包含同步處理程序，而無需讓一般使用者瞭解複寫過程。
多數行動應用程式可於中央站台及遠端站台輸入與更新資料。在 FFA 應用程式中，多數資料皆於遠端站台輸入。
遠端使用者可以使用膝上型電腦、裝置或 Tablet PC 輸入並更新資料。
遠端使用者必須能夠獨立進行更新，不必連接到中央站台。
由於可能有多位使用者分別更新相同的資料，因此可能產生資料衝突，必須處理。
部分資料應只能在中央站台更新，例如產品價格資料表。
使用者應該能夠在需要時同步處理資料，而非只在排程的時間同步處理。
應用程式必須控制遠端站台能夠保持未同步處理的時間長度。
部分資料表需要篩選，每位使用者才能針對一或多個資料表收到不同的資料。例如，每個業務員只會收到其客戶的連絡資訊。
部分資料在站台之間傳送時，必須視為獨立單位。例如，若遠端使用者傳送訂單到中央站台，必須先認可訂單標頭，再認可訂單詳細內容。
應用程式可能會要求在資料同步處理時，執行自訂商務邏輯。
應用程式可能要求透過網際網路同步處理資料，而非透過 VPN 或 IPSEC 撥號網路連接。

CRM 和 SFA 應用程式與 FFA 應用程式在複寫方面的差別在於，是否由多個使用者更新資料 (由多個使用者更新資料會導致衝突)。可由多個使用者更新的資料量取決於篩選資料的范圍。例如，如果資料經篩選後使所有使用者僅可更新他們自己的資料集，則使用者間便不會產生衝突：

在 CRM 和 SFA 應用程式中，資料通常會被篩選，但某些資料仍可在多個位置進行更新。某些資料只在總部進行更新，某些資料只由單一遠端使用者更新，而某些資料可由多個遠端使用者更新。下圖說明了 CRM 與 SFA 常用的篩選：
在 FFA 應用程式中，通常是先在現場收集資料，隨後將資料上載至總部，這樣不會產生衝突，因為單一遠端使用者更新的是指定的資料段。下圖說明了 FFA 應用程式常用的篩選：

這個狀況要使用的複寫類型

SQL Server 使用的是出版業的字眼，來描述複寫系統的元件。元件包含發行者、訂閱者、發行集與發行項，以及訂閱。以上前兩個圖表中，中央站台為「發行者」。中央站台端的資料是發行集，而每個資料表則是發行項 (發行項也可以是其他資料庫物件，例如預存程序)。每個業務員的膝上型電腦與運貨司機的裝置都是發行集的「訂閱者」，並以訂閱的方式接收結構描述與資料。如需系統元件的詳細資訊，請參閱＜複寫發行模型概觀＞。

SQL Server 為不同的應用程式需求提供不同類型的複寫：快照式複寫、交易式複寫，以及合併式複寫。這個狀況使用合併式複寫實作最佳，這種複寫適合處理前一區段所述的需求。如需合併式複寫的詳細資訊，請參閱＜合併式複寫概觀＞與＜合併式複寫的運作方式＞。

與這個狀況相關的合併式複寫選項

合併式複寫提供數個選項，以處理本主題前面所述的需求。下列清單呈現每個需求，以及處理該需求的合併式複寫選項。

資料同步處理應進行程式設計。
複寫透過預存程序和「複寫管理物件」(RMO) 提供程式設計功能。RMO 通常用於行動應用程式。如需程式設計複寫的詳細資訊，請參閱＜Replication Programming＞和＜Sales Orders Sample Scenario＞。
多數行動應用程式可於中央站台及遠端站台輸入與更新資料。在 FFA 應用程式中，多數資料皆於遠端站台輸入。
合併式複寫提供這項功能，不用指定任何其他選項。
遠端使用者可以使用膝上型電腦、裝置或 Tablet PC 輸入及更新資料。
膝上型電腦和 Tablet PC 可以執行 SQL Server 標準版和其他版本，但 Pocket PC 裝置需要 SQL Server 2005 Compact Edition。合併式複寫可讓您建立用於 SQL Server 2005 Compact Edition 的發行集與訂閱。如需詳細資訊，請參閱＜複寫資料至 SQL Server Compact Edition＞。
遠端使用者必須能夠獨立進行更新，不必連接到中央站台。
合併式複寫提供這項功能，不用指定任何其他選項。
由於可能有多位使用者分別更新相同的資料，因此可能產生資料衝突，必須處理。
合併式複寫針對預期會發生資料衝突的情況提供衝突偵測與解決方案。最好能設計應用程式，以避免衝突；但在不可能這樣做的情況下，您可以選取預設衝突解決機制 (先進先贏) 或使用自訂衝突解決機制。如需詳細資訊，請參閱＜偵測及解決合併式複寫衝突＞。
部分資料應只能在中央站台更新，例如產品價格資料表。
合併式複寫針對那些只應在發行者端更新的資料表，提供僅限下載的發行項。如需詳細資訊，請參閱＜使用僅限下載的發行項最佳化合併式複寫效能＞。
使用者應該能夠在需要時同步處理資料，而非只在排程的時間同步處理。
複寫提供兩種訂閱類型：發送訂閱與提取訂閱。發送訂閱較適合視需要的同步處理。如需訂閱類型與排程同步處理的詳細資訊，請參閱＜訂閱發行集＞與＜同步處理資料＞。
應用程式必須控制遠端站台能夠保持未同步處理的時間長度。
合併式複寫允許您設定訂閱過期期間，以確保所有訂閱者在特定的時間內都已同步處理。如需詳細資訊，請參閱＜訂閱逾期與停用＞。
部分資料表需要篩選，每位使用者才能針對一或多個資料表收到不同的資料。例如，每位銷售人員只收到自己客戶的連絡資訊。
合併式複寫允許您篩選資料行與資料列。資料列篩選可以是靜態或參數化的。只有在建立發行集時才會套用靜態篩選；靜態篩選會產生一個資料集。每次訂閱者同步處理時就會套用參數化篩選；它會為每個訂閱者產生不同的資料集。CRM 和 SFA 應用程式通常使用參數化篩選，不過也可以使用靜態篩選。如需詳細資訊，請參閱＜合併式複寫之篩選發行的資料＞。
部分資料在站台之間傳送時，必須視為獨立單位。例如，若遠端使用者傳送訂單到中央站台，必須先認可訂單標頭，再認可訂單詳細內容。
合併式複寫可讓您指定某組相關資料表必須視為一個單位處理。此單位稱為邏輯記錄。如需詳細資訊，請參閱＜使用邏輯記錄分組相關資料列的變更＞。
應用程式可能會要求在資料同步處理時，執行自訂商務邏輯。
合併式複寫允許您指定在同步處理過程中執行的程式碼。這個程式碼可以回應許多的事件，而且能夠存取所同步處理的資料。如需詳細資訊，請參閱＜在合併同步處理期間執行商務邏輯＞。
應用程式可能會要求資料透過網際網路同步處理，而非透過專用連接同步處理。
使用 SQL Server Compact Edition (SQL Server 2005 Compact Edition) 時，會透過 HTTP 或 HTTPS 連接同步處理資料。針對其他版本的 SQL Server，您可以使用 Web 同步處理 (需要 HTTPS)。如需詳細資訊，請參閱＜合併式複寫的 Web 同步處理＞。

實作這個狀況的步驟

若要實作這個狀況，您必須先建立發行集與訂閱，然後初始化每個訂閱。按一下下列的連結，以取得有關每個步驟的詳細資訊：

在初始化訂閱，而且資料在發行者與訂閱者之間流動之後，您可能需要參考下列主題，以取得一般管理與監視工作的資訊：

Share via