ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Business Data Synchronization Server管理者ガイド
11g リリース1 (11.1.1.7.0)
B69393-02
  目次へ移動
目次

前
 
次
 

2 BDSSアーキテクチャの理解

この章では、Oracle Business Data Synchronization Server (BDSS)アーキテクチャの概要について説明します。

この章の構成は、次のとおりです。

2.1 Oracle Business Data Synchronization Serverアーキテクチャの概要

Oracle Business Data Synchronization Server(BDSS)は、PIMサーバー間の同期化を可能にするハブアンドスポーク・アーキテクチャを利用します。ハブは、主要な同期化機能を提供し、PIMサーバーに依存しないため、すべてのタイプのPIMサーバーに対する接続を可能にします。コネクタは、PIMサーバーへのデータ送信およびPIMサーバーからのデータ取得を実行し、システムのスポークを構成します。図2-1に、このアーキテクチャの例で、PIMサーバー間のコネクタの数がより少なくなる例を示します。複数サーバー・トポロジの場合でも、このより単純化された同期化トポロジによって、PIMサーバー間のデータ・フィードバック・ループの潜在的な問題が処理されます。

図2-1 BDSSのハブアンドスポーク・アーキテクチャの例

ハブアンドスポーク・アーキテクチャ

注意:

Oracle Fusion Middleware 11g リリース1では、BDSSにMicrosoft Exchangeのサポート機能が備わっています。


2.1.1 BDSSコンポーネント

BDSSは、次の2つの主要コンポーネントで構成されています。

2.1.1.1 ハブ

ハブは、システムのデータの同期化を統合し、次のサブシステムが含まれます(図2-2を参照)。

図2-2 ハブのサブシステム

ハブ・サブシステム

ディスパッチャ

ディスパッチャは最初に、エンジンに送信する必要があるユーザーのセットを読み取り、リスト上のユーザーが同期化可能であることを確認します。コールされた後、ディスパッチャ・プロセスは、同期化対象のユーザー・セット全体をバッチに分割し、エンジン・コンポーネントをコールします。このユーザー・リストの細分化によって、複数のエンジン・コンポーネントを使用可能にできるため、システムのスケーラビリティが向上します。ディスパッチャ・コールは、使用可能なエンジン・コンポーネント間で分散させることもできます。


注意:

ディスパッチャは、現在同期化中のユーザーはエンジンに送信しません。


スケジューラ

外部スケジューラは、設定された時間間隔でディスパッチャを実行します。BDSSにはスケジューラは付属していません。Windowsスケジューラ・サービスまたはOracle Enterprise Managerスケジューラなど、任意のスケジューリング・サービスを使用できます。


注意:

デフォルトの間隔である5分をお薦めしますが、環境に適したパフォーマンスおよびスケーラビリティを実現するスケジューリング間隔を選択できます。


エンジン

エンジンは、ディスパッチャからユーザーのリストを受信し、これらの各ユーザーを同時に同期化します。エンジンは、各コネクタに接続し、ユーザーに関して変更されたレコードのセットをPIMサーバーから受信します。抽出セットは結合され、PIMサーバーにプッシュ・バックされる完全な変更のセットが作成されます。


注意:

エンジンが通知するのは、PIMサーバーに対して他のPIMサーバー上で変更されたレコードについてのみです。独自の抽出セットから識別した変更はPIMサーバーに通知しません。


同じ同期化サイクル中に両方のPIMサーバーでレコードが変更された場合は、競合が発生する可能性があります。エンジンは、関係する各コネクタ・ドメインの相対優先度に基づいて、保持する変更と破棄する変更を決定します。(各コネクタ・ドメインに割り当てる優先度を構成できます。)結果セットを構成するレコードを決定した後、エンジンは、これらのレコードをPIMサーバーにプッシュし、ユーザーの成功を追跡します。

ハブ自体は、コネクタから受信するデータを読み取りません。かわりに、各レコードのIDタグを読み取り、様々なPIMサーバーのレコードを相互に関連付けるレコード・マップを作成します。ハブは、そのデータをコネクタに渡します。

エンジンには、ユーザーの同期化に必要なデータを格納および取得する、ランタイム構成マネージャも含まれています。このデータには、コンポーネント構成設定、ユーザー情報、マッピング、ユーザー・レコード情報およびPIMサーバー・インスタンスに関する情報が含まれています。

2.1.1.2 コネクタ

コネクタは、処理対象のハブとPIMサーバー間の通信を標準化します。コネクタは、連絡先またはタスクなど、コネクタ・ドメインに対するデータを更新します。同期化セッション時に、コネクタは、ユーザーに対する変更データをそれぞれのPIMサーバーから取得し、ハブ書式に変換します。次に、変換したデータをハブに渡します。また、コネクタは、ハブから取得したデータをPIMサーバーに適した書式に変換します。コネクタは、Webサービスを使用して、ユーザー・レコードの取得とそれらをエンジンに返す処理の両方を実行します。詳細は、第2.2項「コネクタの概要」を参照してください。

