一致関係は、ビジネス・オブジェクトまたは他のデータ間に 1 対 1 の関連を設定します。単純一致関係では、単一キー属性で 2 つのビジネス・オブジェクトを関連付けします。次のセクションで、単純一致関係を使用する手順を説明します。
一致関係定義は、参加者タイプがビジネス・オブジェクトであり data タイプでない ということが、参照関係定義と異なっています (参加者タイプ・リストでの最初の選択)。 単純一致関係の場合、関係は汎用ビジネス・オブジェクトと少なくとも 1 つのアプリケーション固有のビジネス・オブジェクトで構成されます。単純一致関係の参加者タイプは、すべて の参加者に関して 1 つのビジネス・オブジェクトです。すべての参加者に関する参加者属性は、ビジネス・オブジェクトの単一キー属性です (単純一致関係の関係定義の詳細については、"一致関係の定義"を参照)。
単純一致関係を参照する場合は、アプリケーション固有のビジネス・オブジェクトと汎用ビジネス・オブジェクトの間に、「相互参照」変換規則を定義します。詳細については、"一致関係の相互参照"を参照してください。
例: CustIden 関係 (図 99 を参照) により Clarify 顧客内の SiteID キー属性が SAP 顧客内の RefID キー属性に変換されます。これには次のオブジェクト間のマップが組み込まれます。
ClarCust 関係表から、SiteID キー値に関連する関係インスタンス ID を取得します。
SAPCust 関係表から、関係インスタンス ID と関連する RefID キー値を取得します。
図 119 に、CustIden 関係表を使用して SiteID 値の A100 を RefID 値の 806 に変換する方法を示します。
図 119. 関係表を使用した SiteID から RefID への変換
maintainSimpleIdentityRelationship() メソッドは関係表を管理して、関連するアプリケーション固有のキーが単一管理インスタンス ID と関連付けされるようにする必要があります。大まかに説明すると、「相互参照」変換規則を定義した場合には、以下の処理を行うコードが生成されます。
「相互参照」変換では、ソース・ビジネス・オブジェクトからビジネス・オブジェクト動詞が取得されます。インバウンド・マップの場合、ソースはアプリケーション固有のビジネス・オブジェクトであり、アウトバウンド・マップの場合、ソースは汎用ビジネス・オブジェクトです。
「相互参照」変換規則を定義した場合、マップの実行コンテキストから呼び出しコンテキストが取得されます。
この変換は、表 94 に示す呼び出しコンテキストを処理します。
表 94. maintainSimpleIdentityRelationship() の呼び出しコンテキスト
この表 94 に示した各呼び出しコンテキストでの「相互参照」変換の振る舞いについては、次以降のセクションで説明します。
呼び出しコンテキストが EVENT_DELIVERY または ACCESS_REQUEST の場合、呼び出されるマップはインバウンド・マップです。つまり、アプリケーション固有のビジネス・オブジェクトが汎用ビジネス・オブジェクトに変換されます。コネクターにより EVENT_DELIVERY 呼び出しコンテキストが送信され、アクセス・クライアントにより ACCESS_REQUEST 呼び出しコンテキストが送信されます。
いずれの場合でも、インバウンド・マップはアプリケーション固有のビジネス・オブジェクトを入力として受け取り、汎用ビジネス・オブジェクトを出力として戻します。したがって、「相互参照」変換のタスクは、特定のアプリケーション固有のキー値に対応する関係インスタンス ID を、関係表から取得することです。
呼び出しコンテキストが EVENT_DELIVERY および ACCESS_REQUEST の場合、「相互参照」変換のために生成された Java コードは、次のアクションを実行します。
表 95. EVENT_DELIVERY および ACCESS_REQUEST 呼び出しコンテキストのアクション
AppA アプリケーションに固有のビジネス・オブジェクトから AppB アプリケーションに固有のビジネス・オブジェクトへの変換をサポートする一致関係において、呼び出しコンテキストが EVENT_DELIVERY (または ACCESS_REQUEST) で、AppA アプリケーションに固有のビジネス・オブジェクトの動詞が Create または Update である場合に、「相互参照」変換のために生成された Java コードが参加者 AppA に関連付けられている関係表にどのようにアクセスするかを、図 120 に示します。
図 120. Create および Update 動詞を使用した EVENT_DELIVERY および ACCESS_REQUEST
呼び出しコンテキストが EVENT_DELIVERY (または ACCESS_REQUEST) で、アプリケーション固有の動詞が Create または Update である場合、AppA アプリケーションに固有のキー値に一致するエントリーが存在しないときには、「相互参照」変換のために生成された Java コードによって、図 121 に示すような書き込みが関係表に対して行われます。
図 121. 新規の関係エントリーに関して関係表に行う書き込み
呼び出しコンテキストが EVENT_DELIVERY (または ACCESS_REQUEST) で、アプリケーション固有の動詞が Delete である場合には、「相互参照」変換のために生成された Java コードによって、図 122 に示すような書き込みが AppA の関係表に対して行われます。
呼び出しコンテキストが SERVICE_CALL_REQUEST の場合、呼び出されるマップはアウトバウンド・マップです。つまり、汎用ビジネス・オブジェクトがアプリケーション固有のビジネス・オブジェクトに変換されます。アウトバウンド・マップは汎用ビジネス・オブジェクトを入力として受け取り、アプリケーション固有のビジネス・オブジェクトを出力として戻します。したがって、「相互参照」変換のタスクは、アプリケーション固有のビジネス・オブジェクトのキー値のうち、特定の関係インスタンス ID に対応するものを、関係表から取得することです (動詞が Update、Delete、Retrieve のいずれかである場合のみ )。「相互参照」変換では、動詞が Create の場合、アプリケーション固有のキー値は取得されません 。
「相互参照」変換に従って、汎用ビジネス・オブジェクトの動詞を基に関係表で実行されるアクションを、表 96 に示します。
表 96. SERVICE_CALL_REQUEST 呼び出しコンテキストのアクション
汎用ビジネス・オブジェクトの動詞 | 「相互参照」変換により実行されるアクション |
---|---|
Create | アクションは行いません。
呼び出しコンテキストが SERVICE_CALL_RESPONSE の場合、メソッドにより新規エントリーが関係表に実際に書き込まれます。詳細については、"SERVICE_CALL_RESPONSE 呼び出しコンテキスト"を参照してください。 |
Update、Delete、Retrieve |
|
表 96 からわかるように、動詞が Create の場合、「相互参照」変換のために生成された Java コードは、関係表に新規エントリーを書き込みません。関係インスタンス ID に対応するアプリケーション固有のキー値をまだ持っていないので、この書き込み操作は実行されません。コネクターがアプリケーション固有のビジネス・オブジェクトを処理する場合、新規の行の挿入 (複数行の場合もある) が必要なことがアプリケーションに通知されます。この挿入に成功すると、アプリケーションからコネクターに通知され、コネクターにより Create 動詞とアプリケーションのキー値を使用して該当するアプリケーション固有のビジネス・オブジェクトが作成されます。
動詞がその他の動詞 (Update、Delete、および Retrieve) である場合、「相互参照」変換のために生成された Java コードは、関係表に対して読み取り操作を実行します。AppA アプリケーションに固有のビジネス・オブジェクトから AppB アプリケーション固有のビジネス・オブジェクトへの変換をサポートしている一致関係において、呼び出しコンテキストが SERVICE_CALL_REQUESTで、汎用ビジネス・オブジェクトの動詞が Update、Delete、または Retrieve である場合には、「相互参照」変換の際に、参加者 AppB に関連付けられている関係表へのアクセスが発生します (図 123 を参照)。
図 123. Update、Delete、または Retrieve 動詞を使用した SERVICE_CALL_REQUEST
呼び出しコンテキストが SERVICE_CALL_RESPONSE の場合、呼び出されるマップはインバウンド・マップです。つまり、アプリケーション固有のビジネス・オブジェクトが汎用ビジネス・オブジェクトに変換されます。インバウンド・マップはアプリケーション固有のビジネス・オブジェクトを入力として受け取り、汎用ビジネス・オブジェクトを出力として戻します。SERVICE_CALL_RESPONSE 呼び出しコンテキストは、宛先アプリケーションが新規エンティティーの固有値を作成でき、またコネクターがアプリケーション固有のビジネス・オブジェクトを戻すことを示すため、Create 動詞では重要です。
「相互参照」変換規則のタスクは、関係表内のアプリケーション固有のビジネス・オブジェクトのキー値のうち、いずれかの既存の関係インスタンス ID に対応するものを保守することです。呼び出しコンテキストが SERVICE_CALL_RESPONSE の場合、「相互参照」変換のために生成された Java コードは、次のアクションを実行します。
表 97. SERVICE_CALL_RESPONSE 呼び出しコンテキストのアクション
AppA アプリケーションに固有のビジネス・オブジェクトから AppB アプリケーションに固有のビジネス・オブジェクトへの変換をサポートする一致関係において、呼び出しコンテキストが SERVICE_CALL_RESPONSE で、AppB アプリケーションに固有のビジネス・オブジェクトの動詞が Create である場合に、「相互参照」変換のために生成された Java コードが参加者 AppB に関連付けられている関連表にどのようにアクセスするかを、図 124 に示します。
図 124. Create 動詞を使用した SERVICE_CALL_RESPONSE
呼び出しコンテキストが SERVICE_CALL_RESPONSE で動詞が Create の場合、次のアクションに応答してコネクター・コントローラーによりインバウンド・マップが呼び出されます。
コネクターは、Create 動詞を使用してアウトバウンド・マップからアプリケーション固有のビジネス・オブジェクトを受け取ると、この挿入要求をアプリケーションに送信します。このアウトバウンド・マップには、呼び出しコンテキスト SERVICE_CALL_REQUEST があります。呼び出しコンテキストが SERVICE_CALL_REQUEST の場合、「相互参照」変換の際に新規の関係インスタンスを関係表に書き込むことができません。これは、新しいインスタンス ID に対応するアプリケーション固有のキー値がまだないためです。
このアプリケーション固有のビジネス・オブジェクトは、コネクターから InterChange Server Express に送信され、コネクター・コントローラーで受信されます。
このインバウンド・マップには、新しいアプリケーション固有のキーに対応するエントリーを関係表に作成する「相互参照」変換が含まれています。
呼び出しコンテキストが SERVICE_CALL_RESPONSE で、アプリケーション固有の動詞が Create である場合には、「相互参照」変換のために生成された Java コードによって、図 125 に示すような書き込みが関係表に対して行われます。
AppB アプリケーションに固有の新しいキーは、「相互参照」変換によって AppA アプリケーション内の同等の値と関連付けられなければなりません。呼び出しコンテキストが EVENT_DELIVERY または ACCESS_REQUEST の場合、この関連付けに関して「相互参照」変換に求められるのは、新しい関係インスタンス ID の生成だけです。しかし、呼び出しコンテキストが SERVICE_CALL_RESPONSE の場合には、「相互参照」変換では新しいインスタンス ID の生成だけでは不十分です。代わりに、すでに AppA キー値に割り当てたものと同じ関係インスタンス ID を AppB キー値に割り当てる必要があります。このメソッドは、マップの実行コンテキストの一部である、オリジナル要求ビジネス・オブジェクトからの AppA キー値と関連付けされたインスタンス ID を取得します。
呼び出しコンテキストが SERVICE_CALL_RESPONSE で、動詞が Create である場合には、「相互参照」変換のために生成された Java コードによって、以下の手順が実行されます (図 125 を参照)。
EVENT_DELIVERY (または ACCESS_REQUEST) および SERVICE_CALL_RESPONSE 呼び出しコンテキストの両方 (および Create 動詞) を使用したマップの実行が完了すると、AppA と AppB の関係表は共通の関係インスタンス ID を使用してキーを関連付けます。これについて 図 126 に示します。
動詞が Update または Delete の場合 (インスタンス ID がすでに関係表に存在していれば、Retrieve の場合も)、「相互参照」変換の際に関係表に対して行われるのは、関係インスタンス ID の検索だけです。呼び出しコンテキストが SERVICE_CALL_RESPONSE で、アプリケーション固有の動詞が Delete である場合には、「相互参照」変換の際、関係インスタンスを非アクティブ化するため、追加のステップの実行が必要になります (図 127 を参照)。
図 127. SERVICE_CALL_RESPONSE で Delete 動詞に関する関係表への書き込み
呼び出しコンテキストが SERVICE_CALL_FAILURE
の場合、呼び出されるマップはインバウンド・マップです。つまり、アプリケーション固有のビジネス・オブジェクトが汎用ビジネス・オブジェクトに変換されます。SERVICE_CALL_FAILURE
の場合、インバウンド・マップはヌルのアプリケーション固有のビジネス・オブジェクトを入力として受け取り、汎用ビジネス・オブジェクトを出力として戻します。SERVICE_CALL_FAILURE
呼び出しコンテキストは、宛先アプリケーションが新規のエンティティーの固有値を作成できず、したがってコネクターがアプリケーション固有のビジネス・オブジェクトを戻すことができないことを示すため、Create
動詞では重要です。「相互参照」変換のタスクは、表 98 に示すように、すべての動詞に対して同じです。
表 98. SERVICE_CALL_FAILURE 呼び出しコンテキストのアクション
呼び出しコンテキストが ACCESS_RESPONSE
の場合、呼び出されるマップはコール・トリガー・フローの結果としてのアウトバウンド・マップです。これにより汎用ビジネス・オブジェクトがアプリケーション固有のビジネス・オブジェクトに変換されます。アウトバウンド・マップは汎用ビジネス・オブジェクトを入力として受け取り、アプリケーション固有のビジネス・オブジェクトを出力として戻します。したがって、「相互参照」変換のタスクは、表 99 に示すように、すべての動詞に対して同じです。
表 99. ACCESS_RESPONSE 呼び出しコンテキストのアクション
ACCESS_RESPONSE のオリジナル要求ビジネス・オブジェクトはアプリケーション固有のビジネス・オブジェクトなので、「相互参照」変換により、マップの実行コンテキスト (cwExecCtx) 内のオリジナル要求ビジネス・オブジェクトからキー値が自動的に取得されます。
「相互参照」変換では、オリジナル要求ビジネス・オブジェクトへのアクセスが可能である限り、表 99 のタスクを実行できます。しかし、ある場合にはこのビジネス・オブジェクトにアクセスできないことがあります。例えば、「相互参照」変換では、基本要求に存在しない子オブジェクトを処理するとき、その子ビジネス・オブジェクトの関係インスタンス ID の検索を試みます。該当する関係インスタンスが見つからない場合は、その子オブジェクトのキーに CxIgnore 値を設定します。
「相互参照」関係の定義については、"一致関係の相互参照"を参照してください。
子ビジネス・オブジェクトに固有なキー属性がある場合、単純一致関係でこれらの子ビジネス・オブジェクトを関連付けできます。
次のセクションで、この単純一致関係をコーディングする手順を説明します。
子ビジネス・オブジェクト間の単純一致関係の関係定義を作成するには、次の手順を実行します。
ヒント: 子ビジネス・オブジェクトを展開して、キー属性を選択します。
親ビジネス・オブジェクトのマップ (メイン・マップ) で、子ビジネス・オブジェクトを含む属性にマッピング・コードを追加します。この属性の Activity Editor で、次の手順を実行して単純一致関係をコーディングします。
General/APIs/Identity Relationship/Maintain Child Verb 関数ブロックの最後のパラメーターは boolean 値フラグであり、子オブジェクトが複合関係に参加しているかどうかを示します。この子オブジェクトは複合一致関係でなく単純一致関係に参加しているため、General/APIs/Identity Relationship/Maintain Child Verb 関数ブロックへの最後の引き数は false にする必要があります。 子オブジェクトにサブマップが存在する場合は、General/APIs/Identity Relationship/Maintain Child Verb 関数ブロックを呼び出してから、サブマップを呼び出します。詳細については、"ソース子動詞の設定"を参照してください。
サブマップで、以下の手順を実行します。