| Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド 11g リリース1（11.1.1） B55918-02 |
|
 戻る |
 次へ |
Oracle JCAアダプタはJ2EE Connector Architecture（J2CA）1.5標準に基づいており、Oracle WebLogic Serverにデプロイされます。 Oracle JCAアダプタのライフサイクルは、Oracle Fusion Middlewareに依存します。 これらのアダプタは、JCAバインディング・コンポーネントを介してOracle Fusion Middlewareと統合されます。
この章には、次の項が含まれます。
Oracleテクノロジ・アダプタとOracle Adapter for Oracle Applicationsは、Oracle Fusion Middlewareインストールの一部として使用可能です。 これらのアダプタでは、Oracle WebLogic Serverと中間層デプロイの両方がサポートされています。 詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のOracle SOA Suite 11g（11.1.1.0.0）に関する項を参照してください。
レガシー・アダプタとパッケージ・アプリケーション・アダプタは、Oracle Fusion Middleware AdaptersおよびConnectors CDに収録されています。 これらのアダプタでは、中間層デプロイメントのみがサポートされています。 詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のOracle Fusion Middleware AdaptersおよびConnectorsに関する項を参照してください。
|
注意: アダプタをインストールする前に、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のシステム要件と前提条件に関する項を参照し、サポートされているオペレーティング・システムやJDKバージョンなどのシステム要件と前提条件を確認してください。 |
Oracle JCAアダプタは、JCA 1.5リソース・アダプタとしてデプロイされます。 したがって、アダプタを起動または停止するには、すべてのリソース・アダプタでSPIインタフェースの一部としてstart (BootstrapContext)およびstopメソッドを実装する必要があります。 Oracle JCAアダプタは、それを使用するSOAコンポジットによりJCAアウトバウンド相互作用が開始されると起動されます。 また、インバウンド相互作用にSOAコンポジット自体がロードされるとき、またはアダプタによりイベントがOracle BPELプロセスにパブリッシュされるときにも、アダプタを起動できます。
アダプタの起動後に停止するには、Oracle WebLogic Serverを停止するか、またはOracle Fusion Middleware内でJ2EEアプリケーションを停止します。 このリリースでは、JCAバインディング・コンポーネントはJCA 1.5コンテナの一部として機能します。
図2-1に示すように、次のいずれかの方法を使用して、「アダプタ構成ウィザード - アダプタ・インタフェース」ページでアダプタ・インタフェースを定義できます。
「アダプタ構成ウィザード - アダプタ・インタフェース」ページに続いて表示されるページで、指定した操作名とスキーマを使用して生成されるWSDLを使用します。
既存のWSDLをインポートします。
この項では、既存のWSDLをインポートしてアダプタ・インタフェースを定義する方法について説明します。 この機能を使用すると、既存のWSDLを使用してアダプタ・サービスまたは参照を作成できます。 既存のWSDLを選択するオプションは、次のアダプタについてのみサポートされています。
Oracleファイル・アダプタ
Oracle FTPアダプタ
Oracleソケット・アダプタ
Oracle AQアダプタ
Oracle JMSアダプタ
Oracle MQ Seriesアダプタ
既存のWSDLをインポートしてアダプタ・インタフェースを定義するというオプションを選択した場合、以降のウィザード・ページの一部の機能が無効になります。 たとえば、WSDLでは操作名とメッセージ・スキーマを定義するため、図2-2に示すように、以降の操作名フィールドとスキーマ要素フィールドには値が自動的に入力されて変更できません。 ただし、既存のWSDLを使用するように選択しなければ、アダプタ・ウィザードの動作は変わりません。
Oracle MQ Seriesアダプタ、Oracle JMSアダプタおよびOracle AQアダプタの場合、アダプタ構成ウィザードの表示内容が他のアダプタとは少し異なることに注意してください。 コールバックのポート・タイプと操作を選択するための追加オプションがあります。 アダプタ構成ウィザードの以降のオプションは、選択したポート・タイプと操作に応じて有効または無効になります。
たとえば、アダプタ構成ウィザードでOracle MQ Seriesアダプタを定義する際にコールバックを選択すると、「MQにメッセージを送信し、リプライ/レポートを取得」、「MQからメッセージを取得し、リプライ/レポートを送信」および「非同期」オプションのみが有効になります。 コールバックを選択しなければ、「MQにメッセージを蓄積」および「MQからメッセージを取得」オプションのみが有効になります。 同期リプライを使用するWSDL操作を選択すると、「MQからメッセージを取得し、リプライ/レポートを送信」および「同期」オプションのみが有効になります。
既存のWSDLを使用する場合はいずれも、CICSまたはIMSスキーマを使用するためのオプションが無効であることに注意してください。
|
注意: 既存のWSDLをインポートする場合に最も一般的なアプローチは、まずOracle BPELプロセスまたはメディエータを作成し、次にそのWSDLファイルをスキーマ（またはNXSD）から定義することです。 この作業を完了すると、アダプタ・サービスが作成され、BPELプロセスまたはメディエータ・コンポーネント用に生成されたWSDLファイルが既存のWSDLファイルとしてインポートされます。ただし、この機能はスキーマ要素を使用するメッセージにのみ機能することに注意する必要があります。 単純型と複合型はサポートされていません。 |
Oracle JCAアダプタにより、基礎となるバックエンド操作固有のプロパティがメッセージ・ヘッダー要素として公開され、これらの要素をビジネス・プロセス内で操作できるようになります。
Oracle JCAアダプタのプロパティは、Fusion Middleware Controlコンソールで追加または削除したり元に戻すことができます。 ただし、プロパティのタイプによっては、プロパティの変更を適用するには、コンポジット・アプリケーションを再デプロイする必要があります。
表2-1に、構成できるメッセージ・ヘッダー・プロパティのタイプおよび再デプロイが必要かどうかを示します。
表2-1 Oracle JCAアダプタのプロパティ・タイプ
| プロパティ・タイプ | 説明 | 制限 |
|---|---|---|
|
アクティブ化仕様および相互作用仕様 |
SOAコンポジット・アプリケーションにおいては、アクティブ化仕様プロパティはサービスとして機能し、相互作用仕様プロパティは参照として機能します。 |
これらのプロパティは追加したり削除しないでください。 値の変更のみが可能です。 これらのプロパティでは、アダプタのエンドポイントをリサイクルする必要があります。 これらのタイプのプロパティは、他のプロパティにも依存します。 これらのプロパティのいずれかを追加する場合、他にどの依存プロパティを追加する必要があるかを把握する方法はありません。 |
|
エンドポイント |
これらは、アクティブ化仕様プロパティまたは相互作用仕様プロパティを介して公開されない、チューニングに関連するプロパティ（タイムアウト、しきい値、最大間隔などを指定する）です。 |
エンドポイント・プロパティの追加、削除または変更に制限はありません。 これらのプロパティが追加、削除または変更されると、アダプタに通知されますが、再デプロイは必要ありません。
|
詳細は、付録A「Oracle JCAアダプタのプロパティ」を参照してください。
Oracle JCAアダプタのレコード実装はXMLRecordです。 すべてのアダプタの相互作用は、XMLRecordで開始されます。 各JCAレコードは、oracle.tip.adapter.api.record.XMLRecordの実装であることが必要です。 XMLRecordの各インスタンスにはRecordElementが含まれています。 RecordElementペイロードにはデータが含まれています。 さらに、各RecordElementにはデータのBLOBが1つ含まれており、このBLOBはUTF-8でエンコードされたXML文字列の場合と、バイナリ8進バイト・ストリームの場合があります。
XMLRecordは次のメソッドで構成されています。
getPayloadRecordElement: ペイロードRecordElementを取得します。
setPayloadRecordElement: XMLRecordのペイロード・レコード要素を設定します。
Oracle JCAアダプタは、JCA 1.5リソース・アダプタとしてOracle WebLogic Serverコンテナにデプロイされます。 アダプタは、Javaアーカイブ（JAR）フォーマットを使用してリソース・アダプタ・アーカイブ（RAR）ファイルとしてパッケージされます。 アダプタを物理的にデプロイするには、RARファイルを使用して、基礎となるOracle WebLogic Serverまたは中間層プラットフォームにアダプタをコネクタとして登録する必要があります。 RARファイルには、リソース・アダプタに関するデプロイ固有の情報を含んだデプロイメント・ディスクリプタXMLファイルra.xmlが含まれています。 さらに、RARファイルには、Oracle WebLogic Serverとリソース・アダプタの間の規定に関する宣言情報も含まれています。
アダプタでは、.rarファイル内のra.xmlファイルのみでなく、weblogic-ra.xmlテンプレート・ファイルもパッケージされます。 weblogic-ra.xmlファイルは、リソース・アダプタのConnectorFactoryオブジェクトの定義に使用されます（論理デプロイ）。 weblogic-ra.xmlファイルは、リソース・アダプタ用のOracle WebLogic Server固有のデプロイメント・ディスクリプタです。 このファイルにはリソース・アダプタをOracle WebLogic Serverにデプロイするためのデプロイ構成が含まれています。これには、リソース・アダプタのデプロイメント・ディスクリプタで指定されたバックエンド・アプリケーションの接続情報、使用するJava Naming and Directory Interface（JNDI）名、接続プーリング・パラメータ、リソースのプリンシパル・マッピング・メカニズムおよび構成などが含まれます。
詳細は、次を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』
設計時環境とデプロイ先サーバーの間の接続性を確立する必要があります。 このような接続性を確立するには、アプリケーション・サーバー接続を作成する必要があります。
次の手順に従ってアプリケーション・サーバー接続を作成します。
「ファイル」メニューから「新規」を選択します。
図2-3に示すように、「新規ギャラリ」ページが表示されます。
「すべてのテクノロジ」タブで、「一般」カテゴリの「接続」を選択します。
「新規ギャラリ」ページの右側にある「項目」ペインに、確立できる様々な接続のリストが表示されます。
「アプリケーション・サーバー接続」を選択し、「OK」をクリックします。
図2-4に示すように、「アプリケーション・サーバー接続の作成」ページが表示されます。
「接続名」フィールドに接続名を入力します。 この例では、AppsServerConnection1と入力します。
「接続タイプ」で「WebLogic 10.3」を選択し、「次へ」をクリックします。
図2-5に示すように、「認証」ページが表示されます。
ユーザー名とパスワードを入力して「次へ」をクリックします。
図2-6に示すように、「アプリケーション・サーバー接続の作成 - 構成」ページが表示されます。
「構成」ページでホスト名、ポート詳細およびドメイン・サーバー名を入力します。
「次へ」をクリックします。
図2-7に示すように、「アプリケーション・サーバー接続の作成 - テスト」ページが表示されます。
「接続のテスト」をクリックします。 「ステータス」ペインに成功メッセージが表示されます。
「終了」をクリックします。
サーバー接続が作成されました。
SOAコンポジット・アプリケーションはJDeveloperからデプロイします。
JDeveloperでは、デプロイするSOAプロジェクトおよびアプリケーションに対してプロファイルを使用する必要があります。 この項では、JDeveloperによるプロファイルの作成およびデプロイ方法について説明します。
この項では、SOAプロジェクトとアプリケーションのアプリケーション・プロファイルをデプロイする方法について説明します。
アプリケーションをデプロイする手順は、次のとおりです。
デプロイするプロジェクトを右クリックし、図2-8に示すように「デプロイ」→「project_name」→「デプロイ先」→「Application_Server_Connection_Name」を選択します。
「SOAデプロイメントと構成ダイアログ」が表示されます。
図2-9に示すように、デフォルト設定を使用します。
「OK」をクリックします。
「認可リクエスト」ダイアログが表示されます。
ユーザー名とパスワードを入力して「OK」をクリックします。
プロジェクトがコンパイルされ、管理サーバーにデプロイされます。 設計領域で「デプロイメント」タブをクリックすると、デプロイメント・ログを表示できます。
同じバージョンのSOAコンポジット・アプリケーションを再デプロイする場合、コンポジット名は変更できません。 「SOAデプロイメントと構成ダイアログ」で「同じリビジョンIDで既存のコンポジットを上書きします。」チェック・ボックスを選択した場合は、同じリビジョン番号でデプロイできます。 ただし、このチェック・ボックスを選択していない場合は、デプロイメント・ログに次のエラー・メッセージが表示されます。
pr 29, 2009 1:55:57 AM oracle.integration.platform.blocks.deploy.servlet.CompositeDeployerMessages severeSendError SEVERE: Sending back error message: Error during composite deployment: oracle.fabric.common.FabricDeploymentException: Composite with same revision ID already exists: default/<application name>!<revision id>. Please set the overwrite flag or use different revision ID. Abort deployment...
この項では、jarファイルが関連付けられていないアダプタRARファイルを手動でデプロイする方法について説明します。
META-INF/ra.xmlおよびMETA-INF/weblogic-ra.xmlのみを含み、JNDIの作成に必要なjarファイル・アダプタを含んでいないアダプタRARファイルをデプロイする場合は、デプロイ時にデプロイ順序を大きい値（500など）に変更する必要があります。これにより、Oracle WebLogic Serverでは、このアダプタのjarファイルをロードした後でこのRARファイルをデプロイできます。
たとえば、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ファイルを手動でデプロイする手順は、次のとおりです。
Oracle WebLogic Server管理コンソールhttp://servername:portnumber/consoleにナビゲートします。
必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。
Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。
「ドメイン構造」ペインで「デプロイメント」を選択します。
Oracle WebLogic Server管理コンソールの「デプロイメントの概要」ページが表示されます。
「インストール」をクリックします。
「アプリケーション・インストール・アシスタント」ページが表示されます。
「パス」フィールドにアプリケーション・ディレクトリまたはファイルのパスを入力し、「次へ」をクリックします。
このアプリケーションのデプロイ先サーバーを選択し、「次へ」をクリックします。
「オプション設定」ページが表示されます。
これらの設定を変更するかデフォルトを受け入れて、「次へ」をクリックします。
「選択項目を確認して「終了」をクリック」ページが表示されます。
「終了」をクリックしてデプロイを完了します。
RARファイルをデプロイした後、「デプロイメントの概要」の下でデプロイしたRARファイルの名前をクリックします。
「設定」ページが表示されます。
「デプロイ順序」フィールドの値をデフォルト値よりも大きい値に変更します。 たとえば、500に変更します。
これにより、新規にデプロイしたRARファイルがロードされるのは、常にOracle WebLogic Serverにより関連クラスがロードされた後になります。
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として識別されます。 たとえば、データベース・アダプタ・サービス・ウィザードを介して実行中に、createCustomerサービスのJNDI名としてeis/DB/custStoreを指定するとします。 このアダプタ・サービスを使用してコンポジットをモデル化した後は、それを変更せずにそのまま開発、テストまたは本番環境にデプロイする必要があります。 ただし、その前に、正しいEISインスタンスを指している各環境に、eis/DB/custStoreに対応するJNDIエントリがあることを確認してください。
この項では、メッセージの損失がないことをアダプタで保証する方法について説明します。
トランザクション・アダプタにより、エンタープライズ情報システム（EIS）は1フェーズ・コミットまたは2フェーズ・コミット（ローカル・トランザクションまたはグローバル/分散トランザクション）に参加できるようになります。 これらのコミットは、アダプタ（インバウンド）またはOracle User Messaging Service（UMS）（アウトバウンド）により制御されます。 非トランザクション・アダプタでは、トランザクションのセマンティクスを使用せずに配信を保証するために、独自のスキームが実装されます。
この項では、次の内容について説明します。
詳細は、次を参照してください。
『Oracle Fusion Middleware高可用性ガイド』のOracle JCAアダプタの信頼性とトランザクション動作に関する項。
ローカル・トランザクションでは、Oracle WebLogic Serverでリソース・アダプタに対してローカルなリソースを管理できます。 アダプタでは、weblogic-ra.xmlファイル内でtransaction-support要素を指定することでトランザクション・サポートのタイプを定義します。 アプリケーション・コンポーネントがEIS接続をリクエストすると、Oracle WebLogic Serverは現行トランザクション・コンテキストに基づいてローカル・トランザクションを開始します。 アプリケーション・コンポーネントがその接続をクローズすると、Oracle WebLogic Serverはローカル・トランザクションをコミットします。 また、Oracle WebLogic Serverはトランザクションの完了後にEIS接続をクリーン・アップします。
ローカル・トランザクションの場合は、JTAトランザクションが引き続きアクティブであることが検出された場合で、ポリシーが例外をスローしたパートナ・リンクにバインドされていた場合に、フォルト・ポリシーが実行されます。 JTAチェックにより、BPELエンジンはデハイドレーションされる可能性のある処理に進む前に、サード・パーティによるトランザクションの操作を取得できます。
アダプタでは、基礎となるアプリケーション・サーバーのトランザクション・マネージャを利用するJCA 1.5 XA規定でグローバル・トランザクションがサポートされています。 これには、Oracle Adapter for Oracle Applications、Oracle Adapter for Database、Oracle Adapter for Advanced Queuing、Oracle Adapter for JMSおよびOracle Adapter for MQSeriesが含まれます。 非トランザクション・アダプタには、Oracleファイル・アダプタやOracle FTPアダプタがあります。
グローバル・トランザクションの場合、ロールバックを停止するために何か実行することはできません。 このフォルト・タイプは、JTAトランザクションを再試行する必要があることを示します（たとえば、RACノードが停止した場合は、トランザクションを再開して再試行する必要があります）。 この場合、フォルト・ポリシーが実行されます。 ただし、XA動作が必要な場合にフォルト・ポリシーを使用することはお薦めしません。これは、フォルト・ポリシーが独自トランザクションで実行され、グローバル・トランザクションには関与しないためです。
特に、フォルト・ポリシーは特定の参照の実行を開始する前に既存のJTAトランザクションをコミットします（Oracle BPEL PMにおけるInvokeアクティビティなど）。 既存のJTAトランザクションが一時停止されてから再開されることはありません。
非同期SCAサービスのエントリ・ポイントの場合、トランザクション・アダプタではグローバルJTAトランザクションが開始されてから、インバウンド・メッセージがコンポジットに送信されます。 制御がアダプタに戻ると、アダプタによりJTAトランザクションがコミットされるため、次の一連のアクションがアトミックの作業ユニットとして実行されます。
この実行中に何かに失敗すると、アクション1および2がロールバックされます。
同期プロセスの場合、アダプタにより開始されたグローバル・トランザクションは、メッセージ配信とコンポジットの実行にまたがります。
トランザクション・アダプタの場合、アウトバウンドJCA相互作用（Invokeアクティビティ）は、有効範囲としてグローバルなBPEL JTA（EJB）トランザクションを持ちます。 これは、Oracle JCAアダプタの起動を含め、すべてのコンポジット・アクティビティがグローバル・トランザクションの一部となるため、エラーが発生した場合は、すべてのアクティビティがコミットされるかロールバックされるかのいずれかになることを意味します。
たとえば、BPELプロセスでは、異なるinvokeアクティビティを介して（データベース・アダプタを起動して）、異なるデータベース上の複数の表にデータを挿入できます。 BPELインスタンスの終了前に、JTAトランザクションがコミットされます。 その時点でのみ、データベースの挿入操作がコミットされます。 BPELインスタンスの実行中にエラーが発生すると、すべてのアクティビティ（およびデータベース操作）が最後のデハイドレーション・ポイントまでロールバックされます。
WebLogicプラットフォームではOracle WebLogic Serverの移行が使用されているため、管理サーバーやマシンに障害が発生した場合に、同じマシンまたは別のマシン上で自動的に再起動し、障害が発生したサーバー上のコンポジットへのインバウンド・アダプタの機能が再開されます。 その間に、他のクラスタ・メンバー上のインバウンド・アダプタはメッセージ・サービス処理を続行できます。
詳細は、次を参照してください。
第2.14項「アダプタ内でのシングルトン（アクティブ/パッシブ）インバウンド・エンドポイント・ライフサイクルのサポート」
ファイル/FTPアダプタ: 第4.2.18項「高可用性」
データベース・アダプタ: 第9.3.7項「高可用性」
MQアダプタ: 第10.3.4項「高可用性」
『Oracle Fusion Middleware高可用性ガイド』のOracle JCAアダプタと高可用性の説明に関する項。
JCAバインディング・コンポーネントでは、インバウンド・アダプタ・サービスのアクティブ・フェイルオーバーがサポートされています。
この機能を特定のインバウンド・アダプタのエンドポイントに対して有効にするには、例2-1に示すように、singleton JCAサービス・バインディング・プロパティ（composite.xml）を追加し、値をtrueに設定します。 この機能を無効にするには、singletonプロパティの値をfalseに設定します（または、<binding.jca>要素からプロパティを削除します）。
例2-1 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バインディング・コンポーネントのインスタンスでは、アクティブ化の中でいずれがプライマリのアクティブ化となるかについては、ランダムに選択されます。 Oracle WebLogicクラスタのその他のアクティブ化（インスタンス）は、開始されると、JCAリソース・アダプタ上でEndpointActivationを実際に起動することなく、ホット・スタンバイ状態になります。
プライマリのアクティブ化がある時点で応答しなくなったり、手動で非アクティブ化されたり、クラッシュまたは終了した場合、Oracle WebLogicクラスタの残りのJCAバインディング・コンポーネント・メンバーの1つが即座にこのことを検出し、待機中のアクティブ化エージェントの1つにプライマリのアクティブ化の役割を再度割り当てます。
詳細は、第2.13項「コンポジットの可用性とインバウンド・アダプタ」を参照してください。
（参照の）コールバック・インタフェースの定義または（BPELの）中間プロセス受信を使用して、インバウンド非同期メッセージと前のアウトバウンド・メッセージの相関付けにネイティブ相関を使用する場合は、デフォルトで、インバウンド・メッセージの相関付けが可能かどうかに関係なく、常に、JCAフレームワークによってコンポジットへのメッセージのポストが試行されます。
Oracle AQアダプタおよびOracle JMSアダプタの場合は、MessageIdが外部アプリケーションによってリクエスト（起動）メッセージからレスポンス（受信）メッセージのCorrelationIdにコピーされると、アダプタ・フレームワークによってBPEL相関が確実に発生します。
ただし、受信メッセージのCorrelationIdが前の起動メッセージのいずれとも一致しない場合、メッセージは実際には存在しないBPEL対話にマップされます。 この場合、メッセージが実際にデータベースに保存されていても、例2-2に示すSEVEREログ・メッセージが表示されることがあります。
例2-2 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
例2-3に示すように、rejectUncorrelatedMessagesサービス・バインディング・プロパティをcomposite.xmlファイルに追加して、一致しないネイティブ相関IDを拒否するようにアダプタ・フレームワークの動作を明示的に変更できます。
例2-3 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 JCAアダプタは大きなペイロードを処理できますが、Oracle BPEL PMは大きなペイロードの処理時に大量のメモリーを消費するため、OutOfMemoryが発生し、システム全体に影響する可能性があります。
OutOfMemoryなどのエラーを回避するには、Oracle JCAアダプタのペイロードしきい値を設定する必要があります。 ペイロードしきい値を設定すると、Oracle JCAアダプタがしきい値制限よりも小さいペイロードを処理し、その他を拒否することを保証できます。
ペイロードのネイティブ・サイズを使用できる場合は、関連するアダプタではペイロードのネイティブ・サイズを使用して、ペイロード・サイズがしきい値制限より下に制限されます。 たとえば、Oracleファイル・アダプタの場合、ネイティブ・サイズ（ポーリングされたファイルのサイズ）をアダプタに使用でき、ネイティブ・サイズがペイロード・サイズしきい値よりも大きい場合、ファイルは拒否されます。
たとえば、Oracleソケット・アダプタの場合のように、ペイロードのネイティブ・サイズを使用できない場合、アダプタはペイロードのネイティブ・サイズを内部で計算する必要があります。 ネイティブ変換ライブラリを使用して非XMLの変換またはシリアライズされたXMLの解析を行う場合は、ネイティブ・サイズを内部で決定できます。 Oracleデータベース・アダプタは変換フレームワークに依存しませんが、ネイティブ・メッセージのサイズを計算する特別な組込みの処理メカニズムがあります。
|
注意: エラー・リカバリでのデバッチ処理の場合、ペイロード・サイズしきい値を慎重に使用する必要があります。 ペイロード・サイズの違反により、誤りのあるレコードの場合、ストリームのスキップ中に不当な拒否が発生することがあります。 |
ペイロードのネイティブ・サイズを使用できず、かつ、関連するアダプタでネイティブ変換ライブラリが使用されない場合、ペイロード・サイズしきい値制限を強制できません。 たとえば、Oracleファイル/FTPアダプタがファイル・コンテンツのチャンクを渡し、実際のネイティブ・サイズが不明であるXMLデバッチ処理の場合は、ペイロード・サイズしきい値制限を使用できません。 また、シリアライズされたXMLペイロードについて、ネイティブ変換ライブラリのかわりに、ネイティブ・サイズを計算する機能がないXDKパーサーが解析に使用される場合にも、ペイロード・サイズしきい値制限を使用できません。
ペイロードしきい値は、Oracle JCAアダプタによって公開されるノブを使用して設定できます。 次のサンプルに示すように、ノブはアダプタ・サービスのバインディング・プロパティとしてcomposite.xmlファイルで設定できます。
<binding.jca config="getMsg_mq.jca"> <property name="payloadSizeThreshold" type="xs:string" many="false" override="may">1000</property> </binding.jca>
XSDおよび不透明（Opaque）トランスレータ・シナリオは、ペイロード・サイズが決定されるアダプタでのみ処理できます。 特定のOracle JCAアダプタでサポートされているシナリオの詳細は、表2-2を参照してください。
表2-2 Oracle JCAアダプタでサポートされているシナリオ
| ケース | Oracleファイル/FTPアダプタ |
Oracle JMSアダプタ |
Oracle MQ Seriesアダプタ |
Oracle AQアダプタ |
Oracleデータベース・アダプタ |
|---|---|---|---|---|---|
|
NXSD |
はい |
はい |
はい |
はい |
適用なし |
|
XSD |
はい |
はい |
はい |
いいえ |
はい |
|
不透明（Opaque） |
はい |
はい |
はい |
いいえ |
適用なし |
|
DTD |
いいえ |
いいえ |
いいえ |
いいえ |
適用なし |
また、ペイロード・サイズを制限するグローバル・プロパティを設定して、payloadSizeThresholdのデフォルト値を（無限から）有限数に変更できます。 この場合、payloadSizeThresholdのデフォルト値を有限数に設定すると、特定のインバウンド・アダプタのエンドポイントのpayloadSizeThresholdプロパティ値を明示的に構成しない場合にも、グローバル・デフォルトが有効になります。 グローバル・デフォルトをcomposite.xmlの値とともに指定した場合、composite.xmlで指定した値によってグローバル値がオーバーライドされます。 グローバル・プロパティは、Oracle Enterprise ManagerのMBeansブラウザ（アダプタMbean）を使用して変更できます。 この変更は、すべての現在および将来のエンドポイントに対して即座に有効になります。
Oracle JCAアダプタは、インバウンド処理とアウトバウンド処理の両方で大きなペイロードの処理をサポートしています。 ただし、ストリーミング機能を明示的にサポートしているのは次のアダプタのみです。
Oracleファイル・アダプタ
詳細は、第4.5.4項「Oracleファイル・アダプタのスケーラブルなDOM」を参照してください。
Oracle AQアダプタ
詳細は、第7.2.11項「ストリーム・ペイロードのサポート」を参照してください。
Oracle JMSアダプタ
詳細は、「大きなペイロードのストリーミングのサポート」を参照してください。
Oracleデータベース・アダプタ
詳細は、第9.3.5項「大きなペイロードのストリーミング」を参照してください。
他のアダプタには、両方の明示的なサポートはありません。
バッチ処理機能とデバッチ処理機能は、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で構成されています。 設計時構成中にバッチ・サイズを指定する必要があります。 さらに、アダプタには一連のメッセージを単一ファイルにバッチ処理するためのライターも組み込まれています。 詳細は、第4.2.4項「ファイルのデバッチ処理」を参照してください。
Oracle JCA Adapter for Databasesは、一連の表をポーリングしてイベントを検出するためのパブリッシュ・コンポーネントで構成されています。 このコンポーネントでは、BPELプロセスの1度に1つのレコードまたは1度に複数のレコードに対してイベントを発生させることができます。 詳細は、第9.4.2.2項「ポーリング計画」を参照してください。
アダプタの論理デプロイとは、weblogic-ra.xmlデプロイメント・ディスクリプタ・ファイル内にConnectionFactoryオブジェクトを作成することです。 接続情報を追加してJNDI名に割り当てるには、Oracle WebLogic Server管理コンソールまたはWLSTスクリプトを使用して、リソース・アダプタの対応するweblogic-ra.xmlファイルを編集します。 weblogic-ra.xmlファイルには、アダプタのランタイム接続パラメータが含まれています。
コネクション・ファクトリの作成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
次の手順では、Oracle WebLogic Server管理コンソールでDatabaseコネクション・ファクトリを設定する方法について説明します。
この項には、次の項目が含まれます。
データソースを作成する手順は、次のとおりです。
http://servername:portnumber/consoleにナビゲートします。
必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。
Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。
「ドメイン構造」で、「サービス」、「JDBC」を選択し、「データ・ソース」をクリックします。
「JDBCデータ・ソースの概要」ページが表示されます。
「新規作成」をクリックします。 「新しいJDBCデータ・ソースの作成」ページが表示されます。
新しいJDBCデータソースの識別に使用するプロパティについて次の値を入力します。
名前: soademoDatabase
JNDI名: jdbc/soademoDatabase
データベースのタイプ: Oracle
「データベース・ドライバ」はデフォルト値のままにしておきます。
「次へ」をクリックします。 「新しいJDBCデータ・ソースの作成 - トランザクション・オプション」ページが表示されます。
「次へ」をクリックします。 「新しいJDBCデータ・ソースの作成 - 接続プロパティ」ページが表示されます。
「接続プロパティ」ページで接続プロパティを入力し、「次へ」をクリックします。
「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページが表示されます。
「構成のテスト」をクリックし、データベースの可用性および指定した接続プロパティをテストします。 「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページの上部に接続テストに成功したことを示すメッセージが表示されます。
「次へ」をクリックします。 「新しいJDBCデータ・ソースの作成 - ターゲットの選択」ページが表示されます。
ターゲットを選択して「終了」をクリックします。 データソースが作成されました。
「JDBCデータ・ソースの概要」ページが表示されます。 このページには、このドメインに作成されているJDBCデータソース・オブジェクトがまとめられています。 このリストには、作成したデータソースが表示されます。
接続プールを作成する手順は、次のとおりです。
http://servername:portnumber/consoleにナビゲートします。
必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。
Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。
「ドメイン構造」の下で、「デプロイメント」をクリックします。
「デプロイメントの概要」ページが表示されます。
「デプロイメント」リストでデータベース・アダプタ名をクリックします。
「DbAdapterの設定」ページが表示されます。
「構成」タブをクリックし、「アウトバウンド接続プール」タブをクリックします。
「アウトバウンド接続プールの構成表」が表示されます。
「新規作成」をクリックします。
「javax.resource.cci.ConnectionFactory」を選択し、「次へ」をクリックします。
「新しいアウトバウンド接続の作成」ページが表示されます。
「JNDI名:」フィールドにeis/DB/soademoDatabaseと入力します。
|
注意: この手順で入力するJNDI値は、第2.19.1項「データソースの作成」の手順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プロパティの値が「接続ファクトリ・インタフェース」タブに表示されます。
|
注意: アウトバウンド接続プールについて新規の値を追加する場合、管理対象サーバーや管理サーバーを再起動する必要はありません。 ただし、既存の接続プールのプロパティを編集した場合は、サーバーを再起動する必要があります。 |
新しいアダプタ・コネクション・ファクトリを追加したり、既存のアダプタ・コネクション・ファクトリを更新できます。 アダプタ・コネクション・ファクトリを追加または更新した場合に、コンポジットで新しいアダプタ・コネクション・ファクトリのプロパティが使用されるようにするには、次のいずれかの手順を実行する必要があります。
JCAファイルの変更
JCAアダプタ・コネクション・ファクトリ用の新規JNDIを作成します。
コネクション・ファクトリの作成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
デプロイされたコンポジットのJCAファイルを新規JNDIを指すように変更します。
コンポジットは新しく作成された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管理コンソールのホーム・ページにログインします。
「ドメイン構造」ペインで「デプロイメント」を選択します。
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")を指定します。
エンドポイント・プロパティが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に示した設定は、単一インスタンスとRACデータベースの両方のタイプのデータベースに適用可能です。 RACデータベースの場合は、エンドポイント用に作成されたマルチ・データソースを構成するデータソースに、これらの設定を使用する必要があります。 |
表2-3に示した設定を適用する以外に、『Oracle Fusion Middleware 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
Oracle JCAアダプタには、次の各項で説明するエラー処理機能が用意されています。
この項には、次の項目が含まれます。
サービス・インフラストラクチャにポストされる前にエラーになったメッセージは、拒否されたメッセージと呼ばれます。 たとえば、Oracleファイル・アダプタがCSVフォーマットのデータを含んだファイルを取得し、XMLフォーマットに（NXSDを使用して）変換しようとします。 その場合、変換中になんらかのエラーがあると、このメッセージは拒否され、ターゲット・コンポジットにはポストされません。 拒否されたメッセージを生成するのは、主としてアダプタとバインディング・コンポーネントです。
メッセージがサービス・インフラストラクチャ・レイヤーにポストされた後に発生するエラーやフォルトは拒否されません。 このように失敗したメッセージはサービス・インフラストラクチャ・コンポーネントにより処理され、拒否されたメッセージとはみなされません。
アダプタとその他のバインディング・コンポーネント（WSバインディング・コンポーネントなど）は、バインディング・レベルでエラーになったメッセージ、つまりサービス・インフラストラクチャ・レイヤーに入る前にエラーになったメッセージを拒否します。 拒否されたメッセージは、すべてペイロードとともにデータベースに格納されます。
この項には、次の項目が含まれます。
詳細は、第2.15項「アダプタ内でのOracle BPEL Process Managerの相関サポート」を参照してください。
リリース10.xでは、拒否ハンドラはOracle BPELプロセスのデプロイメント・ディスクリプタ（bpel.xml）に定義されていました。 しかし、リリース11gでは、フォルト・ポリシーを使用して拒否ハンドラを定義する必要があります。
インバウンド拒否ハンドラの場合、指定できるアクション・ハンドラは1つのみです。
次の手順に示すように、fault-policies.xmlおよびfault-bindings.xmlという2つのファイルを作成し、JDeveloperのSOAプロジェクト・ディレクトリにコピーする必要があります。
拒否されたメッセージに関するフォルト・ポリシーをfault-policies.xmlファイル内で定義する必要があります。このファイルは、JDeveloperのプロジェクト・ディレクトリにcomposite.xmlとともに格納されています。
次にフォルト・ポリシーの例を示します。
<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies>
<faultPolicy version="2.0.1" id="RejectedMessages">
<Conditions> <!-- All the fault conditions are defined here -->
<faultName xmlns:rjm="http://schemas.oracle.com/sca/rejectedmessages" name="rjm:<SERVICE_NAME>"> <!-- local part of fault name should be the service name-->
<condition>
<action ref="writeToFile"/> <!-- action to be taken, refer to Actions section for the details of the action -->
</condition>
</faultName>
</Conditions>
<Actions> <!-- All the actions are defined here -->
<Action id="writeToFile">
<fileAction>
<location>/tmp/rej_msgs</location>
<fileName>emp_%ID%_%TIMESTAMP%.xml</fileName>
</fileAction>
</Action>
</Actions>
</faultPolicy>
</faultPolicies>
次の例に示すように、フォルト・ポリシーをfault-bindings.xml内のコンポジットのサービス・エンドポイントに関連付ける必要があります。
<faultPolicyBindings version="2.0.1" xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
<service faultPolicy="RejectedMessages">
<name>Read</name>
</service>
...
</faultPolicyBindings>
fault-policies.xmlおよびfault-bindings.xmlファイルをSOAコンポジットのプロジェクト・ディレクトリにコピーします。
SOAコンポジット・プロジェクトをデプロイします。
|
注意: 第2.22.1.1項「拒否ハンドラの構成」の説明に従って拒否ハンドラを構成しなければ、デフォルトのファイル・ベース拒否ハンドラが開始され、拒否されたメッセージは<domain_home>/rejmsgs/<wls_server_name>/<composite_name>に移動されます。
また、Oracle BPEL Process Manager（Oracle BPEL PM）と同じフォルト・ポリシーで、メディエータ・コンポーネントで拒否されたメッセージを構成することもできます。 |
次の拒否メッセージ・ハンドラがあります。
使用可能なアクション・ハンドラ
次に示すのは、フォルト・ポリシーで構成できるシステム定義のエラー・ハンドラです。
Webサービス・ハンドラ
ターゲット・サービスでは事前定義済のWSDLインタフェースを実装する必要があります。
Webサービスの呼出しにはSOAPバインディングが使用されます。
次の例に示すように、ネイティブ・ペイロードをWS添付として渡すことができます。
<Action id="ora-ws"> <invokeWS uri="WebServiceURI"/> <!-- format - <Absolute wsdl path>|service name|port name --> </Action>
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>
Javaインタフェース詳細
次のコード・スニペットは一例です。
package oracle.integration.platform.faultpolicy;
public interface IFaultRecoveryJavaClass
{
public void handleRetrySuccess( IFaultRecoveryContext ctx);
public String handleFault( IFaultRecoveryContext ctx);}
キュー
拒否されたメッセージは、例1: スタンドアロン・データベースの使用および例2: RACデータベースの使用に示すように、適切なコンテキストおよびペイロードとともにJMSメッセージとしてキューにエンキューされます。
例1: スタンドアロン・データベースの使用
<Action id="ora-queue"> <enqueue uri="QueueURI"/> <!-- QueueURI format - jdbc:oracle:thin:@<host>:<port>:<sid>#<un>/<pw>#queue --> </Action>
例2: RACデータベースの使用
<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>
ファイル・アクション・ハンドラの場合にのみ、拒否されたメッセージのプロパティをすべて含んだメタデータ・ファイルが作成されます。 たとえば、Oracleファイル・アダプタの場合、このメタデータ・ファイルにはインバウンド方向やファイル名などの情報が含まれます。 メタデータ・ファイルの場所はペイロード・ファイルと同じで、ネーミング・パターンは<FILE_NAME>_metadataです。
|
注意: 拒否されたメッセージは、Fusion Middleware Controlコンソールからは発行できません。 |
ペイロードの永続性
拒否されたメッセージを再発行する場合、ペイロードの永続性が必要です。 ペイロードはデータベースに格納され、Fusion Middleware Controlコンソールを介してペイロード表示機能を使用できます。 自動エラー処理中に起動されるエラー・ハンドラも、起動時にペイロードを取得します。
データベース内のエラー・ペイロードの永続性はデフォルトで使用可能です。
拒否されたメッセージはrejected_message表に格納されます。 拒否されたメッセージは次のいずれかの手順でチェックできます。
データベースからのチェック
データベースにsoainfraスキーマとして接続し、次のSQLコマンドを実行する必要があります。
select * from rejected_message
Fusion Middleware Controlコンソールからのチェック
「ダッシュボード」タブの「最新のフォルトと拒否メッセージ」セクションまたは「フォルト・メッセージと拒否メッセージ」タブで、拒否されたメッセージを表示できます。
Fusion Middleware Controlコンソールを拒否されたメッセージのチェックに使用する方法の詳細は、次を参照してください。
『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のインバウンド・アダプタに関する最新のフォルト・メッセージと拒否メッセージの監視に関する項。
『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のインバウンド・アダプタに関するフォルト・メッセージと拒否メッセージの監視に関する項。
Oracle JCAアダプタとOracle Adapter for Oracle Applicationsアダプタでは、次の相互作用の接続エラーが処理されます。
Oracle JCAアダプタとOracle Adapter for Oracle Applicationsでは、一時的な接続エラーに関してoracle.tip.adapter.api.exception.PCRetriableResourceException例外が発生します。これはリカバリ可能な接続エラーです。 たとえば、データベース・リスナーを起動できないと、接続エラーが戻される場合があります。
拒否ハンドラには、再試行可能な例外と再試行不可能な例外という2つのタイプがあります。
再試行可能な例外の場合は、jca.retry.countの値を必要な再試行回数に設定する必要があります。 たとえば、jca.retry.countの値を10に設定すると、再試行は10回発生します。 ただし、jca.retry.countに値を設定しない場合、コンポジットの一部として組み込んでいれば、フォルト・ポリシーにより再試行が実行されます。
次のコード・スニペットは、アウトバウンド相互作用に関する再試行可能な例外についてcomposite.xmlファイルに値を設定する一例です。
<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ファイルを介して実行可能な再接続試行の最大回数を定義することで処理できます。 次の例に示すように、このファイルでは再接続試行のパラメータを指定します。
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault">
<condition>
<action ref="ora-retry"/>
</condition>
</faultName>
<Actions>
<Action id="ora-retry">
<retry>
<retryCount>10</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff>2</exponentialBackoff>
</retry>
</Action>
</Actions>
次の例に示すように、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>
この例の再接続パラメータ設定では、JCAバインディング・コンポーネント・ランタイムの再試行回数を10回と指定しており、再試行間隔は2秒から始まって2の倍数ずつ増加します。
|
注意: フォルト・ポリシーは、XAモードのアウトバウンド・アダプタには機能しません。 たとえば、フォルト・ポリシーをアウトバウンド・アダプタの失敗時に再試行させる必要がある場合、フォルト・ポリシーは再試行されず、この失敗の発生前に成功していたアウトバウンド・アダプタはロールバックされません。 |
構成済の再試行回数に達すると、サービス・インフラストラクチャ起動例外がスローされます。 すべての時間測定は秒単位で指定されます。
アウトバウンド・アダプタによりレポートされたエラーにインバウンド・アダプタが応答できるようにするには、サービス・インフラストラクチャ起動例外のタイプの伝播が重要です。アダプタがOracle BPEL Process Managerを同期的にコールし、次にOracle BPEL Process Managerがダウンストリーム・アダプタをコールする場合のフォルトの伝播を示します。 図2-10では、サービス・インフラストラクチャ起動例外が、Oracle BPEL Process Managerを介してダウンストリーム・アダプタからコール元アダプタに伝播しています。
すべてのOracle JCAアダプタ（Oracleソケット・アダプタ以外）とレガシー・アダプタでは、バックエンド・アプリケーションに接続してイベントを受信するためのプル・モデルがサポートされています。
パッケージ・アプリケーション・アダプタ（Oracle Adapter for Oracle Applications以外）では、EIS（Enterprise Information System）からイベントを受信するためのプッシュ・モデルがサポートされています。 接続関連の問題はリカバリ可能とみなされ、ほとんどのインバウンド・アダプタはEISとの接続を確立できるまで再試行を続けます。 ただし、インバウンド・アダプタは、リカバリ不可能なエラーが発生した場合（インバウンド・アダプタがメッセージをパブリッシュ後にEISから削除できない場合など）、汚染されたメッセージを防ぐためにエンドポイントを非アクティブ化します。
パッケージ・アプリケーション・アダプタ（Oracle EBSアダプタ以外）では、バックエンド・アプリケーションからイベントを受信するためのプッシュ・モデルもサポートされています。 この場合、接続の概念は適用されません。 通常、インバウンド・エンドポイントはHTTPリスナー、TCP/IPリスナー、FTPリスナー、MQSeriesリスナーなどで、イベントが発生すると、それぞれのonMessageメソッドがトリガーされます。
拒否ハンドラには、再試行可能な例外と再試行不可能な例外という2つのタイプがあります。
|
注意: これらの拒否ハンドラは、同期プロセスでのみ適用可能です。 非同期プロセスや一方向プロセスには適用されません。 |
インバウンド相互作用に関する再試行可能な例外では、次のプロパティがサポートされています。
jca.retry.count
拒否前の最大再試行回数を指定します。
jca.retry.interval
再試行間の時間間隔（秒単位）を指定します。
jca.retry.backoff
再試行間隔の増加係数（正の整数）を指定します。
jca.retry.maxInterval
再試行間隔の最大値、つまりバックオフ > 1の場合の上限を指定します。
前述のプロパティ・リストは、次の例に示すように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で指定した値によってグローバル値がオーバーライドされます。 グローバル・プロパティは、Oracle Enterprise ManagerのMBeansブラウザ（アダプタMbean）を使用して変更できます。 この変更は、すべての現在および将来のエンドポイントに対して即座に有効になります。
Oracle Enterprise ManagerのMBeansブラウザ（アダプタMbean）を使用してグローバル・プロパティを変更するには、次の手順を使用する必要があります。
http://servername:portnumber/emにナビゲートします。
Fusion Middleware Controlコンソールのホーム・ページが表示されます。
左ペインのナビゲータで「SOA」フォルダの「soa-infra」を右クリックします。
「soa-infra」ページが表示されます。
図2-11に示すように、「SOAインフラストラクチャ」メニューで、「管理」→「システムMBeanブラウザ」の順に選択します。
「システムMBeanブラウザ」ページが表示されます。
図2-12に示すように、「oracle.as.soainfra.config」、「サーバー」→「AdapterConfig」、「アダプタ」の順に選択します。
GlobalInboundJcaRetryCount属性を変更します。
この項では、メッセージ・エラーの処理方法についてサンプル・シナリオを使用して説明します。
図2-13に示すように、2つのコンポジットComposite1およびComposite2があり、それぞれにOracle BPELプロセスがあり、ローカル・リソースとXAリソースが混在している例を考えてみます。
肯定的なシナリオ、つまりメッセージがすべてのキュー（Q1、Q2およびQ3）に正常に配信された場合、トランザクションは正常にコミットされます。
メッセージをQ1（またはいずれかのキュー）には配信できないが、キューQ2およびQ3に配信できる場合、3つのメッセージはすべてXAリソースであり、そのユニットの1つに例外があるため、トランザクションでは3つのメッセージをすべてロールバックする必要があります。 ロールバック例外はQ1が失敗した第2のコンポジットについてのみスローされ、トランザクションでは3つのキューすべてについてメッセージがロールバックされるかわりにQ2およびQ3がコミットされます。
失敗したキューが1つのみで他の2つにはメッセージが正常に配信された場合も、トランザクションですべてのキューをロールバックするには、コールされたコンポジット（Composite2）のcomposite.xmlファイルを例2-4に示すように変更する必要があります。
例2-4 Composite2のcomposite.xmlの変更
<component name="BPELProcess1"> <implementation.bpel src="BPELProcess1.bpel"/> <property name="bpel.config.transaction">required</property> </component>
bpel.config.transactionプロパティをrequiredの値に設定すると、Oracle BPELエンジンは新規トランザクションを作成せず、コール元のトランザクションを使用して同期リクエストを効果的に処理することに注意してください。 したがって、いずれかの時点でトランザクションがロールバックすると、そのトランザクションでの実行内容は何もコミットされません。
「Oracle Enterprise Manager Grid Control」コンソールから、デプロイされたSOAコンポジット・アプリケーションのインスタンスを実行およびテストする準備ができました。 これにより次が可能になります。
コンポジット・アプリケーションの管理。
コンポジットのインスタンスの起動。
コンポジットのインスタンスの追跡。
詳細なコンポーネント・インスタンスの監査証跡の表示。
アプリケーションのテストの詳細は、『Oracle Fusion Middleware 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 Connectとメインフレーム・サーバーのトレース・レベルは、Oracle Studioを使用して設定できます。
Fusion Middleware Controlコンソールを使用してトレース・レベルを設定する手順は、次のとおりです。
http://servername:portnumber/emにナビゲートします。
Fusion Middleware Controlコンソールのホーム・ページが表示されます。
左ペインの「ナビゲータ」で「SOA」フォルダの「soa-infra」を右クリックします。
メニューが表示されます。
図2-14に示すように、「ログ」→「ログ構成」の順に選択します。
「ログ構成」ページが表示されます。
「ログ出力名」リストで「oracle.soa.adapter」を探し、「Oracle Diagnostic Loggingレベル(Javaレベル)」フィールドでログ・レベルを変更します。 この例では、図2-15に示すようにリストから「Trace:32 (FINEST)」を選択します。
|
注意: コンピュータの再起動と再起動の間もログ・レベルを確実に保持するには、「表示」リストから「永続ログ・レベル状態のログ出力」を選択します。 デフォルトでは、ログ・レベルはランタイム・ログ出力用に設定されます。 ランタイム・ログ出力は、コンポーネントの再起動と再起動の間に保持されません。 |
詳細は、第2.25項「アダプタ・ログの表示」を参照してください。
次のように、Oracle JCAアダプタのログを表示できます。
Oracle JCAアダプタと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 Connect管理ツールでもあるOracle Studioを使用して表示できます。 Oracle Connectでは、デーモン・ログ、ワークスペース・ログおよびサーバー・プロセス・ログなど、各種のログが生成されます。
詳細は、第2.24項「Oracle JCAアダプタのトレース・レベルの設定」を参照してください。
