このセクションでは、CollaborationFoundation テンプレートに基づいてコラボレーションをカスタマイズする場合に役立つ情報を提供します。以下のセクションを参照してください。
このセクションでは、製品に用意されているコラボレーションのコードに合わせてコードを標準化するためのコーディング方法について説明します。
コラボレーション・テンプレートで使用する命名規則を確立することは優れた手法です。具体的な命名規則のいくつかを以下に示します。
例えば、ストリング変数名のプレフィックスには文字「s」を、Boolean 変数名のプレフィックスには文字「b」を付けます。次のコードは、この 2 つの変数を初期化します。
String sExceptionType Boolean bBranch
bSendEmail = getConfigProperty("SEND_EMAIL");
Process Designer では、triggeringBusObj という BusObj タイプの変数が自動的に宣言されます。
この変数は、シナリオを実行するフロー・トリガー (通常はトリガー・イベント) を保持します。
サービス呼び出しを通じてフロー・トリガーが送信された後にフロー・トリガーにデータを追加したり、属性値を操作するなど、処理の完了後もフロー・トリガーで作業する必要のある状況がいくつかあります。このような状況は次のとおりです。
これらの状況を対処するには、フロー・トリガーを変更するのではなく、フロー・トリガーのコピーである中間 BusObj 変数を作成した後、必要に応じて中間変数を操作し、サービス呼び出しを通じてこれを送信することを推奨します。
コラボレーションが長期存続ビジネス・プロセスとして構成されている場合には、フロー・トリガー・ビジネス・オブジェクト (triggeringBusObj) の内容はサービス呼び出し間で保持されません。この場合は、必ずフロー・トリガーのコピーを作成してください。
あるビジネス・オブジェクトの内容を別のビジネス・オブジェクトにコピーする機能を提供する API がいくつかあります。それぞれの API には利点と欠点があり、copy() メソッドの使用および duplicate() メソッドの使用で各アプローチについて説明します。
copy() メソッドを使用して、あるビジネス・オブジェクト変数の内容を同じタイプの別のビジネス・オブジェクト変数にコピーできます。WebSphere Business Integration Server Express に用意されているコラボレーション・テンプレートでも同じなので、この方法を使用することをお勧めします。用意されたコンポーネントとカスタム・ビルド・コンポーネントの間で一貫性を保てば、保守容易性も向上します。
このアプローチを使用するには、トリガー・ビジネス・オブジェクトと同じタイプの BusObj オブジェクトの新規インスタンスを作成する必要があります。このとき、シナリオのシナリオ定義でインスタンスを作成し、コピーの BusObj を格納する変数に命名することを推奨します。これらの要件および推奨事項を満たすために、シナリオのシナリオ定義に次のコードを追加します。
BusObj processingBusObj; processingBusObj = triggeringBusObj.duplicate();
次に、processingBusObj 変数上で copy() メソッドを実行し、そこに triggeringBusObj 変数を引き数として渡す必要があります。
シナリオの (変数を初期化するために排他的に使用する) トップレベル・ダイアグラムの最初のアクション・ノードでこれを実行することを推奨します。次のコード例は、triggeringBusObj 変数の内容を processingBusObj 変数にコピーします。
processingBusObj.copy(triggeringBusObj);
例えば、次のコード・フラグメントは、フロー・トリガーと同じ型の変数を宣言し、そのフロー・トリガーのビジネス・オブジェクトの中の値をコピーして値を設定します。
BusObj processingBusObj; processingBusObj = triggeringBusObj.duplicate();
コラボレーションは必要に応じて、processingBusObj を使用してデータを操作します。宛先アプリケーションにデータを送信する準備が整うと、コラボレーションは中間変数を ToBusObj 変数にコピーします。コラボレーションは、宛先アプリケーションへのサービス呼び出しで ToBusObj を使用します。次のコード・フラグメントは、データを ToBusObj にコピーするステートメントを示します。
ToBusObj.copy(processingBusObj);
サービス呼び出しの結果がコラボレーションに正常に戻ると、コラボレーションは次に示すように ToBusObj の値を triggeringBusObj にコピーします。
triggeringBusObj.copy(ToBusObj);
WebSphere Business Integration Server Express のコラボレーションでは通常、コラボレーションが To ポートから戻される ToBusObj を受け取るまでは、triggeringBusObj の元の値を変更しません。中間変数を使用すると、コラボレーションは宛先アプリケーションから正常に値を受け取った後にのみ triggeringBusObj の値を変更するようになります。
例外は、発生したレベルでキャッチし、コラボレーションの中のトップ・プロセスで生成させてください。例外をキャッチすることで、例外の処理方法を指定したり、ユーザーへの提示方法を制御できます。例えば、例外が生成したコンテキストを解明できます。さらに、例外処理のためのアクション・ノードを作成して、例外が生成する可能性のあるコード内のそれぞれの位置を示す文書を表示できます。
すべてのコラボレーションで、トラップした各例外をコラボレーション・ランタイム環境に達するまでに生成させる必要があります。別のコラボレーションを起動するサービス呼び出しを使用する場合、呼び出し側コラボレーションはそのサービス呼び出しの結果として例外が生成していないか検査する必要があります。
例外テキストを呼び出し側ダイアグラムに生成させるには、メッセージ・テキストと例外のタイプを格納するためにそれぞれ別個のストリング変数を宣言してください。例えば、次のコードはこのようなストリング変数を宣言します。
String sMessage String sExceptionType
サービス呼び出しが成功したか、または失敗したかに応じて異なる動作を提供するには、分岐を使用します。失敗を処理する分岐では、2 つのストリング変数に値を割り当てます。以下に例を示します。
sMessage = currentException.getMessage(); sExceptionType = currentException.getType();
サービス呼び出しを行ったプロセスに制御を戻す前に、例外を生成させます。
以下に例を示します。
raiseException(ServiceCallException, 4000, SendRefBusObj.getType(), SendRefBusObj.getVerb(), SendRefBusObj.keysToString(), sExceptionType, sMessage);
上記のコードは、エラー・メッセージ 4000 を指定します。これはコラボレーションの失敗に対する標準のエラー・メッセージです。メッセージ・ファイルには次のテキストが含まれます。
4000 コラボレーションが失敗しました: キー ({3}) を持つ {1}.{2} の同期が失敗しました。 例外は {4}.{5} です。[EXPL] ビジネス・オブジェクトを宛先で同期させることができませんでした。
前述のテキストで、raiseException() メソッドは表 13 に示す値を置換します。
表 13. raiseException() 呼び出しで置換される値
変数 | 置換されるテキスト |
---|---|
{1} | SendRefBusObj.getType() が戻す値 |
{2} | SendRefBusObj.getVerb() が戻す値 |
{3} | SendRefBusObj.keysToString() が戻す値 |
{4} | sExceptionType 変数の値 |
{5} | sMessage 変数の値 |
サービス呼び出しを行うプロセスがコラボレーション内の最上位のプロセスではない 場合、そのサービス呼び出しを行うプロセスは呼び出し側プロセスに例外を生成させる必要があります。呼び出し側プロセスより上位の各プロセスも、最上位プロセスからエラー・メッセージを記録できるように例外を生成させる必要があります。
コラボレーション・ダイアグラムのフローが、コラボレーションの構成プロパティーの値に基づいて作成されていることがよくあります。
コラボレーションはプロパティー値を使用して boolean 変数を設定することができます。この値は採用する経路を決定するために後で使用されます。例えば、次のコードは、bBranch という名前の boolean 変数を宣言して初期化します。
boolean bBranch = false;
InterChange Server Express では分岐変数の値は、コード内の条件に従って設定されます。これらの条件は、いくつかの boolean 変数の値に基づいて設定することができます。例えば、コラボレーションの CONDITION_ONE プロパティーが true と評価される場合のみコラボレーションが CONDITION_TWO プロパティーを評価するとします。
次のコードは、2 つの boolean 変数の値に基づいて分岐するようにします。
次のコードは、CONDITION_ONE が true、CONDITION_TWO が false と評価される場合に、bBranch の値を true に設定します。つまり、CONDITION_ONE が false と評価されるか、CONDITION_TWO が true と評価される場合は、bBranch の値を false に設定します。
if ( bCondition1 && !bCondition2 ) { bBranch = true; } else { bBranch = false; }
ラッパー・コラボレーション とは、別のコラボレーションのビジネス・オブジェクトの検査または同期を処理するコラボレーションです。呼び出し側コラボレーションは、自身のフロー・トリガーで参照されるトップレベルのビジネス・オブジェクトをラッパー・コラボレーションに送信します。
例えば、SalesOrderProcessing コラボレーションは汎用 Order ビジネス・オブジェクトを同期できます。汎用 Order には、注文を行う顧客を表す汎用 Customer ビジネス・オブジェクトへの参照が含まれます。また、汎用 Order には汎用 OrderLineItem ビジネス・オブジェクトの配列も含まれます。各 OrderLineItem は汎用 Item ビジネス・オブジェクトを参照し、注文された品目を表します。
コラボレーション・ロジックをモジュール化する目的で、汎用 Order とこれが参照する汎用ビジネス・オブジェクトを処理するための個別のコラボレーション・テンプレートを用意することができます。例えば、Customer ビジネス・オブジェクトと Item ビジネス・オブジェクトを参照する Order を処理するには、以下のテンプレートを使用できます。
ビジネス・オブジェクトの処理をそれぞれ異なる特定のコラボレーションに分けると、各コラボレーション・テンプレートの再利用が増えるだけでなく、2 つのコラボレーションが同じデータを同時に変更しないようにします。詳細については、"並行処理の問題点"を参照してください。
このセクションでは、CollaborationFoundation コードに対する以下の共通の変更事項について説明します。
このセクションで示す変更を行って、カスタマイズされたコラボレーションを製品に用意されているコラボレーションに合わせて標準化します。
ビジネス・オブジェクトが自身の処理に影響する別のビジネス・オブジェクトを参照するとき、そのビジネス・オブジェクトは従属データを持つといいます。例えば、ユーザーのサイトで、Order、Customer、および Item ビジネス・オブジェクトを同期したいとします。SalesOrderProcessing コラボレーション・オブジェクトが各 Order を同期する前に、Order に参照される Customer が宛先アプリケーションにすでに存在することを確認する必要があります。さらに、各 OrderLineItem に参照される Item も宛先アプリケーションに存在することを確認したり、参照先ビジネス・オブジェクトが存在することを確認するまで Order の同期を停止したりする必要がある場合があります。このような場合、Order オブジェクトは参照先の Customer オブジェクトと Item オブジェクトの存在に依存します。
WebSphere Business Integration Server Express では、Customer または Item ビジネス・オブジェクトを参照するトリガー・ビジネス・オブジェクトを持つコラボレーションが複数用意されているので、単一のインストールでは、同じ Customer データまたは Item データの同期を試みる複数のコラボレーション・オブジェクトが同時に実行されることがあります。データの整合性を維持し、複数のコラボレーションが同じタイプのビジネス・オブジェクトの同じインスタンスを同時に変更しないようにするには、参照先ビジネス・オブジェクトの同期を代行させて、コラボレーション・オブジェクトを分離することをお勧めします。コラボレーションは中間ラッパー・コラボレーションを呼び出して、自身のトリガー・ビジネス・オブジェクトで参照しているビジネス・オブジェクトの検証または同期を処理します。ラッパー・コラボレーションは、複数のコラボレーションを実行している環境でのデータ分離を容易にします。
ラッパー・コラボレーションを使用して、複数のコラボレーションを実行している環境でデータの整合性を維持します。例えば、複数の CustomerSync コラボレーション・オブジェクトが同一インストール上で実行されているとします。1 つのオブジェクトは SalesOrderProcessing と共に実行され、その他のオブジェクトは個別に実行されます。この場合、独立した CustomerSync コラボレーション・オブジェクトは、SalesOrderProcessing コラボレーション・オブジェクトと同様に 2 つのアプリケーション間で Customer データを同期します。SalesOrderProcessing を使用して、参照値を持つ Customer ビジネス・オブジェクトの同期を中間 CustomerWrapper コラボレーション・オブジェクトに代行させる場合、ソフトウェアによってイベント分離が実行されます。つまり、独立型 CustomerSync コラボレーション・オブジェクトは、SalesOrderProcessing から呼び出された CustomerSync コラボレーション・オブジェクトと同時に同一のビジネス・オブジェクト上で作業することはできません。
トリガー・ビジネス・オブジェクトから参照されるビジネス・オブジェクトの同期についての詳細は、並行処理の問題点を参照してください。
CollaborationFoundation を拡張して、依存関係の検査を別のコラボレーションに代行させることができます。この場合、以下の操作を実行します。
従属データを代行させるには、従属ビジネス・オブジェクトごとにポートを作成します。新規ポートに ToBONameWrapper と命名して、製品に用意されている他のコラボレーションとの整合性を維持します。ここで、BOName は参照値を持つ従属ビジネス・オブジェクトです。例えば、SalesOrderProcessing は ToCustomerWrapper というポートを使用して、参照値を持つ Customer ビジネス・オブジェクトを CustomerWrapper に送信します。
ラッパー・コラボレーションに送信される、参照値を持つビジネス・オブジェクトごとに、このようなポートを作成します。例えば SalesOrderProcessing は、SendContactRef や SendItemRef という命名されたポートも使用します。
参照先ビジネス・オブジェクトの検査を別のコラボレーションに代行させるには、新規のコラボレーション構成プロパティーを作成します。このプロパティーを使用すると、コラボレーションを構成して、コラボレーションが参照先ビジネス・オブジェクトを検証または同期するか指定できるようになります。
製品に用意されているコラボレーションとの整合性を維持するには、新規プロパティーを VERIFY_SYNC_BOName と命名します。ここで、BOName は参照値を持つビジネス・オブジェクトです。
例えば SalesOrderProcessing には、Customer ビジネス・オブジェクトの検査を代行させるために使用する VERIFY_SYNC_CUSTOMER というプロパティーが含まれます。このプロパティーに使用可能な値を以下のように設定します。
デフォルトでは、VERIFY_SYNC_BOName プロパティーは neither に設定されます。
コラボレーションが参照値を持つビジネス・オブジェクトの配列を代行させる場合、配列の要素における同期または検証の障害を処理できるよう準備する必要があります。製品に用意されているコラボレーションには、検証または同期中に発生する個々の要素の障害を処理する方法を指定できる構成プロパティーがあります。
例えば汎用 Order ビジネス・オブジェクトには、OrderLineItem 子ビジネス・オブジェクトの配列が含まれています。これらの各 OrderLineItem オブジェクトは、Item ビジネス・オブジェクトを参照できます。したがって、Order ビジネス・オブジェクトを処理するコラボレーションは Item ビジネス・オブジェクトの配列を代行させることができます。同様に、汎用 Order ビジネス・オブジェクトには、OrderContactRef 子ビジネス・オブジェクトの配列が含まれています。これらの各 OrderContactRef オブジェクトは、Contact ビジネス・オブジェクトを参照できます。したがって、Order ビジネス・オブジェクトを処理するコラボレーションは Contact ビジネス・オブジェクトの配列を代行させることができます。
Order ビジネス・オブジェクトを処理する SalesOrderProcessing コラボレーションには、配列内の 1 つ以上の参照先ビジネス・オブジェクトが同期または検証に失敗した場合の対処方法を指定できる構成プロパティーがあります。
オプションの 1 つは、代行された参照先ビジネス・オブジェクトの配列内のビジネス・オブジェクトが同期または検証に失敗した場合に、トリガー・ビジネス・オブジェクトの同期を停止することです。もう 1 つのオプションは、失敗したビジネス・オブジェクトを配列から除去して、トリガー・ビジネス・オブジェクトの同期を続行することです。
失敗した参照値を持つビジネス・オブジェクトを処理するオプションをコラボレーションが評価するのは、そのビジネス・オブジェクトへの検証または同期を試行している場合のみです。したがって、コラボレーションがこのようなオプションを持つプロパティーを評価する必要があるのは、対応する VERIFY_SYNC_BOName プロパティーが verify または sync と評価される場合のみです。
Business Integration Express に用意されているコラボレーションには、配列内の参照先ビジネス・オブジェクトが検証または同期に失敗した場合にオプションを提供する、2 つの構成プロパティーがあります。プロパティーの 1 つは失敗した Contact ビジネス・オブジェクトを処理し、もう一方は失敗した Item ビジネス・オブジェクトを処理します。
Contact ビジネス・オブジェクトの配列の処理方法を以下の例に示します。この例で、SalesOrderProcessing および InstalledProductSync は、参照値を持つ Contact ビジネス・オブジェクトの配列を代行させます。どちらも FAIL_ON_CONTACT_ERROR プロパティーを使用して、呼び出し先コラボレーションが配列内の Contact オブジェクトの 1 つの検証または同期に失敗した場合のコラボレーションの振る舞いを決定します。
CollaborationFoundation を変更して Contact オブジェクトの配列を代行させる場合、他のコラボレーションとの整合性を維持してください。このためには、VERIFY_SYNC_CONTACT が verify または sync と評価され、ContactWrapper が参照先 Contact オブジェクトのいずれかの検証または同期に失敗した場合にのみ FAIL_ON_CONTACT_ERROR を評価するようにコラボレーションをコーディングします。製品に用意されているコラボレーションは、FAIL_ON_CONTACT_ERROR の値に基づいて以下の操作を実行します。
デフォルトでは、FAIL_ON_CONTACT_ERROR プロパティーは True に設定されます。
Item ビジネス・オブジェクトの配列の処理方法を説明します。WebSphere Business Integration Server Express のビジネス・オブジェクトには、Item および Contact ビジネス・オブジェクトへの参照の配列を組み込むことができます。したがって、各汎用 Order は汎用 Item オブジェクトの配列を参照できます。このため、SalesOrderProcessing を構成して、参照先 Item ビジネス・オブジェクトの配列を ItemWrapper に代行させることができます。
検証または同期に失敗した個々の Item のエラーを処理するため、SalesOrderProcessing は FIND_ALL_ITEM_ERRORS プロパティーを使用します。コラボレーションが FIND_ALL_ITEM_ERRORS を評価するのは、VERIFY_SYNC_ITEM が verify または sync と評価される場合と、ItemWrapper が参照先 Item ビジネス・オブジェクトのいずれかの検証または同期に失敗した場合のみです。
図 11 は、VERIFY_SYNC_ITEM が sync と評価され、FIND_ALL_ITEM_ERRORS が true と評価される場合に、CollaborationFoundation が参照先 Item ビジネス・オブジェクトの配列を処理する方法を示しています。
図 11. 参照先 Item ビジネス・オブジェクトの配列の処理例
コラボレーションは、FIND_ALL_ITEM_ERRORS の値に基づいて以下の操作を実行します。
デフォルトでは、FIND_ALL_ITEM_ERRORS の値は false です。
WebSphere Business Integration Server Express には、表 14 のリストにある汎用 Item ビジネス・オブジェクトが用意されています。
トリガー・ビジネス・オブジェクトが Item ビジネス・オブジェクトを参照できる場合、コラボレーション・オブジェクトの構成担当者が、検証または同期する参照先 Item のタイプを指定できるようにすることが重要です。ITEM_TYPE プロパティーにはこの機能があります。
CollaborationFoundation から作成したコラボレーションに、Item ビジネス・オブジェクトを参照するトリガー・ビジネス・オブジェクトがある場合、ITEM_TYPE プロパティーを使用するようコラボレーションを拡張します。値のセットに、システム上で使用可能なすべてのタイプの Item ビジネス・オブジェクトが含まれるように定義します。
デフォルトでは、ITEM_TYPE プロパティーは Item に設定されます。
CollaborationFoundation のメッセージを確認または変更するには、メッセージ・ファイル (collaborations¥messages¥CollaborationFoundation.txt) を編集します。依存関係検査の一部が失敗した場合は、情報を提供するメッセージを作成することによって、他の Business Integration Express のコラボレーションとの整合性を維持します。
WebSphere Business Integration Server Express の同期コラボレーションとラッパー・コラボレーションには固有のエラー・メッセージが用意されているので、CollaborationFoundation から作成されたコラボレーションには、関連するビジネス・オブジェクトの失敗した同期または検証それぞれに特定のエラー・メッセージを組み込む必要はありません。ただし、このようなカスタマイズされたコラボレーションでは、呼び出し先コラボレーションから受け取ったメッセージを明示的に処理する必要があります。これらのメッセージの処理についての詳細は、例外の生成を参照してください。
参照先ビジネス・オブジェクトの検査を別のコラボレーションに代行させるには、そのコラボレーションが参照先ビジネス・オブジェクトを検証または同期するか評価するコラボレーション・シナリオを作成する必要があります。
シナリオでは、コラボレーションの VERIFY_SYNC_BOName プロパティーの値を確認して、コラボレーションが参照先ビジネス・オブジェクトを検証または同期するよう構成されたか判断する必要があります。また、ラッパー・コラボレーションを呼び出す前に参照先ビジネス・オブジェクトに他の予備検査を実行するシナリオを作成することもできます。
例えば以下のコードでは、必要でないかぎりコラボレーションが CustomerWrapper コラボレーションを呼び出さないようにすることにより、パフォーマンスを強化しています。
// Get the value of the configuration property String vsc = getConfigProperty("VERIFY_SYNC_CUSTOMER"); // By default, do not branch to Wrapper call. bBranch= false; // If VERIFY_SYNC_CUSTOMER evaluates to "neither" or // if the source application's business object does not contain the // Customer's primary key, do not change the value of bBranch. if (vsc.equals("neither") || (processingBusObj.isNull("CustomerID")))" {} else { // Get the Customer's primary key from the source // and destination application's business objects. // Note: The DestinationAppRetrieveBusObj variable // contains a value only if the USE_RETRIEVE property evaluates // to "true" and has already been processed. String sc=processingBusObj.getString("CustomerID"); String dc=DestinationAppRetrieveBusObj.getString("CustomerID"); // If the Customer's primary key is the same in both the // source and destination application (therefore, no need to // synchronize), the verb is Update, and USE_RETRIEVE evaluates // to "true", do not change the value of bBranch. if (sVerb.equals("update") && bUseRetrieve && sc.equals.(DC) ) {} else { // If the verb is Create, or if the Customer's primary // keys are not identical and the verb is Update, call // the Wrapper collaboration. bBranch = true; } }
上記のコードを含むコラボレーション・テンプレートの例は、SalesOrderProcessing についての説明を参照してください。SalesOrderProcessing の Additional Processing 3 サブダイアグラムには、VERIFY_SYNC_CUSTOMER、VERIFY_SYNC_ITEM、および VERIFY_SYNC_CONTACT プロパティーの値を検査して、後続の複数の経路から 1 つを決定するコードが含まれます。
SalesOrderProcessing は USE_RETRIEVE ダイアグラムを処理してから Additional Processing 3 サブダイアグラムを処理するので、DestinationAppRetrieveBusObj 変数にすでに宛先アプリケーションのビジネス・オブジェクトが含まれている場合があります。
多くのビジネス・オブジェクトは、自身とは異なるタイプのビジネス・オブジェクトを参照します。例えば、Order は Customer、Contact、および Item を参照します。Order は別の Order ビジネス・オブジェクトを参照しません。Customer、Contact、および Item オブジェクトを参照できる汎用ビジネス・オブジェクトは Order のみではないので、Order を変更するコラボレーションは、参照先ビジネス・オブジェクトの処理を適切なラッパー・コラボレーションに代行させる必要があります。複数のコラボレーションを実行する環境でデータの整合性を維持するため、製品に用意されている 2 つのコラボレーションが同一タイプのビジネス・オブジェクトを変更することはありません。
ただし、InstalledProduct および Item ビジネス・オブジェクトを変更するコラボレーションを分析する場合、ビジネス・オブジェクトの変更についての説明はより複雑になります。
Order と同様に、InstalledProduct ビジネス・オブジェクトは Customer、Contact、および Item を参照できます。ただし、他の汎用ビジネス・オブジェクトとは異なり、InstalledProduct はその親も参照できます。図 12 に、複数の InstalledProduct ビジネス・オブジェクト間の関係を示します。
図 12. 複数の InstalledProduct ビジネス・オブジェクト間の関係
図 12 は、親 InstalledProduct に子 InstalledProduct が含まれていないことを示しています。その代わり、子の ParentId 属性には、String 型の親への参照が含まれています。ParentId 属性が null である InstalledProduct は、その製品階層のトップにあります。
Item ビジネス・オブジェクトには、ビジネス・オブジェクトの変更における別のレベルの複雑さもあります。表 14 に示されるように、WebSphere Business Integration Server Express には Item ビジネス・オブジェクトのファミリーが用意されています。ビジネス・インテグレーション・システムでは、Item ビジネス・オブジェクトの柔軟性を使用します。コラボレーションは Item ビジネス・オブジェクトの ITEM_TYPE プロパティーを使用して、自身がどのタイプの Item を処理するよう構成されているか判断します。
Item は別の Item を親として参照しませんが、Item ビジネス・オブジェクトは Item ファミリー内の別のビジネス・オブジェクトを前提条件として参照できます。例えば、ItemOrder と ItemPlanning は、どちらも ItemBasic を前提条件として参照できます。デフォルトでは、ItemSync コラボレーションの PREQ_ITEMORDER および PREQ_ITEMPLANNING プロパティーは、ItemBasic を Item ビジネス・オブジェクトの前提条件として指定します。
ビジネス・オブジェクトが同一タイプまたは同一タイプ・ファミリーの別のビジネス・オブジェクトを参照する場合、トリガー・ビジネス・オブジェクトを変更する同一コラボレーションは参照先ビジネス・オブジェクトを変更できます。つまり、InstalledProductSync コラボレーションはトリガー・ビジネス・オブジェクトの参照先 Customer、Contact、および Item オブジェクトの処理を代行させる必要があります。
ただし InstalledProductSync は、起動する InstalledProduct のみでなく、トリガー・ビジネス・オブジェクトの親 InstalledProduct およびその親も同期できます。さらに、ItemSync は起動する ItemOrder のみでなく、トリガー・ビジネス・オブジェクトの ItemBasic 前提条件も同期できます。トリガー・ビジネス・オブジェクトの前提条件に固有の前提条件がある場合、ItemSync はそれらをすべて同期できます。
WebSphere Business Integration Server Express には、ビジネス・オブジェクトのスタックを再帰的に処理する 2 つのコラボレーションがあります。
例えば、車を製造する組織が、製品階層内の個別の取り付け製品としてコンポーネントを管理するとします。この場合、燃料噴射装置は取り付け製品として処理され、燃料噴射装置の親 (エンジン) も取り付け製品として処理され、エンジンの親 (車) も取り付け製品として処理されます。燃料噴射装置を同期するために、InstalledProductSync はスタックを構築します。燃料噴射装置はスタックの下位に位置付けされます。コラボレーションは、スタックの最上位に車を位置付けます。同期時に、InstalledProductSync は最初に車を同期し、最後に燃料噴射装置を同期します。
InstalledProductSync は、InstalledProduct の親が InstalledProduct の作成より前に 存在しているという前提事項を基づいています。これは、従業員が雇われるより前に社長が存在するのと同じです。
ItemSync の処理が InstalledProductSync の処理と異なる点は以下のとおりです。
CollaborationFoundation を変更して再帰的処理を実行しようと計画している場合は、InstalledProductSync および ItemSync コラボレーションのコードを調べてください。これらのコラボレーションのシナリオを、CollaborationFoundation から作成したコラボレーションにコピーできます。次にこのシナリオを変更して、特定の要件に合わせることができます。これらのコラボレーションについての詳細は、InstalledProductSync および ItemSync の参照ページを参照してください。