Oracle® Fusion Middleware Oracle Business Data Synchronization Server管理者ガイド 11gリリース2(11.1.2.3.0) B66162-03 |
|
![]() 前 |
![]() 次 |
この付録では、Exchange 2007コネクタのカスタム・フィールドを変換するために使用するXLSTおよびXSDについて説明します。
この付録のトピックは、次のとおりです。
次のコネクタAPIがあります。
用語
APIに関連する用語は次のとおりです。
関連データとは、コネクタのかわりにハブに格納されるコネクタ定義のデータです。任意のタイプのデータを使用できますが、コネクタではデータがAssociatedData構造に準拠していることを確認する必要があります。
関連データは、一意の識別子および複数グループのコレクションで構成されます。各グループには、グループ識別子、および関連データを格納する任意の数のKeyValuePair構造が含まれます。コネクタでは、各グループ内に任意の数のグループおよびKeyValuePair
構造を定義できます。たとえば、Microsoft Exchange 2007用Oracle BDSSコネクタでは、識別子がMailboxProperties
のユーザー・レベルの関連データを定義し、その関連データにグループ識別子がMailboxProperties
の1つのグループを含めることができます。このグループには2つのKeyValuePair
構造が含まれ、キーはlegacyExchangeDN
とmsExchHomeServerName
で、値はActive Directoryから取得されたデータが移入されます。同様に、Exchange 2007コネクタでは、識別子がPIMレコードIDのレコード・レベルの関連データを定義し、その関連データにグループ識別子がSourceKey
、ChangeKey
およびPredecessorChangeList
の3つのグループを含めることができます。SourceKey
グループには単一のKeyValuePair
が保持され、キーはSK
で、値はExchangeレコードのソース・キー値です。ChangeKey
グループには単一のKeyValuePair
が保持され、キーはCK
で、値はExchangeレコードの変更キー値です。PredecessorChangeList
グループには任意の数のKeyValuePair
構造が保持されます(Exchangeレコードの先行変更リストの各変更キーがKeyValuePair
として表されます)。
関連データの特徴は次のとおりです。
ハブに対して不透明です(つまり、ハブから識別されません)。
これはオプションです。
データ・ストアにテキストとして格納されます。
サイズは任意です。
レコード・レベルのRTL(ランタイム・ライブラリ)アクセスAPIに加えて、コネクタではレコード・レベルの関連データをCreateRecord
またはUpdateRecord
コールの結果構造で提供できます。ハブでは、新しい関連データでデータ・ストアを更新します。
レコード・レベルのRTLアクセスAPIに加えて、コネクタではレコード・レベルの関連データをExtractResponse
の各UpsertRecord
で提供できます。ハブでは、その関連データでデータ・ストアを更新します。
PIMサーバー・インスタンスの特定のセットにサービスを提供するコネクタ・インスタンス用の一連の構成の名前。
注意: コネクタ名は指定の同期化セッション中は変更されません。したがって、ステートフル・コネクタの場合は、指定のユーザーおよび同期化セッションの値をキャッシュし、その値をハブ・コールバックまたはRTL(ランタイム・ライブラリ)APIのコール時に使用することもできます。 |
作成/作成競合は、キー・フィールドのフィールド値が一致する同期化されていない複数のレコードが、同じ同期化セッション中に異なる複数のシステムから抽出された場合に発生します。
フィールド・クラスとは、データ型に優先してPIMフィールドに追加セマンティクを適用する、PIMフィールドの分類です。フィールド・クラスの例には、Phone、Address、Email、Category、To、CCおよびBCCがあります。フィールド・クラスでは、次の処理を実行します。
コネクタ間のフィールドの自動マッピングを容易にします。
コネクタ実装を有効にし、特定のクラスに基づいてロジックを実装します。たとえば、コネクタでは、システム内で値(参加者など)を解決するためにフィールド・クラス(To、CC、BCCなど)に関するフィールド情報が必要になる場合があります。
PIMドメイン・ターゲットとは、指定のユーザーおよびドメインについて、ドメインのPIMデータが存在する場所に関する構成メタデータです(オプション)。PIMドメイン・ターゲットは、PIMサーバーが各ユーザーのPIMデータを複数の異なる場所に格納するコネクタで使用できます。たとえば、Exchangeが各ユーザーのタスク・データと連絡先データを異なるフォルダに格納する場合、Exchangeのタスク・データは「Task」フォルダ(または「Task」フォルダのサブフォルダ)に格納され、Exchangeの連絡先データは「Contact」フォルダ(または「Contact」フォルダのサブフォルダ)に格納されます。構成メタデータはコネクタ固有であるため、コネクタ実装ではその構成メタデータを解析します。次に例を示します。
フォルダの相対パスの構成(例: \root\calendar\mycalendar
)は、ドメインのサブフォルダに対する同期化を示します。
抽象値の構成(例: Root)は、ドメインのデフォルトの主フォルダに対する同期化を示します。
コネクタによっては、PIMフォルダを指定せずに、他の方法(Siebel PDQフィルタなど)を指定する場合があります。たとえば、連絡先ドメインの場合、コネクタでは同期化リストのPDQをドメイン・ターゲットとして識別します。PDQでは、フォルダ・パスと異なりターゲット上の物理的な場所を識別しませんが、フォルダ・パスと同様に同期化対象となるレコードのセットを識別します。
注意: このオプションのメタデータはユーザーおよびドメインごとに指定されるため、管理者はBDSSで同期化されるユーザーおよびドメインごとにPIMドメイン・ターゲットを指定する必要があります。コネクタ構成を簡略化するために、開発者はデフォルトのPIMドメイン・ターゲットを作成し、構成が使用できない場合にコネクタでデフォルト値を使用するようにできます。たとえば、構成が使用できない場合、コネクタではドメインに対してデフォルト・フォルダを使用できます。また、開発者は、Rootなどの構成値を要求し、コネクタではドメインに対してデフォルト・フォルダを使用するように指定することもできます。デフォルトのPIMドメイン・ターゲットがない場合、各ユーザーおよびドメインのメタデータが必要になると、コネクタはその構成を要求できます。 |
PIMレコード説明とは、KeyValuePair構造の配列です。各KeyValuePair
構造には、ハブ・フィールド名がキーとして、ハブ・フィールド値が値として保持されます。コネクタでは、RTL(ランタイム・ライブラリ)API GetConfigurationMetadata
を使用して、各ハブ・ドメインのPIMレコード説明に含めるように構成されたハブ・フィールドのリストを取得する必要があります。
PIMレコード説明で使用するハブ・フィールドの構成は、FtsKeyFieldsプロファイルに格納されています。プロファイルのセクション名には、ハブ・ドメイン名が含まれています。プロファイルのパラメータの名前はKeyFieldX形式で、Xは表内の他の行から該当する行を識別するだけでなく、コネクタによるPIMレコード説明の作成時にフィールドの表示順を指定する数値です。コネクタでは、PIMレコード説明を作成し(構成が存在する場合)、KeyValuePair
配列に表示するフィールドの順序がKeyFieldXで指定した順序と同じであることを確認する必要があります。たとえば、FtsKeyFieldsプロファイルの「Task」ハブ・ドメインには、表D-1に示す構成があります。
表D-1 「Task」ハブ・ドメインの構成
プロファイル | セクション(ハブ・ドメイン名) | パラメータ | 値 |
---|---|---|---|
FtsKeyFields |
Task |
KeyField1 |
Subject |
FtsKeyFields |
Task |
KeyField2 |
StartDate |
コネクタでレコードが抽出されると、2つの要素を含むKeyValuePair
配列が作成されます。最初の要素(index0)にはKeyValuePair
が含まれ、キーはSubjectで、値はレコードのハブ・フィールド値です。2番目の要素(index1)にはKeyValuePairが含まれ、キーはStartDateで、値はレコードのハブ・フィールド値です。
ハブ・レコードに構成済のキー・フィールドの値がない場合、コネクタではそのフィールドに空の文字列を挿入する必要があります。
注意: コネクタでは、レコード説明にハブ・フィールド名とハブ・フィールド値を提供する必要があります。コネクタではこの情報を提供するために、PIMからレコードを抽出してハブ書式に変換し、PimRecordDescriptionを作成する必要があります。同様に、コネクタでは、作成または更新操作が正常終了したときに、ハブ・フィールドの名前と値を提供する必要があります。これは非常に重要で、ハブでは、複数のPIMサーバーからの抽出レスポンスを評価するときに、これらのキー・フィールドが含まれたPIMレコード説明を使用してPIMレコードのキー・フィールド照合を実行します。PIMレコード説明は、ハブ・レコードがシステム内を移動するときにハブ・レコードに対して実行された特定の操作に関する情報を記録する場合にも使用されます。 |
Oracle Fusion Middleware 11gリリース2のBDSSの場合、レコード説明のメンバーとして指定するフィールドは複数値タイプにできません。
PIMレコードIDとは、コネクタがPIMサーバー上のレコードを一意に識別するために使用する識別子です。PIMレコードIDは、ユーザーおよびドメインごとにPIMサーバー内で一意である必要があります。コネクタでは、PIMレコードIDとして使用するプロパティがレコードの識別およびレコードへのアクセスに使用できることを確認する必要があります。
コネクタでは、次の場合にPIMレコードIDをBDSSに提供します。
PIMサーバーからレコードを抽出するとき
プッシュされた作成操作が完了したとき
BDSSでは、更新操作または削除操作がPIMサーバーにプッシュされると、PIMレコードIDをコネクタに提供します。
PIMレコード・バージョンIDとは、PIMレコードのバージョンを取得するコネクタ定義の値です。これは、変更されたPIMレコードを追跡できる任意の値です。たとえば、PIMレコードに「最終変更日時」フィールドがある場合、その「最終変更日時」フィールドは、レコードが更新されるたびに更新されるため、コネクタではこのフィールドをPIMレコード・バージョンIDとして使用できます。同様に、レコードが変更されると増分される整数値がPIMレコードにある場合、コネクタではその整数値を使用することもできます。
同期化セッションとは、ハブでBDSSコネクタを介して、1つ以上のハブ・ドメインのハブ・ユーザーのデータを1つ以上のPIMストア間で同期化するセッションです。セッションは、ハブでコネクタAPI InitializeUserSyncSession
をコールすると開始され、同期化セッションIDと呼ばれる一意の識別子によって識別されます。このセッションは、ハブでEndUserSyncSession
APIをコールすると終了します。これら2つのコールの間に、ハブでは次のコネクタAPIをコールできます。
ExtractDomains
API: すべてのハブ・ドメインに対してコネクタがインバウンドのみの同期化用に構成されたハブ構成の場合、このAPIはコネクタでコールされません。コールされるのは、少なくとも1つのハブ・ドメインに対してコネクタが双方向またはアウトバウンドのみの同期化用に構成されたハブ構成の場合です。
CreateRecord
、UpdateRecord
またはDeleteRecord
APIは、セッション中に任意の回数コールできます。
エンジンは、コネクタが提供する同期状態と呼ばれるデータを使用して、PIMサーバーから正常にエクスポートされたユーザーのドメイン・レコードを追跡します。同期状態は、コネクタ・ドメイン・レベルで監視されます。
コネクタでは、同期状態とその書式を定義します。たとえば、コネクタでは、日時スタンプを使用して前の同期化セッション中に実行した抽出問合せの時刻を示したり、PIM APIによって定義された規則を使用して、コネクタがPIMサーバーとデータを交換する方法を記述することができます。たとえば、Exchange 2007用Oracle BDSSコネクタでは、増分変更同期化(ICS)バイナリBLOBが使用されます。コネクタによる同期状態の管理方法の詳細は、第D.4.3項「CommitCachedSyncStateメソッドAPI」、第D.4.8項「GetSyncState API」および第D.4.10項「SaveSyncState API」を参照してください。
注意: このデータはエンジンに対して不透明ですが、エンジンは、いつ同期状態をハブ・データ・ストアに保存するかを指示します。 |
1人のユーザーの各コネクタ・ドメインに対して1つの同期状態があります。同期状態はハブ・データ・ストアに存在し、これによってシステムでは、1つのドメインからすべてのレコードを抽出したり、前の同期状態から発生した作成、読取り、更新および削除操作のみを抽出できます。
注意: エンジンは、ユーザーの各同期化セッションの後にコネクタ・ドメインの同期状態を更新しますが、これは、送信されたレコードの処理時に他のすべてのコネクタでエラーが発生していない場合のみです。コネクタでエラーが発生した場合は、(エラーの修正後に)後続の同期化セッションで一部のレコードを再度抽出する必要があるため、同期状態は更新されません。 |
更新/更新競合は、以前に同期化されたレコードが複数のシステムで更新され、同じ同期化セッションで抽出された場合に発生します。
コネクタのPIMサーバー同期化サービスは、Webサービスとして公開されています。コネクタ開発者は、このドキュメントで定義されているWebサービス・インタフェースを実装します。エンジン、テスト・アプリケーションおよびその他のWebサービス・クライアントはコネクタ・インタフェースのコンシューマで、このインタフェースには次のAPIが含まれます。
注意:
|
ハブでは、各ユーザーの同期化セッションが開始されるたびに、InitializeUserSyncSession
APIをコールします。コネクタはユーザーベースの初期化を実行して、ユーザーがそのコネクタを使用して、指定のsyncSessionId
で識別される同期化セッション中に後続のリクエストを処理できるようにする必要があります。表D-2に、InitializeUserSyncSession
APIのパラメータを示します。
表D-2 InitializeUserSyncSession APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
[in] |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
コネクタがBDSSからメタデータを取得する必要がある場合にコールするURLが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
|
[in] |
DomainInfo構造の配列が格納されます。配列には、構成されたすべてのハブ・ドメインのメタデータが含まれます。このパラメータは、NULL以外の配列である必要があります。各
コネクタでは配列を検証し、指定した |
|
String |
[out] |
オプション・パラメータ。入力時は、パラメータはNULLです。出力時に、コールを受信したコネクタの完全URLが格納されるか、またはNULLのままです。 指定した同期化セッションIDで識別される同期化セッション中に指定のハブ・ユーザーに対して後続のコールを行うときに、同じコネクタ・インスタンス(URLで識別される)をコールするようにコネクタがBDSSに要求する場合、このコールを受信したコネクタはそのURLを提供できます。 |
戻り値
void
例外
コネクタでユーザーを初期化できない場合は、例外をスローして問題を特定するメッセージを提供する必要があります。これによって、BDSSでそのメッセージを記録できます。
InitializeUserSyncSession
APIをコールするには、エンジンで次の処理を実行する必要があります。
すべてのハブ・ドメインのドメイン・メタデータを提供します。
ExtractDomains
、CreateRecord
、UpdateRecord
またはDeleteRecord
をコールする前に、InitializeSyncSession
APIをコールします。
注意: エンジンは、 |
コネクタで例外がスローされると、ハブではコネクタがユーザーを初期化できなかったと判断されます。したがって、ハブでは、指定のハブ・ユーザーおよび同期化セッションについて、コネクタへの後続のコールが実行されません。
指定のユーザーおよび同期化セッションでコネクタが使用するコネクタ・ランタイム・ライブラリURLを提供します。コネクタでは、このメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合、提供されたURLを使用する必要があります。
コネクタ名を提供します。コネクタでこのメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたconnectorName
を使用する必要があります。
コネクタでは、エンジンのInitializeUserSyncSession
APIコールのレスポンスとして、次の処理を実行する必要があります。
APIに渡された各パラメータを検証し、表D-2に示す基準を満たしていることを確認します。
必要なユーザーベースの初期化を実行して、コネクタが後続のハブ・リクエストを処理できるようにします。リクエストには、ハブ・ドメインを抽出したり、レコードを作成、更新または削除するためのものがあります。
コネクタで後続のすべてのコールを同じコネクタ・インスタンスにルーティングする必要がある場合は、コールを受信したコネクタ・インスタンスのURLを提供します。
コネクタでは、後続のハブ・コールを処理するためにこのAPIに渡されたパラメータをキャッシュする必要がある場合、syncSessionId
とpimUserId
の組合せを使用できます。ほとんどのコネクタでは、同期化セッション中に後で使用できるように、提供されたドメイン情報データをキャッシュする必要があります。ステートレス・コネクタで状態を保持する必要がある場合は、これがコネクタ実装詳細とみなされます。
コネクタでコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたRTL(ランタイム・ライブラリ)URLとコネクタ名を使用します。
エンジンは、非同期のWebサービスAPIであるExtractDomains
をコールして、コネクタに指定のハブ・ドメインを抽出するようにリクエストします。抽出とは、変更されたすべてのPIMレコードをPIMストアから取得してダウンロードするプロセスです。コネクタでは、前回の同期状態以降に変更されたすべてのPIMレコードを抽出する必要があります(前回の同期状態は、ハブでInitializeUserSyncSession
がコールされて同期化セッションが開始されると、ユーザーおよびドメインごとに提供されます)。各PIMレコードは、第8章「ハブ・フィールドへのコネクタ・フィールドのマッピング」の定義に従ってハブ書式に変換されます。ハブ書式のレコードは、ExtractDomainResultsCallback
APIを介してハブに提供されます。
表D-3 ExtractDomains APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
|
[in] |
抽出が必要なユーザーおよびドメインに関連する情報が格納されます。このパラメータは、NULL以外である必要があります。 ExtractRequestメンバーは、次の基準を満たしている必要があります。
|
|
|
[in] |
コネクタで抽出リクエストを処理するために必要なコンテキスト情報が格納されます。NULL以外である必要があります。 HubContextメンバーは、次の基準を満たしている必要があります。
|
コネクタでは、このメソッドを非ブロック化の非同期メソッドとして実装する必要があります。実装では、コール側Webサービスのスレッドでの抽出の実行とは異なり、各コネクタ所有のスレッドで各ドメインのデータ抽出が実行される必要があります。
エンジンは、ExtractDomains
APIをコールするときに次の処理を実行します。
このAPIをコールする前に、指定の同期化セッションでInitializeUserSyncSession
へのコールが正常に実行されたことを確認します。
すべてのコネクタから取得したExtractResponse
を分析して競合を解決し、他のPIMコネクタを介して作成、読取り、更新および削除操作を他のPIMサーバーにプッシュします。
システムからエクスポートされて別のシステムにインポートされたPIMレコードのマッピングを保守します。
コネクタから提供されたExtractResponse
が非同期で処理されたことを確認します。
指定のユーザーおよび同期化セッションでコネクタが使用するコネクタ・ランタイム・ライブラリURLを提供します。コネクタでは、このメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合、提供されたURLを使用する必要があります。同じ同期化セッション中は、コネクタへの後続の各コールで同じURLが提供されます。
コネクタ名を提供します。コネクタでこのメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたconnectorName
を使用する必要があります。
注意:
|
コネクタでは、ExtractDomains
APIに対して次のようにレスポンスします。
指定のPIMユーザーIDおよびPIMドメイン・ターゲットのドメインに属するPIMストアから、前回の同期状態以降のすべてのレコードを抽出します。コネクタ実装では、個々のスレッドで指定のドメイン配列内の各ドメインを抽出し、指定のHubContext
構造に含まれるコールバックURLを使用してエンジンへの非同期コールバックを実行する必要があります。ExtractResponse
に次のタイプの更新済PIMレコードを含めることはできません。
PIMドメイン・ターゲットが同じで、ドメインに含まれていないレコードは無視されます。たとえば、Exchangeの電子メール・アイテム(IPM.Note
ドメイン)が「Task」フォルダ(IPM.Task
)に存在することは可能です。この場合、Exchange 2007コネクタは、Task
を抽出するときにIPM.Note
アイテムを無視する必要があります。
PIMフィルタ条件によってフィルタで除去されたすべてのレコード。
リクエストで指定したハブ・ドメインごとに、ExtractResponse
をハブに提供します。前回の同期状態以降に変更されたPIMレコードごとに、変更済PIMレコードのハブ表現が含まれたUpsertRecordが1つ存在する必要があります。また、前回の同期状態以降にPIMサーバーから削除されたレコードごとに、PIMレコードIDが1つ存在する必要があります。
各コネクタには、「Extract Response Batch Size」というBDSSプロファイル・パラメータ構成があります。このパラメータの値には、各ExtractResponse
が保持できるレコードの最大数が格納されます。コネクタは、一連のExtractResponse
(各ExtractResponse
にはこの最大数のレコードが含まれる)を提供するように記述する必要があります。エンジンは、これらのバッチの受信を使用して、コネクタの異常終了などのコネクタ障害の判断に使用する内部タイムアウトをリセットします。たとえば、コネクタで5,000件のカレンダ・レコードを抽出する必要があり、コネクタの構成済バッチ・サイズが100の場合、コネクタはエンジンへのコールバックを少なくとも50回実行します。
注意: Oracle Fusion Middleware 11gリリース2では、BDSSは1つのハブ・ドメインに対して複数の |
抽出されたレコードごとにPIMレコード説明を作成します。
レコードの抽出に失敗すると、コネクタは抽出を終了し、ExtractDomainResultsCallback
APIを介してハブに通知します。コネクタでは、エラーを示す結果コードを設定してエラー発生を示し、ハブで障害に関する情報を記録できるようにエラー説明文を提供する必要があります。
PIMフィルタ条件定義に示すように、コネクタでは、抽出された各レコードに対する構成済フィルタを評価し、レコードの同期化が必要かどうかを判断する必要があります。
注意: Oracle Fusion Middleware 11gリリース2のBDSSでは、コネクタのソフトウェア・コードに、PIMフィルタ条件との比較に使用するPIM日付フィールドを含める必要があります。比較で使用するPIM日付フィールドの値が含まれていないPIMレコードは、ExtractResponseに含める必要があります。 |
コネクタでフィルタを適用する方法の詳細は、第D.2.2.3.3項「不正なレコードのダウンロードの防止」を参照してください。
コネクタは、抽出されたすべてのインバウンド・レコードを、ネイティブPIM API書式から、PIMドメインに対して定義したPIM XMLスキーマ(XSDファイル)に準拠したXMLメッセージに変換する必要があります。PIM XMLメッセージが作成された後、コネクタはXSL変換を使用して、そのPIM XMLメッセージを、提供されたハブXMLスキーマ(XSD)に準拠したハブXMLメッセージに変換する必要があります。コネクタでは、どのPIMフィールドがどのハブPIMにマップされているか、またはデータがどのように変換されるか不明であるため、PIM API書式からハブXML書式への直接変換はできません。第8.1項「データ変換の概要」を参照してください。
エコーの抑制を実行し、ExtractDomainResultsCallback API
を介してレコード・セットをハブに提供する前に、PIMサーバーから抽出したレコードのコレクションからすべてのエコーを削除します。すべてのエコーが削除された場合、コネクタは、エコーのないレコード・セットをエンジンに提供するときに、ExtractResponseMetadata
のechoesSuppressed
フラグ・メンバーをTRUE
に設定する必要があります。
コネクタによっては、BDSSコール間で状態を保持することが必要になる場合があります。コネクタは、状態を保持するかどうかに関係なく、同期状態の保存に関連したBDSSとの規定事項を満たす必要があります。このため、ステートフルおよびステートレスのコネクタの同期状態を簡単に保存するために、次のAPIが提供されています。
ステートレスのコネクタは、PIMサーバーから変更済レコードの最終バッチを収集すると同時に、そのバッチをBDSSに提供する前に、CacheTempSyncState
を介して同期状態をキャッシュする必要があります。ハブでは、ドメインの同期化が完了すると、EndDomainSynchronization
をコールし、同期状態を保存する必要があるかどうかを指示します。その場合、コネクタはCommitCachedSyncState
をコールして、キャッシュされた同期状態をコミットする必要があります。
コネクタがBDSSコール間で状態情報を保持している場合は、BDSSがEndDomainSynchronization
をコールして同期状態を保存する必要があることを指示すると、そのコネクタはSaveSyncState
APIのみを使用して同期状態を直接保存します。
削除の検出。
ハブでは、コネクタでの削除操作について次の2つのユースケースがサポートされています。
ユースケース1: コネクタはネイティブで削除操作を検出できません。この場合、コネクタは、指定のユーザーおよびドメインのすべてのPIMレコードIDを含めた配列を作成することによって、PIMサーバーから削除されたレコードを判別できます。(この配列には、変更済および未変更のレコードのレコードIDを含める必要があります。)コネクタは、このレコードIDの配列をコネクタ・ランタイム・インタフェース・メソッドGetDeletesByIds
に提供し、削除されたレコードを識別するレコードIDの配列を取得できます。次に、コネクタは、これらのレコードIDをExtractResponse
のExtractResponseData
メンバーのdeleteRecordIdArray
に追加できます。コネクタですべてのレコードIDを問い合せることができない場合、そのコネクタは削除操作を同期化できません。
ユースケース2: 次の同期化セッションの前にBDSSで作成されたレコードをエンド・ユーザーが削除すると、コネクタではネイティブでそのレコードの削除を検出できません。
PIMから正常にエクスポートされたレコードは同期状態によって追跡されるため、PIMストアからエクスポートされる直前に作成されたレコードがストアから削除されると、コネクタによってはその削除を検出できない場合があります(つまり、そのレコードはストアにインポートされたがエクスポートされなかったため、同期状態ではその削除を検出できません)。
このユースケースは、エンド・ユーザーがPIMでレコードを作成して削除した場合、つまり、両方の操作が同期化セッションの有効範囲外で発生した場合も同様です。たとえば、BDSSの同期化が5分ごとに発生する場合、その5分が経過する前に、ユーザーがOutlookを使用してExchangeにレコードを作成して削除したとします。そのユーザーが同期化されると、同期状態では、作成されて削除されたレコードとして取得されません。つまり、同期状態は必ずしもPIMストアで実行された操作の履歴レコードではありません。BDSSのコンテキストとの違いは、レコード作成を実行するのがBDSSであることのみです。
コネクタでこの機能を利用するには、エコーを識別できる必要があります。この場合、コネクタでは、エコーの抑制を実行するため、そのエコーを識別するPIMレコードIDが含まれる配列を作成し、GetDeletesByPendingCreateEchoes
をコールして削除済レコードのレコードIDを取得します。次に、コネクタは、これらのレコードIDをExtractResponse
のExtractResponseData
メンバーのdeleteRecordIdArray
に追加できます。
このAPIは非同期です。コネクタ実装では、リクエストの前処理を可能なかぎり少なくして、制御をハブに返す必要があります。つまり、このAPIでは、抽出リクエスト(またはリクエストに関するメタデータ)をコネクタ所有のスレッドにポストした後に、制御をハブに返す必要があります。この方法によって、時間がかかるPIMデータ抽出操作はコネクタ所有のスレッドで実行されます。コネクタでは、Webサービス・コールを正常に受信すると、例外のスローが可能になります。ただし、例外は、前処理に失敗した場合のみスローする必要があります。APIが戻った後、抽出を実行するスレッドは、ExtractDomainResultsCallback
APIを介して、成功か失敗かを示す各ハブ・ドメインのExtractResponse
をハブに提供する必要があります。
コネクタでコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたRTL(ランタイム・ライブラリ)URLとコネクタ名を使用します。RTL URLとコネクタ名は両方とも、HubContext
構造で提供されます。
戻り値
void
例外
コネクタで抽出リクエストをコネクタ所有のスレッドにポストできない場合、そのコネクタは例外をスローして問題を特定するメッセージを提供する必要があります。この処理によって、BDSSではそのメッセージを記録できます。
この項では、ExtractDomainsに関するベスト・プラクティスについて説明します。トピックは次のとおりです。
変更が存在しない場合にPIM抽出操作を実行すると多くのリソースと時間が使用されるため、コネクタでは、指定のドメインに抽出が必要な変更が存在するかどうかを事前に判別する必要があります。たとえば、エンジンがコネクタをコールしてドメインを抽出する場合、コネクタでは、変更がないことを確認するためにのみ、ユーザーをコネクタ・アプリケーションに関連付けて多数のMAPIリソースを割り当てます。より効率的に処理するには、コネクタで、前回の同期状態以降の変更を問い合せるWebDAVリクエストをExchangeサーバーに発行する機能のみを備えたアプリケーションをユーザーに関連付けます。
コネクタでは、PIMフィールド定義およびその他のドメイン関連の構成情報をコネクタ・ランタイム・インタフェース・メソッドGetPimDomainMetadata
を介して取得し、それらを抽出サイクルで使用できるようにキャッシュする必要があります。
カレンダ・ドメインおよびタスク・ドメインを抽出するときは、pimFilterCondition
を適用して、フィルタの基準を満たさないレコードがサーバーからダウンロードされるのを防ぎます。たとえば、コネクタでは、最初に変更済レコードをすべてサーバーからダウンロードし、次にすべてのレコードをフィルタと照合して評価し、抽出結果セットに含めるかどうかを判断する強制的な方法を実行することも可能です。さらに効率的な方法は、フィルタを適用して、そのようなレコードがPIMサーバーからダウンロードされるのを防ぐことです。たとえば、MAPI制限構成をExchange 2007コネクタで使用して、古いレコードがダウンロードされるのを防ぎます。
ハブでは、このEndDomainSynchronization
インタフェースをコールして、指定ユーザーのドメインの同期化を終了します。このインタフェースをコールすると、ユーザーのハブ・ドメインの同期化セッションを正常に(または強制的に)終了できます。
表D-4 EndDomainSynchronization APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
[in] |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
コネクタが指定の同期化セッションで使用する、コネクタ・ランタイム・インタフェースへのURLが格納されます。 |
|
String |
[in] |
ハブ・ドメインを識別します。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
Boolean |
[in] |
コネクタで同期状態を保存する必要があるかどうかを示すブール値。 |
|
Integer |
[out] |
特定の同期化セッションで、指定のドメインおよびユーザーについてコネクタがハブに正常に送信したバッチの数が格納されます。Oracle Fusion Middleware 11gリリース2のBDSSでは、このパラメータは0または1のいずれかです。 |
エンジンは、EndDomainSynchronization
APIをコールするときに次の処理を実行します。
指定のドメインの処理の最後にこのメソッドをコールします。
コネクタで同期状態を保存する必要があるかどうかを示します。次の場合は、フラグをFalse
に設定します。
現在の同期化セッション中にドメインが抽出されなかった場合。
ドメインが抽出され、コネクタでレコードを含まないExtractResponse
が提供され、echoesSuppressed
フラグがfalseの場合。この場合、抽出されたレコードはありません(エコーまたはエコー以外)。
注意: コネクタは、 |
extractResponseCount
を使用して、エラー発生時にハブで受信したExtractResponse
をクリーン・アップします。
指定のユーザーおよび同期化セッションでコネクタが使用するコネクタ・ランタイム・ライブラリURLを提供します。コネクタでは、このメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合、提供されたURLを使用する必要があります。
コネクタ名を提供します。コネクタでこのメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたconnectorName
を使用する必要があります。
エンジンでEndDomainSynchronization
APIがコールされると、コネクタでは次のようにレスポンスします。
ユーザーに関連するドメイン・レベルのリソースをクリーン・アップします(該当する場合)。
saveSyncState
がtrue
の場合、ExtractDomains APIの「コネクタ規定」の項で説明したように、コネクタは、コネクタ・ランタイム・インタフェースAPIを介してドメインの同期状態をハブ・データ・ストアに保存します。
ハブでこのAPIをコールして同期化セッションを強制的に終了する場合でも、ハブに送信するExtractResponse
がないことを確認します。
extractResponseCount
に、指定の同期化セッションでハブに正常に送信されたExtractResponse
の正しい数が常に移入されていることを確認します。
コネクタでコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたRTL(ランタイム・ライブラリ)URLとコネクタ名を使用します。
注意: コネクタが認識していないユーザー・セッションでハブがコネクタをコールした場合、そのコネクタはこのコールで空操作(操作なし)を実行する必要があります。これは、他のコネクタの障害によってハブが同期化セッションを終了する場合などに発生する場合があります。これによって、ハブで同期化セッションを急に終了する必要が生じた場合のハブ・ロジックが簡略化されます。 |
戻り値
Integer
SUCCESS/OKの場合は0
ERROR/NOTOKの場合は0以外
エンジンは、指定したユーザーの全ドメインの同期化の終了時にEndUserSyncSession
インタフェースをコールして、指定したsyncSessionId
で識別される同期化セッションを終了します。コネクタ実装では、この時点を利用して、指定のユーザーに関連付けられたユーザー固有のリソースを解放できます。表D-5に、EndUserSyncSession
インタフェースのパラメータを示します。
表D-5 EndUserSyncSession APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
[in] |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
コネクタが指定の同期化セッションで使用する、コネクタ・ランタイム・インタフェースへのURLが格納されます。 |
|
String |
[in] |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
エンジンは、EndUserSyncSession
APIをコールするときに次の処理を実行します。
同じユーザーに対しては、別の同期化セッションが開始されるまでコネクタをコールしません。
このAPIをコールして、指定のsyncSessionId
で識別される同期化セッションを終了します。
指定のユーザーおよび同期化セッションでコネクタが使用するコネクタ・ランタイム・ライブラリURLを提供します。コネクタでは、このメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合、提供されたURLを使用する必要があります。
コネクタ名を提供します。コネクタでこのメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたconnectorName
パラメータを使用する必要があります。
エンジンでEndUserSyncSession
APIがコールされると、コネクタでは次のようにレスポンスします。
ユーザーに関連するすべてのリソースをクリーン・アップします。
コネクタでコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたRTL(ランタイム・ライブラリ)URLとコネクタ名を使用します。
戻り値
Integer
SUCCESS/OKの場合は0
ERROR/NOTOKの場合は0以外
注意: コネクタが認識していないユーザー・セッションでハブがコネクタをコールした場合、そのコネクタはこのコールで空操作(操作なし)を実行する必要があります。これは、他のコネクタの障害によってハブが同期化セッションを終了する場合などに発生する場合があります。これによって、ハブで同期化セッションを終了する必要が生じた場合のハブ・ロジックが簡略化されます。 |
ハブでは、PIMでレコードを作成する必要がある場合、常にCreateRecord
インタフェースをコールします。表D-6に、CreateRecord
インタフェースのパラメータを示します。
注意: ドメインが抽出されていない場合でも、ハブではこのAPIをコールできます。 |
表D-6 CreateRecord APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
[in] |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
コネクタがランタイム・ライブラリをコールするときに指定の同期化セッションで使用する、コネクタ・ランタイム・インタフェースへのURLが格納されます。 |
|
String |
[in] |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
|
[in/out] |
入力時に、ハブ・レコードがハブXML書式で格納されます。
|
エンジンは、CreateRecord
APIをコールするときに次の処理を実行します。
エンジンでは、このコネクタAPIコールから戻された後に、UpsertRecord
の提供されたRecordMetadata
メンバーに含まれる次のデータでデータ・ストアを更新する必要があります。
PIMレコードID
PIMレコード・バージョンID
PIMレコード関連データ(提供された場合)
PIMレコード説明(提供された場合)
レコードが正常に作成された場合、エンジンでは、メタデータが格納されるようにハブ・データ・ストアを更新するのに加えて、ストア内の指定の行のechoPending
フラグをTRUE
に設定する必要があります。
指定のユーザーおよび同期化セッションでコネクタが使用するコネクタ・ランタイム・ライブラリURLを提供します。コネクタでは、このメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合、提供されたURLを使用する必要があります。
コネクタ名を提供します。コネクタでこのメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたconnectorName
を使用する必要があります。
エンジンでCreateRecord
APIがコールされると、コネクタでは次のようにレスポンスします。
PIMストアにレコードを作成し、表D-6に示すメタデータを提供します。
ハブ書式のXMLメッセージを、PIMサーバーでのレコードの作成に適した書式に変換します。
コネクタでコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたRTL(ランタイム・ライブラリ)URLとコネクタ名を使用します。
戻り値
Integer
SUCCESS/OKの場合は0
ERROR/NOTOKの場合は0以外
エンジンは、PIMサーバーでレコードを更新する必要がある場合、常にUpdateRecord
インタフェースをコールします。表D-7に、UpdateRecord
メソッドのパラメータを示します。
注意: ドメインが抽出されていない場合でも、ハブではこのAPIをコールできます。 |
表D-7 UpdateRecord APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
[in] |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
コネクタがランタイム・ライブラリをコールするときに指定の同期化セッションで使用する、コネクタ・ランタイム・インタフェースへのURLが格納されます。 |
|
String |
In |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
|
In |
ハブ・レコード、および更新されるレコードに関してハブ・データ・ストアから取得されるメタデータが格納されます。
|
|
|
Out |
出力時に、次の内容を含む更新済レコード・メタデータがPIMレコードから取得されて格納されます。
|
エンジンは、UpdateRecord
APIをコールするときに次の処理を実行します。
エンジンは、抽出レスポンスの評価時に検出された競合を解決するときに次の処理を実行します。
更新/更新競合の場合、ハブでは、非優先コネクタでこのAPIをコールしたときに抽出されたレコードで提供されるAssociatedDataではなく、BDSSストアからのAssociatedData
を非優先コネクタに提供する必要があります。
作成/作成競合の場合、ハブでは、非優先コネクタでこのAPIをコールしたときにその非優先コネクタから抽出されたレコードで提供されるAssociatedData
を使用する必要があります。
レコードが正常に更新された場合、エンジンでは、メタデータが格納されるようにデータ・ストアを更新するのに加えて、ストア内の指定の行のechoPending
フラグをFALSE
に設定する必要があります。
指定のユーザーおよび同期化セッションでコネクタが使用するコネクタ・ランタイム・ライブラリURLを提供します。コネクタでは、このメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合、提供されたURLを使用する必要があります。
コネクタ名を提供します。コネクタでこのメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたコネクタ名を使用する必要があります。
エンジンでUpdateRecord
APIがコールされると、コネクタでは次のようにレスポンスします。
PIMサーバーで指定のPIMレコードIDによって識別されるレコードを更新し、RecordMetaData構造を移入します。
BDSSによる抽出の後、コネクタによる更新の処理の前にPIMサーバーでレコードが削除された場合、コネクタでは、レコードが削除されたために更新が無視されたことを示すログ・メッセージを提供する必要があります。(後続の抽出サイクルでは、削除操作を検出してエンジンに伝播する必要があります。)
アウトバウンド更新のプッシュ直前にPIMレコードが変更された場合に発生する競合をPIM APIで検出した場合、コネクタではその競合を「BDSS優先」方式で解決します(つまり、BDSSがコネクタに提供したレコードによって、エンド・ユーザーの変更が上書きされます)。
コネクタでコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたRTL(ランタイム・ライブラリ)URLとコネクタ名を使用します。
戻り値
Integer
SUCCESS/OKの場合は0
ERROR/NOTOKの場合は0以外
エンジンは、PIMサーバーからレコードを削除する必要がある場合、常にDeleteRecord
APIをコールします。表D-8に、DeleteRecord
メソッドのパラメータを示します。
注意: ドメインが抽出されていない場合でも、ハブではこのAPIをコールできます。 |
表D-8 DeleteRecord APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
[in] |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
コネクタがコネクタ・ランタイム・ライブラリをコールするときに指定の同期化セッションで使用する、コネクタ・ランタイム・インタフェースへのURLが格納されます。 |
|
|
String |
[in] |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
削除するレコードのPIMレコードIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
PIMレコード説明 |
In |
PIMレコード説明が格納されます。 |
エンジンは、DeleteRecord
APIをコールするときに次の処理を実行します。
指定のユーザーおよび同期化セッションでコネクタが使用するコネクタ・ランタイム・ライブラリURLを提供します。コネクタでは、このメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合、提供されたURLを使用する必要があります。
コネクタ名を提供します。コネクタでこのメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたconnectorName
パラメータを使用する必要があります。
エンジンでDeleteRecord
APIがコールされると、コネクタでは次のようにレスポンスします。
指定のPIMレコードIDで識別されるレコードをPIMで削除します。
コネクタでは、PIMレコード関連データが必要な場合、コネクタ・ランタイム・インタフェース・メソッドGetRecordAssociatedData
を介してこのデータを取得できます。ほとんどのPIMサーバーでは、PIMレコードIDのみ必要です。
削除がPIMに送信される前にPIMレコードが削除された場合は、エラー以外のコードを返します。コネクタでは、レコードがすでに削除されていたために削除に失敗したことを示すメッセージを記録できます。
コネクタでコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたRTL(ランタイム・ライブラリ)URLとコネクタ名を使用します。
戻り値
Integer
SUCCESS/OKの場合は0
ERROR/NOTOKの場合は0以外
ハブでは、GetPimServerEndPoint
インタフェースをコールして指定の同期化対応ユーザーのPIMサーバー・エンドポイントを取得し、返されたendPointToken
を使用して、同期化セッション中にユーザーを同期化するときにコネクタのクラスタ内のどのコネクタ・インスタンスをコールするかを決定します。表D-9に、GetPimServerEndPoint
インタフェースのパラメータを示します。
表D-9 GetPimServerEndPointインタフェースAPIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
[in] |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
[in] |
コネクタがコネクタ・ランタイム・ライブラリをコールするときに指定の同期化セッションで使用する、コネクタ・ランタイム・インタフェースへのURLが格納されます。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
Out |
出力時に、コネクタ定義のエンドポイント・トークンが格納されます。このパラメータは、NULLにできます。また、空にもできます。 |
|
Boolean |
Out |
出力時に、受信コネクタが指定のユーザーを同期化できるかどうかを示します。 |
ハブでは、ユーザーのPIMサーバー・エンドポイントを取得する必要がある場合のみ、GetPimServerEndPoint
APIをコールします。ハブでは、このAPIをコールするときに次の処理を実行します。
構成メタデータ、および返されたendPointToken
とcanSyncUser
を使用して、指定のユーザーを抽出するためにコールするコネクタを決定します。ハブでは、最初にendPointToken
をチェックします。endPointToken
値がNULL以外の空でない文字列の場合、ハブではそのendPointToken
値を使用して、ユーザーの同期化に使用するコネクタURLを取得します。NULLまたは空の場合、ハブではブール値をチェックして、そのブール値を返した受信コネクタがユーザーの同期化に使用できるかどうかを判断します。
指定のユーザーおよび同期化セッションでコネクタが使用するコネクタ・ランタイム・ライブラリURLを提供します。コネクタでは、このメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合、提供されたURLを使用する必要があります。
コネクタ名を提供します。コネクタでこのメソッドの実装の一環としてコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたconnectorName
を使用する必要があります。
GetPimServerEndPoint
APIを受信するコネクタでは、次の処理を実行します。
指定のユーザーに対してPIMサーバー・エンドポイントを解決します。コネクタで指定のユーザーを解決できない場合は、エラーを返す必要があります。
注意: 受信コネクタ・インスタンスは、ユーザーの同期化を実行するインスタンスと異なる(クラスタは同じでも)場合があります。 |
PIMサーバー・エンドポイント値(endPointToken
)は、コネクタ実装詳細です。管理者がURLをエンドポイントに正しくマップできるように、開発者はPIMサーバー・エンドポイント値を文書化する必要があります。たとえば、Exchangeの場合、コネクタでは指定のユーザー・メールボックスをホストするExchangeサーバーのNetBios名を返します。このため、管理者はExchangeサーバーのこれらのNetBios名をクラスタURLにマップする必要があります。
コネクタでコネクタ・ランタイム・ライブラリをコールする必要がある場合は、提供されたRTL(ランタイム・ライブラリ)URLとコネクタ名を使用します。
戻り値
Integer
SUCCESS/OKの場合は0
ERROR/NOTOKの場合は0以外
エンジン・コールバック・インタフェースは単一のメソッドExtractDomainResultsCallback
で構成されたWebサービスベースのインタフェースで、ハブにExtractResponseを提供するときにコネクタでコールされます。
ExtractDomainResultsCallback
APIは非同期で、エンジンが指定のExtractResponse
で提供される情報をキューに入れた直後にコール側コネクタに戻ります。表D-10に、ExtractDomainResultsCallback
メソッドのパラメータを示します。
コネクタでは、エンジンのExtractDomainResultsCallback
APIコールのレスポンスとして、次の処理を実行します。
コネクタでは、PIMからレコードを抽出して指定のExtractResponse
を作成するとき、このAPIをコールする前にすべてのエコーをレスポンスから削除する必要があり、エコーが削除されている場合はechoesSuppressed
フラグをtrue
に設定する必要があります。
コネクタでは、ExtractResponse
の順序番号を指定する必要があります。1番目の抽出レスポンスは1に、2番目は2のように番号を付けます。Oracle Fusion Middleware 11gリリース2のBDSSでは、順序番号は常に1です。
戻り値
void
コネクタ・ランタイム・インタフェースは、コネクタがハブ・データ・ストア内の特定のメタデータ(AssociatedData
など)にアクセスできる、WebサービスベースのAPIです。このインタフェースは、同期状態の保存など、すべてのコネクタに共通のサービスを提供します。
コネクタ作成者はこのインタフェースを実装しません。コネクタ実装はこのインタフェースのコンシューマです。
通常、すべてのAPIは整数を返して成功(0)または失敗(0以外)を示します。すべてのAPIでは、リカバリ不能なエラー(BDSSストアに対する読取りや書込みが不可、不正なパラメータなど)が発生すると、RemoteException
をスローできます。開発者は、例外およびAPIコール全体の成功を判断するための戻り値を考慮してコネクタを記述する必要があります。
コネクタでは、GetPimRecordVersions
メソッドを使用して、BDSSデータ・ストアに格納されている1つ以上のPIMレコードのPIMレコード・バージョンIDを取得できます。この情報を取得すると、コネクタでは、BDSSが正常に同期化したPIMレコード(1つまたは複数)の最新バージョンを判別できます。
表D-11 GetPimRecordVersions APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String [] |
In |
コネクタでバージョンIDを取得するPIMレコードIDの配列が格納されます。 |
|
String [] |
Out |
出力時に、
同期化セッションが障害なしで完了すると、空でないバージョンIDが
|
戻り値
Integer
SUCCESS/OKの場合は0
ERRORの場合は0以外
例外
リカバリ不能なエラーが発生した場合は、RemoteException
がスローされます。
CacheTempSyncState
メソッドは、指定の同期状態をBDSSストアの一時的なデータ格納場所に保存します。状態を保持しないコネクタでは、指定のドメインのPIMデータを抽出した後、最新の一連のレコードをBDSSに提供する前に、このメソッドをコールします。
表D-12 CacheTempSyncState APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMドメイン・ターゲットが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
指定のユーザー、ドメイン、ドメイン・ターゲットおよびサーバー・タイプについてキャッシュされる同期状態が格納されます。 |
戻り値
Integer
SUCCESS/OKの場合は0
ERRORの場合は0以外
例外
リカバリ不能なエラーが発生した場合は、RemoteException
がスローされます。
CommitCachedSyncState
メソッドは、BDSSストア内の一時的な格納場所にすでに保存されている同期状態を、BDSSストア内の永続的な格納場所に保存します。これは、BDSSコール間で状態情報を保持できないコネクタで使用することを目的にしています。
コネクタでは、このメソッドをコールする前に、同じ同期化セッション内でCacheTempSyncState
を正常にコールしている必要があります。通常、ステートレス・コネクタでは、特定のドメインのデータ抽出が完了する直前にCacheTempSyncState
をコールします。次に、ハブでEndDomainSynchronization
をコールするときにこのメソッドをコールして、同期状態を保存する必要があることを示します。表D-13に、CommitCachedSyncState
メソッドのパラメータを示します。
表D-13 CommitCachedSyncState APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMドメイン・ターゲットが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
戻り値
Integer
SUCCESS/OKの場合は0
ERRORの場合は0以外
例外
リカバリ不能なエラーが発生した場合は、RemoteException
がスローされます。
コネクタでは、GetConfigurationMetaData
APIをコールして、プロファイル構成メタデータを取得します。1つのプロファイルには1つ以上のセクションがあります。各セクションには1つ以上のパラメータがあり、各パラメータには1つの値が含まれます。プロファイルは、概念的にはWindowsの.ini
構成ファイルと同じです。BDSSコネクタでは、独自のプロファイルを定義して、コネクタに固有のメタデータを格納できます。表D-14に、GetConfigurationMetaData
メソッドのパラメータを示します。
表D-14 GetConfigurationMetaData APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
ConfigurationProfile [] |
In/Out |
入力時に、取得されるプロファイル・メタデータが移入されるConfigurationProfile構造が格納されます。出力時に、リクエストされたプロファイル・メタデータが含まれるように配列が更新されます。 |
GetConfigurationMetaData
APIを使用すると、コネクタでは、1回のコールで複数のプロファイル間の任意の構成メタデータを取得できます。コネクタでconfigMetadataArray
パラメータを作成および移入し、そのコネクタで取得する内容を指定すると、APIではリクエストされた構成(構成が存在する場合)をconfigMetadataArray
に移入します。
基本的に、コネクタでは、ConfigurationProfile構造の配列を作成し、取得する構成のスコープを指定する方法で移入し、GetConfigurationMetaData
APIによって構造の移入を完了します。スコープの指定は、プロファイル、セッションまたはパラメータ・ベースで実行できます。たとえば、コネクタでプロファイルのセクション全体が必要な場合は、ConfigurationProfile
構造を作成し、目的のプロファイル名とセクション名のみを指定して、そのConfigurationProfile
をconfigMetadataArray
に追加します。同様に、コネクタでプロファイルのセクションの1つのパラメータが必要な場合は、プロファイル名、セクション名およびパラメータ名を指定したConfigurationProfile
を作成してconfigMetadataArray
に追加します。
表D-15に、コネクタでconfigMetadataArray
を作成して構成メタデータを取得する方法、およびGetConfigurationMetaData
APIによってconfigMetadataArray
を更新する方法について、共通のユースケースを示します。
表D-15 ConfigMetadataArrayのユースケース
ユースケース | コネクタによるconfigMetadataArray [in]の作成 | APIによるconfigMetadataArray[out]の更新 |
---|---|---|
特定のプロファイルにある特定のセクションの特定のパラメータ値を取得します。 スコープは |
配列のサイズは1で、次のように移入される単一の
|
|
プロファイル内のセクションのパラメータの名前と値を取得します。スコープは |
配列のサイズは1で、次のように移入される単一の
配列のサイズは1で、次のように移入される単一の
|
|
プロファイル内のすべてのセクションのパラメータの名前と値を取得します。スコープは |
配列のサイズは1で、次のように移入される単一の
NULL |
各 |
複数のプロファイル内のすべてのセクションのパラメータの名前と値を取得します。 スコープは |
配列は |
|
戻り値
Integer
SUCCESS/OKの場合は0
ERRORの場合は0以外
GetConfigurationMetaData
APIがエラーを返すのは、ストアが使用不可、メモリー不足など処理が中断される状況が発生したためにBDSSストアからメタデータを取得できなかった場合のみです。特定の構成値、セクションまたはプロファイルを取得できなかった場合は、エラーを返しません。コネクタでは、特定の構成メタデータ値の取得に失敗した場合、実際に障害が発生しているかどうかを判断します。たとえば、コネクタで、コネクタ・プロファイルの1つのセクションから抽出レスポンス・バッチ・サイズを取得するとします。不要なイベントは発生せず、カスタマがこの値の構成に失敗すると、このAPIはSUCCESS/OKエラー・コードを返し、対応する値はそのままにします。(つまり、抽出レスポンス・バッチ・サイズに設定したコネクタ構成値に応じて、値はNULLまたは空にできます。)この時点で、コネクタは構成エラーの重大度を判断して適切に処理します。たとえば、コネクタ機能を停止するようなリカバリ不能なエラーとみなさない場合は、エラーまたは警告を記録してデフォルト値を使用できます。また、エラーまたは警告を記録して、リカバリ不能なエラーとみなすこともできます。
例外
リカバリ不能なエラーが発生した場合は、RemoteException
がスローされます。
現在の同期化セッションでハブでレコードが作成された後、次の同期化セッションの前に削除操作が発生した場合、コネクタでは、ハブで作成されたレコードの削除をネイティブで検出できない場合にGetDeletesByPendingCreateEchoes
APIをコールします。表D-16に、GetDeletesByPendingCreateEchoes
APIのパラメータを示します。
表D-16 GetDeletesByPendingCreateEchoes APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String [] |
In |
エコーをそれぞれ識別するPIMレコードIDの配列が格納されます。このパラメータは、NULL以外である必要があります。配列の長さは1以上である必要があります。ハブでは、PIMレコードIDが空の文字列または-1のエントリは無視します。コネクタにエコーが存在しない場合でも、配列を提供する必要があります。PIMレコードIDとして空の文字列を格納する配列のサイズは1にすることをお薦めします。 |
|
String [] |
In |
前回の同期状態以降にPIMで更新または作成されたレコードをそれぞれ識別するPIMレコードIDが格納されます。NULL以外である必要があります。配列の長さは1以上である必要があります。ハブでは、PIMレコードIDが空の文字列または-1のエントリは無視します。コネクタにアップサート・レコードが存在しない場合でも、PIMレコードIDとして空の文字列が格納された配列(配列のサイズは1を推奨)を提供する必要があります。 |
|
String [] |
Out |
出力時に、PIMから削除済と識別された各レコードのPIMレコードIDが格納されます。削除操作が検出されなかった場合、返される配列はNULLです。 |
戻り値
Integer
SUCCESS/OKの場合は0
ERROR/NOTOKの場合は0以外
例外
リカバリ不能なエラーが発生した場合は、RemoteException
がスローされます。
コネクタでは、PIMサーバーからの削除をネイティブで検出できない場合、GetDeletesBylds
メソッドをコールします。このメソッドは、前回に同期化された指定のユーザー、ハブ・ドメインおよびコネクタ名について、PIMレコードIDのリストをハブ・ストアに問い合せます。次に、ハブ・ストア・ベースの配列をコネクタ提供の配列と比較して、削除されたレコードを識別するPIMレコードIDの配列を作成します。ハブ・ストア・ベースの配列にあり、コネクタが提供する配列にないPIMレコードIDは、削除されたとみなされます。表D-17に、GetDeletesByIds
メソッドのパラメータを示します。
表D-17 GetDeletesBylds APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
コネクタ名が格納されます。NULL以外で空でない必要があります。 |
|
String[] |
In |
指定のユーザー、ドメインおよびサーバー・タイプのすべてのPIMレコードのPIMレコードIDが格納された配列。このパラメータは、NULL以外である必要があります。PIMにPIMレコードが存在しない場合、コネクタでは、PIMレコードIDとして空の文字列が格納されたサイズ1の配列を提供する必要があります。 |
|
String[] |
Out |
出力時に、PIMから削除されたレコードを識別するPIMレコードIDの配列が格納されます。削除対象がない場合、返される配列はNULLです。 |
戻り値
Integer
SUCCESS/OKの場合は0
ERROR/NOTOKの場合は0以外
例外
リカバリ不能なエラーが発生した場合は、RemoteException
がスローされます。
コネクタでは、GetRecordAssociatedData
APIをコールして、レコードに関連付けられたPIMレコード関連データをハブ・データ・ストアから取得します。これは、コネクタでデータをPIMレコードに関連付けている場合に役立ちます。たとえば、コネクタでデータを各PIMレコードに関連付けると、エコー検出が容易になり、このAPIを使用してそのデータを取得できます。表D-18に、GetRecordAssociatedData
APIのパラメータを示します。
表D-18 GetRecordAssociatedData APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
In |
同期化セッションIDが格納されます。NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ドメインが格納されます。NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。NULL以外で空でない必要があります。 |
|
String |
In |
コネクタ名が格納されます。NULL以外で空でない必要があります。 |
|
String [] |
Out |
PIMレコード関連データを取得する各レコードのPIMレコードIDが格納された配列。このパラメータは、NULL以外でサイズが0より大きい必要があります。配列の各要素は、NULL以外で空でない必要があります。 |
|
String [] |
Out |
出力時に、この配列には、
|
|
String [] |
出力時に、成功またはエラー・コードで構成される配列です。この配列と
|
戻り値
Integer
SUCCESS/OK
の場合は0。すべてのAssociatedData
がデータ・ストアから読み取られた場合です。
ERROR/NOTOK
の場合は0以外。いずれかのAssociatedData
要素の読取りに失敗した場合です。コール元ではerrorArray
を検証して読取りが失敗した要素を判別し、コネクタではエラーの重大度を判断します。errorArray
のエラー・コードには、より明示的なエラー・コードを含めることができます。
例外
リカバリ不能なエラーが発生した場合は、RemoteException
がスローされます。
コネクタでは、GetSyncState
APIをコールして、ドメインに関連付けられたコネクタ定義の同期状態を取得します。このメソッドは、データ・ストアの永続的な格納場所に格納された同期状態のみを返します。永続的および一時的な同期状態の詳細は、「CacheTempSyncState API」、「CommitCachedSyncState Method API」および「SaveSyncState API」を参照してください。表D-19に、GetSyncState
APIのパラメータを示します。
表D-19 GetSyncState APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMドメイン・ターゲットが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
出力時に、指定のユーザー、ドメイン、ドメイン・ターゲットおよびサーバー・タイプの同期状態が格納されます。指定のユーザー、ドメイン、コネクタ名およびドメイン・ターゲットの同期状態が存在しない場合、戻り値はNULLです。 |
戻り値
Integer
SUCCESS/OKの場合は0
ERROR/NOTOKの場合は0以外
例外
リカバリ不能なエラーが発生した場合、または同期状態が存在しない場合は、RemoteException
がスローされます。
コネクタでは、GetUserAssociatedData
APIをコールして、ユーザー・レベルでコネクタ固有のPIMユーザー関連データを取得します。このAPIを使用すると、複数のスレッドで指定のユーザーの関連データにアクセスできます。表D-20に、GetUserAssociatedData
APIのパラメータを示します。
表D-20 GetUserAssociatedData APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
コネクタ定義のユーザー関連データの識別子の配列が格納されます。 |
|
関連データ[] |
Out |
出力時に、ユーザー固有の関連データが格納されます。この配列と |
|
Integer [] |
Out |
出力時に、PIMユーザー関連データの取得の成功または失敗を示すエラー・コードの配列が格納されます。 |
戻り値
Integer
SUCCESS/OKの場合は0(すべてのAssociatedData
要素がデータ・ストアから読み取られた場合です。)
ERROR/NOTOKの場合は0以外。いずれかのAssociatedData
要素の読取りに失敗した場合です。コール元ではerrArray
を検証して読取りが失敗した要素を判別し、コネクタではエラーの重大度を判断します。errArray
のエラー・コードには、より明示的なエラー・コードを含めることができます。
例外
リカバリ不能なエラーが発生した場合は、RemoteException
がスローされます。
BDSSコール間で状態を保持するコネクタでは、このAPIをコールして、ドメインに関連付けられたコネクタ定義の同期状態をハブ・ストアに保存する必要があります。状態を保持しないコネクタでは、CacheTempSyncState
およびCommitCachedSyncState
を使用して同期状態を保持する必要があります。表D-21に、SaveSyncState
APIのパラメータを示します。
表D-21 SaveSyncState APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMドメイン・ターゲットが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
指定のユーザー、ドメイン、ドメイン・ターゲットおよびサーバー・タイプの同期状態が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
戻り値
Integer
SUCCESS/OKの場合は0
ERROR/NOTOKの場合は0以外
例外
リカバリ不能なエラーが発生した場合は、RemoteException
がスローされます。
コネクタでは、setRecordAssociatedData
APIをコールして、コネクタ定義のPIMレコード関連データを指定のレコードに関連付けます。表D-22に、SetRecordAssociatedData
APIのパラメータを示します。
表D-22 SetRecordAssociatedData APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String [] |
In |
PIMレコード関連データがBDSSデータ・ストアに書き込まれるレコードのPIMレコードIDの配列。 |
|
関連データ[] |
In |
BDSSデータ・ストアに書き込まれる各レコードのPIMレコード関連データが格納された配列。 |
|
Integer [] |
Out |
出力時は、エラー・コードの配列です。この配列と |
戻り値
Integer
SUCCESS/OKの場合は0すべてのAssociatedData
要素がBDSSデータ・ストアに書き込まれた場合です。
ERROR/NOTOKの場合は0以外。いずれかのAssociatedData
要素の書込みに失敗した場合です。コール元ではerrorArray
を検証して書込みが失敗した要素を判別し、コネクタではエラーの重大度を判断します。
例外
リカバリ不能なエラーが発生した場合は、RemoteException
がスローされます。
コネクタでは、SetUserAssociatedData
APIをコールして、ユーザー・レベルのコネクタ固有のPIMユーザー関連データを保存します。このAPIを使用すると、複数のスレッドで指定のユーザーの関連データにアクセスできます。表D-23に、SetUserAssociatedData
APIのパラメータを示します。
表D-23 SetUserAssociatedData APIのパラメータ
パラメータ | データ型 | タイプ | 説明 |
---|---|---|---|
|
String |
In |
同期化セッションIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ドメインが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
ハブ・ユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
PIMユーザーIDが格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String |
In |
コネクタ名が格納されます。このパラメータは、NULL以外で空でない必要があります。 |
|
String [] |
In |
コネクタ定義のユーザー関連データの識別子の配列。 |
|
|
In |
ユーザー固有の関連データが格納されます。 |
|
Integer [] |
Out |
出力時に、ユーザー関連データの設定(BDSSストアに永続的に保持)の成功または失敗を示すエラー・コードの配列が格納されます。この配列、 |
戻り値
Integer
SUCCESS/OKの場合は0すべてのAssociatedData
要素がBDSSデータ・ストアに書き込まれた場合です。
ERROR/NOTOKの場合は0以外。いずれかのAssociatedData
要素の書込みに失敗した場合です。コール元ではerrArray
を検証して書込みが失敗した要素を判別し、コネクタではエラーの重大度を判断します。
例外
リカバリ不能なエラーが発生した場合は、RemoteException
がスローされます。
この項では、BDSSとコネクタの間で渡されるデータの構造について説明します。
共通構造にはKeyValuePair
構造が含まれます。
KeyValuePair
は、メタデータをキーと値の構造に保持するために使用する基本構造です。コネクタに対して定義されている他の多くのデータ構造で使用されます。表D-24に、KeyValuePair
構造のメンバーを示します。
コネクタ・インタフェース関連の構造は次のとおりです。
DomainInfo
構造には、同期化セッションでコネクタがユーザーに対して初期化を実行するために必要なドメイン情報が格納されます。この構造は、ハブでコネクタのInitializeUserSyncSession
APIをコールした場合のみ使用されます。表D-25に、DomainInfo
構造のメンバーを示します。
表D-25 DomainInfoデータ構造のメンバー
メンバー | データ型 | 説明 |
---|---|---|
|
String |
PIMドメイン・ターゲットが格納されます。NULL以外である必要があります。空にはできます。 このメンバーの詳細は、第D.1.5項「PIMドメイン・ターゲット」を参照してください。 |
|
String |
ドメイン抽出に適用されて、抽出に含まないレコードを除外するPIMフィルタ条件が格納されます。このメンバーは、NULL以外である必要があります。空にはできます。 |
|
String |
ハブ・ドメインを識別します。このメンバーは、NULL以外で空でない必要があります。 |
|
String |
ドメインのPIM同期状態が格納されます。このメンバーは、NULL以外である必要があります。このメンバーは空にできます。 |
BDSSでExtractDomains
APIを介してユーザーの抽出を開始すると、ExtractRequest
構造がコネクタに渡されます。表D-26に、ExtractRequest
構造のメンバーを示します。
ExtractResponse
構造は、コネクタでエンジン・コールバック・インタフェースのExtractDomainResults
コールバック・メソッドを介してレコード・データおよびステータス情報をエンジンに伝播するために使用します。表D-27に、ExtractResponse
構造のメンバーを示します。
ExtractResponseData
構造には、PIMサーバーから抽出されたレコードが格納されます。表D-28に、ExtractResponseData
構造のメンバーを示します。
表D-28 ExtractResponseDataデータ構造のメンバー
メンバー | データ型 | 説明 |
---|---|---|
|
Boolean |
構造にアップサート・レコードがあるかどうかを示します。この配列には、有効なUpsertRecord構造があります。 |
|
UpsertRecord [] |
この配列は、NULL以外で空でない必要があります。変更されたレコードがない場合、配列は長さが1で、NULL以外のメンバーが含まれるNULL以外のUpsertRecordが1つ必要です。ただし、メンバーは空の文字列にできます。
|
|
Boolean |
|
|
String [] |
文字列の配列で、配列の各要素には、前回の同期化セッション以降に削除されたPIMレコードのPIMレコードIDが格納されます。 NULL以外で空でない必要があります。削除されたレコードがない場合、配列は長さが1で、NULL以外のPIMレコードID(空も可能)が1つ必要です。
|
ExtractResponseMetaData
構造には、ドメイン抽出の指定のExtractResponseMetaData
に関するメタデータ情報が格納されます。表D-29に、ExtractResponseMetaData
構造のメンバーを示します。
表D-29 ExtractResponseMetaDataデータ構造のメンバー
メンバー | データ型 | 説明 |
---|---|---|
|
String |
同期化セッションIDが格納されます。このメンバーは、NULL以外で空でない必要があります。 |
|
String |
ハブ・ドメインが格納されます。このメンバーは、NULL以外で空でない必要があります。 |
|
String |
ハブ・ユーザーIDが格納されます。このメンバーは、NULL以外で空でない必要があります。 |
|
String |
|
|
String |
抽出に失敗した理由が格納されます。このメンバーは、NULL以外である必要がありますが、空にはできます。 |
|
String |
PIMドメインが格納されます。このメンバーは、NULL以外で空でない必要があります。 |
|
String |
PIMユーザーIDが格納されます。このメンバーは、NULL以外で空でない必要があります。 |
|
String |
コネクタ名が格納されます。 |
|
String |
|
|
String |
|
HubContext
構造(表D-30を参照)は、ランタイム・ライブラリまたはエンジン・コールバック・インタフェースのコール時に、コールするBDSSインスタンスの情報をコネクタに提供します。
表D-30 HubContextデータ構造のメンバー
メンバー | データ型 | 説明 |
---|---|---|
|
String |
コネクタでコールするBDSS Webサービス・コンポーネントをホストするサーバーのURLが格納されます。このメンバーは、NULL以外で空でない必要があります。 |
|
String |
セッションIDが格納されます。このメンバーは、NULL以外で空でない必要があります。 |
|
String |
コネクタでコネクタ・ランタイム・ライブラリをコールしてメタデータの読取りまたは書込みを行うときに使用するURLが格納されます。 |
|
String |
コネクタ名が格納されます。このメンバーは、NULL以外で空でない必要があります。 |
PimRecordDescription
構造(表D-31)には、PIMレコード説明が格納されます。KeyField
メタデータがドメインに対して構成されている場合、コネクタでは指定のドメインのアップサート・レコードすべてについてこの説明を作成する必要があります。
表D-31 PimRecordDescriptionデータ構造のメンバー
メンバー | データ型 | 説明 |
---|---|---|
|
KeyValuePair [] |
PIMレコード説明を構成するハブ・フィールド名とハブ・フィールド値が格納されたKeyValuePair構造の配列。配列は、NULL以外である必要があります。
|
|
Boolean |
|
コネクタでは、AssociatedData
構造(表D-32)を使用して、データをPIMレコードまたはPIMユーザーのいずれかに関連付けることができます。
表D-32 AssociatedDataデータ構造のメンバー
メンバー | データ型 | 説明 |
---|---|---|
|
String |
関連データを一意に識別するコネクタ定義の識別子が格納されます。このメンバーは、NULL以外である必要があります。 |
|
Boolean |
|
|
関連データのグループ(1つまたは複数)を定義する このメンバーのサイズは1以上である必要があります。
|
AssocDataElement
データ構造には、関連データのグループが格納されます。表D-33に、AssocDataElement構造のメンバーを示します。
表D-33 AssocDataElementデータ構造のメンバー
メンバー | データ型 | 説明 |
---|---|---|
|
String |
|
|
Boolean |
|
|
|
グループ内の1つの関連データを表す、任意の大きさの
|
注意: 関連データがバイナリの場合、コネクタではデータをBase64にエンコードして、データベースに非BLOBとして保存します。この場合、関連データのチャンクおよびチャンク解除はコネクタで実行されます。 |
RecordMetaData
構造には、PIMサーバーから抽出されたりPIMサーバーにプッシュされるPIMレコードに関するメタデータが格納されます。表D-34に、RecordMetaData
構造のメンバーを示します。
表D-34 RecordMetaDataデータ構造のメンバー
メンバー | データ型 | 説明 |
---|---|---|
|
String |
PIMレコードIDが格納されます。このメンバーは、NULL以外で空でない必要があります。 |
|
String |
PIMレコード・バージョンIDが格納されます。このメンバーは、NULL以外で空でない必要があります。 |
|
Boolean |
レコード処理に失敗したかどうかを示すブール値。この値がtrueに設定されている場合は、 |
|
String |
UpsertRecordの処理中に発生したエラーの理由を説明します。このメンバーは、NULL以外である必要がありますが、空の文字列にはできます。 |
|
|
|
|
|
PIMレコード説明が格納されます。ドメインに対して |
UpsertRecord
構造は、PIMサーバーから抽出されたりPIMサーバーにプッシュされるハブ・レコードの構造を定義します。削除されたハブ・レコードは、この構造に表示されません。表D-35に、UpsertRecord
構造のメンバーを示します。
抽出リクエストの結果コードを定義する列挙型。例D-1に、Enum
定義を示します。
次の構成構造があります。
ConfigurationSection
構造は、構成ファイルまたは.ini
構成ファイルと概念的に同等なプロファイルのセクションを表します。つまり、プロファイルには一意の名前が付いたセクションのコレクションが含まれ、各セクションにはパラメータと値のコレクションが含まれます。表D-36に、ConfigurationSection構造のメンバーを示します。
表D-36 ConfigurationSection構成構造のメンバー
メンバー | データ型 | 説明 |
---|---|---|
|
String |
プロファイルに含まれるセクション名を識別します。 |
|
KeyValuePair [] |
プロファイルのセクションに含まれる構成パラメータと値が格納されます。 |
ConfigurationProfile
構造はプロファイルを表します。表D-37に、ConfigurationProfile構造のメンバーを示します。
開発者は、コネクタを少なくとも3つのパッケージ(ハブ・トランスポート・パッケージ、PIMトランスポート・パッケージ、変換パッケージ)に分割する必要があります。
ハブ・トランスポート・パッケージ
ハブ・トランスポート・パッケージには、ハブと直接通信するコンポーネントが含まれます。これらのコンポーネントでは、ハブとの通信に関連するすべての詳細を処理しますが、PIMストアやサーバーに対して直接データ交換操作を実行することはありません。かわりに、PIMトランスポート・パッケージと通信して、PIMストアとデータを交換します。このコンポーネントは汎用で、再利用して1つ以上のPIMトランスポート・パッケージと通信できます。
PIMトランスポート・パッケージ
PIMトランスポート・パッケージには、PIMサーバーおよびPIMストアと直接通信するコンポーネントが含まれます。これらのコンポーネントではハブと直接通信しませんが、かわりに、PIM関連のすべての詳細を処理します。これらは、ハブとPIMトランスポート・パッケージの間の通信を容易にするPIMトランスポートAPIです。
変換パッケージ
変換パッケージには、レコード・データをハブ書式とPIM書式の間で変換するコンポーネントが含まれます。
詳細は、第2.2項「コネクタの概要」を参照してください。
この項では、Exchange 2007コネクタの動作を説明するために、次の前提を使用します。
cjonesおよびtsmytheというユーザーが存在するBPELシステム。
charles.jones@sample.comおよびtsmythe@sample.comというユーザーが存在するExchangeシステム。
cjonesユーザーをcharles.jones@sample.comユーザーにマップするハブ・ユーザー。
BPELサーバーおよびExchange組織外に存在し、電子メール・アドレスがtom.johnson@microsoft.comのユーザー。
ハブでのカレンダ・サポートの目的と同様に、汎用コネクタ・コンポーネントの目的は、他のドメインの同期化と同じ方法でカレンダの同期化をサポートすることです。つまり、特定のドメインのレコード・データは汎用コンポーネントに関連付けられません。さらに、汎用コンポーネントでは、特定のドメイン固有のロジックを実装しません。
削除を検出できないPIMトランスポートのために、ハブ・トランスポートでは削除検出機能を提供します。PIMトランスポート・コンポーネントで削除をネイティブで検出できない場合は、削除するレコードIDのリストが決定した後にハブ・トランスポートで新しいPIMトランスポート・インタフェース・メソッドを起動すると、PIMトランスポートでは、削除したレコードを削除として抽出レスポンスに表示するか、またはファンニング済インスタンスであるカレンダ・レコードに対する例外として表示するかを決定できます。前者の場合、レコードIDは削除リストに残ります。後者の場合、レコードIDは削除リストから削除され、コネクタでは、EXDATEリストにある削除発生の開始日がマスターVEVENTに含まれるように該当するアップサート・レコードを更新する必要があります。ハブ・トランスポートではこの処理をカレンダ・ドメインに対して実行できると同時に、すべてのドメインに対しても実行できるため、PIMトランスポートでは抽出レスポンスを変更して最終的にハブに送信できます。PIMExtractResponse
、FinalizeExtractResponse
(PIMExtractResponse
response
)などのメソッドは適切なシグネチャです。
カレンダの同期化をテストするには、反映同期化を使用します。PIMトランスポート・インタフェースでは、コネクタ・タイプを返す新しいメソッドが必要です。ハブ・トランスポートでは、BDSSから構成プロファイルを読み取る前の時点でこのメソッドをコールし、コネクタ名に対応するプロファイル名ではなく、新しいPIMトランスポート・メソッドからの戻り値に対応する名前のプロファイルをロードします。
この項では、ランタイム・ライブラリ(RTL)のメソッドについて説明します。
ハブ規定では、次のメソッドおよび機能を使用します。
このメソッドはランタイム・ライブラリに含まれるメソッドの1つで、コネクタではこのメソッドを使用して関連データ値から関連データIDを取得できます。このメソッドはgetUserAssociatedData
およびgetRecordAssociatedData
に似ており、コネクタでは関連データ値のコレクションを提供して、対応するassocdata
IDのコレクションとともに、リクエストした各assocDataID
のステータス・コード(成功、失敗、またはデータベースに存在しない)を取得します。
たとえば、関連データのキーと値のペアのコレクション{Key1,Value1}、{Key2,Value2}、{Key3,Value3}が含まれるMyGroupのグループ名がMyCalendarAssocDataZに保持され、そのassocDataId
が保持されるassocData
をコネクタでBDSSに格納した場合、後でコネクタで値MyCalendarAssocDataZを取得するときは、MyGroupおよび{Key1,Value1}、{Key2,Value2}、{Key3,Value3}の一部または全部を指定してこのAPIをコールできます。APIでは、指定したグループ名およびキーと値のペアが含まれる行について関連データ表を問い合せて、IDを取得します。APIでは、関連データ値が複数の行にわたってセグメント化されている場合があることを考慮する必要があります。
ハブでは、カレンダ・レコードを作成または更新するコネクタ・メソッドをコールするときに、ユーザー・マップ・メタデータを使用して、作成/更新リクエストに付随するレコード・メタデータの一部としてターゲット・システムのPIMユーザーIDを提供することにより、参加者の解決をサポートしています。ハブで作成/更新操作中にこのメタデータを提供するには、ソース・コネクタで、カレンダ・レコードのソース・システムの参加者を抽出レスポンスに提供する必要があります。BDSSコネクタのRecordMetadataには、参加者メタデータを保持するデータ・メンバーが含まれます。
たとえば、ハブでBPELサーバーからcjonesのカレンダを抽出するとき、BPELタスク・コネクタでは、アップサート・レコードに関連付けられたレコード・メタデータにcjonesを指定します。次にハブでは、そのレコードがcharles.jones@sample.comユーザーのExchangeカレンダに作成される必要があると判断します。ハブでは、ユーザー・マップでcjonesを検索し、cjonesがExchangeのcharles.jones@sample.comにマップされていることを検出します。ユーザーがマップされているため、ハブでは、アップサート・レコードに関連付けられたレコード・メタデータにcharles.jones@sample.com(cjonesではなく)を提供し、これをExchange 2007コネクタをコールしてレコードを作成するときに提供します。
これをサポートするには、BDSSコネクタのRecordMetadataを更新して、タイプAttendeeMetadataのデータ・メンバーが参加者メタデータを保持する必要があります。
AttendeeMetada
は、コネクタ・インタフェース用のBDSS WSDLのWSDL構成です。このクラスは、ハブ・カレンダ・レコードに関連付けられた参加者情報を管理します。
次のことが前提になります。
繰返しのカレンダ会議には、マスター・レコードとは異なる参加者を含む例外や他の例外を含めることができます。
カレンダを作成または更新するターゲット・コネクタでは、ICAL内に含まれる参加者情報を使用できません(ICALの参加者情報はソース・コネクタで定義されているため)。
このクラスを使用すると、ターゲット・コネクタでは各会議の発生に関連付けられた参加者を判別できます。これはコレクションのマップ構成を意味し、マップは会議発生の開始日をキーとして取得し、指定のキーのコレクションにはその会議に関連付けられた参加者が含まれます。マップに含まれるエントリが1つの場合は、例外がないカレンダ・レコードであることを意味します。マップに複数のエントリが含まれる場合は、例外があるカレンダ・レコードであることを意味し、その例外にはマスター・レコードとは異なる参加者が含まれます。
次の各項では、BDSSを使用してカレンダ・レコードを同期化する際にコネクタ実装で準拠する必要がある規定上の義務事項を定義します。コネクタは、コネクタ・インタフェースのドキュメントに定義されている規定上の義務事項にも準拠する必要があります。
コネクタがデータを交換するカレンダ・システムがフェデレーテッドPIMの場合、コネクタではハブからフェデレーション・モデルを抽出する必要があります。たとえば、ある1つのカレンダ会議がSiebelモデルに類似しており、カレンダ・レコードをリレーショナル・データベースに格納すると、各レコードには一意の行IDが含まれ、カレンダ・レコードからユーザー表に外部キーを追加することによってカレンダ・レコードを表示できます。コネクタで指定のカレンダ・レコードを抽出すると、各参加者が同期化されるときに、参加者ごとにカレンダ・レコードの行IDと参加者の行IDを連結したPIMレコードIDを作成できます。後続の同期化セッションで、BDSSがコネクタに対して更新操作または削除操作を実行するように指示すると、ハブでは作成されたIDを提供し、コネクタではその2つの行IDを解析して適切な操作を実行できます。
フェデレーテッド・システムのコネクタでは、指定のBDSSリクエストを別の操作に変換する必要がある場合があります。たとえば、システムのカレンダ・モデルでは、参加者が変更できるのは、その参加者が開催する会議のみとします。BDSSはコネクタに対して更新操作を実行するように指示したが、コネクタでは同期化するユーザーの行IDが開催者ではなく参加者であると判断した場合、コネクタではBDSSコールに対して操作を実行せず、場合によってはメッセージを記録することもできます。つまり、開催者が同期化されると、変更(ある場合)が同期化されるため、コネクタが開催者を同期化の対象と判断した場合は操作なしが適切です。(ソースが非フェデレーテッドPIMの場合、開催者は会議のコピーを変更できません。)コネクタが開催者を同期化の対象と判断した場合は(ユーザーが組織に定義されていない場合、またはユーザーが同期化用のBDSSユーザー・マップに追加されていない場合のいずれか)、操作なしは適切ではありません。同様に、BDSSがコネクタに対してレコードを削除するように指示し、コネクタでは参加者がそのレコードをすでに削除したと判断した場合、コネクタはレコード全体を削除するのではなく、その参加者をカレンダ・レコードから削除します(つまり、カレンダ・レコード全体を削除するのではなく、参加者ユーザーを識別する外部キーをカレンダ・レコードから削除します)。コネクタが開催者から削除を取得した場合は、カレンダ・レコード自体を削除できます。ユーザーを同期化する順序は保証されていないため、開催者の削除が同期化された後にコネクタで参加者の削除を受信した場合、コネクタでは以降の削除に対して操作を実行しないことがあります。
これは、フェデレーションの抽出方法に関するコネクタ実装詳細ですが、実装では次の動作を保証する必要があります。
コネクタでは、各参加者ユーザーを同期化するとき、会議から削除された各参加者の削除を送信する必要があります。たとえば、レコードAに開催者のユーザーAと参加者のユーザーBが含まれ、ユーザーCは削除されていた場合は、ユーザーAを同期化すると抽出レスポンスに削除が含まれ、ユーザーBを同期化すると抽出レスポンスに削除が含まれます。
参加者の削除とは異なり、カレンダ・レコードが削除されると、開催者および各参加者の抽出には削除が含まれます。
レコードが会議(参加者あり)から予定(参加者なし)に変更された場合、コネクタでは、カレンダ・レコードに関連付けられた残りのユーザーのアップサート(PIMのカレンダ・モデルに応じて、開催者である場合とそうでない場合があります)、および残りのユーザーの削除を提供する必要があります。
コネクタでは、最初の抽出時、または進行中の抽出でレコードが更新された場合、カレンダ・レコードに関連付けられた各ユーザーのアップサート・レコードを提供する必要があります。たとえば、レコードAに開催者のユーザーAと参加者のユーザーBが含まれている場合は、ユーザーAを最初に同期化するとき、およびユーザーBを最初に同期化するときに、レコードAがハブへの抽出レスポンスに提供される必要があります。さらに、レコードAがユーザーによって更新された場合は、ユーザーAを同期化するとき、およびユーザーBを同期化するときに、レコードAが提供される必要があります。レコードAへの更新が新規参加者ユーザーCの追加であった場合は、ユーザーA、ユーザーBおよびユーザーCの抽出レスポンスにレコードAが提供される必要があります。
コネクタでは、特定のユーザーがBDSSを介して行った更新のエコーは伝播しませんが、レコードに関連付けられた他のユーザーの更新は伝播する必要があります。たとえば、フェデレーテッド・システム内のレコードAには参加者としてユーザーA、ユーザーBおよびユーザーCが含まれ、このレコードはセッション1で同期化されるとします。次に、セッション2では、コネクタはdeleteRecord
コールを受信してユーザーCを削除します。コネクタでは、カレンダ・レコードを削除するのではなく、カレンダ・レコードからユーザーCを削除します。セッション3では、アップサートはユーザーAおよびユーザーBの抽出レスポンスに表示され、新しい参加者リスト(ユーザーCは参加者に含まれません)が示されます。ユーザーCを同期化するとき、この削除はエコーの削除とみなされるため、ハブに送信される抽出レスポンスにレコードの削除は含まれません。このような方法で、ユーザーCにマップされた参加者が他のシステムからレコードを削除すると、BDSSでは、他のシステムでユーザーAおよびユーザーBにマップされた参加者がレコードを更新して、ユーザーCが会議の参加者でなくなったことを示します。
ハブでは参加者の解決がサポートされていますが、コネクタ実装では次のシナリオを考慮する必要があります。
ユースケース1: ユーザーがBDSSで同期化対象として構成されていないケースです。たとえば、BPELサーバーで作成されたカレンダ・レコードにtsmytheという名前の参加者が含まれ、tsmytheは有効なBPELサーバー・アカウントとExchangeアカウントを持っていますが、tsmytheは自分のBPELデータをBDSSを介して同期化することを希望していないとします。レコードは、BPELタスク・コネクタによって抽出されます。cjonesを同期化するときは、参加者としてcjonesおよびtsmytheをレコード・メタデータに指定します。ハブでは、Exchange 2007コネクタをコールしてレコードを作成するとき、Exchange 2007コネクタにcharles.jones@sample.comを提供できますが、レコード・メタデータのtsmytheに対するExchangeユーザーIDは提供できません。
ユースケース2: ユーザーは組織内の人員として認識されていないケースです。たとえば、Microsoft社のExchangeユーザーtom.johnson@microsoft.comが会議を開催してcharles.jones@sample.comを招待した場合、この招待者が会議への参加を承諾するとExchangeフォルダにカレンダ・アイテムが作成されます。さらに、tom.johnson@microsoft.comはExchangeシステムおよびBPELシステムに定義されていないとします。BDSSで、cjonesをcharles.jones@sample.comにマップするハブ・ユーザーを同期化すると、Exchange 2007コネクタではtom.johnson@microsoft.comをExchange組織内のユーザーとして解決できません。tom.johnson@microsoft.comがレコード・メタデータに指定されます。次に、ハブでレコードをBPELサーバーにプッシュすると、BPELタスク・コネクタでもtom.johnson@microsoft.comをBPELユーザーに解決できません。
ユースケース3: 受信コネクタがターゲット・システムでレコードを作成または更新するときに、レコード・メタデータに格納された参加者情報が不十分なケースです。この場合、コネクタでは提供された情報を使用してユーザーの解決を試みます。たとえば、Exchangeコネクタでは、カレンダ・レコードを作成するときに、参加者の名、姓およびユーザー電子メール・アドレスを指定する必要があります。コネクタでレコード・メタデータに格納された電子メール・アドレスをActive Directoryへの問合せに指定すると、電子メール・アドレスが一致するユーザーの名と姓が返されます。
コネクタでは、特定の参加者をコネクタのシステム内のユーザーに解決できない場合、次の抽出時に、未解決の参加者をハブに戻す必要があります。これによって、レコードの更新が別のコネクタにプッシュされても、参加者が会議から削除されません。
指定のカレンダ・レコードの抽出時に、カレンダ・レコードに関連付けられた未解決の参加者をコネクタで解決するには、次の方法があります。
BDSSデータ・モデルを拡張して、参加者メタデータを保持する表を作成し、コネクタがメタデータを設定または取得できる新規のランタイム・ライブラリAPIを定義します。
BDSSのレコード・レベルまたはユーザー・レベルの関連データ機能を使用します。レコード・レベルの関連データを使用すると、BDSSストア内で未解決の参加者が多数重複する可能性があります。このため、ユーザー・レベルの関連データを使用することをお薦めします。ユーザー・レベルの関連データを使用する場合もBDSSストア内で未解決の参加者が重複する可能性がありますが、レコード・レベルの関連データを使用する場合と比較すると重複は少なくなります。重複を回避するには、未解決の参加者のみを保持するための特別なBDSS PIMユーザーをコネクタで作成します。
解決不能な参加者を作成/更新時にPIMレコード自体に書き込むと、次回にレコードが抽出されるときに、コネクタで未解決の参加者を取得できます。コネクタがデータを交換するシステムで参加者の値が不明確でも許容される場合、コネクタでは解決不能な参加者を単純に参加者フィールドに書き込むことができます。ただし、システムでは参加者の値を明確にする必要があるため、コネクタでは、エンド・ユーザーはデフォルトで表示できないカスタム・フィールドに解決不能な参加者を書き込む必要があります。
注意: 指定のユーザーは同じコネクタ・タイプの異なるコネクタ・インスタンスで同期化できるため、未解決の参加者をメモリー内キャッシュに保持することは有効な方法ではありません。たとえば、Exchange 2007コネクタにInstance 1とInstance 2という2つのインスタンスがあり、異なるサーバーにデプロイされているとします。同期化セッション1で、charles.jones@sample.comがInstance 1を介して同期化されます。tom.johnson@microsoft.comは解決できないため、コネクタではExchangeレコードの作成時にこの参加者を含めないことを決定します。会議が更新され、その後、BDSSで別の同期化セッションが実行されると、charles.jones@sample.comはInstance 2を介して同期化されます。このセッションでは、レコードが抽出されるときにInstance 2でtom.johnson@microsoft.comを簡単にリストアする方法はありません(コネクタ・インスタンスが相互に通信しない場合)。 |
解決不能な参加者をシステム・レコードに保持できないコネクタでは、BDSSソリューション(レコードまたはユーザー関連データ)を使用するか、または独自のメソッドを実行する必要があります。
会議の参加者が参加者のグループまたは配信リストで識別される場合、コネクタでは配信リストを参加者としてICALに提供できません。かわりに、コネクタでは、グループの各メンバーをICALに提供する必要があります。あるシステムの参加者のグループが別のシステムでも定義されている場合があり、グループ名または配信リスト名がシステム間で一致している場合はグループのメンバーシップが同じである保証がないため、この配信リストを展開する必要があります。また、コネクタでは、すべての埋込みグループまたは配信リストのメンバーを展開し、ICALに重複が含まれないようにする必要があります。次に例を示します。
配信リストAのメンバーはUser1およびUser2です。
配信リストBのメンバーは、配信リストA、User1、User2およびUser3です。
カレンダ・レコードにリストされる参加者は次のとおりです。
配信リストA
配信リストB
User3
グループのメンバーシップによってカレンダ・レコードに重複が含まれますが、ICALに含まれるのはUser 1、User 2およびUser 3のみです。
コネクタでは、すべてのICAL繰返しパターンをサポートするように試みる必要があります。
抽出時に、コネクタでは、繰返しパターンをネイティブ定義から同等のICAL定義に変換する必要があります。同様に、コネクタでは、カレンダ・レコードを作成または更新するときに、ICAL繰返しパターンを同等のネイティブ・パターンに変換する必要があります。
ただし、コネクタで指定のICAL繰返しパターンをネイティブでサポートできない場合があります。このような場合でも、コネクタでは、ハブからの作成/更新リクエストを実行しようとします。これを解決する主要な方法はファンニングです。この形式のファンニングとは、元のパターンをコピーして複数のカレンダ・レコードを作成するプロセスです(非フェデレーテッド・システムと混同しないでください)。
コネクタでは常に、1つのレコードを繰返しなしの複数のカレンダ・レコードにファンニングし、各インスタンスには繰返しパターンで定義される日付に発生するように開始日があります。コネクタでは、この操作をハブから抽出する必要があります。
注意: Oracle Fusion Middleware 11gリリース2のBDSSでは、EXRULEはサポートされていません。 |
次の各項では、ファンニングに関連するコネクタ規定について説明します。
コネクタでは、システムからカレンダ・レコードを抽出するとき、ICAL RFCに準拠した、レコードのICAL表現を作成する必要があります。
すでに繰返しパターンをファンニングしたコネクタでは、次回にレコードが同期化されるときに、すべてのファンニング済インスタンスを、元の繰返しパターンを含む単一のICAL表現に結合する必要があります。ファンニング済レコードから繰返しパターンを再作成するとき、コネクタ実装では次の処理を実行します。
PIM内のファンニング済インスタンスへの変更がICALの例外に変換され、「Calendar Hub Domain Schema」セクションにリストされた要件ごとに個別のVEVENTとして表されていることを認識します。
PIM内のファンニング済インスタンスの削除が、マスターVEVENTのEXDATEに変換されます。
ファンニング済インスタンスが単一のICALメッセージに結合され、ExtractResponse
はレスポンスにファンニング済インスタンスを含みません。さらに、コネクタでは適切なPIMレコード・バージョンを提供する必要があります。
繰返しパターンが適用されるクライアントを介してPIMユーザーがファンニング済インスタンスを更新した場合、コネクタでは、ファンニング済レコード(ただし、この時点では繰返しレコード)を個別のレコードとして同期化し、抽出の実行時に元のレコードでEXDATEを指定する必要があります。また、抽出したレコードが別のシステムの対応するレコードと競合する場合は、競合を解消するユースケースを考慮する必要があります。この場合、コネクタでは繰返しの予定を削除し、優先するレコード・データに置換します。
各ファンニング済インスタンスに関するメタデータは保持されるため、抽出が実行されるとき、コネクタでは次のことが可能です。
ファンニング済インスタンスのセットを判別します。
各ファンニング済インスタンスをICALに表示する方法(つまり、マスターVEVENT、例外VEVENT)を決定します。これは、コネクタにおいて、複数の同期化セッション間で各ファンニング済インスタンスの状態を追跡する必要があることを意味します。たとえば、セッション1で同期化された3つのファンニング済レコード(レコードA、レコードBおよびレコードC)があるとします。これらのレコードはすべて、繰返しパターンおよび同じ会議IDを持つ単一のICALに結合される必要があります。レコードAに対する更新、およびレコードCの削除がセッション2で同期化されると、ステップ1でレコードAがICALに例外VEVENTとして表示され、ステップ2でレコードCがマスターVEVENTにEXDATEとして表示されます。セッション2で、レコードBは抽出レスポンスに含まれ、レコードAとレコードCは含まれない場合、コネクタでは、レコードBを例外VEVENTとして追加し、レコードAとレコードCは抽出レスポンスに含まれていなくても、レコードAは例外VEVENTとして、レコードCはマスターVEVENTのEXDATEとして提供する必要があります。
前述したように、コネクタでは、レコードおよび各ファンニング済インスタンスに関するメタデータを格納して、繰返しパターンの再作成に役立てる必要があります。コネクタでは、メタデータを、BDSSデータ・ストアに関連データとして格納することも、PIMレコードの非表示フィールドに格納することも可能です。コネクタに格納される内容はコネクタ実装詳細で、すべてのコネクタで必ずしも同じではありません。
コネクタでレコード関連データがBDSSデータ・ストアに格納され、ランタイム・ライブラリがエラーを返したとき、リクエストされたすべての関連データについて各ステータス・コードがデータがデータベースになかったために障害が発生したことを示しており、提供された同期状態が空またはNULLの場合、ユーザーは再度初期化されます(ランタイム・ライブラリがエラーを返し、成功を示すステータス・コードと、データベースにデータがなかったために失敗したことを示すステータス・コードがある場合、このエラーはリカバリ不能です)。コネクタでは、このユースケースを考慮して、(会議ID別にレコードを照合して)最初の抽出を実行するときにファンニング済インスタンスを結合します。
ハブでCreateRecord
がコールされると、コネクタでは受信したICALを検証して、レコードをファンニングする必要があるかどうかを判断します。最初に、すべてのVEVENT間で各RRULE、RDATEおよびEXDATEを検証して、最終的な繰返しパターンを決定します。最終的な繰返しパターンをネイティブで表現できない場合、コネクタではレコードをファンニングして、後続のセッションでパターンをリストアするために必要なすべてのメタデータを格納します。
ファンニング済インスタンスの作成時に障害は発生した場合、コネクタではファンニング済インスタンスの作成を停止し、ファンニングされるレコードに関連して正常に作成されたファンニング済インスタンスをすべて削除し、エラーをハブに返します。コネクタでメッセージを記録することも可能です(同じセッション内で作成および更新操作が発生している場合は、後続のセッションに影響しません)。
ハブでUpdateRecord
がコールされると、コネクタでは、更新対象のレコードがすでにファンニングされているかどうかを判別する必要があります。レコードがすでにファンニングされている場合は、受信したICALをファンニング済インスタンスに適用し、場合によっては受信したパターンを再度ファンニングする必要があります(新しいパターンがレコードに適用された場合は、ネイティブで表現できません)。ファンニングが再実行された場合、コネクタでは、最初に古いファンニング済インスタンスを削除してから、新しいインスタンスを作成する必要がある場合があります。また、コネクタでは、後続の抽出でこれらの削除を除外する必要があります。
コネクタですでにファンニングされたレコードに対する更新を取得し、開始日が元のファンニングのファンニング制限外である例外VEVENTがICALにある場合、コネクタでは例外をPIMに作成する必要があります。
コネクタでは、表D-38に示すファンニング関連のユースケースを考慮する必要があります。コネクタで各ユースケースを処理する方法がコネクタ実装詳細です。
表D-38 ファンニングのユースケース
更新するパターンはサポート対象か | レコードはファンニング済か | コメント |
---|---|---|
True |
True |
同期化セッション間でサポート対象外のパターンがサポート対象のパターンに変更されたことを示します。 |
True |
False |
通常の更新です。ファンニングはありません。 |
False |
True |
同期化セッション間でサポートされていないパターンを示します。 |
既存のファンニング済インスタンスの更新時に障害が発生した場合(つまり、削除や再ファンニングではなく、ファンニング済インスタンスを実際に更新した場合)、コネクタでは更新を停止し、更新されるレコードに関連して正常に更新されたファンニング済インスタンスをリストアして、エラーをハブに返す必要があります。コネクタでメッセージを記録することも可能です。このような更新-更新-リストア操作が同じセッションで発生すると、後続のセッションに影響を与えます。
ハブでDeleteRecord
がコールされると、コネクタでは、削除対象のレコードがすでにファンニングされているかどうかを判別する必要があります。その場合、コネクタではすべてのファンニング済インスタンスを削除する必要があります。
既存のファンニング済インスタンスの削除時に、すべて削除される前に障害が発生した場合、同期状態は保存されないため(コネクタが削除を停止してエラーをハブに返す場合)、コネクタでは正常に削除されたファンニング済インスタンスをリストアする必要はなく、後続のセッションで削除が再試行されます。
PIMトランスポート・コンポーネントでは、次のことをサポートします。
Exchangeでは、不完全な名前を参加者としてリストできます。したがって、Exchange 2007コネクタでは、メタデータから取得した参加者のリストをExchangeレコードの「To」、「CC」および「BCC」フィールドに直接書き込みます。
BDSSの必須参加者はExchangeの「To」フィールド、任意参加者はExchangeの「CC」フィールド、リソースはExchangeの「BCC」フィールドに書き込まれます。
PIMトランスポートでは、指定のユーザーの会議に対する更新リクエストを受信して、そのユーザーが参加者または開催者として表示されていない場合に、エラーをスローします。
PIMトランスポートでは、Exchange WebサービスのResolveNamesおよびExpandDLを使用して、参加者および配信リスト・メンバーシップを解決します。
表D-39に示すメタデータは、PIMトランスポートでカレンダの同期化を有効にするために、レコード・レベルの関連データとしてBDSSデータ・ストアに格納されるか、またはExchangeストアの非表示フィールドに格納されます。
表D-40に、サポート対象の繰返しパターンおよび各パターンの例を示します。各サンプルでは、パターンのICAL以外の記述に続いて、パターンを表すICAL RRULE値を示します。この表には、可能なすべてのパターンがリストされているわけではありません。
表D-40 サポート対象の繰返しパターン
Exchangeパターン | ICAL RRuleプロパティ値の例 |
---|---|
Daily |
毎日、2日ごと、無期限
毎日、毎日、10回
毎日、5日ごと、7月末まで
毎日、すべての平日、無期限
毎日、すべての平日、10回
毎日、すべての平日、7月末まで
|
Weekly |
隔週の月曜、水曜および金曜、無期限
隔週の月曜、水曜および金曜、10回
3週間ごとの月曜、水曜および金曜、7月末まで
|
Absolute Monthly |
隔月の15日、無期限
|
Relative Monthly |
毎月最後の平日
毎月最後の週末
毎月1日、10回
隔月の第4木曜、2010年10月末まで
毎月第3木曜
3か月ごとの第4月曜
|
Absolute Yearly |
毎年7月4日
|
Relative Yearly |
毎年7月2日、10回
7月最後の週末、2018年まで
|
ExchangeのCalendarItemType
には、タイムゾーン関連のプロパティとしてTimeZone
およびMeetingTimeZone
があります。TimeZone
プロパティは読取り専用で、カレンダ・レコードのタイムゾーンのテスト専用の記述です。MeetingTimeZone
プロパティは、新規カレンダまたは更新されたカレンダ・アイテムに設定されるプロパティです。
PIMトランスポートでは、カレンダ・レコードの作成または更新時にICAL VTIMEZONE
値を同等のMeetingTimeZone
値に変換し、抽出時にはこの逆に変換する必要があります。
Exchange Webサービスでは、すべての日時値が協定世界時(UTC)で格納されます。コネクタでは、ICALの日時値の書式を確認して、必要な場合はUTCに変換する必要があります。ICALでもVTIMEZONE情報が必要になるため、これによって処理が単純になります。
Exchange 2007サーバーでは、ユーザーが特定のカレンダ・レコードを更新すると、そのレコードに新しいPIMレコードIDが付けられる場合があります(詳細は、http://support.microsoft.com/
のMicrosoftサポートを参照)。したがって、PIMトランスポートでは、作成または抽出するすべてのカレンダ・レコードについて、レコード・レベルの関連データとしてItemIdType
およびMeetingId
の両方を保存する必要があります。
PIMトランスポートでExchangeレコードの抽出、更新または削除を行うときは、特定のカレンダ・レコードに対してExchangeが実行するこのレコード再作成プロセスによって指定の操作に失敗する場合があることを考慮する必要があります。
通常、PIMトランスポートでは、最初に、使用可能なItemIdType
を使用して指定の操作を実行しようとします。操作に失敗し、Exchangeストアにレコードが存在しないため操作に失敗したことが結果コードで示された場合、コネクタでは、このエラーが発生したのは、エンド・ユーザーが実際にレコードを削除したためか、またはExchangeのレコード再作成プロセスのためかを判断する必要があります。コネクタではこれを判断するために、Exchangeに対して、更新レコード・コールに付随するメタデータで提供されたレコード関連データに含まれるのと同じMeetingId
が含まれるカレンダ・レコードのItemIdType
を問い合せます。問合せで一致が返された場合はExchangeでレコードが再作成されており、そうでない場合はユーザーがレコードを削除しています。Exchangeでレコードが再作成されている場合は、問合せで返された新しいItemIdType
を使用して操作が再試行されます。
次の各項では、Exchangeに対してレコードの抽出、作成、更新および削除を行うときにPIMレコードIDが変更されることについて、Exchange PIMトランスポートで実行する必要がある処理の追加詳細を説明します。
Exchange PIMトランスポートでは、ランタイム・ライブラリ内にあるGetAssocDataIdOfAssociatedData
メソッドを使用すると、ItemIdType
からBDSSデータ・ストアに格納されたPIMレコードIDへの必要な変換を実行できるため、DeleteUnaware
インタフェースを実装しないように更新できます。PIMトランスポートで削除の検出を実行するように設定すると、Exchangeサーバーへの追加問合せが不要になります。
コネクタでは、他のドメインと同じロジックに従ってドメインを抽出します。ただし、以前にファンニングされたインスタンスを、単一のICALメッセージを含む単一のPIMUpsertRecord
に結合する追加ステップを実行する必要があります。
抽出レスポンスにファンニング済インスタンスが含まれる場合、抽出されなかったファンニング済インスタンスは前のセッションで更新または削除されている場合があるため、コネクタでは、関連するすべてのファンニング済インスタンス(抽出レスポンスに含まれるものと含まれなかったものの両方)をすべて識別し、元の繰返しパターンが設定された単一のICALメッセージに各ファンニング済インスタンスを表示する方法を決定する必要があります。
コネクタでは、再作成プロセスの中で、元のレコード・データおよび元の繰返しパターンを含むマスターVEVENT
が必要です。コネクタでは、1つのレコードのファンニング済インスタンスをすべて取得して単一のICALに結合する必要があるため、FanningState
が「Fanned」(これはファンニング済レコードの初期状態を示します)のファンニング済インスタンスを使用することもできます。ただし、変更が実行された各ファンニング済インスタンスの場合、この方法は失敗します(各インスタンスの例外が含まれる繰返しパターンと同じです)。このため、PIMトランスポートでは、マスターVEVENTをレコード・レベルの関連データとして格納します。
たとえば、セッション1で、パターンが「3か月ごとの初日、4回」のレコードのCreateRecord
をエンジンがコールし、Exchangeでこのパターンをサポートしていないとします。PIMトランスポートでは、3か月ごとの初日に該当する繰返しなしの4つのインスタンスにこのパターンをファンニングします。セッション2の前に、Outlookユーザーが1番目のファンニング済インスタンスの開始日を変更し、2番目のファンニング済インスタンスを削除します。セッション2が開始されると、コネクタではRRULEパターンが「3か月ごとの初日、4回」になるようにICALを再作成し、抽出レスポンスには、日付が変更されたカレンダ・レコードを含む1つのアップサート、および削除されたレコードを含む1つの削除が含まれます。マスターVEVENTはレコード関連データまたはExchangeレコードのいずれかから取得され、アップサートは例外VEVENTとしてICALに表示されます。削除は、マスターVEVENTのEXDATEとしてICALに表示されます。セッション3の前に、3番目のファンニング済インスタンスを更新して、レコードの開始時間を変更したとします。セッション3が開始されると、抽出レスポンスには3番目のファンニング済インスタンスのみが含まれますが、セッション2で行われた変更がパターンに反映されるように他のインスタンスも取得する必要があります。コネクタでは、Exchangeに対して他のレコードを問い合せて、マスターVEVENTに2番目のインスタンスのEXDATE(これはセッション2で削除されたため)、および2つの例外VEVENT(日付が変更された1番目のファンニング済インスタンスの例外、および時刻が変更された3番目のファンニング済インスタンスの例外)が含まれるように、パターンを再作成する必要があります。
ユーザーが繰返しパターンをファンニング済インスタンスに追加した場合、コネクタではそのファンニング済インスタンスを元のパターンの削除インスタンスとして処理し、レコードは結合されたICALに含めるのではなく、抽出レスポンスに個別のレコードとして保持します。受信コネクタでは、EXDATEがあるため元のパターンのインスタンスを非表示にし、ファンニングされた例外レコードに対して新しい繰返しレコードを作成します。
注意: ICAL RFCでは、VEVENTには任意の数のRRULE、RDATE、EXRULEおよびEXDATEを含めることができると規定されています。繰返しルールを含む例外を表すのは簡単ですが、例外が含まれた繰返しパターンを含む例外を表すのは困難です(それ自体に例外パターンを持つ繰返しパターンが含まれるこのような例外は無限に繰り返される可能性があります)。 |
ExchangeではPIMレコードIDを変更できるため、コネクタでは、抽出レスポンスに含まれる特定のPIMレコードIDが変更されたかどうかを判断する必要があります。これを行うには、抽出されたファンニング済インスタンスのItemIdType
値を、指定した元の開始日にBDSSレコード関連データとして格納されているItemIdTypes
(Exchangeレコードの非表示フィールドにも関連データとして格納されています)と対比して不一致を検出します。IDの変更が検出されると、コネクタでは、新しいItemIdType
を含むようにレコード関連データを更新する必要があります。
次の各項では、CallPIMRecord
メソッド・コールによって発生するプロセスについて説明します。
PIMトランスポートでは、カレンダ・レコードの各VEVENTに含まれるRRULE、RDATEおよびEXDATEプロパティをすべて評価して、レコードをファンニングする必要があるかどうかを決定します。
ファンニングが必要な場合、コネクタでは、ファンニング済レコードのコレクションの単一の一意IDをBDSSに提供するように要求されます。PIMトランスポートでは、原則として、他のドメインに対してこの処理を行う場合に指定のレコードのPR_SOURCE_KEYを提供するため、コネクタでは、1番目のファンニング済インスタンスのPR_SOURCE_KEYをPIMレコードIDとして提供して、ファンニング済レコードのコレクションを表します。
Exchangeで作成された各ファンニング済インスタンスには、次の非表示フィールドがあります。
OriginalStartDate
: ファンニング済インスタンスの開始日が格納されます。この値は、レコードの有効期間中に変更されることはありません。
BDSSFabricatedPIMRecordId
: BDSSにPIMレコードIDとして提供されるレコードIDが格納されます。前述したように、これは1番目のファンニング済インスタンスのPR_SOURCE_KEY
です。
注意: 1番目のファンニング済インスタンスにこの非表示フィールドの値は含まれません。コネクタでは、関連するファンニング済レコードを単一のインスタンスに結合するときに、この違いを考慮する必要があります。 |
場合によってはマスターVEVENTデータ(保留中のオープンな問題)。
MeetingId
: Exchangeレコードの会議ID。
非表示のExchangeフィールドに加えて、PIMトランスポートには、作成されたレコードIDに関連付けられたレコード・レベルの次の関連データがあります。
FannedState
: 各ファンニング済インスタンスの関連データ。
OriginalStartDate
: 各ファンニング済インスタンスの関連データ。
ItemIdType
: 各ファンニング済インスタンスの関連データ。
場合によってはマスターVEVENTデータ。
PIMトランスポートでは、レコードをファンニングする必要がある場合に、ファンニング制限の構成値に基づいて各インスタンスの開始日を計算し、受信するパターンを表すレコードのコレクションを作成します。
PIMトランスポートでは、次の場合にレコードをファンニングします。
サポート対象の繰返しパターンではRRULEのコレクションを表すことができない場合。
RDATEがICALに存在する場合。
レコード作成の場合、メソッドでレコードが作成されるまでExchangeにレコードが存在しないため、PIMレコードIDの変更はコネクタに影響を与えません。ただし、レコードの変更および抽出時に抽出コードによってExchangeでPIMレコードIDを変更したかどうかを判別できるように、レコード・レベルの関連データを提供する必要があります。
カレンダ・ドメインの場合、他のすべてのドメインと同様に、Exchange PIMトランスポートでは、指定のレコードのPR_SOURCE_KEY値をPIMレコードIDとして提供し、Exchange WebサービスIDまたはItemIdTypeをレコード関連データとして格納します。コネクタでは常に、Exchangeレコードと相互作用する場合はItemIdTypeを指定し、BDSSと相互作用する場合はPR_SOURCE_KEYを指定する必要があります。
この項では、UpdatePIMRecordメソッド・コールで発生する次のプロセスについて説明します。
PIMトランスポートでは、UpdateRecordのコール時にレコード関連データに提供された関連データを検証して、更新対象のレコードがすでにファンニングされているかどうかを判別します。
PIMトランスポートでは、RRULE、RDATEおよびEXDATE属性のコレクションを検証して、受信したICALをネイティブでExchangeに表示できるかどうかを判別します。
表D-41に、カレンダ・レコードの更新時にPIMトランスポートで実行する処理を示します。
表D-41 PIMトランスポートの更新処理
更新するパターンはサポート対象か | レコードはファンニング済か | 処理 |
---|---|---|
True |
True |
同期化セッション間でサポート対象外のパターンがサポート対象のパターンに変更されたことを示します。
|
True |
False |
更新を実行します。 |
False |
True |
同期化セッション間でサポートされていないパターンを示します。 元の繰返しパターンが変更された場合は、次の処理が実行されます。
元の繰返しパターンが変更されなかった場合は、次の処理が実行されます。
|
False |
False |
同期化セッション間でサポート対象のパターンがサポート対象外のパターンに変更されたことを示します。
|
PIMトランスポートで更新を受信し、パターンがすでにファンニングされて指定のファンニング済インスタンスにはRecurringException
のFannedState
があるが、関連データに格納された元の開始日と一致するEXDATEがマスターVEVENTにないことを確認すると、コネクタでは競合が発生してExchangeデータが失われたとみなす必要があります。この場合、コネクタでは、RecurringException
のFannedStateがあるファンニング済レコードを削除して、関連データを更新する必要があります。この削除は後続の同期化セッションで他のコネクタに伝播され、繰返しパターンを持つファンニング済例外のために個別に同期化された繰返しレコードが削除されます。
コネクタでは、ICALに含まれるMeetingId
を更新された各レコードの非表示のExchangeフィールドに格納し、既存のカレンダ・レコードのMeetingId
は更新しません。抽出が実行されると、非表示フィールドのMeetingId
(レコード上のではなく)がICALに配置されます。非表示フィールドに格納されるMeetingId
は、会議のレコードに格納された実際のMeetingId
と同じ場合とそうでない場合があります。同じ場合は、BDSSまたはExchangeクライアントのいずれかでレコードが作成されたことを意味します。異なる場合は、更新された結果、競合が発生してExchangeデータが失われたことを意味します。いずれの場合も、コネクタでは後続のセッションの更新時にICALに含まれるMeetingId
をハブに返すため、問題はありません。MeetingID
を返すことによって、Exchange自体またはExchangeクライアントが実行する会議管理をコネクタが誤って破損することはありません。
PIMトランスポートでは、第D.8.2.6項「PIMレコードID」の説明に従って更新を実行します。
Exchange PIMトランスポートでは、常にレコードの作成済ID(PR_SOURCE_KEYとも呼ばれます)を指定しますが、Exchangeで削除を実行するときはItemIdTypeを指定する必要があるため、任意のドメインに対して削除操作を実行するときは、常にBDSS RTLからレコード関連データを取得する必要があります。
レコードがすでにファンニングされている場合、PIMトランスポートでレコードのファンニング済インスタンスをすべて削除するには、レコードのレコード関連データを取得して各インスタンスを削除します。