モバイル ユーザーとのデータ交換
モバイル ユーザーに対するデータの提供と収集は、多くのアプリケーションの重要な要素です。モバイル ユーザーをサポートするアプリケーションの大半は、次の 2 つのカテゴリに大きく分類できます。
顧客間関係管理 (CRM) とセールス フォース オートメーション (SFA)
たとえば営業担当者は、SFA アプリケーションを使用して、顧客の訪問先で注文データを入力できます。入力されたデータは、その後、本社やデータ センターなどの集中管理場所に送信されます。
フィールド フォース オートメーション (FFA)
たとえば、配送ドライバー、保守要員、検査担当者などの現場の作業員は、ハンドヘルド デバイスで FFA アプリケーションを使用して、遠隔地からデータの収集や送信を行うことができます。配送ドライバーは、荷物の配達に関するデータを配送先で入力できます。入力されたデータは、その後、集中管理場所に送信されます。
どちらのカテゴリのアプリケーションも、必要とするレプリケーション機能はよく似ています。両者の最大の違いは、データが複数のユーザーによって更新されるかどうかです。この問題については、この後の「このシナリオの一般的な要件」で説明します。
以下の図は、データをモバイル ユーザーに配信するための 2 つの方法を表しています。一方はラップトップを使用し、もう一方はハンドヘルド デバイス (Microsoft SQL Server Compact 3.5 SP2 が実行されているデバイス) を使用します。1 つ目の方法は SFA アプリケーションや CRM アプリケーションでよく使用され、2 つ目の方法は FFA アプリケーションでよく使用されます。ただし、いずれの方法も、どちらのカテゴリのアプリケーションにも使用できます。
1 つ目の図は、ラップトップを使用する一連のユーザーが中央サイトに直接接続するシナリオを表しています。
.gif "営業担当者から本社へのデータのレプリケーション")
2 つ目の図は、ハンドヘルド デバイスを使用するユーザーが、Microsoft Windows インターネット インフォメーション サービス (IIS) サーバーを介して中央サイトに接続するシナリオを表しています。SQL Server Compact 3.5 SP2 を使用する場合は、IIS サーバーが必要になります。
.gif "配送ドライバーへのデータのレプリケーション")
Adventure Works Cycles の例
Adventure Works Cycles は、データベースの概念とシナリオを説明するために使用する架空の製造会社です。詳細については、「AdventureWorks2008R2 サンプル データベース」を参照してください。
Adventure Works Cycles では、大規模な営業部門が多くの時間をかけて、同社の主な顧客である自転車の小売店およびフランチャイズ販売店に対する直接の営業活動にあたっています。地域ごとに営業担当者のチームが割り当てられており、通常は、各営業担当者がそれぞれ特定の顧客を担当します。ただし、顧客データは、営業担当者および営業部門責任者の間で共有されます。営業担当者はラップトップで注文データを入力し、都合のよいときにデータを本社に送信します。
Adventure Works Cycles は、自転車の部品や完成品の配送に A-1 Shipping 社を利用しています。A-1 Shipping 社のすべての配送ドライバーは、SQL Server Compact 3.5 SP2 が実行されているデバイスを使用しています。ドライバーは、配送が完了するたびに配送についてのデータを入力します。このデータは、A-1 Shipping の本社にレプリケートされて、デバイスから削除されます。その後、顧客エクストラネットを通じて Adventure Works Cycles に公開されます。
このシナリオの一般的な要件
CRM、SFA、および FFA の各アプリケーションには一般的に以下のような特性があり、適切なレプリケーション ソリューションで対処する必要があります。
データの同期をプログラムできる必要があります。これにより、ラップトップやハンドヘルド デバイスのアプリケーションをカスタマイズして同期機能を追加することができます。エンド ユーザーにはレプリケーションの知識は必要ありません。
ほとんどのモバイル アプリケーションは、中央サイトとリモート サイトでデータの入力や更新を行うことができます。FFA アプリケーションでは、ほとんどのデータがリモート サイトで入力されます。
リモート ユーザーは、ラップトップ、ハンドヘルド デバイス、または Tablet PC を使用してデータの入力や更新を行います。
リモート ユーザーは、中央サイトに接続することなく独立して更新できることが必要です。
複数のユーザーが同じデータを別々に更新する可能性があるため、データの競合の問題に対処する必要があります。
製品の価格テーブルのデータなど、一部のデータは中央サイトでのみ更新されます。
スケジュールされた時刻以外に、ユーザーが要求時にデータを同期できる必要があります。
アプリケーションは、リモート サイトが非同期のままでいられる期間を制御する必要があります。
各ユーザーが 1 つ以上のテーブルに対して異なるデータを受信できるように、一部のテーブルではフィルタ選択が必要です。たとえば、各営業担当者は、自分が担当している顧客に関する連絡先情報だけを受け取ります。
一部のデータは、サイト間で転送される際に 1 つの単位として扱う必要があります。たとえば、リモート ユーザーから中央サイトに注文を送信する際には、注文のヘッダーを注文の詳細より先にコミットする必要があります。
データが同期された時点で実行されるカスタム ビジネス ロジックが必要な場合があります。
VPN や IPSEC のダイヤルアップ ネットワーク接続ではなく、インターネット経由でのデータの同期が必要になる場合があります。
レプリケーションの観点から見た場合、CRM アプリケーションや SFA アプリケーションと FFA アプリケーションとの最大の違いは、データが複数のユーザーによって更新されるかどうかです (複数のユーザーによって更新される場合は競合が発生する可能性があります)。複数のユーザーによって更新されるデータ量は、データをどの程度フィルタ選択するかによって決まります。たとえば、すべてのユーザーが自分のデータ以外は更新しないようにデータがフィルタ選択されていれば、ユーザー間の競合は発生しません。
CRM アプリケーションと SFA アプリケーションではデータのフィルタ選択がよく行われますが、それでも一部のデータは複数の場所で更新されます。本部でしか更新されないデータや 1 人のリモート ユーザーしか更新しないデータもあれば、複数のリモート ユーザーによって更新されるデータもあります。次の図は、CRM や SFA でよく使用されるフィルタ選択を表しています。
.gif "セールス フォース オートメーション アプリケーションのフィルター選択")
FFA アプリケーションでは、データが主に現場で収集され、その後、本部にアップロードされるのが一般的です。個々のデータは 1 人のリモート ユーザーによって更新されるため、競合は発生しません。次の図は、FFA アプリケーションでよく使用されるフィルタ選択を表しています。
.gif "フィールド フォース オートメーション アプリケーションのフィルター選択")
このシナリオで使用するレプリケーションの種類
SQL Server では、出版業界にたとえてレプリケーション システムのコンポーネントを表しています。コンポーネントには、パブリッシャ (出版社)、サブスクライバ (購読者)、パブリケーション (出版物) とアーティクル (記事)、およびサブスクリプション (定期購読物) があります。上記の最初の 2 つの図では、中央サイトがパブリッシャです。中央サイトのデータはパブリケーションで、各データ テーブルはアーティクルです (アーティクルはストアド プロシージャなどの他のデータベース オブジェクトの場合もあります)。各営業担当者のラップトップや配送ドライバーのハンドヘルド デバイスは、パブリケーションのサブスクライバです。これらは、スキーマやデータをサブスクリプションとして受け取ります。システムのコンポーネントの詳細については、「レプリケーションのパブリッシング モデルの概要」を参照してください。
SQL Server では、さまざまなアプリケーション要件に対して各種のレプリケーション (スナップショット レプリケーション、トランザクション レプリケーション、およびマージ レプリケーション) を用意しています。このシナリオはマージ レプリケーションによる実装が最適で、前のセクションで概説した要件によく適合します。マージ レプリケーションの詳細については、「マージ レプリケーションの概要」および「マージ レプリケーションの動作方法」を参照してください。
このシナリオに関連するマージ レプリケーションのオプション
マージ レプリケーションでは、このトピックで先に説明した要件に対応するための、いくつかのオプションが用意されています。次に、各要件とそれに対応するマージ レプリケーション オプションの一覧を示します。
データの同期をプログラムできる必要があります。
レプリケーションでは、ストアド プロシージャとレプリケーション管理オブジェクト (RMO) によるプログラムが可能です。RMO はモバイル アプリケーションに使用されるのが一般的です。レプリケーションのプログラミングの詳細については、「開発者ガイド (レプリケーション)」および「Sales Orders Sample Scenario」を参照してください。
ほとんどのモバイル アプリケーションは、中央サイトとリモート サイトでデータの入力や更新を行うことができます。FFA アプリケーションでは、ほとんどのデータがリモート サイトで入力されます。
マージ レプリケーションでは、別のオプションを指定する必要はありません。
リモート ユーザーは、ラップトップ、ハンドヘルド デバイス、または Tablet PC を使用してデータの入力や更新を行います。
ラップトップや Tablet PC では SQL Server Standard やその他のエディション (SQL Server Compact 3.5 SP2 を含む) を実行できますが、Pocket PC デバイスには SQL Server Compact 3.5 SP2 が必要です。マージ レプリケーションでは、SQL Server Compact 3.5 SP2 で使用できるパブリケーションやサブスクリプションを作成できます。詳細については、「SQL Server Compact へのデータのレプリケート」を参照してください。
リモート ユーザーは、中央サイトに接続することなく独立して更新できることが必要です。
マージ レプリケーションでは、別のオプションを指定する必要はありません。
複数のユーザーが同じデータを別々に更新する可能性があるため、データの競合の問題に対処する必要があります。
マージ レプリケーションは、データの競合が予測される場合には競合の検出と解決策を提供します。競合が発生しないようにアプリケーションを設計するのが理想的ですが、それが不可能な場合は、既定の競合解決メカニズム (最初のデータを優先) やカスタムの競合解決を使用できます。詳細については、「マージ レプリケーションの競合の検出と解決」を参照してください。
製品の価格テーブルのデータなど、一部のデータは中央サイトでのみ更新されます。
マージ レプリケーションでは、パブリッシャでのみ更新されるテーブルのダウンロード専用アーティクルが提供されます。詳細については、「ダウンロード専用アーティクルを使用したマージ レプリケーションのパフォーマンス最適化」を参照してください。
スケジュールされた時刻以外に、ユーザーが要求時にデータを同期できる必要があります。
レプリケーションでは、プッシュ サブスクリプションとプル サブスクリプションの 2 種類のサブスクリプションを使用できます。要求時の同期処理には、プル サブスクリプションの方が適しています。サブスクリプションの種類および同期処理のスケジュールの詳細については、「パブリケーションのサブスクライブ」および「データの同期」を参照してください。
アプリケーションは、リモート サイトが非同期のままでいられる期間を制御する必要があります。
マージ レプリケーションでは、すべてのサブスクライバが特定の期間内に同期されるように、サブスクリプションの有効期限を設定できます。詳細については、「サブスクリプションの有効期限と非アクティブ化」を参照してください。
各ユーザーが 1 つ以上のテーブルに対して異なるデータを受信できるように、一部のテーブルではフィルタ選択が必要です。たとえば、各営業担当者は、自分が担当している顧客に関する連絡先情報だけを受け取ります。
マージ レプリケーションでは、列と行をフィルタ選択することができます。行フィルタには、静的なものと、パラメータ化されたものがあります。静的フィルタは、パブリケーションの作成時にのみ適用されます。1 つのデータセットが生成されます。パラメータ化されたフィルタは、サブスクライバが同期されるたびに適用されます。各サブスクライバごとに別々のデータセットが生成されます。CRM アプリケーションと SFA アプリケーションでは、多くの場合、パラメータ化されたフィルタが使用されますが、静的フィルタも使用できます。詳細については、「マージ レプリケーション用にパブリッシュされたデータのフィルター選択」を参照してください。
一部のデータは、サイト間で転送される際に 1 つの単位として扱う必要があります。たとえば、リモート ユーザーから中央サイトに注文を送信する際には、注文のヘッダーを注文の詳細より先にコミットする必要があります。
マージ レプリケーションでは、関連するテーブルのセットを 1 つの単位として処理するように指定できます。この単位を論理レコードと呼びます。詳細については、「論理レコードによる関連行への変更のグループ化」を参照してください。
データが同期された時点で実行されるカスタム ビジネス ロジックが必要な場合があります。
マージ レプリケーションでは、同期時に実行されるコードを指定することができます。このコードは多種多様なイベントに対応し、同期対象のデータにアクセスできます。詳細については、「マージ同期中のビジネス ロジックの実行」を参照してください。
専用接続ではなくインターネットを経由したデータの同期が必要になる場合があります。
(SQL Server Compact 3.5 SP2) を使用する場合、データは HTTP 接続または HTTPS 接続を経由して同期されます。SQL Server の他のエディションでは、Web 同期が利用できます。この場合は HTTPS が必要です。詳細については、「マージ レプリケーションの Web 同期」を参照してください。
このシナリオの実装手順
このシナリオを実装するには、最初にパブリケーションとサブスクリプションを作成してから、各サブスクリプションを初期化してください。各手順の詳細については、以下のリンクをクリックしてください。
サブスクリプションの初期化が終わり、パブリッシャとサブスクライバの間でデータ フローが発生したら、共通の管理および監視作業の詳細について、必要に応じて以下のトピックを参照してください。