| Oracle® Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド 11gリリース(11.1.1.6.2) B55918-06 |
|
 前 |
 次 |
この章では、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テクノロジ・アダプタとOracle Adapter for Oracle Applicationsは、Oracle Fusion Middlewareインストールの一部として使用可能です。これらのアダプタでは、Oracle Containers for Java EEと中間層デプロイメントの両方がサポートされています。詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』を参照してください。
レガシー・アダプタとパッケージ・アプリケーション・アダプタは、Oracle Fusion Middleware AdaptersおよびConnectors CDに収録されています。これらのアダプタでは、中間層デプロイメントのみがサポートされています。
|
注意: アダプタをインストールする前に、 |
Oracle JCAアダプタは、JCA 1.5リソース・アダプタとしてデプロイされます。したがって、アダプタを起動または停止するには、すべてのリソース・アダプタでSPIインタフェースの一部としてstart (BootstrapContext)およびstopメソッドを実装する必要があります。Oracle JCAアダプタは、それを使用するSOAコンポジットによりJCAアウトバウンド相互作用が開始されると起動されます。また、インバウンド相互作用にSOAコンポジット自体がロードされるとき、またはアダプタによりイベントがOracle BPELプロセスにパブリッシュされるときにも、アダプタを起動できます。
アダプタを起動後に停止するには、Oracle Containers for Java EEを停止するか、または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アダプタにより、基礎となるバックエンド操作固有のプロパティがメッセージ・ヘッダー要素として公開され、これらの要素をビジネス・プロセス内で操作できるようになります。
これらのプロパティが公開されているため、Fusion Middleware ControlコンソールでOracle JCAアダプタのプロパティを追加または削除したり元に戻すことができます。ただし、プロパティのタイプによっては、プロパティの変更を適用するには、コンポジット・アプリケーションを再デプロイする必要があります。
表2-1に、構成できるメッセージ・ヘッダー・プロパティのタイプおよび再デプロイが必要かどうかを示します。
表2-1 Oracle JCAアダプタのプロパティ・タイプ
| プロパティ・タイプ | 説明 | 制限 |
|---|---|---|
|
アクティブ化仕様および相互作用仕様 |
SOAコンポジット・アプリケーション内で、アクティブ化仕様プロパティはサービスとして機能し、相互作用仕様プロパティは参照として機能します。 |
これらのプロパティは追加したり削除しないでください。値の変更のみが可能です。 これらのプロパティでは、アダプタのエンドポイントをリサイクルする必要があります。これらのタイプのプロパティは、他のプロパティにも依存します。プロパティを追加する場合、他にも追加する必要がある従属プロパティを把握する方法はありません。 |
|
エンドポイント |
これらは、アクティブ化仕様プロパティまたは相互作用仕様プロパティを介して公開されない、チューニングに関連するプロパティ(タイムアウト、しきい値、最大間隔などを指定する)です。 |
エンドポイント・プロパティの追加、削除または変更に制限はありません。これらのプロパティが追加、削除または変更されると、アダプタに通知されますが、再デプロイは必要ありません。
|
詳細は、付録A「Oracle JCAアダプタのプロパティ」を参照してください。
Oracle JCAアダプタは、Oracle Containers for Java EEコンテナに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)名を提供します。 接続プーリングのパラメータを提供します。 リソースのプリンシパル・マッピング・メカニズムを提供します。 構成情報を提供します。 |
詳細は、次を参照してください。
『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ファイルをデプロイする場合は、デプロイ時に、Oracle WebLogic Serverがアダプタのjarファイルのロード後にこのRARファイルをデプロイできるよう、デプロイメント順序を高い値(500など)に変更する必要があります。
たとえば、META-INF/ra.xmlとMETA-INF /weblogic-ra.xmlのみを含み、新しいJNDIのインスタンス化に必要なjarファイル・アダプタ(DbAdapter.jar)が含まれていないDBAdapter_NewJndis.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として識別します。たとえば、データベース・アダプタ・サービス・ウィザードを通じて実行しているときは、eis/DB/custStoreをcreateCustomerサービスのJNDI名として指定します。
このアダプタ・サービスを使用してコンポジットをモデル化した後は、一切の変更を行わずに開発、テストおよび本番環境にデプロイする必要があります。ただし、デプロイの前に、正しいEISインスタンスを指している各環境に、eis/DB/custStoreに対応するJNDIエントリがあることを確認してください。
要約:
すべてのJCAファイルはweblogic-ra.xmlファイルに定義されたJNDI名を参照します。
デプロイするすべての環境でJNDI名が同じになるようにweblogic-ra.xmlファイルを更新する必要があります。
weblogic-ra.xmlデプロイメント・ディスクリプタを使用して、再試行間隔や再試行回数などのデプロイメント時のプロパティの値を指定します。このファイルは、エンドポイントの環境も識別します。
デプロイメントの前に、適切な環境に対応するJNDIエントリがあることを確認します。
この項では、メッセージの損失がないことをアダプタで保証する方法について説明します。
トランザクション・アダプタによって、エンタープライズ情報システム(EIS)は1フェーズ・コミットまたは2フェーズ・コミット(ローカル・トランザクションまたはグローバル/分散トランザクション)に参加できます。
非トランザクション・アダプタはトランザクション・セマンティクスを使用せずに、配信を確保する固有のスキームを実装します。
この項では、次の内容について説明します。
詳細は、次を参照してください。
『Oracle Fusion Middleware高可用性ガイド』のOracle JCAアダプタの信頼性とトランザクション動作に関する項。
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トランザクションが一時停止されてからコミットされることはありません。
Oracleファイル・アダプタやOracle FTPアダプタなどの非トランザクション・アダプタをトランザクション・アダプタとともに使用する際は、再試行によって非トランザクション・データに影響する場合があるため、重複するメッセージの作成などに注意してください。たとえばメッセージの重複が発生しないようにビジネス・プロセスをモデル化するなどして、注意を払う必要があります。
再試行に関するトピックの追加情報は、第2.21.1項「拒否されたメッセージの処理」およびそれ以降の項を参照してください。
ポーリング: すべてのOracle JCAアダプタとレガシー・アダプタは、プル、つまりポーリングをサポートしていますが、これは、イベントを受信する、つまりEISエンドポイントに使用可能なメッセージおよびデータを定期的に問い合せるためにバックエンド・アプリケーションに接続するモデルです。この例外は、異なるロジスティクスのセットを使用するOracle Socket Adapterですが、その場合、ソケット・アダプタは、他のアダプタがクライアント・ソケットを使用して接続するのと同じように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の移行が使用されているため、管理サーバーに障害が発生した場合に、同じ物理システムまたは別の物理システム上でそのサーバーが自動的に再起動し、障害が発生したサーバー上のコンポジットに固有のインバウンド・アダプタの機能が再開されます。
その間に、他のクラスタ・メンバー上のインバウンド・アダプタはメッセージ・サービス処理を続行できます。
詳細は、次を参照してください。
第2.13項「アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート」
ファイル/FTPアダプタ: 第4.2.18項「高可用性」
データベース・アダプタ: 第9.3.7項「高可用性」
MQアダプタ: 第10.3.4項「高可用性」
『Oracle Fusion Middleware高可用性ガイド』のOracle JCAアダプタと高可用性の説明に関する項。
JCAバインディング・コンポーネントでは、インバウンド・アダプタ・サービスのアクティブ・フェイルオーバーがサポートされています。
このフェイルオーバー機能を特定のインバウンド・アダプタのエンドポイントに対して有効にするには、singleton JCAサービス・バインディング・プロパティ(composite.xml)を<binding.jca>要素に追加し、値をtrueに設定する必要があります(例2-1を参照)。
この機能を無効にするには、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バインディング・コンポーネントのインスタンスによって、プライマリのアクティブ化の役割を引き受ける1つのアクティブ化がアクティブ化の中からランダムに選択されます。
Oracle WebLogicクラスタ内の他のアクティブ化(インスタンスとも呼ばれる)は、JCAリソース・アダプタでEndpointActivationを起動せずにホットスタンバイ状態で開始されます。これらのアクティブ化にプライマリのアクティブ化の役割を再度割り当てることができます。
プライマリのアクティブ化がある時点で応答しなくなったり、手動で非アクティブ化されたり、クラッシュまたは終了した場合、Oracle WebLogicクラスタの残りのJCAバインディング・コンポーネント・メンバーのいずれかが即座にこの非アクティブ化を検出し、スタンバイ状態のアクティブ化エージェントの1つにプライマリのアクティブ化の役割を再度割り当てます。
詳細は、第2.12項「コンポジットの可用性とインバウンド・アダプタ」を参照してください。
ネイティブ相関を使用し、コールバック・インタフェース(参照用)を定義するか、中間プロセス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にコピーする必要があります。
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 JCAアダプタによって公開されるノブを使用して設定できます。次のサンプルに示すように、ノブはアダプタ・サービスのバインディング・プロパティとしてcomposite.xmlファイルで設定できます。
<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)トランスレータ・シナリオは、ペイロード・サイズが決定されるアダプタでのみ処理できます。特定の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オブジェクトを作成します。weblogic-ra.xmlファイルにはアダプタのランタイム接続パラメータが含まれています。
接続情報を追加してJNDI名を割り当てるには、Oracle WebLogic Server管理コンソールまたはWLSTスクリプトを使用して、リソース・アダプタの対応する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.18.1項「データソースの作成」のステップ5で入力した値とは異なります。このステップで指定したJNDI名は、後でアプリケーションをビルドするときに作成するデータベース接続に入力する値と一致する必要があります。 |
「終了」をクリックします。
このリソース・アダプタのアウトバウンド接続プール・グループとインスタンスの表を示す「DbAdapterの設定」ページが表示されます。
構成の変更内容は、新規デプロイメント計画に格納する必要があります。これを次のステップで行います。
「パス」フィールドで、デプロイメント計画ファイルのパスを選択または入力します。パスは「.xml」で終了する必要があります。
|
注意: AdminserverがコンピュータAで実行中で、Oracle SOA ServerがコンピュータBで実行中の場合は、Oracle SOA Serverで行った変更内容をアクティブ化する前に、デプロイメント計画ファイルをコンピュータBにコピーする必要があります。デプロイメント計画をOracle SOA Serverコンピュータにコピーせずに変更内容をアクティブ化しようとすると、 |
「プロパティ」フィールドに、xADataSourceNameの値としてjdbc/soademoDatabaseを入力します。
「保存」をクリックします。
|
注意: この手順のように「保存」をクリックした時点ではプロパティが保存されません。かわりに、変更内容を保存するには[Enter]を押す必要があります。 |
「ドメイン構造」の下で、「デプロイメント」をクリックします。
「デプロイメントの概要」が表示されます。
次の手順を実行します。
「DbAdapter」チェック・ボックスを選択して「更新」をクリックします。
「アプリケーション更新アシスタント」ページが表示されます。
「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します」オプションを選択します。
「次へ」を選択して「終了」をクリックします。
選択したデプロイメントが更新されたことを示す「デプロイメントのサマリー」ページが表示されます。
「ドメイン構造」で、「デプロイメント」、「DbAdapter」、「構成」および「アウトバウンド接続プール」を順にクリックします。
ステップ11で入力したxADataSourceプロパティの値が「接続ファクトリ・インタフェース」タブに表示されます。
|
注意: アウトバウンド接続プールについて新規の値を追加する場合、管理対象サーバーや管理サーバーを再起動する必要はありません。ただし、既存の接続プールのプロパティを編集した場合は、サーバーを再起動する必要があります。 |
新規アダプタ・コネクション・ファクトリを追加するか、既存のアダプタ・コネクション・ファクトリを更新できます。
アダプタ・コネクション・ファクトリを追加または更新する場合は、次の手順のいずれかを実行して、コンポジットで新規アダプタ・コネクション・ファクトリのプロパティが使用されていることを確認する必要があります。
次の手順を実行します。
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 Containers for Java EEの再起動を回避するには、次の手順を実行する必要があります。
Oracle WebLogic Server管理コンソールのホーム・ページにログインします。
「ドメイン構造」ペインで「デプロイメント」を選択します。
Oracle WebLogic Server管理コンソールの「デプロイメントの概要」ページが表示されます。
新しいコネクション・ファクトリを追加したアダプタを選択します。
「更新」をクリックします。
「アプリケーション更新アシスタント」ページが表示されます。
「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します」オプションを選択します。
「次へ」を選択して「終了」をクリックします。
選択したデプロイメントが更新されたことを示す「デプロイメントのサマリー」ページが表示されます。この手順を使用して、たとえば、再起動の必要なしにアダプタのエンドポイントを変更できます。
WebLogicコンソールを使用すると、JMSで使用するコネクション・ファクトリを作成できます。第8.4.1.4.1項「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のドキュメント( |
表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を使用して)変換しようとします。その場合、変換中になんらかのエラーがあると、このメッセージは拒否され、ターゲット・コンポジットにはポストされません。
拒否されたメッセージを生成するのは、主としてアダプタとバインディング・コンポーネントです。
同期フローの下流で発生したエラーまたは障害は、インバウンド・アダプタによって次のように処理されます。
例外が再試行不可能な場合は、即座に拒否されます。
例外が再試行可能な場合は、無制限に再試行されます。
再試行はjca.retry.countの値(構成されている場合)と同じ回数だけ行われ、再試行回数の上限に達した場合は拒否されます。
バインディング・レベルでエラーになったメッセージはアダプタによって拒否されます。つまり、サービス・インフラストラクチャ・レイヤーに入る前にエラーになります。
拒否メッセージは、すべてペイロードとともにデータベースに格納されます。拒否メッセージは後から問い合せることができます。
この項には、次の項目が含まれます。
詳細は、第2.14項「アダプタ内での相関サポート」を参照してください。
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.21.1.1項「拒否ハンドラの構成」の説明に従って拒否ハンドラを構成しなければ、デフォルトのファイル・ベース拒否ハンドラが処理を開始し、拒否されたメッセージは また、Oracle BPEL Process Manager(Oracle BPEL PM)と同じフォルト・ポリシーで、メディエータ・コンポーネントで拒否されたメッセージを構成することもできます。 |
拒否メッセージはrejected_messageテーブルに格納されます。
次のいずれかの手順を使用して、拒否されたメッセージをチェックできます。メッセージを取得し、固有の実装に応じて追加処理を実行できます。
データベースからのチェックを行うには、データベースにsoainfraスキーマとして接続し、次のSQLコマンドを実行する必要があります。
select * from rejected_message
「ダッシュボード」タブの「最新のフォルトと拒否メッセージ」セクションまたは「フォルト・メッセージと拒否メッセージ」タブで、拒否されたメッセージを表示できます。
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管理者ガイド』のインバウンド・アダプタに関するフォルト・メッセージと拒否メッセージの監視に関する項。
この項では、メッセージ・エラーの処理方法についてサンプル・シナリオを使用して説明します。
図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ファイルを例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に設定され、失敗したキューが1つでもトランザクションですべてのキューがロールバックされるようになります。
bpel.config.transactionプロパティをrequiredの値に設定すると、Oracle BPELエンジンは新規トランザクションを作成せず、コール元のトランザクションを使用して同期リクエストを効果的に処理します。したがって、いずれかの時点でトランザクションがロールバックすると、そのトランザクションでの実行内容は何もコミットされません。
拒否メッセージ・ハンドラを指定することにより、インバウンド・アダプタでのエラー処理方法を決定できます。
拒否ハンドラを作成して、メッセージ・エラーを処理できます。メッセージ・エラーには変換時のエラー、相関IDの不一致、メッセージ受信後のXML解析エラーなどがあります。
再試行可能性の点からエラー処理を検討する前に、使用可能なエラー・ハンドラを理解することが重要です。
次に示すのは、フォルト・ポリシーで構成できるシステム定義のエラー・ハンドラです。
Webサービス・ハンドラ
カスタムJavaハンドラ
JMSキュー
ファイル
拒否されたメッセージは、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つの入力操作、および入力メッセージ用スキーマが必要です。これを次の例に示します。
<?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);}
次の2つの例に示すように、拒否メッセージは、適切なコンテキストとペイロードとともに、JMSメッセージとしてJMSキューにエンキューできます。
最初の例は、スタンドアロン・データベースを使用します。
<Action id="ora-queue"> <enqueue uri="QueueURI"/> <!-- QueueURI format - jdbc:oracle:thin:@<host>:<port>:<sid>#<un>/<pw>#queue --> </Action>
2番目の例は、Oracle 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コンソールを介してペイロード表示機能を使用できます。デフォルトのエラー・ハンドラへのペイロードの指定に加えて、メッセージ/ペイロードは構成された各エラー・ハンドラに完全に指定されます。
インバウンドの再試行可能なエラーは通常、一時的な接続エラーです。インバウンド・アダプタによって再試行が行われるのは、アウトバウンド・バインディングによってスローされた同期プロセスの再試行可能なエラーのみです(回数はデフォルトでは無制限であり、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で指定した値によってグローバル値がオーバーライドされます。
グローバル・プロパティは、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属性を変更します(グローバル・プロパティの例を参照)。
再試行不可能なエラーは通常、変換またはメッセージ解析の結果生成されます。
インバウンド・アダプタはインバウンド・メッセージを拒否することによって、エンタープライズ情報システムからスローされた再試行不可能なエラーを処理します。エラーが再試行不可能な場合は、拒否ハンドラを使用して再試行不可能なエラーを処理する必要があります。
エンタープライズ情報システムとの相互作用からスローされた再試行不可能なエラーの例には、次が含まれます。
主キーの違反
キューが存在しない
マスター・レコードが存在しない
ペイロードをシリアライズできない
操作が再試行されるまで、再試行不可能なエラーは自身の解決を行いません。たとえば、あるファイルからのメッセージがメディエータを介してインバウンド・ファイル・アダプタに送信される場合があります。メディエータには、データベース・テーブルにデータを挿入するアウトバウンド・データベース・アダプタへの順次ルーティングがあります。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「フォルトの伝播」は、アダプタによるサービス・インフラストラクチャの同期呼び出しにおけるフォルトの伝播を示します。Oracle BPEL Process Managerはこの後、下流のアダプタを呼び出します。
この図で、サービス・インフラストラクチャ起動例外は、下流のアダプタからOracle BPEL Process Managerを介して呼び出し元のアダプタに伝播しています。
次の2つのケースでは、フォルト・ポリシー・メカニズムが動作しません。
XAモードのアウトバウンド・アダプタ
メディエータの順次ルーティングでのアウトバウンド・アダプタ
「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 Studioを使用して、Oracle Connectとメインフレーム・サーバーのトレース・レベルを設定できます。
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.24項「アダプタ・ログの表示」を参照してください。
次のように、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.23項「Oracle JCAアダプタのトレース・レベルの設定」を参照してください。
カスタムJCAアダプタ・ウィザードをJDev IDEで汎用アダプタ・ウィザードとして構成して、相互作用/アクティブ化の仕様、プロパティおよびデフォルト値を構成ファイルから読み取って表示できます。ウィザードでは仕様の選択、デフォルトのプロパティ値のオーバーライド、新しいプロパティの追加を行うことができます。カスタム・アダプタ・ウィザードには、次のようないくつかの目的があります。
カスタム・アダプタ・ウィザードはそのままで使用して、カスタム・ランタイム・アダプタをサポートできます。カスタム・アダプタを使用する場合は、カスタム・アダプタ構成ファイルcustomAdapter-config.xmlを指定(または拡張)します。
より具体的なアダプタを作成する場合は、カスタム・アダプタ・クラスを変更または拡張できます(たとえば、アダプタにあわせてテキストを変更できます)。
カスタム・アダプタ・ウィザードを使用して、JCAアダプタ・フレームワークを使用し、SCAEndpointインタフェースにフックすることで、新しいアダプタ・ウィザードを作成する方法についての簡単な例を確認できます。
SOA jdev拡張をインストールすると、カスタム・アダプタのjavaソース・ファイルは<JAVA_HOME>に配置されます。
/jdeveloper/integration/adapters/samples/custom
JDevとともにインストール可能なオプションとしてSOAを選択すると、デフォルトではカスタム・アダプタは使用できません。カスタム・アダプタを使用できるようにするには、<JDEV_HOME>\jdeveloper\integration\seed\soa\configuration\ soa-config.xmlファイルを編集し、"custom"を検索し、<adapterType>要素のコメントを解除します。JDEVコンポーネント・パレットに、SOAダイアグラムのカスタム・アダプタが表示されます。
<JDEV_HOME>\jdeveloper\integration\seed\soa\configuration\ customAdapter-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の例を示します。
<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>
JDev内で「公開されたサービス」または「外部参照」スイムレーンにカスタム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には拒否されたメッセージを再発行する機能がないため、ユーザーが再発行を処理します。
