| Oracle® Fusion Middlewareテクノロジ・アダプタの理解 12c (12.2.1) E69958-02 |
|
 前 |
 次 |
この章では、JCAバインディング・コンポーネントを介してOracle Fusion Middlewareと統合される、Oracle JCAアダプタのインストール、起動と停止、エラー処理、構成とデプロイについて説明します。
Oracle JCAアダプタはJ2EE Connector Architecture (J2CA) 1.5標準に基づいており、Oracle Containers for Java EEにデプロイされます。Oracle JCAアダプタのライフサイクルは、Oracle Fusion Middlewareに依存します。これらのアダプタは、JCAバインディング・コンポーネントを介してOracle Fusion Middlewareと統合されます。
この章の内容は次のとおりです。
このトピックでは、Oracle JCAアダプタのインストール手順について説明します。
Oracleテクノロジ・アダプタとOracle Adapter for Oracle Applicationsは、Oracle Fusion Middlewareインストールの一部として使用可能です。これらのアダプタでは、Oracle Containers for Java EEと中間層デプロイメントの両方がサポートされています。詳細は、Oracle Fusion Middlewareのインストールのプランニングを参照してください。
SOA Foundationプロファイルによって、アダプタは論理的に2つのグループに分けられます。Tier 1とTier 2があります。
Tier 1のアダプタには、次のものが含まれます。
ファイル
FTP
データベース
JMS
AQ
MQ Series
UMS
Tier 2のアダプタには、次のものが含まれます。
ソケット
LDAP
コヒーレンス
MSMQ
JDE
SAP
AS400
Tier 1のアダプタは、このリリースをインストールすると、デフォルトで有効になります。残りのアダプタはインストール済の状態ですが、管理対象サーバーにターゲット設定されていません。これらを使用するには、手動でターゲット設定する必要があります。
レガシー・アダプタとパッケージ・アプリケーション・アダプタは、Oracle Fusion Middleware AdaptersおよびConnectors CDに収録されています。これらのアダプタでは、中間層デプロイメントのみがサポートされています。
注意:
アダプタをインストールする前に、次のページ(http://docs.oracle.com/html/E18558_01/fusion_requirements.htm)のシステム要件ドキュメントを参照してください。
JCA 1.5リソース・アダプタとしてデプロイされます。したがって、アダプタを起動または停止するには、すべてのリソース・アダプタでSPIインタフェースの一部としてstart (BootstrapContext)およびstopメソッドを実装する必要があります。開始されるのは、それらを使用するSOAコンポジットがアウトバウンド相互作用を開始するときです。また、インバウンド相互作用にSOAコンポジット自体がロードされるとき、またはアダプタによりイベントがJCAバインディング・コンポーネントにパブリッシュされるときにも、アダプタを起動できます。
アダプタの起動後に停止するには、停止するか、またはOracle Fusion Middleware内でJ2EEアプリケーションを停止します。このリリースでは、JCAバインディング・コンポーネントはJCA 1.5コンテナの一部として機能します。
コンポジットをデプロイする前に、サーバーの起動ログファイルに次のようなメッセージが表示されることがあります。これらは問題のない警告で、アダプタが適切に機能していることを表しています。
<Warning> <J2EE> <slc01aec> <soa_server1> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'>
<<WLS Kernel>> <> <57ab8b08-803c-4edb-9da9-82791e12c429-00000004>
<1372403795938> <BEA-160140> <Unresolved optional package references
(in META-INF/MANIFEST.MF): [Extension-Name: oracle.adapter.ext, referenced from: /scratch/vaspatel/fmwhome12/soa/soa/connectors
/FileAdapter.rar]. Ensure that the referenced optional package has been
deployed as a library.> <Warning> <J2EE> <slc01aec> <soa_server1>
<[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'>
<<WLS Kernel>> <> <57ab8b08-803c-4edb-9da9-82791e12c429-00000004>
<1372403796778> <BEA-160140> <Unresolved optional package references
(in META-INF/MANIFEST.MF): [Extension-Name: oracle.adapter.ext, referenced from: /scratch/vaspatel/fmwhome12/soa/soa/
connectors/FtpAdapter.rar]. Ensure that the referenced optional package has been
deployed as a library.>
図2-1 に示すように、次のいずれかの方法を使用して、「アダプタ構成ウィザード - アダプタ・インタフェース」ページでアダプタ・インタフェースを定義できます。
「アダプタ構成ウィザード - アダプタ・インタフェース」ページの後に表示されるページで、指定した操作名とスキーマを使用して生成されるWSDLを使用します。
既存のWSDLをインポートします。
この項では、既存のWSDLをインポートしてアダプタ・インタフェースを定義する方法について説明します。この機能を使用すると、既存のWSDLを使用してアダプタ・サービスまたは参照を作成できます。既存のWSDLを選択するオプションは、次のアダプタについてのみサポートされています。
Oracleソケット・アダプタ
Oracle JCA Adapter for MSMQ
Oracle JCA Adapter for UMS
Oracle JCA Adapter for Oracle JD Edwards World
Oracle JCA Adapter for LDAP
Oracle JCA Adapter for Coherence
既存のWSDLをインポートしてアダプタ・インタフェースを定義するというオプションを選択した場合、以降のウィザード・ページの一部の機能が無効になります。たとえば、WSDLでは操作名とメッセージ・スキーマを定義するため、図2-2 に示すように、以降の操作名フィールドとスキーマ要素フィールドには値が自動的に入力されて変更できません。ただし、既存のWSDLを使用するように選択しなければ、アダプタ・ウィザードの動作は変わりません。
アダプタ構成ウィザードは、他のアダプタとは異なって表示されます。ポート・タイプや操作などのコールバックを選択するための追加オプションがあります。
アダプタ構成ウィザードの以降のオプションは、選択したポート・タイプと操作に応じて有効または無効になります。
たとえば、アダプタ構成ウィザードを使用して定義する場合、コールバックを選択すると、「MQにメッセージを送信し、リプライ/レポートを取得」およびMQからメッセージを取得し、リプライ/レポートを非同期で送信オプションのみが有効になります。
コールバックを選択しなかった場合は、「MQにメッセージを蓄積」および「MQからメッセージを取得」オプションのみが有効になります。
同期リプライを含むWSDL操作を選択した場合は、MQからメッセージを取得し、リプライ/レポートを同期で送信オプションが有効になります。既存のWSDLを使用する場合、CICSまたはIMSスキーマを使用するオプションは無効になります。
注意:
既存のWSDLをインポートする最も一般的な方法は、最初にOracle BPELプロセスまたはメディエータを作成し、それらのWSDLファイルをスキーマ(またはNXSD)から定義します。これが完了すると、アダプタ・サービスが作成され、BPELプロセスまたはメディエータ・コンポーネントに作成されたWSDLファイルが既存のWSDLファイルとしてインポートされます。
ただし、この機能はスキーマ要素を使用するメッセージにのみ機能することに注意する必要があります。単純型と複合型はサポートされていません。
Oracle JCAアダプタにより、基礎となるバックエンド操作固有のプロパティがメッセージ・ヘッダー要素として公開され、これらの要素をビジネス・プロセス内で操作できるようになります。
これらのプロパティが公開されているため、Fusion Middleware ControlコンソールでOracle JCAアダプタのプロパティを追加または削除したり元に戻すことができます。ただし、プロパティのタイプによっては、プロパティの変更を適用するには、コンポジット・アプリケーションを再デプロイする必要があります。
注意:
SOAコンポジット・エディタのプロパティ・インスペクタを使用して、JCAプロパティを変更できます。ただし、この方法で変更を実行する場合、変更したプロパティの検証は行われません。
表2-1 に、構成できるメッセージ・ヘッダー・プロパティのタイプおよび再デプロイが必要かどうかを示します。
表2-1 Oracle JCAアダプタのプロパティ・タイプ
| プロパティ・タイプ | 説明 | 制限 |
|---|---|---|
アクティブ化仕様および相互作用仕様 |
SOAコンポジット・アプリケーション内で、アクティブ化仕様プロパティはサービスとして機能し、相互作用仕様プロパティは参照として機能します。 |
これらのプロパティは追加したり削除しないでください。値の変更のみが可能です。 これらのプロパティには、リサイクル対象のアダプタ・エンドポイントが必要です。これらのプロパティ・タイプは、他のプロパティにも依存しています。プロパティを追加する場合、他にも追加する必要がある従属プロパティを把握する方法はありません。 |
エンドポイント |
これらは、アクティブ化仕様プロパティまたは相互作用仕様プロパティを介して公開されない、チューニングに関連するプロパティ(タイムアウト、しきい値、最大間隔などを指定する)です。 |
エンドポイント・プロパティの追加、削除または変更には制限がありません。プロパティが追加、削除または変更されるとアダプタに通知が送信されますが、アダプタによる再デプロイメントは不要です。
|
詳細は、「Oracleファイル/FTPアダプタのプロパティ」を参照してください
コンテナにJCA 1.5リソース・アダプタとしてデプロイされます。アダプタは、Javaアーカイブ(JAR)フォーマットを使用してリソース・アダプタ・アーカイブ(RAR)ファイルとしてパッケージ化されます。
アダプタの物理デプロイでは、RARファイルを使用して、基礎となるWebLogic Serverまたは中間層プラットフォームにアダプタをコネクタとして登録します。
注意:
アダプタに変更を行った後、サーバーを再起動してデプロイメントを更新する必要があります。そうしなければ、行った変更は有効になりません。構成プラン・ファイルに構成の変更を保存した後、デプロイメントを更新して変更を反映する必要があります。
デプロイメントの更新アクションによって、新しいプラン・ファイルが各サーバー・インスタンスのステージング・ディレクトリに同期されます。その時点で、新しいデプロイメント・プランがソースでアクティブになります。
RARファイルには、リソース・アダプタに関するデプロイ固有の情報を含んだデプロイメント・ディスクリプタXMLファイルra.xmlが含まれています。さらに、RARファイルには、Oracle Containers for Java EEとリソース・アダプタの間の規定に関する宣言情報も含まれています。
アダプタでは、.rarファイル内のra.xmlファイルのみでなく、weblogic-ra.xmlテンプレート・ファイルもパッケージされます。weblogic-ra.xmlファイルは、リソース・アダプタのConnectorFactoryオブジェクトの定義に使用されます(論理デプロイ)。weblogic-ra.xmlファイルは、リソース・アダプタ用のOracle Containers for EE固有のデプロイメント・ディスクリプタです。これにはリソース・アダプタをWebLogic Serverにデプロイするためのデプロイ構成が含まれています。これには、リソース・アダプタのデプロイメント・ディスクリプタで指定されたバックエンド・アプリケーションの接続情報、使用するJava Naming and Directory Interface (JNDI)名、接続プーリング・パラメータ、リソースのプリンシパル・マッピング・メカニズムおよび構成などが含まれます。
| ファイル | 目次 |
|---|---|
RARファイル |
リソース・アダプタに関するデプロイ固有の情報を含みます。 Oracle Containers for Java EEとリソース・アダプタの間の規定に関する宣言情報を含みます |
|
リソース・アダプタの リソース・アダプタをWebLogic Serverにデプロイするためのデプロイ構成を含みます。 リソース・アダプタのデプロイメント・ディスクリプタで指定されたバックエンド・アプリケーションの接続情報を提供します。 使用するJava Naming and Directory Interface (JNDI)名を提供します。 接続プーリングのパラメータを提供します。 リソースのプリンシパル・マッピング・メカニズムを提供します。 構成情報を提供します |
設計時環境とデプロイ先サーバーの間の接続性を確立する必要があります。このような接続性を確立するには、アプリケーション・サーバー接続を作成する必要があります。
次の手順に従ってアプリケーション・サーバー接続を作成します。
図2-3 に示すように、「新規ギャラリ」ページが表示されます。
図2-4 に示すように、「アプリケーション・サーバー接続の作成」ページが表示されます。
図2-5 に示すように、「認証」ページが表示されます。
図2-6 に示すように、「アプリケーション・サーバー接続の作成 - 構成」ページが表示されます。
図2-7 に示すように、「アプリケーション・サーバー接続の作成 - テスト」ページが表示されます。
SOAコンポジット・アプリケーションはJDeveloperからデプロイします。
JDeveloperでは、デプロイするSOAプロジェクトおよびアプリケーションに対してプロファイルを使用する必要があります。この項では、JDeveloperによるプロファイルの作成およびデプロイ方法について説明します。
この項では、SOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする方法を説明します。アプリケーションをデプロイするには、次の手順を実行する必要があります。
JCAアダプタの設計時の構成ウィザード画面をキャプチャしたJCAアダプタ・メタデータは、サーバーにデプロイされるときに検証されます。
たとえば、/in/valid/directoryのPhysicalDirectory値を選択していて、SOAサーバーがこのメタデータを使用してアダプタのデプロイを試行する場合、(ファイル)アダプタはすべてのメタデータを参照し、1つまたは複数のメタデータが正しくない場合は例外をスローします。
これにより、JDeveloperでデプロイメント・アクションのロールバックが発生します。アダプタは、実行時に、すべての参照およびJNDI名付きのJCAコネクション・ファクトリが使用可能なこと(エラーなく参照できること)を検証します。データソースとコネクション・ファクトリが使用可能な場合は、デプロイメントが検証され、処理が続行されます。
Oracle SOAプラットフォームの11xxシリーズのリリースからプロジェクトを移行した場合、そのプロジェクトに対するデプロイメントの検証ロジックは施行されません。そのため、以前のコンポジット・アプリケーションは中断しません。
この項では、jarファイルが関連付けられていないアダプタRARファイルを手動でデプロイする方法について説明します。
META-INF/ra.xmlとMETA-INF/weblogic-ra.xmlのみを含み、JNDIの作成に必要なjarファイル・アダプタが含まれていない任意のアダプタRARファイルをデプロイする場合は、デプロイ時に、Oracle WebLogic Serverがアダプタのjarファイルのロード後にこのRARファイルをデプロイできるよう、デプロイメント順序を高い値(500など)に変更する必要があります。
たとえば、META-INF/ra.xmlとMETA-INF /weblogic-ra.xmlのみを含み、新しいJNDIのインスタンス化に必要なjarファイル・アダプタ(DbAdapter.jar)が含まれていないDBAdapter_NewJndis.rarファイルをデプロイする場合は、次の手順を実行できます。
注意:
この場合、DBAdapter_NewJndis.rarファイルをデプロイした後で、デプロイメント順序をより高い値に変更する必要があります。これにより、Oracle WebLogic Serverを再起動した場合でも、Oracle WebLogic ServerによってDBAdapter_NewJndi.rarファイルが正しくデプロイされます。
次の手順に従って、jarファイルが関連付けられていないアダプタRARファイルを手動でデプロイします。
AdminserverがコンピュータAで実行中で、Oracle SOA ServerがコンピュータBで実行中の場合は、Oracle SOA Serverで行った変更内容をアクティブ化する前に、デプロイメント計画ファイルをコンピュータBにコピーする必要があります。
デプロイメント計画をOracle SOA Serverコンピュータにコピーせずに変更内容をアクティブ化しようとすると、NullPointerExceptionがスローされます。
アダプタ構成ウィザードによって生成されたすべてのJCAファイルにはJNDIへの参照があります。参照はweblogic-ra.xmlファイルに定義されていますが、これはアダプタのデプロイメント・ディスクリプタです。
JNDI名は開発環境からテスト環境または本番環境に移行する際のキーとなります。
開発、テストおよび本番の3つのすべての環境でJNDI名が同一になるようにweblogic-ra.xmlファイルを更新する必要があります。
再試行間隔や再試行回数などのデプロイメント時のプロパティの値を指定し、テスト環境または本番環境に再デプロイする必要があります。
weblogic-ra.xmlはエンドポイントを開発EIS、テストEIS、または本番EISとして識別します。たとえば、データベース・アダプタ・サービス・ウィザードを通じて実行しているときは、eis/DB/custStoreをcreateCustomerサービスのJNDI名として指定します。
このアダプタ・サービスを使用してコンポジットをモデル化した後は、一切の変更を行わずに開発、テストおよび本番環境にデプロイする必要があります。ただし、デプロイの前に、正しいEISインスタンスを指している各環境に、eis/DB/custStoreに対応するJNDIエントリがあることを確認してください。
要約:
すべてのJCAファイルはweblogic-ra.xmlファイルに定義されたJNDI名を参照します。
デプロイするすべての環境でJNDI名が同じになるようにweblogic-ra.xmlファイルを更新する必要があります。
weblogic-ra.xmlデプロイメント・ディスクリプタを使用して、再試行間隔や再試行回数などのデプロイメント時のプロパティの値を指定します。このファイルは、エンドポイントの環境も識別します。
デプロイメントの前に、適切な環境に対応するJNDIエントリがあることを確認します。
このトピックでは、出力メッセージとreplyアクティビティを追加して、一方向の非同期BPELプロセスを同期させるプロセスについて説明します。
メッセージを順序付けるには、BPELプロセスを同期させます。成功した後、BPELエンジンへのメッセージをパブリッシュするリソース・アダプタ・スレッドをBPELインスタンス全体の実行に使用します。
非同期BPELプロセスの場合は、BPELエンジンのワーカー・スレッド・プロセスがメッセージを受信します。そのため、1つのBPELインスタンスがほぼ他のプロセスからのものになるため、メッセージの順序付けは保証されません。
通常、1つのJCAリソース・アダプタのウィザードでは、一方向の (非同期) WSDL、つまり操作に入力メッセージのみを含むWSDLのみが作成されます。WSDLを生成したウィザードは手動で変更し、入力メッセージと出力メッセージを含むリクエスト-レスポンス (同期) タイプのWSDLにする必要があります。
<types> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://acme.com/adapterService/"> <import namespace="http://TargetNamespace.com/adapterService/type" schemaLocation="adapterTypes.xsd" /> . . . <element name="empty"> <complexType/> </element>
<message name="ignoreMessage"> <part name="empty" element="tns:empty"/> </message>
<portType name="Receive_ptt"> <operation name="Receive"> <input message="tns:payloadMessage"/> <output message="tns:ignoreMessage"/> </operation> </porttype>
<binding name="Receive_binding" type="tns:Receive_ptt"> <pc:inbound_binding /> <operation name="Receive"> <jca:operation .../> <input/> <output/> </operation> </binding>
<variables> <variable name="ignore" messageType="ns1:ignoreMessage"/> . . . <sequence name="main"> <receive partnerLink="ReceivePL" portType="ns1:Receive_ptt" operation="Receive" variable="Receive_1_Read_InputVariable" createInstance="yes"/> . . . <!-- processing --> <invoke partnerLink="DB_Insert" portType="ns1:DB_Insert_ptt" operation="InsertCust" inputVariable="NewCust"/> <reply partnerLink="ReceivePL" portType="ns1:Receive_ptt" operation="Receive" variable="ignore"/> . . . <!-- optionally more processing --> </sequence>
この例のリソース・アダプタがマルチスレッド・インバウンドをサポートしている場合は、複数スレッドの確率的な遅延によってメッセージ順序付けが保証されなくなるため、1つのスレッドのみを使用するよう構成/調整します。
この項では、メッセージの損失がないことをアダプタで保証する方法について説明します。
トランザクション・アダプタによって、エンタープライズ情報システム(EIS)は1フェーズ・コミットまたは2フェーズ・コミット(ローカル・トランザクションまたはグローバル/分散トランザクション)に参加できます。
非トランザクション・アダプタはトランザクション・セマンティクスを使用せずに、配信を確保する固有のスキームを実装します。
この項では、次の内容について説明します。
詳細は、次を参照してください。
XAの目標は、同一のトランザクション内から複数のリソース(データベース、アプリケーション・サーバー、メッセージ・キュー、トランザクション・キャッシュ)にアクセスできるようにすることです。XAは2フェーズ・コミットを使用して、すべてのリソースがどのようなトランザクションでも一貫してコミットまたはロールバックするようにします。
XAの仕様には、リソース・マネージャがトランザクション・アクセスをサポートするために実行する必要のある手順が記述されています。この仕様を順守するリソース・マネージャはXA準拠であると呼ばれます。
XAトランザクションは、複数のリソースを操作する場合に使用するシナリオの一部です。たとえば、2つ以上のデータベース、データベースとJMS接続、またはこれらのすべてとアダプタ、これらがすべて単一のトランザクション内にある場合などです。
トランザクション・アダプタにより、XAトランザクション・サポートが有効になります。これは、固有のデータ処理とともに、それぞれの変更の結果が明確に定義されるようにして、成功または失敗の結果、データが破損する可能性を防止します。他の変更とは独立して実行され、完了すると、基礎となるデータは他のトランザクションが発生するまで同一の状態に置かれます。
XAは2フェーズ・コミット・プロトコルで、1フェーズ・コミット/エミュレート・プロトコルよりも堅牢です。1フェーズ・プロトコルやエミュレート・プロトコルでは、メッセージが消失したりロールバック/コミットの不整合が発生する可能性があります。
XAトランザクションはアプリケーション・サーバーのトランザクション・マネージャによって開始されるトランザクションです。すべてのXAリソースは任意のアクティブなグローバル・トランザクションに参加する必要があり、トランザクション・マネージャのシグナルによってのみコミットまたはロールバックされます。シグナルの受信後にコミットが失敗した場合は、最終的にコミットが必ず行われるようなリカバリ・メカニズムも存在している必要があります。
未参加のローカル・リソースはアクティブなグローバル・トランザクションに関係なくローカル・トランザクションを開始または終了できます。コミットは即座に実行される可能性があり、これはトランザクション・マネージャからのシグナルへの応答ではありません。コミットに失敗するとトランザクションはロールバックされ、例外がスローされます。コミットを同期する他のリソースがないため、このトランザクションの特別なリカバリは不要です。
アダプタではra.xmlデプロイメント・ディスクリプタ・ファイルのtransaction-support要素を指定することによって、トランザクション・サポートのタイプが定義されます。
アダプタは基礎となるアプリケーション・サーバー・トランザクション・マネージャを利用するJCA 1.5 XA規定でグローバル・トランザクションをサポートします。
基礎となるアプリケーション・トランザクション・マネージャを利用するアダプタのタイプには、Oracle Adapter for Oracle Applications、データベース、アドバンスト・キューイング、JMSおよびMQSeriesアダプタなどがあります。
基礎となるトランザクション・マネージャを利用しない非トランザクション・アダプタには、Oracleファイル・アダプタとOracle FTPアダプタがあります。
グローバル・トランザクションの参加者はだれでもグローバル・トランザクションにロールバックのマークを付けることができます。グローバル・トランザクションにロールバックのマークが付けられると、他の参加者がロールバックを取り消すことはできなくなります。
フォルト・タイプは、エラーが再試行可能かどうかを示します。再試行可能な場合は、JCA再試行プロパティによって再試行が管理されます。エラー処理の項を参照してください。エラーが再試行不可能とみなされた場合、このようなエラーの処理はフォルト・ポリシーによって管理されます - その場合、フォルト・ポリシーが実行されます。これは、インバウンド・アダプタとアウトバウンド・アダプタでも同じです。
フォルト・ポリシーによって実行される操作はローカル・トランザクション内に留まり、グローバル・トランザクションには含まれません。
特に、固有のトランザクションで実行するフォルト・ポリシーは、特定の参照の実行を開始する前に既存のすべてのJTAトランザクションをコミットします(たとえば、Oracle BPEL PMでのinvokeアクティビティなど)。既存のJTAトランザクションが一時停止されてからコミットされることはありません。
非トランザクション・アダプタをトランザクション・アダプタとともに使用する際は、再試行によって非トランザクション・データに影響する場合があるため、重複するメッセージの作成などに注意してください。たとえば、メッセージの重複が発生しないようにビジネス・プロセスをモデル化するなどして、注意を払う必要があります。
デキューおよびエンキュー・レスポンスがキューにリプライするインバウンド同期リクエスト/レスポンス・シナリオは、手動リカバリの候補ではありません。そのため、再試行の上限に達した場合、失敗としてマークされます。
再試行に関するトピックの追加情報は、「拒否されたメッセージの処理」およびそれ以降の項を参照してください。
ポーリング: すべてのレガシー・アダプタは、プル、つまりポーリングをサポートしていますが、これは、イベントを受信する、つまりEISエンドポイントに使用可能なメッセージおよびデータを定期的に問い合せるためにバックエンド・アプリケーションに接続するモデルです。この例外は、異なるロジスティクスのセットを使用しますが、その場合、ソケット・アダプタは、他のアダプタがクライアント・ソケットを使用して接続するのと同じようにEISエンドポイントに接続する(ポーリング)か、サーバー・ソケットを作成してから着信リクエストを待機できます(プッシュ)。ポーリングでは、接続関連の問題はリカバリ可能であり、インバウンド・アダプタはEISとの接続を確立できるまで再試行を続けます。アダプタ・エンドポイントは、コンポジットがアクティブな期間中、失われた接続の回復を試行します。また、この期間中、接続の問題を特定する診断でログを更新します。
ローカル再試行: 通常は、一時的な接続エラーです。再試行を再び試行でき、再試行によってデータが壊れることはありません。ただし、連続しないローカル再試行はトランザクション状態を変更できます。再試行可能なエラーの例には、一時的な権限エラーまたはリソース制限エラー、あるいはその両方が含まれます。トランザクションが再試行可能な場合、これは必ずしもロールバックを意味するとはかぎりません。
グローバル再試行: コンポジットの開始点(BPELがコンポジットの一部であるBPEL Receiveなど)にロールバックされるトランザクションで、BPEL Receiveは、コンポジット・アプリケーション内のBPELフロー内の開始点にあります。トランザクションは無制限に再試行することも、jca.count.retryが示す回数だけ再試行することもできます。再試行の前に、ロールバックが発生する可能性があります。たとえば、同期プロセスにBPELフォルトがある場合、マスターおよび子レコードによるデータベースの部分更新があり、一時的なデータベース・フォルトが発生して、toplinkマッピング・ロジックにより再試行が受入可能であると決定された場合などです。つまり、データが損なわれていないために明示的な再試行とみなされ、ロールバックが必要な場合、グローバル再試行が行われる可能性があります。
再試行不可: 再試行されないトランザクション。再試行不可の状態では、既存の状態の変更はありません。再試行なしの条件は、バインディング・フォルトから導出されます。通常、再試行不可の状況は、データベースの整合性が問題である場合に発生します。したがって、再試行不可のトランザクションが拒否された場合、ロールバックされます(通常、このトランザクションはデータベース制約の問題に関連しています)。「データがすでに存在します」などのエラー(主キー・エラーなど)は、メッセージ相関IDエラーと同様に、再試行できません。再試行できないエラーのリストは、この章の後半にあります。
インバウンド・トランザクション: インバウンド・アダプタによって開始されたトランザクションです。たとえば、JMSシステムからSOAシステムに入るトランザクションなどです。
アウトバウンド・トランザクション: SOAシステムからの(つまり、アダプタからの)アウトバウンド・トランザクションです。たとえば、SOAシステムの外部でデータベースに対して作成されたトランザクションなどです。
JTAトランザクション: プロセスの各ステップはJTAトランザクションのコンテキスト内で実行されます。JTAトランザクションでは1つ以上の操作がアトミック作業ユニットとして実行されます。XAについては、前述の項を参照してください。
非同期トランザクション: サブトランザクションで構成されるコンポジット・トランザクションです。ただし、これらのサブトランザクションは連続的でシリアライズされているため、一部のサブトランザクションがコミットされても、他のサブトランザクションが実行中であったり、まだ実行されていない場合があります。非同期トランザクションはただ1回のみ伝播されることが保証されています。ソースの更新がコミットされると、トランザクションがコミットされ、ターゲットに対する更新が適切に伝播されることが予期されます。
同期トランザクション: 中間プロセスなしに、あるエンドポイントから別のエンドポイントへ1つのスレッドで実行されるトランザクションです。これはシリアライズされていません。
次の項では、非同期トランザクションと同期トランザクションについて、JMS、DB、BPELテクノロジの標準的なアダプタの組合せを通じて説明します。例ではメディエータなどの他のアダプタや他の手段が使用されている場合もあります。
非同期サービス・エントリ・ポイントの場合、トランザクション・アダプタはコンポジットにインバウンド・メッセージを送信する前に、グローバルJTAトランザクションを開始します。
次に示す例では、JMSアダプタにバインドされたテスト・コンポジットを使用し、JMSアダプタは、この例ではBPELにバインドされたコンポジットにバインドされ、BPELはDBアダプタにワイヤリングされます。BPELはメッセージをDBアダプタにディスパッチします。
この例では、メッセージはポーリングJMSアダプタによってJMSから読み込まれ、BPELプロセスに書き込まれます、BPELプロセスではトランザクションがコミットされます。これはJTA1(最初のXAトランザクション)です。
再試行が不可能な、または再試行回数の上限に達したBPELアクティビティ・エラーについては、BPELは情報を格納するリカバリ表に書込みを行います。この情報にはBPELエラーが含まれます。
2番目のトランザクションJTA2は、BPELディスパッチ表から読み取るDBアダプタで始まり、データベース挿入引数を取得して、更新メッセージをDBアダプタに書き込みます。このトランザクションJTA 2は参照エンドポイントDBアダプタ(つまり、SOAからのアウトバウンド)からデータベース自体へのアウトバウンドを続行します。データベース内の重複するデータ状況からの再試行状況は、DBアダプタからBPELの表に再試行されるか、データベースからDBアダプタに再試行されます。
エラー処理のグローバル再試行は、BPEL Receiveアクティビティ・インスタンス、または通常はトランザクションが開始された位置に戻ります。このような再試行は、一時的なデータベース・フォルトなどのエラーがあった場合に行われる可能性があります。デフォルトの再試行回数は無制限(デフォルト)、またはjca.retry.countプロパティで指定された回数です。
2番目のXAトランザクションJTA2の一部でエラーが発生した場合は、ロールバックが発生します。
同期プロセスでは、アダプタによって開始されるグローバル・トランザクションは次の両方にわたります。
メッセージの配信
コンポジットの実行
非同期トランザクション・フローと同様、デフォルトの再試行回数は無制限で、jca.count.retryで指定できます。
同期トランザクション・フローは非同期フローと似ていますが、次の点が異なります。
フローは、JMSアダプタと中間処理(BPEL処理など)の間、およびBPELとデータベース・アダプタの間(同じ例を使用)のリクエスト-レスポンス・メッセージで構成されます、データベース・アダプタには、挿入などを要求するメッセージが書き込まれます。同期トランザクションでは、再試行可能なエラーはコンポジット内のBPEL (例の中間状態)によって捕捉されません。トランザクションは、最終的にJMSアダプタに返され、グローバル再試行が行われる可能性があります。
同期トランザクションは単に1つのJTAトランザクションであり、2つのトランザクションではありません。
アダプタ拒否表は、アダプタ拒否のレコードを保持します。同期トランザクションのコンテキスト内では、ローカルのBPELエラー処理はバイパスされます。同期トランザクションでは、プライベートBPEL表には関連するアダプタ拒否データは含まれません。かわりに、データはアダプタ拒否表に保持されます。
再試行回数の上限に達したローカル再試行はBPELリカバリ表に格納されます。
同期の例で使用されているのと類似の例を使用して、同期メッセージ・フローの例が非同期における例に対し、トランザクションを通じてたった1つのJTAトランザクションJTA 1で構成されていたことを思い出すと、処理は簡単です。トランザクションはサービス・エンドポイントへのポーリングされたインバウンド・メッセージで開始され、JMSでのメッセージの読取り、BPELプロセスへの書込みが行われます。
非同期トランザクションとは異なり、同期トランザクションでは、JTAトランザクションはこの時点ではコミットされません。
かわりに、同じJTAトランザクションは参照エンドポイントDBアダプタからデータベース自体へのアウトバウンドを続行します。その後、BPELからメッセージが読み込まれ、BPELからの挿入引数を使用してDBアダプタが起動されます。この時点でJTAトランザクションがコミットされます。
非同期トランザクションと同様、再試行はグローバルに行われ、jca.retry.countプロパティで指定された回数に従います。この例では、ローカルで再試行可能なフォルトはデータベースからBPELプロセス、またはデータベースからDBアダプタに戻って試行されます。
インバウンド・アダプタは独立したワーク・スレッドで実行します。アダプタは接続のリカバリを行い、固有の再試行プロパティを使用します(たとえば、adapter.jms.retry.intervalなど)。
トランザクション・アダプタはコンポジットにインバウンド・メッセージを送信する前に、グローバルJTAトランザクションを開始します。
トランザクション・アダプタの場合、再試行はローカル再試行(BPELリモート・フォルトなど)、グローバル再試行、または再試行なし(バインディング・フォルトと同様)のいずれかになります。グローバル再試行はトランザクションが開始した場所に返されます。デフォルトの再試行回数は無制限ですが、jca.retry.countで指定された回数のみ再試行可能です。
アダプタに制御が戻ると、アダプタはJTAトランザクションをコミットし、次の一連の操作をアトミック作業ユニットとして実行します。
インバウンド・アダプタ・エンドポイント(表やキューなど)からのメッセージの削除をコミットします。
コンポジット・インスタンスの実行をコミットします。
この一連のコミット操作、つまりメッセージの削除とコンポジット・インスタンスの実行においていずれかの操作が失敗すると、操作は両方ともロールバックされます。
Oracle JCAアダプタの起動を含むすべてのアウトバウンド・トランザクション・コンポジット・アクティビティは、グローバル・トランザクションの一部です。エラーが発生すると、デフォルトの動作では、すべてのアクティビティはコミットされるかまたはロールバックされるかのいずれかになります。
たとえば、BPELプロセスは異なるInvokeアクティビティを通じて、(異なるデータベースの)複数の表にデータを挿入できます。
BPELインスタンスが終わりに近づくと、JTAトランザクションがコミットされます。
データベースの挿入操作はこの時点でのみコミットされます。
ただし、BPELインスタンスの実行中にエラーが発生した場合、すべてのアクティビティ(およびそれに伴うデータベース操作)は最後のBPELデハイドレーション・ポイント(最後にBPELインスタンスがデータベースに格納された時点)までロールバックされます。
アウトバウンド・トランザクションが再試行可能かどうかは、特定の相互作用の性質および範囲によって異なります。具体的には次のとおりです。
たとえばデータベースの整合性など、アウトバウンド・トランザクションのターゲット側で整合性を伴う相互作用は再試行されません。
単一レコードでの些細なデータベースの問題など、ローカル再試行が可能な条件が存在する場合は、ローカル再試行が行われます。
たとえばマスター詳細レコードと子レコードの両方を更新するような問題など、エラーが解消する余地のあるより複雑なデータベース整合性のシナリオにおける再試行では、トランザクションは最初のBPEL Receiveまでロールバックされ、再び開始される場合があります(BPELを使用するシナリオの場合)。再試行はここでもjca.retryに従いますが、他のいずれかのBPELエラー処理の再試行パラメータに従う場合もあります。
アダプタからのアウトバウンドの接続上の問題は、一般に、常に再試行可能です。アウトバウンド・トランザクションでは、アダプタは接続が確立できない場合に再試行可能例外をスローし、これにより適切なJCAバインディングが再試行します(jca.retry.countを経由)。
アウトバウンド相互作用に関連する接続の再試行可能なエラーの例には、データベース・リスナーが起動されていないために発生する接続エラーなどがあります。
WebLogicプラットフォームではOracle WebLogic Serverの移行が使用されているため、管理サーバーに障害が発生した場合に、同じ物理システムまたは別の物理システム上でそのサーバーが自動的に再起動し、障害が発生したサーバー上のコンポジットに固有のインバウンド・アダプタの機能が再開されます。
その間に、他のクラスタ・メンバー上のインバウンド・アダプタはメッセージ・サービス処理を続行できます。
詳細は、次を参照してください。
JCAバインディング・コンポーネントでは、インバウンド・アダプタ・サービスのアクティブ・フェイルオーバーがサポートされています。
このフェイルオーバー機能を特定のインバウンド・アダプタのエンドポイントに対して有効にするには、次のサンプル・コードに示すように、singleton JCAサービス・バインディング・プロパティ(composite.xml)を<binding.jca>要素に追加し、値をtrueに設定する必要があります。
この機能を無効にするには、singletonプロパティの値をfalseに設定します(または、<binding.jca>要素からプロパティを削除します)。
例 - composite.xmlのシングルトン・プロパティ
<service name="JmsTopicSubscr" ui:wsdlLocation="JmsTopicSubscr.wsdl">
<interface.wsdl interface=
"http://xmlns.oracle.com/
...#wsdl.interface(Subscr_ptt)"/>
<binding.jca config="JmsTopicSubscr_file.jca">
<property name="singleton">true</property>
</binding.jca>
</service>
Oracle WebLogicクラスタでは、同一(JMSなど)のアダプタ(インバウンド)のエンドポイント(特定のコンポジット・サービス向け)の複数のアクティブ化が、クラスタ内でアクティブなアダプタ・フレームワークのすべてのインスタンスによって、暗黙的かつ自動的に検出されます。
ただし、メッセージの読取りまたはパブリッシュを開始できるアクティブ化は1つのみです。
JCAバインディング・コンポーネントのインスタンスによって、プライマリのアクティブ化の役割を引き受ける1つのアクティブ化がアクティブ化の中からランダムに選択されます。
Oracle WebLogicクラスタ内の他のアクティブ化(インスタンスとも呼ばれる)は、JCAリソース・アダプタでEndpointActivationを起動せずにホットスタンバイ状態で開始されます。これらのアクティブ化にプライマリのアクティブ化の役割を再度割り当てることができます。
プライマリのアクティブ化がある時点で応答しなくなったり、手動で非アクティブ化されたり、クラッシュまたは終了した場合、Oracle WebLogicクラスタの残りのJCAバインディング・コンポーネント・メンバーのいずれかが即座にこの非アクティブ化を検出し、スタンバイ状態のアクティブ化エージェントの1つにプライマリのアクティブ化の役割を再度割り当てます。
詳細は、「コンポジットの可用性とインバウンド・アダプタ」を参照してください。
ネイティブ相関を使用し、コールバック・インタフェース(参照用)を定義するか、中間プロセスBPEL Receiveによって、インバウンド非同期メッセージを前のアウトバウンド・メッセージに関連付けることができます。
たとえば、次のコンポジットではそのような相関が定義されます。
<reference name='Outbound'>
<interface.wedl
interface="http://xmlns.oracle.com/pcbpel/demo#wsdl.interface
(JMSOutbound_PortType)"
callbackinterface=
"http://xmlns.oracle.com/pcbpel/demo#wsdl.interface
(JMSCallback_PortType)"/>
<binding.jca.operation="Consume"
config="SampleOutbound_adapter.jca"/>
jcaファイルにはJCA相互作用とJCAアクティブ化の両方が含まれている必要があります。
リクエストとレスポンスの間の関連付けはJCAバインディング・ランタイムによって透過的に行われます。
JMSの使用例では、サード・パーティ・アプリケーションはリクエスト・メッセージのJMSメッセージIDをレスポンス・メッセージのJMS相関IDにコピーする必要があります。
使用例の場合は、外部アプリケーションによってリクエスト(起動)メッセージのMessageIdがレスポンス(受信)メッセージのCorrelationIdにコピーされると、アダプタ・フレームワークによってBPEL相関が確実に発生します。
ただし、受信メッセージのCorrelationIdが以前のどの起動メッセージとも一致しない場合、メッセージは実際に存在しないBPEL対話にマップされます。
この場合、メッセージはデータベースに保持されますが、次のサンプル・コードに示すようなSEVEREログ・メッセージが表示される場合があります。
例 - receiveのcorrelationIdが前の起動のいずれとも一致しない場合のログ・エラー
SEVERE: JCABinding=> aqadapter
aqadapterAdapter Service aqadapter was
unable to perform delivery of inbound message
to the composite ... due to: Cannot
simply post callback message to the composite
as there is no
service element associated with the callback.
Recommendation:
add/set the JCA reference/binding property
'rejectUncorrelatedMessages' to true ...
SEVERE: JCABinding=> aqadapter Unable to
create/save Composite Instance Fault due to: null
次のサンプル・コードに示すように、rejectUncorrelatedMessagesサービス・バインディング・プロパティをcomposite.xmlファイルに追加して、一致しないネイティブ相関IDを拒否するようにアダプタ・フレームワークの動作を明示的に変更できます。
例 - rejectUncorrelatedMessagesプロパティの設定
<reference name="ReqReply" ui:wsdlLocation=
"ReqReply.wsdl">
<interface.wsdl
interface="http://xmlns.oracle.com/pcbpel
/adapter/mq/MQAsyncSol_ReplyQ_
NonRelatedMsg/SOA_AsyncSol_ReplyQ_NonRelatedMsg/
ReqReply/#wsdl.
interface(Enqueue_ptt)"
callbackInterface="http://xmlns.oracle.com/
pcbpel/adapter/mq/
MQAsyncSol_ReplyQ_NonRelatedMsg/
SOA_AsyncSol_ReplyQ_NonRelatedMsg/ReqReply/
#wsdl.interface(Dequeue_ptt)"/>
<binding.jca config="ReqReply_mq.jca">
<property name="rejectUncorrelatedMessages">
true</property>
</binding.jca>
</reference>
rejectUncorrelatedMessagesがtrueに設定されている場合、相関付けできない受信メッセージはアダプタ・フレームワークによって拒否されます。つまり、パブリッシュしているJCAリソース・アダプタにプッシュバックされます。
デフォルトでは、このプロパティはfalseに設定されます。
詳細は、次を参照してください。
システム・リソースは有限であり、処理にはしきい値制限があります。システム・リソースに依存するOracle SOA Suiteにも一定のサイズ制限がありますが、大部分は基礎となるリソースに起因するもので、これを超える受信リクエストの処理は実行できません。
たとえば、大きなペイロードを処理できますが、Oracle BPEL PMは大きなペイロードを処理する際に多くのメモリーを消費し、この結果OutOfMemory条件が発生し、システム全体が影響を受ける場合があります。
OutOfMemoryなどのエラーを回避するには、ペイロードしきい値を設定する必要があります。ペイロードしきい値を設定すると、しきい値制限よりも小さいペイロードを処理し、その他を拒否することを保証できます。この項では、ペイロードの相対サイズに関する考慮事項について説明します。
ペイロードのネイティブ・サイズを使用できる場合、関連するアダプタはペイロードのネイティブ・サイズを使用して、しきい値制限を超えないようにペイロードのサイズを制限します。
たとえば、Oracleファイル・アダプタではポーリングされたファイルのネイティブ・サイズを使用できます。サイズがペイロード・サイズのしきい値を超える場合、ファイルは拒否されます。
ペイロードのネイティブ・サイズを使用できない場合、たとえばよくあるケースですが、アダプタはペイロードのネイティブ・サイズを内部で計算する必要があります。
非XMLの変換またはシリアライズXMLの解析にネイティブ変換ライブラリを使用して、ネイティブ・サイズを内部で特定できます。
Oracleデータベース・アダプタは変換フレームワークに依存していませんが、ネイティブ・メッセージのサイズを計算するための特別な処理メカニズムが組み込まれています。
注意:
エラー・リカバリでのデバッチ処理の場合、ペイロード・サイズしきい値を慎重に使用する必要があります。ペイロード・サイズの違反により、誤りのあるレコードの場合、ストリームのスキップ中に不当な拒否が発生することがあります。
ペイロードしきい値は、公開されるノブを使用して設定できます。次のサンプルに示すように、ノブはアダプタ・サービスのバインディング・プロパティとしてcomposite.xmlファイルで設定できます(1000の値はバイト単位です)。
<binding.jca config="getMsg_mq.jca"> <property name="payloadSizeThreshold" type="xs:string" many="false"override="may">1000</property> </binding.jca>
ペイロードのネイティブ・サイズを使用できず、かつ、特定のアダプタでネイティブ変換ライブラリが使用されない場合、ペイロード・サイズしきい値制限を強制できません。たとえば、Oracleファイル/FTPアダプタがファイル・コンテンツのチャンクを渡し、実際のネイティブ・サイズが不明であるXMLデバッチ処理の場合は、ペイロード・サイズしきい値制限を使用できません。また、シリアライズされたXMLペイロードについて、ネイティブ変換ライブラリのかわりに、ネイティブ・サイズを計算する機能がないXDKパーサーが解析に使用される場合にも、ペイロード・サイズしきい値制限を使用できません。
XSDおよび不透明(Opaque)トランスレータ・シナリオは、ペイロード・サイズが決定されるアダプタでのみ処理できます。特定のサポートされているシナリオの詳細は、表2-2を参照してください。
表2-2 サポートされている変換シナリオ
| シナリオ | |||||
|---|---|---|---|---|---|
NXSD |
はい |
はい |
はい |
はい |
適用なし |
XSD |
はい |
はい |
はい |
いいえ |
はい |
不透明(Opaque) |
はい |
はい |
はい |
いいえ |
適用なし |
DTD |
いいえ |
いいえ |
いいえ |
いいえ |
適用なし |
また、ペイロード・サイズを制限するグローバル・プロパティを設定して、payloadSizeThresholdのデフォルト値を(無限から)有限数に変更できます。この場合、payloadSizeThresholdのデフォルト値を有限数に設定すると、特定のインバウンド・アダプタのエンドポイントのpayloadSizeThresholdプロパティ値を明示的に構成しない場合にも、グローバル・デフォルトが有効になります。グローバル・デフォルトをcomposite.xmlの値とともに指定した場合、composite.xmlで指定した値によってグローバル値がオーバーライドされます。
Fusion Middleware ControlのMBeanブラウザ(アダプタMbean)を使用して、このグローバル・プロパティを変更できます。この変更は、すべての現在および将来のエンドポイントに対して即座に有効になります。
Oracle JCAアダプタは、インバウンド処理とアウトバウンド処理の両方で大きなペイロードの処理をサポートしています。ただし、ストリーミング機能を明示的にサポートしているのは次のアダプタのみです。
Oracleファイル・アダプタ
詳細は、「Oracleファイル・アダプタのスケーラブルなDOM」を参照してください。
Oracle AQアダプタ
詳細は、「ストリーム・ペイロードのサポート」を参照してください。
Oracle JMSアダプタ
詳細は、「大きなペイロードのストリーミング」を参照してください。
Oracleデータベース・アダプタ
詳細は、「大きなペイロードのストリーミング」を参照してください。
他のアダプタには、両方の明示的なサポートはありません。
次のアダプタでは、バッチ機能とデバッチ機能がサポートされています。
Oracle JCA Adapter for Files
Oracle JCA Adapter for FTP
Oracle JCA Adapter for Databases
Oracle JCA Adapter for FileとOracle JCA Adapter for FTPは、単一の大型ファイルを複数のバッチにデバッチ処理するためのReaderで構成されています。設計時構成中にバッチ・サイズを指定する必要があります。さらに、アダプタには一連のメッセージを単一ファイルにバッチ処理するためのライターも組み込まれています。詳細は、「ファイルのデバッチ処理」を参照してください。
Oracle JCA Adapter for Databasesは、一連の表をポーリングしてイベントを検出するためのパブリッシュ・コンポーネントで構成されています。このコンポーネントでは、BPELプロセスの1度に1つのレコードまたは1度に複数のレコードに対してイベントを発生させることができます。詳細は、「ポーリング戦略」を参照してください。
アダプタの論理デプロイメントでは、weblogic-ra.xmlデプロイメント・ディスクリプタ・ファイル内にConnectionFactoryオブジェクトを作成します。weblogic-ra.xmlファイルには、アダプタのランタイム接続パラメータが含まれています。
接続情報を追加してJNDI名を割り当てるには、Oracle WebLogic Server管理コンソールまたはWLSTスクリプトを使用して、リソース・アダプタの対応するweblogic-ra.xmlファイルを編集する必要があります。
コネクション・ファクトリの作成の詳細は、Oracle WebLogic ServerおよびOracle Coherenceのインストールと構成を参照してください。
次の手順では、Oracle WebLogic Server管理コンソールでDatabaseコネクション・ファクトリを設定する方法について説明します。
この項には次のトピックが含まれます:
接続プールを作成する手順は、次のとおりです。
http://servername:portnumber/consoleにナビゲートします。
必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。
Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。
「ドメイン構造」の下で、「デプロイメント」をクリックします。
「デプロイメントのサマリー」ページが表示されます。
「デプロイメント」リストでデータベース・アダプタ名をクリックします。
「DbAdapterの設定」ページが表示されます。
「構成」タブをクリックし、「アウトバウンド接続プール」タブをクリックします。
「アウトバウンド接続プールの構成表」が表示されます。
「新規」をクリックします。
「javax.resource.cci.ConnectionFactory」を選択し、「次へ」をクリックします。
「新しいアウトバウンド接続の作成」ページが表示されます。
「JNDI名:」フィールドにeis/DB/soademoDatabaseと入力します。
注意:
この手順で入力するJNDI値は、「データソースの作成」の手順5で入力した値とは異なります。この手順で指定するJNDI名は、後でアプリケーションの構築時に作成するデータベース接続に入力する値と一致する必要があります。
「終了」をクリックします。
このリソース・アダプタのアウトバウンド接続プール・グループとインスタンスの表を示す「DbAdapterの設定」ページが表示されます。
構成の変更内容は、新規デプロイメント計画に格納する必要があります。これを次のステップで行います。
「パス」フィールドで、デプロイメント計画ファイルのパスを選択または入力します。パスは「.xml」で終了する必要があります。
注意:
AdminserverがコンピュータAで実行中で、Oracle SOA ServerがコンピュータBで実行中の場合は、Oracle SOA Serverで行った変更内容をアクティブ化する前に、デプロイメント計画ファイルをコンピュータBにコピーする必要があります。
デプロイメント計画をOracle SOA Serverコンピュータにコピーせずに変更内容をアクティブ化しようとすると、NullPointerExceptionがスローされます。
「プロパティ」フィールドに、xADataSourceNameの値としてjdbc/soademoDatabaseを入力します。
「保存」をクリックします。
注意:
この手順のように「保存」をクリックした時点ではプロパティが保存されません。かわりに、変更内容を保存するには[Enter]を押す必要があります。
「ドメイン構造」の下で、「デプロイメント」をクリックします。
「デプロイメントの概要」が表示されます。
次の手順を実行します。
「DbAdapter」チェック・ボックスを選択し、「更新」を選択します。
「アプリケーション更新アシスタント」ページが表示されます。
「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します」オプションを選択します。
「次へ」をクリックして、「完了」をクリックします。
選択したデプロイメントが更新されたことを示す「デプロイメントのサマリー」ページが表示されます。
「ドメイン構造」で、「デプロイメント」、「DbAdapter」、「構成」および「アウトバウンド接続プール」を順にクリックします。
ステップ11で入力したxADataSourceプロパティの値が「接続ファクトリ・インタフェース」タブに表示されます。
注意:
アウトバウンド接続プールについて新規の値を追加する場合、管理対象サーバーや管理サーバーを再起動する必要はありません。ただし、既存の接続プールのプロパティを編集した場合は、サーバーを再起動する必要があります。
新規アダプタ・コネクション・ファクトリを追加するか、既存のアダプタ・コネクション・ファクトリを更新できます。
アダプタ・コネクション・ファクトリを追加または更新する場合は、次の手順のいずれかを実行して、コンポジットで新規アダプタ・コネクション・ファクトリのプロパティが使用されていることを確認する必要があります。
次の手順を実行します。
コンポジットは新しく作成されたJNDIからプロパティを取得します。
JCAアダプタ・コネクション・ファクトリ用の新規JNDIを作成します。
コンポジットの構成プランを作成します。
構成プランを作成するには、JDeveloperの設計領域でcomposite.xmlを右クリックします。表示されたメニューで「構成プランの生成」をクリックします。構成プランが生成されます。
JCAファイルでJNDIの論理名を指定します。
たとえば、次のサンプルで、jndi-nameは論理JNDI名です。
<connection-factory location="jndi-name" adapterRef=""/>
構成計画で、論理名を新規JNDIの絶対値に置き換えます。
たとえば、次の例では、論理JNDI名jndi-nameは、絶対値eis/MQ/MQSeriesAdapter7に置き換えられています。
<wsdlAndSchema
name="DQ1.wsdl|DQ1_mq.jca
|EQ1.wsdl|EQ1_mq.jca|monitor.config">
<searchReplace>
<search>jndi-name</search>
<replace>eis/MQ/MQSeriesAdapter7</replace>
</searchReplace>
</wsdlAndSchema>
コンポジットで新規アダプタ・コネクション・ファクトリのプロパティが使用される場合、再起動を回避するには、次の手順を実行する必要があります。
Oracle WebLogic Server管理コンソールのホーム・ページにログインします。
「ドメイン構造」ペインで「デプロイメント」を選択します。
「Oracle WebLogic Server管理コンソール - デプロイメントのサマリー」ページが表示されます。
新しいコネクション・ファクトリを追加したアダプタを選択します。
「更新」をクリックします。
「アプリケーション更新アシスタント」ページが表示されます。
「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します」オプションを選択します。
「次へ」をクリックして、「完了」をクリックします。
選択したデプロイメントが更新されたことを示す「デプロイメントのサマリー」ページが表示されます。この手順を使用して、たとえば、再起動の必要なしにアダプタのエンドポイントを変更できます。
WebLogicコンソールを使用すると、JMSで使用するコネクション・ファクトリを作成できます。「Oracle WebLogic Server管理コンソールを使用した新規接続の作成」を参照してください
この項では、Oracle JCAアダプタで使用する非XAデータソースとXAデータソースの推奨設定について説明します。
マルチ・データ・ソースの推奨設定は、次のとおりです。
test-frequency-secondsを5に設定します
algorithm-typeをLoad-Balancingに設定します。
data-source-listでは、カンマ区切りの子データソース・リストを指す必要があります。たとえば、(JDBC Data Source-0,JDBC Data Source-1)を指定します。
エンドポイント・プロパティがOracle RACデータベースに常駐する場合は、マルチ・データソースを使用します。
表2-3 に、Oracle JCAアダプタで使用するXAデータソースと非XAデータソースの推奨設定を示します。
表2-3 XAデータソースと非XAデータソースの推奨設定
| XAデータソース | 非XAデータソース |
|---|---|
使用するドライバは |
使用するドライバは |
JDBC URLには次のフォーマットを使用する必要があります。 jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=service_name)(INSTANCE_NAME=inst1))) |
XAデータソースと同じです。 |
次のプロパティを設定する必要があります。 <property> <name>oracle.net.CONNECT_TIMEOUT</name> <value>10000</value> </property> |
XAデータソースと同じです。 |
|
XAデータソースと同じです。 |
|
XAデータソースと同じです。 |
|
XAデータソースと同じです。 |
|
XAデータソースと同じです。 |
|
XAデータソースと同じです。 |
|
XAデータソースと同じです。 |
|
|
|
該当なし |
|
該当なし |
|
該当なし |
注意:
表2-3 に示した設定は、単一インスタンスとOracle RACデータベースの両方のタイプのデータベースに適用可能です。Oracle RACデータベースの場合は、エンドポイント用に作成されたマルチ・データソースを構成するデータソースに、これらの設定を使用する必要があります。詳細は、Oracle RACのドキュメント(http://www.oracle.com/technetwork/database/options/clustering/documentation/index.html)を参照してください。
表2-3 で説明している設定の適用に加えて、『Oracle WebLogic Server JTAアプリケーションの開発』のOracle Thin/XAドライバの使用に関する手順を実行する必要があります
これらの手順は、XAドライバを使用するデータソースに必須です。前述のリンクで記述されている手順を実行した後、次のSQL文を実行してWLS JTAリカバリが機能できるようにする必要があります。
grant select on sys.dba_pending_transactions to public GRANT FORCE ANY TRANSACTION TO public grant execute on sys.dbms_xa to public
利用できるエラー処理機能を次の項に示します。これらの拒否ハンドラは、同期プロセスでのみ適用可能です。非同期プロセスや一方向プロセスには適用されません。
この項には次のトピックが含まれます:
サービス・インフラストラクチャにポストされる前にエラーになったメッセージは、拒否されたメッセージと呼ばれます。たとえば、CSVフォーマットのデータを含んだファイルを取得し、XMLフォーマットに(NXSDを使用して)変換しようとします。その場合、変換中になんらかのエラーがあると、このメッセージは拒否され、ターゲット・コンポジットにはポストされません。
拒否されたメッセージを生成するのは、主としてアダプタとバインディング・コンポーネントです。
同期フローの下流で発生したエラーまたは障害は、インバウンド・アダプタによって次のように処理されます。
例外が再試行不可能な場合は、即座に拒否されます。
例外が再試行可能な場合は、無制限に再試行されます。
再試行はjca.retry.countの値(構成されている場合)と同じ回数だけ行われ、再試行回数の上限に達した場合は拒否されます。
バインディング・レベルでエラーになったメッセージはアダプタによって拒否されます。つまり、サービス・インフラストラクチャ・レイヤーに入る前にエラーになります。
拒否されたメッセージは、すべてペイロードとともにデータベースに格納されます。拒否メッセージは後から問い合せることができます。
フォルトはバインディングまたはリモートとして分類することもできます。通常、リモート・フォルトはデータベースの接続停止などの一時的な障害で再試行可能であるのに対し、バインディング・フォルトは非一時的な障害で再試行不可能としてマークされます。状況に応じて、これらの非一時的な障害も修正できます。たとえば、MQ Seriesアダプタのターゲット・キューがデータベースの完全または一意の制約違反になるようなフォルトは修正可能です。ただし、変換やトランスフォーメーションによる検証の失敗などの特定の非一時的な障害は、コンポジットを再デプロイせずに修正することはできません。バインディング・フォルトとリモート・フォルトの両方が原因で拒否されたメッセージは、リカバリ可能としてマークされます(手動リカバリの場合)。リカバリの成功はシナリオに依存します。手動リカバリが失敗する場合は、失敗したインスタンスを調査してアクションを開始する必要があります。
この項には次のトピックが含まれます:
詳細は、「アダプタ内での相関サポート」を参照してください。
10.xリリースでは、拒否ハンドラはOracle BPELプロセスのデプロイメント・ディスクリプタ(bpel.xml)内で定義されていました。
ただし、11gリリースでは、フォルト・ポリシーを使用して拒否ハンドラを定義する必要があります。
インバウンド拒否ハンドラの場合、指定できるアクション・ハンドラは1つのみです。
次の手順に示すように、fault-policies.xmlおよびfault-bindings.xmlという2つのファイルを作成し、JDeveloperのSOAプロジェクト・ディレクトリにコピーする必要があります。
注意:
「拒否ハンドラの構成」の説明に従って拒否ハンドラを構成しなければ、デフォルトのファイルベース拒否ハンドラが処理を開始し、拒否されたメッセージは<domain_home>/rejmsgs/<wls_server_name>/<composite_name>に移動されます。
また、Oracle BPEL Process Manager (Oracle BPEL PM)と同じフォルト・ポリシーで、メディエータ・コンポーネントで拒否されたメッセージを構成することもできます。
拒否メッセージはrejected_message表に格納されます。
次のいずれかの手順を使用して、拒否されたメッセージをチェックできます。メッセージを取得し、固有の実装に応じて追加処理を実行できます。
データベースからのチェックを行うには、データベースにsoainfraスキーマとして接続し、次のSQLコマンドを実行する必要があります。
select * from rejected_message
「ダッシュボード」タブの「最新のフォルトと拒否メッセージ」セクションまたは「フォルト・メッセージと拒否メッセージ」タブで、拒否されたメッセージを表示できます。
Fusion Middleware Controlコンソールを拒否されたメッセージのチェックに使用する方法の詳細は、次を参照してください。
『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のインバウンド・アダプタに対する最新のフォルトと拒否メッセージの監視に関する項。
『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のインバウンド・アダプタに対するフォルトと拒否メッセージの監視に関する項
この項では、メッセージ・エラーの処理方法についてサンプル・シナリオを使用して説明します。
図2-10 に示すように、2つのコンポジットComposite1およびComposite2があり、それぞれにOracle BPELプロセスがあり、ローカル・リソースとXAリソースが混在しています。
メッセージがすべてのキュー(Q1、Q2およびQ3)に正常に配信された場合、トランザクションは正常にコミットされます。
メッセージがQ1 (またはいずれかのキュー)に配信されず、キューQ2およびQ3に配信された場合、トランザクションは3つのメッセージすべてをロールバックする必要がありますが、これは、すべてがXAリソースであり、XAユニットのいずれかに例外が発生したためです。
ロールバック例外は、Q1が失敗した2番目のコンポジットにのみスローされます。トランザクションは3つのキューすべてのメッセージをロールバックするかわりにQ2とQ3をコミットします。
失敗したキューが1つのみで他の2つにはメッセージが正常に配信された場合も、トランザクションですべてのキューをロールバックするには、コールされたコンポジット(Composite2)のcomposite.xmlファイルを次のサンプル・コードに示すように変更する必要があります。
例 - Composite2のcomposite.xmlの変更
<component name="BPELProcess1">
<implementation.bpel src="BPELProcess1.bpel"/>
<property name="bpel.config.transaction">
required</property>
</component>
これにより、プロパティbpel.config.transactionの値がrequiredに設定され、失敗したキューが1つでもトランザクションですべてのキューがロールバックされるようになります。
bpel.config.transactionプロパティをrequiredの値に設定すると、Oracle BPELエンジンは新規トランザクションを作成せず、コール元のトランザクションを使用して同期リクエストを効果的に処理します。したがって、いずれかの時点でトランザクションがロールバックすると、そのトランザクションでの実行内容は何もコミットされません。
拒否メッセージ・ハンドラを指定することにより、インバウンド・アダプタでのエラー処理方法を決定できます。
拒否ハンドラを作成して、メッセージ・エラーを処理できます。メッセージ・エラーには変換時のエラー、相関IDの不一致、メッセージ受信後のXML解析エラーなどがあります。
メッセージ・エラーで使用可能な拒否ハンドラ
再試行可能性の点からエラー処理を検討する前に、使用可能なエラー・ハンドラを理解することが重要です。
次に示すのは、フォルト・ポリシーで構成できるシステム定義のエラー・ハンドラです。
拒否されたメッセージは、Webサービスを呼び出して処理できます。Webサービスを使用してこれらのエラーを処理する場合は、次の例に示すように、ターゲット・サービスによって実装された定義済のWSDLインタフェース、Webサービス呼出し用のSOAPバインディング、Webサービスの添付として渡されるネイティブ・ペイロードを実装する必要があります。
<Action id="ora-ws"> <invokeWS uri="WebServiceURI"/> <!-- format - <Absolute wsdl path>|service name|port name --> </Action>
Webサービス・ハンドラのWSDLインタフェースには、単一のポート・タイプ、1つの入力操作、および入力メッセージ用スキーマが必要です。これを次の例に示します。
例 - Webサービス・ハンドラのWSDLインタフェース
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xmlns.oracle.com/pcbpel/errorHandling"
xmlns:tns="http://xmlns.oracle.com/pcbpel/errorHandling"
elementFormDefault="qualified">
<element name="RejectedMessage" type="tns:RejectedMessageType">
<complexType name="RejectedMessageType"/>
<sequence>
<element name="MessageHeader" type="string"/>
<!-- base64 encoded string -->
<element name="MessagePayload" type="string"/>
<!-- base64 encoded string -->
<element name="RejectionReason" type="string"/>
</sequence>
<attribute name="RejectionId" type="string"/>
</complexType>
</schema>
エラー処理の別のオプションでは、エラーを転送する定義済のJavaフレームワーク(インタフェース)を作成します。次の例に示すように、ターゲット・クラスによってJavaインタフェースを実装できます。
<Action id="ora-custom">
<javaAction className="mypackage.myClass"
defaultAction="ora-terminate">
<returnValue value="SUCCESS" ref="ora-file"/>
<returnValue value="FAILED" ref="ora-ws"/>
</javaAction>
</Action>
インタフェース自身はフォルト・リカバリ・クラスを指定します。インタフェースの例については、次のスニペットを参照してください。
package oracle.integration.platform.faultpolicy;
public interface IFaultRecoveryJavaClass
{
public void handleRetrySuccess
( IFaultRecoveryContext ctx);
public String handleFault( IFaultRecoveryContext ctx);}
拒否メッセージは、適切なコンテキストとペイロードとともにJMSメッセージとしてJMSキューにエンキューすることはできませんが、次の2つの例に示すようにAQアダプタを使用してこのタスクを実行できます。
最初の例は、スタンドアロン・データベースを使用します。
例 - スタンドアロン・データベースとAQアダプタを使用した拒否メッセージのエンキュー
<faultPolicies>
<faultPolicy version="2.0.1" id="MQ_ServiceFaults_MED">
<Conditions>
<faultName xmlns:rjm="http://schemas.oracle.
com/sca/rejectedmessages" name="rjm:DQ">
<condition>
<action ref="ora-enqueue"/>
</condition>
</faultName>
</Conditions>
<Actions>
<Action id="ora-enqueue">
<enqueue uri="jdbc:oracle:thin:
@//myhost.com:1521/orcl#scott/tiger#REJ_MSG_Q" />
</Action>
</Actions>
</faultPolicy>
</faultPolicies>
2番目の例は、Oracle RACデータベースとともに使用されます。
例 - Oracle RACデータベースとAQアダプタを使用した拒否メッセージのエンキュー
<Action id="ora-queue"> <enqueue uri="QueueURI"/> <!-- QueueURI format - jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS_ LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host1>)(PORT=<port1>))( ADDRESS=(PROTOCOL=TCP)(HOST=<host2>)(PORT=<port2>)))(CONNECT_DATA=(SERVICE_ NAME=<service_name>)))#<un>/<pw>#queue --> </Action>
拒否されたメッセージをファイルに格納することによって、メッセージのエラー・ハンドラを作成します。次の例に示すように、適切なコンテキストとともにペイロードを格納できます。ペイロード・ファイルは、構成した場所に作成されます。
<Action id="ora-file"> <fileAction> <location>FOLDER_LOCATION</location> <fileName>FILE_NAME</fileName> <!-- FILE_NAME will support %ID%(rejected message instance id) or %TIMESTAMP% wildcards --> </fileAction> </Action>
データベース内でのエラーのペイロードの永続性は、デフォルトで有効になっています。ファイル・アダプタ・ハンドラの場合にのみ、拒否されたメッセージのプロパティをすべて含んだメタデータ・ファイルが作成されます。
たとえば、このメタデータ・ファイルにはインバウンド方向やファイル名などの情報が含まれます。メタデータ・ファイルの場所はペイロード・ファイルと同じで、ネーミング・パターンは<FILE_NAME>_metadataです。
拒否メッセージの再発行には、ペイロードの永続性が必要です。ペイロードはデータベースに格納され、Fusion Middleware Controlコンソールを介してペイロード表示機能を使用できます。デフォルトのエラー・ハンドラへのペイロードの指定に加えて、メッセージ/ペイロードは構成された各エラー・ハンドラに完全に指定されます。
インバウンドの再試行可能なエラーは通常、一時的な接続エラーです。インバウンド・アダプタによって再試行が行われるのは、アウトバウンド・バインディングによってスローされた同期プロセスの再試行可能なエラーのみです(回数はデフォルトでは無制限であり、jca.retry.countプロパティの設定によって制限されます)。JTAトランザクションはいずれも再試行の前にロールバックされます。
アウトバウンド・アダプタによってスローされる再試行可能なエラーの例には、接続エラーだけでなく、一時的な権限エラーまたはリソース制限エラー、あるいはその両方も含まれます。
「データがすでに存在します」などのエラー(主キー・エラーなど)は再試行できません。また、メッセージ相関IDエラーは再試行できません。
設定された再試行回数の上限に達した場合、拒否メカニズムによってエラーが処理されます。
インバウンド・アダプタを構成して、インバウンドの再試行可能なエラーを処理できます。次のプロパティはインバウンド相互作用の再試行可能な例外のためにサポートされており、composite.xmlファイル内に指定できます。
デフォルトでは、インバウンド・エラーは無制限に再試行されますが、アダプタの再試行はコンポジット(ローカル)アプリケーションのレベル、またはグローバル・レベルで行われます。
コンポジットでプロパティを構成した後、サービス・レベルではプロパティの構成に意味があります(たとえば、拒否前に再試行回数を構成すると、間隔プロパティの値はデフォルト値になります)。
composite.xmlファイルでは、次のプロパティを指定できます。
jca.retry.count
拒否までの再試行回数の最大値を指定します。この値の指定は、他のプロパティの値を指定するための前提条件です。
jca.retry.interval
再試行間の時間間隔(秒単位)を指定します。
jca.retry.backoff
再試行間隔の増加係数(正の整数)を指定します。
jca.retry.maxInterval
再試行間隔の最大値、つまりバックオフ > 1の場合の上限を指定します。
コンポジット・アプリケーションのxmlディスクリプタを変更して、再試行に適用されるプロパティを指定できます。前述のプロパティ・リストは、次の例に示すようにJDeveloperのcomposite.xmlファイルで指定します。
<service name="Inbound">
<interface.wsdl interface="http://
xmlns...#wsdl.interface(Inbound_PortType)"/>
<binding.jca config="Inbound_db.jca">
<property name="jca.retry.count">5</property>
<property name="jca.retry.interval">1</property>
<property name="jca.retry.backoff">2</property>
<property name="jca.retry.maxInterval">6</property>
</binding.jca>
</service>
再試行可能な例外については、jca.retry.countの値を再試行の実行回数に設定する必要があります。
たとえば、jca.retry.countの値を10に設定すると、再試行は10回行われます。
ただし、jca.retry.countの値が設定されていない場合、再試行は無制限に実行されます。これは再試行可能なエラーのデフォルトです。
注意:
エラーに関してインバウンド・アダプタが無限に再試行すると、再試行のたびに別のコンポジット・インスタンスが作成されるため、複数のコンポジット・インスタンスが作成されることになります。
再試行を制限するグローバル・プロパティを変更して、jca.retry.countのデフォルト値を(無限から)有限数に変更できます。
この場合、jca.retry.countのデフォルト値を有限数に設定すると、特定のインバウンド・アダプタのエンドポイントのjca.retry.countプロパティ値を明示的に構成しない場合にも、グローバル・デフォルトが有効になります。
グローバル・デフォルトをcomposite.xmlの値とともに指定した場合、composite.xmlで指定した値によってグローバル値がオーバーライドされます。
Fusion Middleware ControlコンソールのMBeanブラウザ(アダプタMbean)を使用して、このグローバル・プロパティを変更できます。この変更は、すべての現在および将来のエンドポイントに対して即座に有効になります。
再試行不可能なエラーは通常、変換またはメッセージ解析の結果生成されます。
インバウンド・アダプタはインバウンド・メッセージを拒否することによって、エンタープライズ情報システムからスローされた再試行不可能なエラーを処理します。エラーが再試行不可能な場合は、拒否ハンドラを使用して再試行不可能なエラーを処理する必要があります。
エンタープライズ情報システムとの相互作用からスローされた再試行不可能なエラーの例には、次が含まれます。
主キーの違反
キューが存在しない
マスター・レコードが存在しない
ペイロードをシリアライズできない
再試行不可能なエラーは、単に再試行しても解決されないと予想されるため、再試行されません。たとえば、あるファイルからのメッセージがメディエータを介してインバウンド・ファイル・アダプタに送信される場合があります。メディエータには、データベース表にデータを挿入するアウトバウンド・データベース・アダプタへの順次ルーティングがあります。DBアダプタでは挿入操作が実行中であるため、固有の制限エラーが発生する場合があります。この固有の制限エラーは、次のように処理されます。
アウトバウンド・データベース・アダプタによって再試行不可能なエラーと見なされます。
伝播によってインバウンド・アダプタに戻ります。
拒否ハンドラを使用して、インバウンド・アダプタによっても再試行不可能なエラーと見なされます。定義されているフォルト・ポリシーがある場合は、アダプタによって使用されます。
メディエータで変換エラーが発生する可能性があります。この種のエラーは再試行不可能です。WSDLのシグネチャに応じて、エラーは処理を行うインバウンド・アダプタに戻されます。
アウトバウンド相互作用エラーは、アダプタからのアウトバウンド相互作用を持つメッセージで発生します。
この項では、これらのアウトバウンド相互作用エラーの再試行可能性と不可能性について説明し、関連する設定可能なプロパティの概要について示します。
アウトバウンドの再試行可能なエラーは、composite.xmlファイルのjca.retry.countの値に基づいて再試行できます。
アウトバウンド・エラー処理の再試行可能な例外については、jca.retry.countの値を再試行の実行回数に設定する必要があります。
たとえば、jca.retry.countの値を10に設定すると、再試行は10回行われます。
ただし、jca.retry.countの値が設定されていない場合は、コンポジットの一部にフォルト・ポリシーが含まれていれば、フォルト・ポリシーによって再試行が実行されます。
次のコード・スニペットは、アウトバウンド相互作用に関する再試行可能な例外についてcomposite.xmlファイルに値を設定する方法の一例です。
再試行は5分に設定され(間隔は1分)、他のプロパティは適切に構成されます。前述のように、追加のプロパティが意味を持つのは、jca.retry.countプロパティが指定されている場合です。
<reference name="Outbound">
<interface.wsdl interface="http://
xmlns...#wsdl.interface(Outbound_PortType)"/>
<binding.jca config="Outbound_jms.jca">
<property name="jca.retry.count">5</property>
<property name="jca.retry.interval">1</property>
<property name="jca.retry.backoff">2</property>
<property name="jca.retry.maxInterval">6</property>
<property name="jca.retry.maxPeriod">30</property>
</binding.jca>
</reference>
アウトバウンド相互作用に関する再試行不可能な例外は、fault-policy.xmlファイルを介して実行可能な再接続試行の最大回数を定義することで処理が可能で、このファイルは、再試行不可能なエラーに予期される動作を設定します。
このフォルト・ポリシー・ファイルでは、次の例に示すように、再接続試行のパラメータを指定します。これには、次のものがあります。
再接続の再試行回数(retryCount)
再接続の再試行間隔(retryInterval)
接続の再試行に関する指数関数的バックオフ値(exponentialBackoff)
すべての時間測定は秒単位で指定されます。
例 - 再接続試行のパラメータの指定
<faultName xmlns:bplex="http://schemas.oracle.com/bpel/extension" name='bplex;bindingFault">
<condition>
<action ref="ora-retry"/>
</faultName>
</condition>
<Actions>
<Action id="ora-retry">
<retry>
<retryCount>10</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff>2</exponentialBackoff>
</retry>
</Action>
</Actions>
次の例に示すように、faultPolicy ConnectionFaultsと参照名writeMessageToQueueを使用して、フォルト・ポリシーをfault-bindings.xmlファイル内のコンポジットの参照エンドポイントに関連付ける必要があります。
例 - フォルト・ポリシーとコンポジットの参照エンドポイントの関連付け
<?xml version="1.0" encoding="UTF-8"?>
<faultPolicyBindings version="2.0.1"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<reference faultPolicy="ConnectionFaults">
<name>writeMessageToQueue</name>
</reference>
</faultPolicyBindings>
有効な結果が生成される前に構成済の再試行回数に達すると、サービス・インフラストラクチャ起動例外がスローされます。
サービス・インフラストラクチャ起動例外のタイプの伝播は、アウトバウンド・アダプタによって報告されたエラーに対して、インバウンド・アダプタが応答できるようにするために重要です。
図2-13は、アダプタによるサービス・インフラストラクチャの同期呼び出しにおけるフォルトの伝播を示します。この後、下流のアダプタを呼び出します。
この図で、サービス・インフラストラクチャ起動例外は、下流のアダプタから介して呼び出し元のアダプタに伝播しています。
次の2つのケースでは、フォルト・ポリシー・メカニズムが動作しません。
XAモードのアウトバウンド・アダプタ
メディエータの順次ルーティングでのアウトバウンド・アダプタ
XAモードのアウトバウンド・アダプタ
フォルト・ポリシー・メカニズムは、XAモードのアウトバウンド・アダプタでは機能しません。
たとえば、XAモードで、フォルト・ポリシーをアウトバウンド・アダプタの失敗時に再試行させる必要がある場合、フォルト・ポリシーは再試行されず、この失敗の発生前に成功していたアウトバウンド・アダプタはメッセージをロールバックしません。
メディエータの順次でのアウトバウンド・アダプタ
フォルト・ポリシーは、メディエータの順次ルーティングで起動されたアウトバウンド・アダプタでも機能しません。これは、メディエータのフォルト・ポリシーはパラレル・ルーティング・ルールにのみ適用可能であるためです。
アウトバンド・アダプタにメッセージを送るBPELプロセスに対してインバウンド・アダプタがメッセージを送信するシナリオにおいて、JDeveloperとFusion Middleware Controlを介してOracle Web Services Manager (OWSM)を使用し、ペイロードにPII (個人の身元を特定する情報)ポリシーを適用できます。
この方法でOWSMを使用すると、暗号化および復号化されるようにアダプタ・ペイロードを構成できます。BPEL監査証跡を調査する個人には、ユーザーが暗号化するように指定したデータは表示されません。
暗号化するインバウンドからペイロード要素を選択します。対応するエンドポイントに対して、復号化する同じ要素を選択する必要もあります。
一般的に、Webサービスのセキュリティには、認証、許可(またはアクセス制御)、機密およびプライバシ保護、整合性、否認防止などのいくつかの側面があります。
アダプタでこれを使用することは、個人の身元を特定する機密情報(PII)の維持に関連します。
PIIポリシーをペイロードに適用するには、JCAの暗号化および復号化をJCAエンドポイントで実現します。PIIの暗号化の目的は、データがシステム内部にあるときにその安全を守ることです。
そのためには、独自のマップ名とキー名を含むセキュリティ資格証明をエンドポイントのデータに対して指定します。エンドポイントに指定するセキュリティ資格証明は、指定するマップ名とキー名で一意に識別されます。
次の手順を実行して、JCAの暗号化および復号化をサービス・エンドポイントと参照エンドポイントにアタッチします。表示する例は、ファイル・サービスです。
oracle.wsm.securityを入力して保存します。エントリの記入が完了すると、図2-17 のようにダイアログが表示されます。キーを作成するときにマップを指定する必要があります。
「リクエスト・データの暗号化」ダイアログを図2-19 に示します。「編集」アイコンを選択してPIIポリシーを編集し、暗号化するファイルを指定します。
図2-20 「暗号化するフィールドを選択します」ダイアログの使用
SOAおよびセキュリティの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。
デプロイされたSOAコンポジット・アプリケーションのインスタンスを実行およびテストできます。このようなインスタンスの実行およびテストにより、次のことが可能になります。
コンポジット・アプリケーションの管理
コンポジットのインスタンスの起動
コンポジットのインスタンスの追跡
詳細なコンポーネント・インスタンスの監査証跡の表示
アプリケーションのテストの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。
次のタイプのアダプタについて、トレース・レベルを設定します。
Oracle JCAアダプタとOracle Adapter for Oracle Applications: ロガーoracle.soa.adapterでログ・レベルをTRACE:32のように設定します。
アダプタのトレース・レベルの設定の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。
パッケージ・アプリケーション・アダプタ: アウトバウンド相互作用の場合は、weblogic-ra.xmlファイル内でパッケージ・アプリケーション・アダプタのLoglevelプロパティを設定します。
レガシー・アダプタ: Oracle Studioを使用して、Oracle Connectとメインフレーム・サーバーのトレース・レベルを設定できます。
Fusion Middleware Controlコンソールを使用してトレース・レベルを設定するには、次の手順を実行します。
「ログ構成」ページが表示されます。
注意:
コンピュータの再起動と再起動の間もログ・レベルを確実に保持するには、「表示」リストから「永続ログ・レベル状態のログ出力」を選択します。デフォルトでは、ログ・レベルはランタイム・ログ出力用に設定されます。ランタイム・ログ出力は、コンポーネントの再起動と再起動の間に保持されません。
詳細は、「アダプタ・ログの表示」を参照してください。
次のように、ログを表示できます。
Oracle Adapter for Oracle Applications: これらのアダプタでは、ログ・ファイルをOracle Diagnostic Logging (ODL)フォーマットでリダイレクトするJCAバインディング・コンポーネントのLogManagerインタフェースが実装されます。アウトバウンド相互作用とインバウンド相互作用の両方について、ログ・ファイルがsoa-diagnostic.logファイルにリダイレクトされます。
server-soa管理サーバーにデプロイされているOracle SOA Suiteのログ・ファイルは、次の場所にあります。
MW_HOME/user_projects/domains/domain_name/servers/server-soa/logs/soa-diagnostic.log
ログ・ファイルの検索と閲覧の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。
パッケージ・アプリケーション・アダプタ: このタイプのアダプタはJ2CA 1.5標準の一部ではないため、LogManagerインタフェースは実装されません。したがって、システム・コンポーネントの場合、ログ出力は次の場所にリダイレクトされます。
ORACLE_INSTANCE\diagnostics\logs\component_type\component_name。アウトバウンド相互作用の場合、ログは同じ場所に移動されます。これに対して、インバウンド相互作用の場合、ログはsoa-diagnostic.logにリダイレクトされます。
レガシー・アダプタ: レガシー・アダプタは、J2CAリソース・アダプタとOracle Connectで構成され、Oracle Connectはメインフレーム・アプリケーションおよびデータ・ストアと通信するためのネイティブ・アダプタで構成されます。Oracle Connectのログは、Oracle Studioを使用して表示できます。Oracle Studioは、メインフレーム・アダプタのデザインタイム・ツールであり、Oracle Connectの管理ツールです。Oracle Connectは、デーモン・ログ、ワークスペース・ログ、サーバー・プロセス・ログなど、様々なタイプのログを生成します。
詳細は、「Oracle JCAアダプタのトレース・レベルの設定」を参照してください。
カスタムJCAアダプタ・ウィザードをJDeveloper IDEで汎用アダプタ・ウィザードとして構成して、相互作用/アクティブ化の仕様、プロパティおよびデフォルト値を構成ファイルから読み取って表示できます。ウィザードでは仕様の選択、デフォルトのプロパティ値のオーバーライド、新しいプロパティの追加を行うことができます。カスタム・アダプタ・ウィザードには、次のようないくつかの目的があります。
カスタム・アダプタ・ウィザードはそのままで使用して、カスタム・ランタイプ・アダプタをサポートできます。カスタム・アダプタを使用する場合は、カスタム・アダプタ構成ファイルcustomAdapter-config.xmlを指定(または拡張)します。
より具体的なアダプタを作成する場合は、カスタム・アダプタ・クラスを変更または拡張できます(たとえば、アダプタにあわせてテキストを変更できます)。
カスタム・アダプタ・ウィザードを使用して、JCAアダプタ・フレームワークを使用し、SCAEndpointインタフェースにフックすることで、新しいアダプタ・ウィザードを作成する方法についての簡単な例を確認できます。
SOA JDeveloper拡張をインストールすると、カスタム・アダプタのJavaソース・ファイルは<JAVA_HOME> /jdeveloper/integration/adapters/samples/customに配置されます
カスタム・アダプタは、デフォルトではJDeveloperコンポーネントに表示されません。次に、カスタム・アダプタがJDeveloperコンポーネントに表示されるようにextension.xmlファイルを更新する推奨の方法を示します。
アーカイブ・マネージャで <jdev_home>\soa\plugins\jdeveloper\extensions\oracle.sca.ui.adapters.jarを開きます。
META-INF/extension.xmlを検索して選択し、「抽出」を選択します。jarが含まれている現在のファイルにファイルを格納できます。
Linuxのコマンド・ラインから、抽出したextension.xmlファイルを編集します(viまたはemacsを使用)。
カスタム・アダプタのエントリのコメントを外し、ファイルを格納します。
アーカイブ・マネージャで、「追加」ボタンを押します(アーカイブするファイルを追加します)。extension.xmlファイルを選択して、「追加」をクリックします。
JDeveloperを再起動します。
<JDEV_HOME>\jdeveloper\integration\seed\soa\configuration\ custom\Adapter-config.xmlファイルには、カスタム・アダプタの詳細なオプション(connection-factoryの場所、interaction-spec className、activation-spec className、プロパティ)が含まれています。
activation-spec内のプロパティは、インバウンド・アダプタに固有のプロパティです。interaction-spec内のプロパティは、アウトバウンド・アダプタに固有のプロパティです。プロパティの値はカスタム・アダプタによって表示されたデフォルト値です。
customAdapter-config.xmlの内容は、カスタム・ランタイム・アダプタで必要なオプションにあわせて変更できます。たとえば、すべてのプロパティの名前やデフォルト値の変更、新しいプロパティの追加、複数のアクティブ化仕様と相互作用仕様の追加などを行うことができます。
displayResourceKeyおよびresourceBundle属性はオプションです。activation-spec、interaction-spec、またはproperty要素にdisplayResourceKeyが含まれている場合、属性値はリソース・バンドルから表示可能なテキストを取得するキーとして使用されます。リソース・バンドルが使用できない場合やバンドルにキーがない場合は、キー自身が表示可能なテキストとして使用されます(リソース・バンドルを含める必要はありません)。使用するリソース・バンドルは、connection-factory要素にresourceBundle属性を配置することによって指定できます。
変更されたcustomAdapter-config.xmlの例を示します。
例 - 変更されたcustomAdapter-config.xml
<adapter-config xmlns="http://platform.integration.oracle/blocks/
adapter/fw/metadata">
<connection-factory location="eis/Custom/CustomAdapter"
resourceBundle="oracle.tip.tools.ide.pm.modules.
bizintegration.adapter.custom.resource. CustomStringResourceBundle"/>
<endpoint-interaction >
<interaction-spec className="oracle.tip.adapter.
custom.outbound.
CustomInteractionSpec" displayResourceKey=
"CustomInteractionSpec" >
<property name="PropX" value="x"
displayResourceKey="SAMP_PROP_X" />
<property name="PropY" value="y"
displayResourceKey="Sample Property Y"/>
<property name="Append" value="false"/>
<property name="NumberMessages" value="1"/>
</interaction-spec>
</endpoint-interaction>
<endpoint-activation>
<activation-spec className=
"oracle.tip.adapter.custom.inbound.CustomActivationSpec"
displayResourceKey="CustomActivationSpec">
<property name="UseHeaders" value="false"/>
<property name="PhysicalDirectory" value="x"/>
<property name="Recursive" value="true"/>
<property name="DeleteFile" value="true"/>
<property name="IncludeFiles" value="x"/>
<property name="PollingFrequency" value="60"/>
<property name="MinimumAge" value="0"/>
</activation-spec>
</endpoint-activation>
</adapter-config>
JDeveloper内で「公開されたサービス」または「外部参照」スイムレーンに「カスタムJCAアダプタ」アイコンをドラッグ・アンド・ドロップすると、アダプタ構成の「ようこそ」ページがIDEに表示されます。「次へ」を選択して、カスタム・アダプタ構成ウィザードのワークフローを開始できます。
次の画面には、他のアダプタの構成ウィザードと同じようにサービスのタイプと名前が表示されます。この画面により、構成するアダプタにおいて意味のあるサービスの名前を指定できます。
config.xmlファイルに<connection-factory>エントリが(カスタム・ランタイム・アダプタで必要なため)含まれている場合は、ウィザードの「接続情報」ページにデフォルトの「コネクション・ファクトリの位置」が表示されます。config.xmlに<connection-factory>エントリが(カスタム・ランタイム・アダプタで不要なため)含まれていない場合、ウィザードのこのページは表示されません。
次の「アダプタ・インタフェース」画面には、他のアダプタの構成ウィザードと同じように情報が表示されます。(各アダプタの構成ウィザードの詳細は個々の適切な章を参照してください。)この画面には、後で作成する操作およびスキーマで新しいWSDLを定義する方法、またはWSDLの名前、ポート・タイプおよび操作を使用して既存のWSDLをインポートする方法が示されています。
次の画面では、相互作用のタイプ、つまりインバウンドまたはアウトバウンドを選択できます。アウトバウンド相互作用を選択すると、ウィザードには相互作用クラス名(または、この例のような変換済の表示名)のリストが表示され、その中から選択できます。これらは事前に、customAdapter-config.xmlファイルで指定した名前です。
次の画面では、JCAプロパティの名前と値を指定できます。選択したクラス名に応じて、customAdapter-config.xmlファイル内でそのクラス名に関連付けられているプロパティが表示されます。この画面では、デフォルト値の変更やプロパティの追加と削除を行うことができます。
次の画面は、カスタム・アダプタ・ウィザードの「メッセージ」画面です。この画面では、他のアダプタ構成ウィザードと同じように、スキーマを指定するか、またはスキーマが不透明であることを宣言することで、ファイルの読取り操作に関するメッセージを定義できます。
次のページは、カスタム・アダプタ構成ウィザードの「最後」画面です。作成したWSDLファイルの名前が表示されます。
次に、アダプタに関するよくある質問をいくつか挙げます。
コンポジット・アプリケーションがタイムアウトになるのはなぜですか。コンポジット・アプリケーションがアダプタを使用して実行するのに十分な時間を指定しても、アプリケーションは依然としてタイムアウトになります。
この一因に、WebLogicのタイムアウト値があります。ビジネス・プロセスでアダプタを使用する場合は、WebLogic Server JTAのタイムアウト値を考慮する必要があります。
たとえば、Timeout Secondsの値が30秒に設定されているとします。Oracle WebLogic JTA属性Timeout Secondsの値をデフォルトの30よりも大きい値、ビジネス・プロセスのコンテキスト全体で意味を持つ値に増やす必要があります。WebLogic Serverコンソールを使用して、「WLSコンソール」→SOADomain→「構成」→「JTA」に移動し、JTAトランザクションのタイムアウト値を変更できます。しかく
Oracle JMSアダプタなどのトランザクション・アダプタはJTAトランザクション内で実行されます。トランザクションでは1つ以上の操作がアトミック作業ユニットとして実行されます。
トランザクション内の1つの操作が失敗すると、すべての操作がロールバックされて、アプリケーションは元の状態に戻ります。ビジネス・プロセス・ロジックがステートフルまたはステートレスのどちらで定義されているかによって、特定のビジネス・プロセス内には1つ以上のトランザクションが含まれている場合があります。
非トランザクション・アダプタはトランザクション・セマンティクスを使用せずに、配信を確保する固有のスキームを実装します。
サービス・エンジンはインバウンド・ディレクトリからファイルを取得して処理し、処理したファイルを出力ディレクトリに送信します。インバウンド・アダプタは、変換(構成されている場合)およびビジネス・シナリオの一部として処理された変換済コンテンツのパブリッシュに制限されています。ビジネス・シナリオではアダプタを使用して、出力ディレクトリへの書込みを行うことができます。ただし、Oracleファイル・アダプタには非トランザクションの性質があるため、このプロセス中に障害によってフェイルオーバーが発生すると、ファイルが失われる可能性があります。その結果、インバウンド・アダプタが読み取ったファイルの一部が出力ディレクトリに送信されない場合があります。当然ながら、単一ノード・クラスタ(またはクラスタなし)の場合は、フェイルオーバーのオプションはありません。
ファイル・アダプタは、メッセージの損失を防ぐ高可用性が構成されていないかわりに、ファイル・システムへの整合性のあるアクセスとクラスタ・ノード間のロード・バランシングを確保するように構成されています。単一ノードのセットアップの場合、ファイル・アダプタの高可用性は不要で、メッセージの損失は発生しません。
このように、非トランザクションの性質があるため、Oracleファイル・アダプタに高可用性を構成して、フェイルオーバーの発生時にファイルが重複しないようにする必要があります。ファイル・アダプタでメッセージが失われることはなくなりますが、(障害時リカバリにおいて)一部が重複する可能性があります。
また、処理のシナリオにトランザクション・アダプタと非トランザクション・アダプタが含まれている場合は、非トランザクション部分の処理内でのファイルの整合性を確保する必要があります。
JMSアダプタはローカル・トランザクションでも機能できます。これは、(グローバル)JTAトランザクションの境界内から独立して開始され、コミットされるトランザクションです。つまり、ローカル・トランザクションはアダプタの現在の起動においてのみ存続します。
拒否されたメッセージは、デフォルトではデータベース(具体的にはrejected_message表)内に格納されます。デフォルトの拒否されたメッセージ・ハンドラは、メッセージをファイルシステム上に格納し、拒否されたメッセージを明示的に処理するポリシーが定義されていない場合に関与します。このハンドラは、WLS_HOMEの事前に定義された場所にあるファイル・システム上にメッセージのペイロードおよびプロパティを格納します。現在、Oracle SOA Suiteには拒否されたメッセージを再発行する機能がないため、ユーザーが再発行を処理します。
SOA Suite 11gデプロイメントでは、FTP、データベースおよびファイルとの統合などの様々なアクティビティやその他のアクティビティに対してテクノロジ・アダプタの使用を組み込むことができます。これらのアダプタとの統合は簡単な上に機能を強化しますが、操作の観点からいくつかの課題が生じる可能性もあります。
その課題の1つに、SOAコンポーネント・インスタンス間で論理ビジネス・トランザクションを関連付ける方法があります。通常、この関連付けは実行コンテキストID ()を使用して実行されますが、ビジネス・トランザクションの範囲がFTP、データベース、ファイルなどのテクノロジにまで及ぶと、ECIDの関連付けが失われる可能性があります。
OracleアダプタのJCAフレームワークの新機能では伝播が可能です。この機能は、11.1.1.4および11.1.1.5で使用可能なバック・ポートを持つSOA Suite 11.1.1.7で使用できます。
ECIDの伝播の基本概念は、ECIDを格納できるメッセージのペイロードで場所を識別することにあります。
次に、メッセージのECIDの場所に関連する2つの「バインディング・プロパティ」が「公開されたサービス」(コンポジットの左側)または「外部参照」(コンポジットの右側)のいずれかに追加されます。
これにより、メッセージからECIDを抽出するか、メッセージにECIDを追加するための十分な情報がJCAフレームワークに提供されます。
メッセージからECIDを抽出すると、そのECIDが新しいコンポーネント・インスタンスに使用されます。
メッセージでECIDの格納場所を決定する際には、次の2つのオプションがあります。
メッセージ・スキーマに新しいオプションの要素を追加します。
スキーマで使用されていない既存の要素を利用します。
メッセージにオプションの要素を追加できることが最善のシナリオです。未使用の要素を見つけることはほとんどの場合に難しいことがわかっています。スキーマには、次のように表示されるECID値が保持されています。
11d1def534ea1be0:7ae4cac3:13b4455735c:-8000-00000000000002dc
メッセージ内でECIDの格納に必要な場所を特定すると、JCAフレームワークでもその情報を保持する必要があります。フレームワークで必要な2つの情報は、次のメッセージ・スキーマに関連付けられています。
メッセージ内の要素の名前空間
メッセージ内の要素に対するXPath
これをより理解するには、最初に次のデータベース表の例を確認します。
データベース・アダプタ構成ウィザードでコンポジットに「公開されたサービス」が作成されると、次のスキーマが作成されます。
この例では、コンポジット内のReadRowサービスに追加される2つの「バインディング・プロパティ」を次のように示しています。
<!-- Properties for the binding to propagate the from the database table --> <property name="jca..nslist" type="xs:string" many="false"> xmlns:ns1="http://xmlns.oracle.com/pcbpel/adapter/db/top/ReadRow" </property> <property name="jca..xpath" type="xs:string" many="false"> /ns1:PropagationCollection/ns1:Propagation/ns1: </property>
jca..nslistという名前のプロパティは、スキーマで定義されたtargetNamespaceを含みます。
jca..xpathという名前のプロパティは、要素に対するXPath文を含みます。
XPath文は、jca..nslistプロパティで定義されている適切なネームスペース接頭辞(ns1)を含みます。
データベース・アダプタ・サービスでデータベースから行を読み取ると、ペイロードからECID値が取得され、さらにペイロードからECID要素が削除されます。コンポーネント・インスタンスが作成されると、取得されたECIDと関連付けられ、ペイロードにはECID要素/値を除くすべてが含まれます。ECIDは、データベース、ファイルまたはキューなどのリソース・テクノロジに安全に格納された場合のみ表示可能となります。
この項には、データベース、表、ファイルおよびJMSキューを使用したECIDの伝播方法について簡略化された例が含まれています。この例のコンポジットは次のように表示されます。
この例のフローは次の順序で発生します。
insertwithbpelprocess_client_epサービスを使用してデータベースの挿入を起動します。
InsertWithBPELProcessにより、データベース・アダプタを使用してデータベースに行が追加されます。JCAフレームワークでは、挿入の前にメッセージにECIDが追加されます。
ReadRowサービスではレコードが取得され、JCAフレームワークではメッセージから抽出されます。メッセージからECID要素が削除されます。
ReadRowBPLProcessのインスタンスが作成され、取得したECIDと関連付けられます。
ReadRowBPELProcessにより、ファイル・アダプタを介してファイル・システムにレコードが書き込まれます。JCAフレームワークでは、ファイルにメッセージを書き込む前にメッセージにECIDが追加されます。
ReadFileサービスではファイル・システムからレコードが取得され、JCAフレームワークではメッセージからECIDが抽出されます。メッセージからECID要素が削除されます。
ReadFileBPELProcessのインスタンスが作成され、取得したECIDと関連付けられます。
ReadFileBPELProcessにより、JMSアダプタを使用してメッセージがエンキューされます。JCAフレームワークでは、メッセージECIDをエンキューする前にメッセージにECIDが追加されます。
DequeueMessageサービスではレコードが取得され、JCAフレームワークではメッセージからECIDが抽出されます。メッセージからECID要素が削除されます。
DequeueMessageBPELProcessのインスタンスが作成され、取得したECIDと関連付けられます。
論理フローが終了します。
Fusion Middleware Controlに「フローのトレース」が表示されると、ECIDによって関連付けられたすべてのインスタンスが表示されます。