Oracle Fusion Middleware 11gリリース1の場合、BDSSにはMicrosoft Exchange 2007用Oracle BDSSコネクタ(Exchange 2007コネクタ)が付属しています。Exchange 2007コネクタでは、ユーザーのMicrosoft Exchangeメールボックスとの相互作用時に、Exchange 2007 Exchange Web Service(EWS)が使用されます。Exchange 2007コネクタでは、カレンダおよびタスク・データの同期化がサポートされています。


注意:

BDSSコネクタAPIを使用して、サービス・リクエストまたは商談など、ドメインを同期化するコネクタを作成できます。詳細は、付録C「コネクタAPI」を参照してください。


2.1.2 BDSSによるユーザーの同期化方法

BDSSでは、MBean(マネージドBean)を使用して構成される一連のユーザーが、各エンド・システムからのユーザー・ログインをハブ・ユーザーと呼ばれるユーザーの中央表現にマッピングすることによって処理されます。ディスパッチャは、スケジュールによってトリガーするか、またはユーザーによるレコードの変更時にコネクタがハブにイベント通知を送信したときにトリガーできます。スケジューラベースの同期化では、一部のユーザーに変更がない場合でも、各間隔ですべてのユーザーが同期化されます。イベントベースの同期化は、同期化対象のデータがあるときのみユーザーが同期化されるためより効率的です。

2.1.2.1 同期化オプション

次の同期化オプションを、各コネクタ・ドメインの各ユーザーに対して設定できます。たとえば、ユーザーに対するタスク・アイテムの同期化を有効にした場合は、BDSSによって、そのユーザーに対するタスクが自動的に同期化されます。

Inbound

インバウンド方向では、エンティティ(ドメイン、ユーザーまたはコネクタなど)に対するデータの交換が、PIMサーバーへのレコードおよびレコード更新のプッシュのみに限定されます。PIMサーバー上のレコードの変更は、他のシステムに伝播されません。

Outbound

アウトバウンド方向を使用すると、コネクタはPIMサーバーからレコードの作成、更新および削除イベント・データを抽出できます。アウトバウンド方向では、PIMサーバーからの変更の収集のみを許可することによって、エンティティに対する同期化が限定されます。レコードまたは変更のPIMサーバーへのプッシュは行われません。

None

データの同期化は発生しません。

Full

完全同期化は、双方向(つまり、インバウンドとアウトバウンドの両方)の同期化を有効にします。

コネクタ、ドメインおよびユーザーに対して、同期化方向を構成できます。詳細は、第4.1.2項「同期化方向の指定」を参照してください。

2.1.2.2 スケジューラベースの同期化

BPELサーバーとMicrosoft Exchangeサーバー間の同期化セッションの例を示す一般的なフローは、次のとおりです。

  1. スケジューラがディスパッチャをトリガーします。

  2. ディスパッチャが、同期化可能なハブ・ユーザー、つまり同期化が有効化されているが現在同期化中ではないユーザーを検索します。

  3. ディスパッチャはこれらのユーザーをバッチにまとめます。

  4. ディスパッチャはそのバッチをエンジンに送信します。

  5. エンジンが各ユーザーに対する同期化セッションを開始します。

  6. 同期化セッションによって、次の操作が実行されます。

    1. ユーザーに対する適切なPIMサーバーを判別します。

    2. ユーザーに対するドメイン(タスクまたは連絡先など)を判別します。

    3. 抽出メッセージを各コネクタに対するコネクタ・インスタンスに送信します。この抽出メッセージには、レコード変更がリクエストされるユーザー・ドメインがリストされています。

  7. コネクタが抽出レスポンスをエンジンに返します。各抽出レスポンスには、特定のコネクタ・ドメインに対する新規、更新および削除レコードを記述した情報が含まれています。

  8. エンジンが抽出レスポンス・レコードをマージして、必要に応じて競合を解決します。

  9. エンジンは適切なレコード変更を各PIMサーバーに送信します。

  10. ユーザーの同期化プロセスが終了します。

第C.1.9項「同期化セッション」も参照してください。

2.1.2.3 同期状態を使用したレコード変更の追跡

エンジンは、コネクタが提供する同期状態と呼ばれるデータを使用して、PIMサーバーから正常にエクスポートされたユーザーのドメイン・レコードを追跡します。同期状態は、コネクタ・ドメイン・レベルで監視されます。同期状態の詳細は、付録C「コネクタAPI」を参照してください。

2.1.3 イベントベースの同期化

