データ・プロバイダ・サービスへのXMLデータ操作の委任

エンティティ変数を使用して、基礎となるデータ・プロバイダ・サービスがBPELデータ操作を実行するように指定できます。データ・プロバイダ・サービスはデータ・ストア内でデータ操作をバックグラウンドで実行しますが、Oracle SOA Suiteが提供する他のデータ・ストア関連の機能(たとえば、データベース・アダプタ)を使用しません。これにより、Oracle SOA Suiteの実行時パフォーマンスが向上し、コンパイルおよび実行時に、基礎となるデータ・プロバイダ・サービスのネイティブ機能が組み込まれます。

エンティティ変数は、SDOベースのデータを使用してOracle Application Development Framework (ADF) Business Componentデータ・プロバイダ・サービスと一緒に使用できます。

11gより前のリリースでは、BPELビジネス・プロセス内で交換された変数およびメッセージは、XML構造に組み込まれる分離されたペイロード(Webサービスから返されるデータのスナップショット)でした。ある場合では、ユーザーにはこの構成要素タイプが必要でした。別の場合では、この構成要素は難題でした。

エンティティ変数は、次のような11gより前のリリースの問題に対応しています。

拡張データ変換

基礎となるデータがXML形式でない場合は、データ変換(デリミタ付きテキストからXMLへの変換など)が必要でした。基礎となるデータのサイズが大きい場合、処理はパフォーマンスに影響を与える場合がありました。
失効したスナップショット・データ

(WSDLメッセージを含めて)BPEL内の変数は分離されたペイロードでした。これが必要な場合もありました。別の場合では、Oracle BPEL Process Managerの外部にある他のアプリケーションによって変数が最新データに変更されて表示されることが必要でした。つまり、分離されたデータ・モデルでは、すべてのニーズを満たさない失効したデータ・セットが提供されていました。また、スナップショットによってデータが重複するため、データ・サイズが大きい場合はパフォーマンスに影響を与えていました。
ネイティブ・データ動作の損失

一部のデータ変換の実装には、XMLスキーマの範囲外のデータ構造の適用またはビジネス・データ・ロジックが必要でした。たとえば、開始日は終了日より前である必要があります。変数が分離されたペイロードの場合は、関連するWebサービスの起動中にのみ検証が実行されました。特定の操作後(ただしWebサービスの起動前)に、特別なビジネス・データ・ロジックを必要に応じて実行することが推奨される場合がありました。

リリース11gからリリース12cまででこれらの課題に対応するには、変数宣言時にエンティティ変数を作成します。エンティティ変数は、バックグラウンドで様々なデータ・プロバイダ・サービス・テクノロジにアクセスし、プラグインするためのデータ・ハンドルとして機能します。コンパイルおよび実行時に、Oracle BPEL Process Managerは基礎となるデータ・プロバイダ・サービスにデータ操作を委任します。

表6-1では、以前のリリース(例としてデータベース・アダプタを使用)と、エンティティ変数を使用するリリース11gと12cで、データ変換がどのように実行されるかを説明します。

表6-1 以前および現在のリリースでのデータ操作機能

10.1.xリリース	エンティティ変数を使用する場合の11gと12cのリリース
データを明示的にロードして保存するようなデータ操作は、Oracle BPEL Process Managerのデータベース・アダプタにより実行されていました。すべてのデータ(たとえば、注文書)はデータベースのデハイドレーション・ストアに保存されていました。	データをロードして保存するようなデータ操作は、データ・プロバイダ・サービス(Oracle ADF Business Componentアプリケーション)により自動的に実行され、サービスを起動するコードを記述する必要はありません。 Oracle BPEL Process Managerは、注文書データを指し示すキー(たとえば、注文書ID (POID))を格納します。Oracle BPEL Process Managerは、データへのアクセスがリクエストされたときにこのキーをフェッチします(bind entityアクティビティが実行します)。キーを使用してデータをバインドするように明示的にリクエストする必要があります。データ・プロバイダ・サービスは、すべてのデータ変更をデハイドレーション・ストア・データベースとは異なるデータベースに格納します。これによりデータは重複しません。
変数内のデータはドキュメント・オブジェクト・モデル(DOM)形式でした。	変数内のデータはSDO形式であり、DOMより簡単に変換処理できます。特に、データ・プロバイダ・サービスがSDO形式に対応している場合は簡単です。

10.1.xリリース

エンティティ変数を使用する場合の11gと12cのリリース

データを明示的にロードして保存するようなデータ操作は、Oracle BPEL Process Managerのデータベース・アダプタにより実行されていました。すべてのデータ(たとえば、注文書)はデータベースのデハイドレーション・ストアに保存されていました。

データをロードして保存するようなデータ操作は、データ・プロバイダ・サービス(Oracle ADF Business Componentアプリケーション)により自動的に実行され、サービスを起動するコードを記述する必要はありません。

Oracle BPEL Process Managerは、注文書データを指し示すキー(たとえば、注文書ID (POID))を格納します。Oracle BPEL Process Managerは、データへのアクセスがリクエストされたときにこのキーをフェッチします(bind entityアクティビティが実行します)。キーを使用してデータをバインドするように明示的にリクエストする必要があります。データ・プロバイダ・サービスは、すべてのデータ変更をデハイドレーション・ストア・データベースとは異なるデータベースに格納します。これによりデータは重複しません。

変数内のデータはドキュメント・オブジェクト・モデル(DOM)形式でした。

変数内のデータはSDO形式であり、DOMより簡単に変換処理できます。特に、データ・プロバイダ・サービスがSDO形式に対応している場合は簡単です。

ノート:

現在は、BPELプロセス・サービス・コンポーネントのみがSDO形式の変数を使用できます。コンポジット・アプリケーションに、SDOベースのJavaバインディング・コンポーネント参照と接続されたOracle Mediatorサービス・コンポーネントがある場合、変数のデータ形式のデフォルトはDOMとなります。さらに、表6-1で説明したリリース10.1.xの機能は、リリース11gと12cでもサポートされています。