このセクションでは、データベース接続プールが役立つような状況を いくつか示します。
ビジネス・オブジェクト内の 1 つ以上のフィールドの値に応じて、ビジネス・オブジェクトを別の宛先アプリケーションへ経路指定することが、ビジネス・プロセスのロジックで指示される場合があります。
例えば、CustomerType などの属性の値に応じて、異なるアプリケーションでサイトが顧客エンティティーを 保管および処理する場合があります。この場合、コラボレーション・テンプレートは、その属性の値を 検索および評価し、その値に基づいてどの宛先アプリケーションへ ビジネス・オブジェクトを送信するかを決定する必要があります。
Java ではこれを制御フロー構造で実行できますが、値と宛先アプリケーションのペア化はコラボレーション・テンプレート内に ハードコーディングされます。プロシージャーの変更のために変更が必要な場合や 新しい値やアプリケーションがインターフェースに導入されたために 追加が必要な場合は、コラボレーション・テンプレートを変更および再コンパイル して、再配置する必要があります。
それよりも柔軟な実装では、値と宛先アプリケーションのペア化がデータベース表に保管されます。そうした方法を実装するには、以下の手順を実行します。
ルーティング値 | 宛先アプリケーション値 |
---|---|
Customer | AppA |
Federal | AppB |
Reseller | AppC |
Academic | AppD |
表内で同等の値をルックアップすることによって、値を変換しなければならない場合もあります。多くの場合、こうした操作はルックアップ関係の実装によって行いますが、ルックアップ関係の使用が常に意味をなすわけではありません。ルックアップ関係は、インターフェースに含まれた各アプリケーションが 独自の方法でデータの断片を表現する必要があるような状況のために特に 設計されています。そのため、各アプリケーションごとに参加者が作成され、統合ブローカーが各アプリケーションを接続するのとほぼ同じ方法で、ルックアップ関係自体が各参加者を接続します。値を他の値のいずれかに変換しなければならないが、インターフェースに含まれる各アプリケーションのために そのデータの個別の表現を保持する必要はないという場合もあります。そのような場合は、関連する値を保管するための表をリポジトリー内に 作成し、データベース接続と SQL SELECT ステートメントを使用して目的の値を 検索する必要があります。
さらに、ルックアップ関係用の API を使用すると、アプリケーション間で関連データを容易に抽出することができますが、より複雑な照会の助けにはなりません。ルックアップ関係 API は、データの断片を受け取り、そのデータが 関係内で他のアプリケーション・データの断片と共有しているキー値を戻すか、またはキー値を受け取り、それに関連したデータの断片を戻すために設計されています。ただし、ルックアップ関係 API は、複数の列値を戻すことや、ストアード・プロシージャーを実行することはできません。これは、CwDBConnection クラスの API が実行できます。
この要件は、データベース照会ではなく、「if/else」ステートメントや「switch/case」ステートメントなどの制御構造 を使用することによって Java コードで満たすこともできます。それぞれの方法について次に示す利点と欠点を考慮し、状況に応じて適切な方法を選択してください。
ビジネス・インテグレーション・システムのオペレーションに関する情報を、データベースに保管して永続的なものにし、問題解決や履歴分析のために参照できるようにしたいと考える顧客もいます。
この要件を満たすには、以下の手順を実行します。
通常、こうした要件には、コラボレーションが処理中の ビジネス・オブジェクトに含まれる情報 (処理中のエンティティーの 基本キーなど) またはシステム自体に関する情報 (ビジネス・オブジェクト要求 の正常な処理など) の永続化が含まれます。ビジネス・オブジェクト・プローブ機能を使用して、基本キー値などのビジネス・オブジェクト・データを永続化することができます。詳細については、「コラボレーション開発ガイド」を参照してください。