イベントベースの同期化では、ハブで必要な処理量が削減されます。また、不要なユーザー同期化セッションを排除することによって、ネットワークおよびデータベースの使用量も削減されます。イベントベースの同期化を使用すると、ハブは、レコードの変更が発生したときのみユーザーを同期化します。ユーザーに対する変更がない場合、ハブはユーザーを同期化しません。

ドメインに影響を与えるユーザー変更では、同期化セッションはトリガーされず、標準の同期化(第2.1.2項を参照)と同様に、スケジューラによって同期化セッションの頻度が指示されます。イベントベースの同期化プロセスは、PIMサーバーがそのコネクタにユーザーのレコードが変更されたことを通知したときに開始されます。次に、コネクタは、ハブに通知し、PIMサーバー上のレコードを変更したユーザーであることを示すイベント・フラグを設定します。スケジューラが新しい同期化サイクルをトリガーすると、ディスパッチャは、同期化されるようにこのユーザーをまとめてエンジンに送信します。

BDSSは、イベントベースの同期化に対してユーザーにフラグ付けできるコネクタとPIMサーバー、およびイベントベースの同期化に対してユーザーにフラグ付けできないPIMサーバーを処理します。イベントベースの同期化に対してすべてのコネクタおよびPIMサーバーがユーザーにフラグ付けできるシステムでは、ディスパッチャは変更フラグ付きのユーザーを1つにまとめます。これらのユーザーに対する同期化が開始されると、ハブは、スケジュールされた同期化セッションの場合と同様にユーザーを同期化します(つまり、ハブは、ハブがコネクタの初期通知を受信した後でユーザーのPIMデータに対して変更が発生している可能性があるため、コネクタからの変更をリクエストします)。エンジンは、同期化サイクル中に、ユーザーの処理またはコネクタへの抽出メッセージの送信は実行しません。これらの同期化セッション中、同期化方向は、フラグ付けされていないユーザーに対してはインバウンドのみです。イベントにフラグ付けできないコネクタがあるシステムでは、ハブは、イベントベースの同期化について、これらのコネクタに属するすべてのユーザーを同期化します。

BDSSコネクタでイベント通知の送信をサポートできない場合、ハブは、ユーザー同期化セッションを開始するためのイベントベースの方法をサポートできません。たとえば、コネクタが変更を検出できないシステムで変更が行われた場合、ハブがユーザーに対するレコードを同期化できるのは、その同じユーザーに対するイベント通知がサポートされているコネクタがあるシステムでレコードの変更が行われた場合のみです。

BDSSは、起動(または再起動)されるたびに、完全またはインバウンド同期化のいずれかに設定されたドメインすべてで、同期化するユーザーに対して変更フラグを設定します。これらのフラグによって、コネクタはユーザーに対するサブスクリプションを作成できます。コネクタは、可能な場合は、ドメインごとに別々のサブスクリプションを作成します。


注意:

イベントベースの同期化を有効にするには、CONNECTORSテーブルのSYNC_EVENTS_ENABLED_FLGSUPPORTS_EVENTS_FLGおよびUSER_EVENT_FLGの各フラグを設定します。


イベントベースの同期化のフロー

  1. ディスパッチャが、同期化可能なハブ・ユーザーを取得します。

  2. ディスパッチャはこれらのユーザーをバッチにまとめます。

  3. ディスパッチャはこれらのユーザーをエンジンに送信します。

  4. エンジンが各ユーザーに対する同期化セッションを開始します。同期化セッションによって、次の操作が実行されます。

    1. ユーザーに対する適切なPIMサーバーを判別します。

    2. ユーザーのドメイン(タスクまたは連絡先など)に対する変更があるかどうかを判別します。

    3. 抽出メッセージを各コネクタに対するコネクタ・インスタンスに送信します。この抽出メッセージには、レコード変更がリクエストされるユーザー・ドメインがリストされています。

    4. コネクタが抽出レスポンスをエンジンに返します。

    5. エンジンが抽出レスポンスを処理し、データをコネクタにプッシュします。

  5. ユーザーの同期化プロセスが終了します。ハブがコネクタ・ユーザーに対する変更フラグをリセットします。コネクタでイベントがサポートされていない場合、ハブは、変更フラグを同期化が発生する状態のままにします。

2.2 コネクタの概要

コネクタは、Webサービスを使用して、ユーザー・レコードをハブに通知します。コネクタはBDSSコネクタAPIを実装します。付録C「コネクタAPI」では、BDSSコネクタ・インタフェース、コネクタ・ランタイム・インタフェースおよびエンジン・コールバック・インタフェースについて詳細に説明しています。コネクタは、次の3つのコンポーネントで構成されています。

2.2.1 ハブ・トランスポート

ハブ・トランスポートは、コネクタ・インタフェースを実装し、エンジンとコネクタ間のデータ交換を実行します。

2.2.2 トランスフォーマ

トランスフォーマは、ハブ・スキーマとPIMサーバーのスキーマの両方にデータを変換します。ハブによるデータの書式設定方法を定義でき、顧客のニーズにあわせて自由に修正できます。Oracle JDeveloperを使用すると、ハブおよびPIMサーバーのXSD(XMLスキーマ定義)をマップするXSLT(XML変換)を作成できます。第8章「ハブ・フィールドへのコネクタ・フィールドのマッピング」も参照してください。


注意:

ハブ・スキーマは作成および修正できますが、コネクタ・スキーマは変更できません。コネクタ・スキーマはコネクタ開発者によって作成され、変更しないままにする必要があります。


2.2.3 PIMトランスポート

PIMトランスポートは、PIM APIインタフェースを使用し、コネクタとPIMサーバー間のデータ交換を実行します。データ交換の一環として、PIMトランスポートは、PIM XMLスキーマ表現とPIMサーバー表現間でデータを変換します。

2.2.4 コネクタ・コンポーネントによる同期化時のドメイン・データの管理方法

ハブとコネクタ間の同期化はデフォルトで双方向ですが、同期化方向をインバウンドのみまたはアウトバウンドのみに限定するように構成できます。

2.2.4.1 インバウンド同期化

コンポーネントは、PIMサーバーからのデータ受信時に、次のように相互作用します。

  1. PIMトランスポートは、ネイティブPIMサーバーAPIを使用して、ドメインに対するレコード・セットを収集します。このデータは、PIMサーバー固有の書式です。

  2. PIMトランスポートは、レコードが属しているドメインに対して定義されているPIM XSDに準拠するPIM XML書式に、各レコードを変換します。

  3. PIMトランスポートは、各PIM XMLレコードをトランスフォーマに渡し、トランスフォーマは次の処理を実行して、PIM XMLレコードをハブXMLレコードに変換します。

    1. 同期化方向(インバウンド)を判別して、正しいXLSTドキュメントを適用します(PIMからハブ)。第5.4項「コネクタ構成プロファイルの作成」も参照してください。

    2. XSLTドキュメントを各レコードに適用するAPIを起動します。このXLSTには、ハブとPIMサーバーの両方に対するスキーマ定義が含まれています。

    3. ハブXMLレコードをハブ・トランスポートに返します。

  4. ハブ・トランスポートは、APIをコールして、ハブXMLレコード・セットを含むSOAP(Simple Object Access Protocol)メッセージを作成します。

  5. 次に、ハブ・トランスポートは、APIをコールしてSOAPメッセージをハブにプッシュします。

2.2.4.2 アウトバウンド同期化

アウトバウンド同期化では最初に、ハブが、ハブXML書式の単一のレコードを含むSOAPメッセージをコネクタに送信します。次に、コネクタが、このXMLレコードをターゲットのPIMサーバーで必要とされる適切な書式に変換します。

コンポーネントは、PIMサーバーからのデータ受信時に、次のように相互作用します。

  1. ハブ・トランスポートが、ハブXMLレコードを含むSOAPメッセージを受信します。

  2. 次に、ハブ・トランスポートは、ハブXMLセットをトランスフォーマに渡します。

  3. トランスフォーマが、次の処理を実行して、レコードをハブXMLから適切なPIM XMLに変換します。

    1. 同期化方向(アウトバウンド)を識別して、適切なXSLTをハブXMLレコードに適用します(ハブからPIM)。

    2. APIをコールしてXSLTを適用します。

    3. 変換したレコードをハブ・トランスポートに渡します。

  4. ハブ・トランスポートが、PIM XMLレコードをPIMトランスポートに渡します。

  5. PIMトランスポートが、PIMサーバーへのレコードのプッシュに使用されるネイティブPIM APIで必要な書式にPIM XMLを変換します。

  6. PIMトランスポートは、PIM API書式設定レコードをPIMサーバーに送信します。

2.2.5 エラー・メッセージ

エラーをBPELタスク・フローに統合して、同期化時に発生した管理者データ・エラーに関するアラートを通知できます。たとえば、ユーザーがサードパーティのPIMサーバーで受け入れることができない文字を記述に含むレコードを誤って作成した場合、そのPIMサーバーでは、次の同期化セッション時にそのレコードが拒否されます。その結果、BDSSはレコード・サマリーとエラーを含むBPELイベントを発生させます。管理者は、エラー・コードをチェックするBPELプロセスを設定し、サポートされていない文字をレコードから削除するようにユーザーに通知する電子メールを送信します。

イベントは、BDSSによってクリティカル、エラーまたは警告のメッセージがそのログ・ファイルに記録されるたびに発生します。BDSSが、BPELサーバーまたはWebサービスに対するBPELイベントを発生させることもできます。