2 アダプタ・フレームワーク
この章では、アダプタのインストール、起動と停止、エラー処理、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 JCAアダプタの起動と停止
-
Oracle JCAアダプタのメッセージ・ヘッダー・プロパティの構成
-
Oracle JCAアダプタの物理デプロイ
-
JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ
2.1 Oracle JCAアダプタのインストール
ここでは、Oracle JCAアダプタのインストール手順を概観します。
Oracleテクノロジ・アダプタとOracle Adapter for Oracle Applicationsは、Oracle Fusion Middlewareインストールの一部として使用可能です。これらのアダプタでは、Oracle Containers for Java EEと中間層デプロイメントの両方がサポートされています。
SOA Foundationプロファイルによって、アダプタは論理的に2つのグループに分けられます。Tier1とTier2があります。
Tier 1のアダプタには、次のものが含まれます。
-
ファイル
-
FTP
-
データベース
-
JMS
-
AQ
-
MQ Series
-
UMS
Tier 2のアダプタには、次のものが含まれます。
-
ソケット
-
LDAP
-
Coherence
-
MSMQ
-
JDE
-
SAP
-
AS400
Tier 1のアダプタは、このリリースをインストールすると、デフォルトで有効になります。残りのアダプタはインストール済の状態ですが、管理対象サーバーにターゲット設定されていません。これらを使用するには、手動でターゲット設定する必要があります。
レガシー・アダプタとパッケージ・アプリケーション・アダプタは、Oracle Fusion Middleware AdaptersおよびConnectors CDに収録されています。これらのアダプタでは、中間層デプロイメントのみがサポートされています。
ノート:
アダプタをインストールする前に、関連ドキュメント内の「システム要件と仕様」および「Oracle Fusion Middlewareのインストールのプランニング」に関するドキュメントを参照してください。
2.2 Oracle JCAアダプタの起動と停止
Oracle JCAアダプタは、JCA 1.5リソース・アダプタとしてデプロイされます。したがって、アダプタを起動または停止するには、すべてのリソース・アダプタでSPIインタフェースの一部としてstart
(BootstrapContext)
およびstop
メソッドを実装する必要があります。
Oracle JCAアダプタは、それを使用するSOAコンポジットによりJCAアウトバウンド相互作用が開始されると起動されます。また、インバウンド相互作用にSOAコンポジット自体がロードされるとき、またはアダプタによりイベントがJCAバインディング・コンポーネントにパブリッシュされるときにも、アダプタを起動できます。
アダプタを起動後に停止するには、Oracle Containers for Java EEを停止するか、または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.3 既存WSDLのインポートによるアダプタ・インタフェースの定義
アダプタ構成ウィザードのアダプタ・インタフェース・ページで、アダプタ・インタフェースを定義できます。
図2-1に示すように、次のいずれかの方法でアダプタ・インタフェースを定義できます。
-
「アダプタ構成ウィザード - アダプタ・インタフェース」ページの後に表示されるページで、指定した操作名とスキーマを使用して生成されるWSDLを使用します。
-
既存のWSDLをインポートします。
この項では、既存のWSDLをインポートしてアダプタ・インタフェースを定義する方法について説明します。この機能を使用すると、既存のWSDLを使用してアダプタ・サービスまたは参照を作成できます。既存のWSDLを選択するオプションは、次のアダプタについてのみサポートされています。
-
Oracleファイル・アダプタ
-
Oracle FTPアダプタ
-
Oracleソケット・アダプタ
-
Oracle AQアダプタ
-
Oracle JMSアダプタ
-
Oracle MQ Seriesアダプタ
-
Oracle JCA Adapter for MSMQ
-
UMS用のOracle JCAアダプタ
-
Oracle JCA Adapter for Oracle JD Edwards World
-
LDAP用のOracle JCAアダプタ
-
Coherence用のOracle JCAアダプタ
既存のWSDLをインポートしてアダプタ・インタフェースを定義するというオプションを選択した場合、以降のウィザード・ページの一部の機能が無効になります。たとえば、WSDLでは操作名とメッセージ・スキーマを定義するため、図2-2に示すように、以降の操作名フィールドとスキーマ要素フィールドには値が自動的に入力されて変更できません。ただし、既存のWSDLを使用するように選択しなければ、アダプタ・ウィザードの動作は変わりません。
2.3.1 Oracle MQ Seriesアダプタ、Oracle JMSアダプタ、Oracle AQアダプタ用のアダプタ構成ウィザード
Oracle MQ Seriesアダプタ、Oracle JMSアダプタおよびOracle AQアダプタの場合、アダプタ構成ウィザードの表示内容が他のアダプタとは少し異なります。ポート・タイプや操作などのコールバックを選択するための追加オプションがあります。
アダプタ構成ウィザードの以降のオプションは、選択したポート・タイプと操作に応じて有効または無効になります。
2.3.1.1 コールバックの使用例
たとえば、アダプタ構成ウィザードを使用してOracle MQ Seriesアダプタを定義する場合、コールバックを選択すると、「MQにメッセージを送信し、リプライ/レポートを取得」およびMQからメッセージを取得し、リプライ/レポートを非同期で送信オプションのみが有効になります。
コールバックを選択しなかった場合は、「MQにメッセージを蓄積」および「MQからメッセージを取得」オプションのみが有効になります。
同期リプライを含むWSDL操作を選択した場合は、MQからメッセージを取得し、リプライ/レポートを同期で送信オプションが有効になります。既存のWSDLを使用する場合、CICSまたはIMSスキーマを使用するオプションは無効になります。
ノート:
既存のWSDLをインポートする最も一般的な方法は、最初にOracle BPELプロセスまたはメディエータを作成し、それらのWSDLファイルをスキーマ(またはNXSD)から定義します。これが完了すると、アダプタ・サービスが作成され、BPELプロセスまたはメディエータ・コンポーネントに作成されたWSDLファイルが既存のWSDLファイルとしてインポートされます。
ただし、この機能はスキーマ要素を使用するメッセージにのみ機能することに注意する必要があります。単純型と複合型はサポートされていません。
2.4 Oracle JCAアダプタのメッセージ・ヘッダー・プロパティの構成
Oracle JCAアダプタにより、基礎となるバックエンド操作固有のプロパティがメッセージ・ヘッダー要素として公開され、これらの要素をビジネス・プロセス内で操作できるようになります。
Oracle JCAアダプタのプロパティは、Fusion Middleware Controlコンソールで追加したり、削除したり元に戻したりすることができます。ただし、プロパティのタイプによっては、プロパティの変更を適用するには、コンポジット・アプリケーションを再デプロイする必要があります。
ノート:
SOAコンポジット・エディタのプロパティ・インスペクタを使用して、JCAプロパティを変更できます。ただし、この方法で変更を実行する場合、変更したプロパティの検証は行われません。
表2-1に、構成できるメッセージ・ヘッダー・プロパティのタイプおよび再デプロイが必要かどうかを示します。
表2-1 Oracle JCAアダプタのプロパティ・タイプ
プロパティ・タイプ | 説明 | 制限事項 |
---|---|---|
アクティブ化仕様および相互作用仕様 |
SOAコンポジット・アプリケーション内で、アクティブ化仕様プロパティはサービスとして機能し、相互作用仕様プロパティは参照として機能します。 |
これらのプロパティは追加したり削除しないでください。値の変更のみが可能です。 これらのプロパティには、リサイクル対象のアダプタ・エンドポイントが必要です。これらのプロパティ・タイプは、他のプロパティにも依存しています。プロパティを追加する場合、他にも追加する必要がある従属プロパティを把握する方法はありません。 |
エンドポイント |
これらは、アクティブ化仕様プロパティまたは相互作用仕様プロパティを介して公開されない、チューニングに関連するプロパティ(タイムアウト、しきい値、最大間隔などを指定する)です。 |
エンドポイント・プロパティの追加、削除または変更には制限がありません。プロパティが追加、削除または変更されるとアダプタに通知が送信されますが、アダプタによる再デプロイメントは不要です。
|
参照構成ドメインでアダプタを構成している場合は、アダプタ構成ウィザードで、これらの重要なJCAエンドポイント・プロパティの一部を変更できます。初期プロパティ値は、レジリエンシに役立つように事前にロードされます。参照構成ドメインと構成方法の詳細は、参照構成ドメインでのコンポジットの開発に関する項を参照してください。
詳細は、Oracle JCAプロパティに関する項を参照してください。
2.5 Oracle JCAアダプタの物理デプロイ
Oracle JCAアダプタは、Oracle Containers for Java EEコンテナにJCA 1.5リソース・アダプタとしてデプロイされます。アダプタは、Javaアーカイブ(JAR)フォーマットを使用してリソース・アダプタ・アーカイブ(RAR
)ファイルとしてパッケージ化されます。
アダプタの物理デプロイでは、RAR
ファイルを使用して、基礎となるWebLogic Serverまたは中間層プラットフォームにアダプタをコネクタとして登録します。
ノート:
アダプタに変更を行った後、サーバーを再起動してデプロイメントを更新する必要があります。そうしなければ、行った変更は有効になりません。構成プラン・ファイルに構成の変更を保存した後、デプロイメントを更新して変更を反映する必要があります。
デプロイメントの更新アクションによって、新しいプラン・ファイルが各サーバー・インスタンスのステージング・ディレクトリに同期されます。その時点で、新しいデプロイメント・プランがソースでアクティブになります。
2.5.1 RARデプロイメント・ディスクリプタ・ファイルとweblogic-ra.xmlテンプレート・ファイル
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.6 Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成
設計時環境とデプロイ先サーバーの間の接続性を確立します。
接続性を確立するには、アプリケーション・サーバーの接続を作成します。次のステップに従ってアプリケーション・サーバー接続を作成します。
2.7 JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ
JDeveloperでは、SOAプロジェクトおよびアプリケーションをデプロイするために、プロファイルを使用する必要があります。
デプロイメント例
クラシック・モードのJDeveloperおよび参照構成モードのサーバー: 参照構成モードで実行しているサーバーに、クラシック設定のSOAコンポジットをデプロイしようとしているというメッセージが、JDeveloperに表示されます。Oracle JCAアダプタを参照構成モードに移行する必要があります。JDeveloperのOracle JCAアダプタの「アダプタの参照構成設定の有効化」オプションの使用の詳細は、アダプタ構成ウィザードのJCAエンドポイント・プロパティに関する項を参照してください。
参照構成モードのJDeveloperおよびクラシック・モードのサーバー: モードが一致しないというメッセージがJDeveloperに表示され、デプロイメントをキャンセルまたは続行できます。参照構成モードへのサーバーの移動の詳細は、『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』の参照構成ドメインの作成に関する項を参照してください。
ノート:
JDeveloperの統合Weblogic Serverでは、参照構成機能はサポートされません。参照構成オプションを使用して開発されたOracle JCAアダプタ・アプリケーションは、JDeveloperの統合WebLogic Serverにはデプロイできません。この項では、JDeveloperによるプロファイルの作成およびデプロイ方法について説明します。
2.7.1 SOAプロジェクトおよびアプリケーションに対するアプリケーション・プロファイルのデプロイ
この項では、SOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする方法を説明します。アプリケーションをデプロイするには、次のステップを実行する必要があります。
2.7.2 アダプタのデプロイメントの検証
JCAアダプタの設計時の構成ウィザード画面をキャプチャしたJCAアダプタ・メタデータは、サーバーにデプロイされるときに検証されます。
たとえば、/in/valid/directoryのPhysicalDirectory値を選択していて、SOAサーバーがこのメタデータを使用してアダプタのデプロイを試行する場合、(ファイル)アダプタはすべてのメタデータを参照し、1つまたは複数のメタデータが正しくない場合は例外をスローします。
これにより、JDeveloperでデプロイメント・アクションのロールバックが発生します。アダプタは、実行時に、すべての参照およびJNDI名付きのJCAコネクション・ファクトリが使用可能なこと(エラーなく参照できること)を検証します。データソースとコネクション・ファクトリが使用可能な場合は、デプロイメントが検証され、処理が続行されます。
Oracle SOAプラットフォームの11xxシリーズのリリースからプロジェクトを移行した場合、そのプロジェクトに対するデプロイメントの検証ロジックは施行されません。そのため、以前のコンポジット・アプリケーションは中断しません。
2.8 Jarファイルが関連付けられていないアダプタRARファイルの手動デプロイ
ここでは、jarファイルが関連付けられていないアダプタRARファイルを手動でデプロイする方法を学習します。
META-INF/ra.xml
とMETA-INF/weblogic-ra.xml
のみを含み、JNDIの作成に必要なjarファイル・アダプタが含まれていない任意のアダプタRARファイルをデプロイする場合は、デプロイ時に、Oracle WebLogic Serverがアダプタのjarファイルのロード後にこのRARファイルをデプロイできるよう、デプロイメント順序を高い値(500など)に変更する必要があります。
2.8.1 手動デプロイメントの例
たとえば、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ファイルを手動でデプロイします。
2.9 リモートOracle SOAサーバーで作業中のデプロイメント計画の処理
リモートのOracle SOAサーバーで作業している場合に、デプロイメント計画を扱う方法を学習します。
AdminserverがコンピュータAで実行中で、Oracle SOA ServerがコンピュータBで実行中の場合は、Oracle SOA Serverで行った変更内容をアクティブ化する前に、デプロイメント計画ファイルをコンピュータBにコピーする必要があります。
デプロイメント計画をOracle SOA Serverコンピュータにコピーせずに変更内容をアクティブ化しようとすると、NullPointerException
がスローされます。
2.10 異なる環境からのリポジトリの移行
ここでは、開発、テストおよび本番の3つの環境すべてでレポジトリの移行を行う方法を学習します。
アダプタ構成ウィザードによって生成されたすべての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エントリがあることを確認します。
2.11 メッセージの順序付け
ここでは、出力メッセージと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つのスレッドのみを使用するよう構成/調整します。
2.12 メッセージの損失がないことをOracle JCAアダプタで保証する方法
ここでは、メッセージが失われないようにする方法を学習します。
トランザクション・アダプタによって、エンタープライズ情報システム(EIS)は1フェーズ・コミットまたは2フェーズ・コミット(ローカル・トランザクションまたはグローバル/分散トランザクション)に参加できます。
非トランザクション・アダプタはトランザクション・セマンティクスを使用せずに、配信を確保する固有のスキームを実装します。
2.12.1 XAトランザクションのサポート
XAの目標は、同一のトランザクション内から複数のリソース(データベース、アプリケーション・サーバー、メッセージ・キュー、トランザクション・キャッシュ)にアクセスできるようにすることです。XAは2フェーズ・コミットを使用して、すべてのリソースがどのようなトランザクションでも一貫してコミットまたはロールバックするようにします。
XAの仕様には、リソース・マネージャがトランザクション・アクセスをサポートするために実行する必要のある手順が記述されています。この仕様を順守するリソース・マネージャはXA準拠であると呼ばれます。
XAトランザクションは、複数のリソースを操作する場合に使用するシナリオの一部です。たとえば、2つ以上のデータベース、データベースとJMS接続、またはこれらのすべてとアダプタ、これらがすべて単一のトランザクション内にある場合などです。
トランザクション・アダプタにより、XAトランザクション・サポートが有効になります。これは、固有のデータ処理とともに、それぞれの変更の結果が明確に定義されるようにして、成功または失敗の結果、データが破損する可能性を防止します。他の変更とは独立して実行され、完了すると、基礎となるデータは他のトランザクションが発生するまで同一の状態に置かれます。
XAは2フェーズ・コミット・プロトコルで、1フェーズ・コミット/エミュレート・プロトコルよりも堅牢です。1フェーズ・プロトコルやエミュレート・プロトコルでは、メッセージが消失したりロールバック/コミットの不整合が発生する可能性があります。
2.12.2 ローカル・トランザクションとグローバル(XA)トランザクション
XAトランザクションはアプリケーション・サーバーのトランザクション・マネージャによって開始されるトランザクションです。すべてのXAリソースは任意のアクティブなグローバル・トランザクションに参加する必要があり、トランザクション・マネージャのシグナルによってのみコミットまたはロールバックされます。シグナルの受信後にコミットが失敗した場合は、最終的にコミットが必ず行われるようなリカバリ・メカニズムも存在している必要があります。
未参加のローカル・リソースはアクティブなグローバル・トランザクションに関係なくローカル・トランザクションを開始または終了できます。コミットは即座に実行される可能性があり、これはトランザクション・マネージャからのシグナルへの応答ではありません。コミットに失敗するとトランザクションはロールバックされ、例外がスローされます。コミットを同期する他のリソースがないため、このトランザクションの特別なリカバリは不要です。
2.12.2.1 ローカル・トランザクションのアダプタ・サポート
アダプタではra.xml
デプロイメント・ディスクリプタ・ファイルのtransaction-support要素を指定することによって、トランザクション・サポートのタイプが定義されます。
2.12.2.2 グローバル・トランザクションのアダプタ・サポート
アダプタは基礎となるアプリケーション・サーバー・トランザクション・マネージャを利用するJCA 1.5 XA規定でグローバル・トランザクションをサポートします。
基礎となるアプリケーション・トランザクション・マネージャを利用するアダプタのタイプには、Oracle Adapter for Oracle Applications、データベース、アドバンスト・キューイング、JMSおよびMQSeriesアダプタなどがあります。
基礎となるトランザクション・マネージャを利用しない非トランザクション・アダプタには、Oracleファイル・アダプタとOracle FTPアダプタがあります。
2.12.2.2.1 グローバル・トランザクションの再試行およびロールバックとフォルト・ポリシー
グローバル・トランザクションの参加者はだれでもグローバル・トランザクションにロールバックのマークを付けることができます。グローバル・トランザクションにロールバックのマークが付けられると、他の参加者がロールバックを取り消すことはできなくなります。
フォルト・タイプは、エラーが再試行可能かどうかを示します。再試行可能な場合は、JCA再試行プロパティによって再試行が管理されます。エラー処理の項を参照してください。エラーが再試行不可能とみなされた場合、このようなエラーの処理はフォルト・ポリシーによって管理されます - その場合、フォルト・ポリシーが実行されます。これは、インバウンド・アダプタとアウトバウンド・アダプタでも同じです。
フォルト・ポリシーによって実行される操作はローカル・トランザクション内に留まり、グローバル・トランザクションには含まれません。
特に、固有のトランザクションで実行するフォルト・ポリシーは、特定の参照の実行を開始する前に既存のすべてのJTAトランザクションをコミットします(たとえば、Oracle BPEL PMでのinvokeアクティビティなど)。既存のJTAトランザクションが一時停止されてからコミットされることはありません。
Oracleファイル・アダプタやOracle FTPアダプタなどの非トランザクション・アダプタをトランザクション・アダプタとともに使用する際は、再試行によって非トランザクション・データに影響する場合があるため、重複するメッセージの作成などに注意してください。たとえば、メッセージの重複が発生しないようにビジネス・プロセスをモデル化するなどして、注意を払う必要があります。
デキューおよびエンキュー・レスポンスがキューにリプライするインバウンド同期リクエスト/レスポンス・シナリオは、手動リカバリの候補ではありません。そのため、再試行の上限に達した場合、失敗としてマークされます。
2.12.3 トランザクションとアダプタの基本概念
再試行に関するトピックの追加情報は、「拒否されたメッセージの処理」およびそれ以降の項を参照してください。
-
ポーリング: すべてのOracle JCAアダプタとレガシー・アダプタは、プル、つまりポーリングをサポートしていますが、これは、イベントを受信する、つまりEISエンドポイントに使用可能なメッセージおよびデータを定期的に問い合せるためにバックエンド・アプリケーションに接続するモデルです。この例外は、異なるロジスティクスのセットを使用するOracle Socketアダプタですが、その場合、ソケット・アダプタは、他のアダプタがクライアント・ソケットを使用して接続するのと同じように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つのスレッドで実行されるトランザクションです。これはシリアライズされていません。
2.12.3.1 非同期トランザクション・フロー
次の項では、非同期トランザクションと同期トランザクションについて、JMS、DB、BPELテクノロジの標準的なアダプタの組合せを通じて説明します。たとえば、メディエータなどの他のアダプタや他の手段が使用されている場合もあります。
非同期サービス・エントリ・ポイントの場合、トランザクション・アダプタはコンポジットにインバウンド・メッセージを送信する前に、グローバルJTAトランザクションを開始します。
2.12.3.1.1 JMS、BPEL、DBアダプタとデータベースの使用例
次に示す例では、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の一部でエラーが発生した場合は、ロールバックが発生します。
2.12.3.2 同期トランザクション・フロー
同期プロセスでは、アダプタによって開始されるグローバル・トランザクションは次の両方にわたります。
-
メッセージの配信
-
コンポジットの実行
非同期トランザクション・フローと同様、デフォルトの再試行回数は無制限で、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アダプタに戻って試行されます。
2.12.4 インバウンド・トランザクション
インバウンド・アダプタは独立したワーク・スレッドで実行します。アダプタは接続のリカバリを行い、固有の再試行プロパティを使用します(たとえば、adapter.jms.retry.interval
など)。
トランザクション・アダプタはコンポジットにインバウンド・メッセージを送信する前に、グローバルJTAトランザクションを開始します。
トランザクション・アダプタの場合、再試行はローカル再試行(BPELリモート・フォルトなど)、グローバル再試行、または再試行なし(バインディング・フォルトと同様)のいずれかになります。グローバル再試行はトランザクションが開始した場所に返されます。デフォルトの再試行回数は無制限ですが、jca.retry.count
で指定された回数のみ再試行可能です。
アダプタに制御が戻ると、アダプタはJTAトランザクションをコミットし、次の一連の操作をアトミック作業ユニットとして実行します。
-
インバウンド・アダプタ・エンドポイント(表やキューなど)からのメッセージの削除をコミットします。
-
コンポジット・インスタンスの実行をコミットします。
この一連のコミット操作、つまりメッセージの削除とコンポジット・インスタンスの実行においていずれかの操作が失敗すると、操作は両方ともロールバックされます。
2.12.5 アウトバウンド・トランザクション
Oracle JCAアダプタの起動を含むすべてのアウトバウンド・トランザクション・コンポジット・アクティビティは、グローバル・トランザクションの一部です。エラーが発生すると、デフォルトの動作では、すべてのアクティビティはコミットされるかまたはロールバックされるかのいずれかになります。
たとえば、BPELプロセスは異なるInvokeアクティビティを通じて、(異なるデータベースの)複数の表にデータを挿入できます。
BPELインスタンスが終わりに近づくと、JTAトランザクションがコミットされます。
データベースの挿入操作はこの時点でのみコミットされます。
ただし、BPELインスタンスの実行中にエラーが発生した場合、すべてのアクティビティ(およびそれに伴うデータベース操作)は最後のBPELデハイドレーション・ポイント(最後にBPELインスタンスがデータベースに格納された時点)までロールバックされます。
アウトバウンド・トランザクションが再試行可能かどうかは、特定の相互作用の性質および範囲によって異なります。具体的には、次のようになります。
-
たとえばデータベースの整合性など、アウトバウンド・トランザクションのターゲット側で整合性を伴う相互作用は再試行されません。
-
単一レコードでの些細なデータベースの問題など、ローカル再試行が可能な条件が存在する場合は、ローカル再試行が行われます。
-
たとえばマスター詳細レコードと子レコードの両方を更新するような問題など、エラーが解消する余地のあるより複雑なデータベース整合性のシナリオにおける再試行では、トランザクションは最初のBPEL Receiveまでロールバックされ、再び開始される場合があります(BPELを使用するシナリオの場合)。再試行はここでも
jca.retry
に従いますが、他のいずれかのBPELエラー処理の再試行パラメータに従う場合もあります。 -
アダプタからのアウトバウンドの接続上の問題は、一般に、常に再試行可能です。アウトバウンド・トランザクションでは、アダプタは接続が確立できない場合に再試行可能例外をスローし、これにより適切なJCAバインディングが再試行します(
jca.retry.count
を経由)。
アウトバウンド相互作用に関連する接続の再試行可能なエラーの例には、データベース・リスナーが起動されていないために発生する接続エラーなどがあります。
2.13 コンポジットの可用性とインバウンド・アダプタ
2.14 アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート
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>
2.14.1 同一のアダプタ・エンドポイントの複数のアクティブ化
Oracle WebLogicクラスタでは、同一(JMSなど)のアダプタ(インバウンド)のエンドポイント(特定のコンポジット・サービス向け)の複数のアクティブ化が、クラスタ内でアクティブなアダプタ・フレームワークのすべてのインスタンスによって、暗黙的かつ自動的に検出されます。
ただし、メッセージの読取りまたはパブリッシュを開始できるアクティブ化は1つのみです。
JCAバインディング・コンポーネントのインスタンスによって、プライマリのアクティブ化の役割を引き受ける1つのアクティブ化がアクティブ化の中からランダムに選択されます。
2.14.2 ホットスタンバイ状態
Oracle WebLogicクラスタ内の他のアクティブ化(インスタンスとも呼ばれる)は、JCAリソース・アダプタでEndpointActivation
を起動せずにホットスタンバイ状態で開始されます。これらのアクティブ化にプライマリのアクティブ化の役割を再度割り当てることができます。
プライマリのアクティブ化がある時点で応答しなくなったり、手動で非アクティブ化されたり、クラッシュまたは終了した場合、Oracle WebLogicクラスタの残りのJCAバインディング・コンポーネント・メンバーのいずれかが即座にこの非アクティブ化を検出し、スタンバイ状態のアクティブ化エージェントの1つにプライマリのアクティブ化の役割を再度割り当てます。
詳細は、「コンポジットの可用性とインバウンド・アダプタ」を参照してください。
2.15 アダプタ内での相関サポート
ネイティブ相関を使用し、コールバック・インタフェース(参照用)を定義するか、中間プロセス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相関が確実に発生します。
2.15.1 起動と一致しない受信メッセージのCorrelationID: ログ・エラー・メッセージ
ただし、受信メッセージの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
2.15.1.1 一致しないネイティブ相関IDの拒否
次のサンプル・コードに示すように、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
に設定されます。
詳細は、次を参照してください。
2.16 ペイロード・サイズしきい値の設定
システム・リソースは有限であり、処理にはしきい値制限があります。システム・リソースに依存するOracle SOA Suiteにも一定のサイズ制限がありますが、大部分は基礎となるリソースに起因するもので、これを超える受信リクエストの処理は実行できません。
たとえば、Oracle JCAアダプタは大きなペイロードを処理できますが、Oracle BPEL PMは大きなペイロードを処理する際に多くのメモリーを消費し、この結果OutOfMemory
条件が発生し、システム全体が影響を受ける場合があります。
OutOfMemory
などのエラーを回避するには、Oracle JCAアダプタのペイロードしきい値を設定する必要があります。ペイロードしきい値を設定すると、Oracle JCAアダプタがしきい値制限よりも小さいペイロードを処理し、その他を拒否することを保証できます。この項では、ペイロードの相対サイズに関する考慮事項について説明します。
2.16.1 ペイロードのネイティブ・サイズ
ペイロードのネイティブ・サイズを使用できる場合、関連するアダプタはペイロードのネイティブ・サイズを使用して、しきい値制限を超えないようにペイロードのサイズを制限します。
たとえば、Oracleファイル・アダプタではポーリングされたファイルのネイティブ・サイズを使用できます。サイズがペイロード・サイズのしきい値を超える場合、ファイルは拒否されます。
ペイロードのネイティブ・サイズを使用できない場合、たとえばOracleソケット・アダプタでよくあるケースですが、アダプタはペイロードのネイティブ・サイズを内部で計算する必要があります。
非XMLの変換またはシリアライズXMLの解析にネイティブ変換ライブラリを使用して、ネイティブ・サイズを内部で特定できます。
Oracleデータベース・アダプタは変換フレームワークに依存していませんが、ネイティブ・メッセージのサイズを計算するための特別な処理メカニズムが組み込まれています。
注意:
エラー・リカバリでのデバッチ処理の場合、ペイロード・サイズしきい値を慎重に使用する必要があります。ペイロード・サイズの違反により、誤りのあるレコードの場合、ストリームのスキップ中に不当な拒否が発生することがあります。
2.16.1.1 ペイロードしきい値の設定
ペイロードしきい値は、Oracle JCAアダプタによって公開されるノブを使用して設定できます。次のサンプルに示すように、ノブはアダプタ・サービスのバインディング・プロパティとしてcomposite.xml
ファイルで設定できます(1000の値はバイト単位です)。
<binding.jca config="getMsg_mq.jca"> <property name="payloadSizeThreshold" type="xs:string" many="false"override="may">1000</property> </binding.jca>
2.16.1.2 ペイロード・サイズ強制の制限
ペイロードのネイティブ・サイズを使用できず、かつ、特定のアダプタでネイティブ変換ライブラリが使用されない場合、ペイロード・サイズしきい値制限を強制できません。たとえば、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 |
はい |
はい |
はい |
いいえ |
はい |
不透明 |
はい |
はい |
はい |
いいえ |
該当なし |
DTD |
いいえ |
いいえ |
いいえ |
いいえ |
該当なし |
2.16.1.2.1 グローバル・ペイロード・サイズの有限値への変更
また、ペイロード・サイズを制限するグローバル・プロパティを設定して、payloadSizeThreshold
のデフォルト値を(無限から)有限数に変更できます。この場合、payloadSizeThreshold
のデフォルト値を有限数に設定すると、特定のインバウンド・アダプタのエンドポイントのpayloadSizeThreshold
プロパティ値を明示的に構成しない場合にも、グローバル・デフォルトが有効になります。グローバル・デフォルトをcomposite.xml
の値とともに指定した場合、composite.xml
で指定した値によってグローバル値がオーバーライドされます。
Fusion Middleware ControlのMBeanブラウザ(アダプタMbean)を使用して、このグローバル・プロパティを変更できます。この変更は、すべての現在および将来のエンドポイントに対して即座に有効になります。
2.17 大きなペイロードのストリーミング
Oracle JCAアダプタは、インバウンド処理とアウトバウンド処理の両方で大きなペイロードの処理をサポートしています。
次に示すアダプタは、ストリーミング機能を明示的にサポートしています。
-
Oracleファイル・アダプタ
詳細は、「スケーラブルなDOM」を参照してください。
-
Oracle AQアダプタ
詳細は、「ストリーム・ペイロードのサポート」を参照してください。
-
Oracle JMSアダプタ
詳細は、「大きなペイロードのストリーミング」を参照してください。
-
Oracleデータベース・アダプタ
詳細は、「大きなペイロードのストリーミング」を参照してください。
他のアダプタには、両方の明示的なサポートはありません。
2.18 バッチ処理とデバッチ処理のサポート
Oracle JCA Adapter for FileとOracle JCA Adapter for FTPは、単一の大型ファイルを複数のバッチにデバッチ処理するためのReader
で構成されています。設計時構成中にバッチ・サイズを指定する必要があります。さらに、アダプタには一連のメッセージを単一ファイルにバッチ処理するためのライターも組み込まれています。
次のアダプタでは、バッチ機能とデバッチ機能がサポートされています。
-
ファイル用のOracle JCAアダプタ
-
FTP用のOracle JCAアダプタ
-
Oracle JCA Adapter for Databases
詳細は、「ファイルのデバッチ処理」を参照してください。
Oracle JCA Adapter for Databasesは、一連の表をポーリングしてイベントを検出するためのパブリッシュ・コンポーネントで構成されています。このコンポーネントでは、BPELプロセスの1度に1つのレコードまたは1度に複数のレコードに対してイベントを発生させることができます。詳細は、「ポーリング戦略」を参照してください。
2.19 アダプタ・コネクション・ファクトリの追加
アダプタの論理デプロイメントでは、weblogic-ra.xml
デプロイメント・ディスクリプタ・ファイル内にConnectionFactory
オブジェクトを作成します。
weblogic-ra.xml
ファイルには、アダプタのランタイム接続パラメータが含まれています。接続情報を追加してJNDI名を割り当てるには、Oracle WebLogic Server管理コンソールまたはWLSTスクリプトを使用して、リソース・アダプタの対応するweblogic-ra.xml
ファイルを編集する必要があります。
次のステップでは、Oracle WebLogic Server管理コンソールでDatabaseコネクション・ファクトリを設定する方法について説明します。
2.19.2 接続プールの作成
接続プールを作成するには:
-
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
プロパティの値が「接続ファクトリ・インタフェース」タブに表示されます。
ノート:
-
接続プールに未使用または無効な接続が蓄積され、プールが最大容量に達した場合、接続プールの「縮小間隔」を小さくし、「最大容量」を大きくすることで修正できます。これらのプロパティを変更するには、DbAdapter、「構成」、「アウトバウンド接続プール」、javax.resource.cci.ConnectionFactory、接続プールのJNDI名の順に移動します。「最大容量」に大きい値を入力し、「縮小の有効化」をtrueに設定して、「縮小頻度」に小さい値を入力します。
-
既存の接続プールのプロパティを編集した場合は、サーバーを再起動する必要があります。ただし、アウトバウンド接続プールについて新規の値を追加する場合、管理対象サーバーや管理サーバーを再起動する必要はありません。
2.20 アダプタ・コネクション・ファクトリの追加または更新
新規アダプタ・コネクション・ファクトリを追加するか、既存のアダプタ・コネクション・ファクトリを更新できます。
アダプタ・コネクション・ファクトリを追加または更新する場合は、次の手順のいずれかを実行して、コンポジットで新規アダプタ・コネクション・ファクトリのプロパティが使用されていることを確認する必要があります。
2.20.2 構成プランの使用
-
-
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管理コンソール - デプロイメントのサマリー」ページが表示されます。
-
新しいコネクション・ファクトリを追加したアダプタを選択します。
-
「更新」をクリックします。
「アプリケーション更新アシスタント」ページが表示されます。
-
「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します」オプションを選択します。
-
「次へ」をクリックして、「完了」をクリックします。
選択したデプロイメントが更新されたことを示す「デプロイメントのサマリー」ページが表示されます。この手順を使用して、たとえば、再起動の必要なしにアダプタのエンドポイントを変更できます。
2.20.3 WebLogic Serverコンソールを使用した新規接続の作成
WebLogicコンソールを使用すると、JMSで使用するコネクション・ファクトリを作成できます。「Oracle WebLogic Server管理コンソールを使用した新規接続の作成」を参照してください
2.21 Oracle JCAアダプタで使用するデータソースの推奨設定
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
2.22 エラー処理
Oracle JCAアダプタには、エラー処理機能があります。これらの拒否ハンドラは、同期プロセスでのみ適用可能です。非同期プロセスや一方向プロセスには適用されません。
2.22.1 拒否されたメッセージの処理
サービス・インフラストラクチャにポストされる前にエラーになったメッセージは、拒否されたメッセージと呼ばれます。たとえば、Oracleファイル・アダプタがCSVフォーマットのデータを含んだファイルを選択し、XMLフォーマットに(NXSDを使用して)変換しようとします。その場合、変換中になんらかのエラーがあると、このメッセージは拒否され、ターゲット・コンポジットにはポストされません。
拒否されたメッセージを生成するのは、主としてアダプタとバインディング・コンポーネントです。
2.22.1.1 下流で発生したエラーまたはフォルトの処理方法
同期フローの下流で発生したエラーまたは障害は、インバウンド・アダプタによって次のように処理されます。
-
例外が再試行不可能な場合は、即座に拒否されます。
-
例外が再試行可能な場合は、無制限に再試行されます。
-
再試行は
jca.retry.count
の値(構成されている場合)と同じ回数だけ行われ、再試行回数の上限に達した場合は拒否されます。
バインディング・レベルでエラーになったメッセージはアダプタによって拒否されます。つまり、サービス・インフラストラクチャ・レイヤーに入る前にエラーになります。
拒否されたメッセージは、すべてペイロードとともにデータベースに格納されます。拒否メッセージは後から問い合せることができます。
フォルトはバインディングまたはリモートとして分類することもできます。通常、リモート・フォルトはデータベースの接続停止などの一時的な障害で再試行可能であるのに対し、バインディング・フォルトは非一時的な障害で再試行不可能としてマークされます。状況に応じて、これらの非一時的な障害も修正できます。たとえば、MQ Seriesアダプタのターゲット・キューがデータベースの完全または一意の制約違反になるようなフォルトは修正可能です。ただし、変換やトランスフォーメーションによる検証の失敗などの特定の非一時的な障害は、コンポジットを再デプロイせずに修正することはできません。バインディング・フォルトとリモート・フォルトの両方が原因で拒否されたメッセージは、リカバリ可能としてマークされます(手動リカバリの場合)。リカバリの成功はシナリオに依存します。手動リカバリが失敗する場合は、失敗したインスタンスを調査してアクションを開始する必要があります。
この項には次のトピックが含まれます:
詳細は、「アダプタ内での相関サポート」を参照してください。
2.22.1.2 拒否ハンドラの構成
10.xリリースでは、拒否ハンドラはOracle BPELプロセスのデプロイメント・ディスクリプタ(bpel.xml
)内で定義されていました。
ただし、11gリリースでは、フォルト・ポリシーを使用して拒否ハンドラを定義する必要があります。
インバウンド拒否ハンドラの場合、指定できるアクション・ハンドラは1つのみです。
2.22.1.2.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)と同じフォルト・ポリシーで、メディエータ・コンポーネントで拒否されたメッセージを構成することもできます。
2.22.1.3 拒否されたメッセージのチェック
拒否メッセージはrejected_message
表に格納されます。
次のいずれかのステップを使用して、拒否されたメッセージをチェックできます。メッセージを取得し、固有の実装に応じて追加処理を実行できます。
2.22.1.3.1 データベースからのチェック
データベースからのチェックを行うには、データベースにsoainfraスキーマとして接続し、次のSQLコマンドを実行する必要があります。
select * from rejected_message
2.22.1.3.2 Fusion Middleware Controlコンソールからのチェック
「ダッシュボード」タブの「最新のフォルトと拒否メッセージ」セクションまたは「フォルト・メッセージと拒否メッセージ」タブで、拒否されたメッセージを表示できます。
Fusion Middleware Controlコンソールを拒否されたメッセージのチェックに使用する方法の詳細は、次を参照してください。
-
『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のインバウンド・アダプタに対する最新のフォルトと拒否メッセージの監視に関する項。
-
『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のインバウンド・アダプタに対するフォルトと拒否メッセージの監視に関する項。
2.22.1.3.3 メッセージ・エラーの処理: サンプル・シナリオ
この項では、メッセージ・エラーの処理方法についてサンプル・シナリオを使用して説明します。
図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エンジンは新規トランザクションを作成せず、コール元のトランザクションを使用して同期リクエストを効果的に処理します。したがって、いずれかの時点でトランザクションがロールバックすると、そのトランザクションでの実行内容は何もコミットされません。
2.22.2 インバウンド相互作用のエラー処理
拒否メッセージ・ハンドラを指定することにより、インバウンド・アダプタでのエラー処理方法を決定できます。
2.22.2.1 メッセージ・エラーの拒否ハンドラ
拒否ハンドラを作成して、メッセージ・エラーを処理できます。メッセージ・エラーには変換時のエラー、相関IDの不一致、メッセージ受信後のXML解析エラーなどがあります。
メッセージ・エラーで使用可能な拒否ハンドラ
再試行可能性の点からエラー処理を検討する前に、使用可能なエラー・ハンドラを理解することが重要です。
次に示すのは、フォルト・ポリシーで構成できるシステム定義のエラー・ハンドラです。
2.22.2.1.1 Webサービス・ハンドラ
拒否されたメッセージは、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>
2.22.2.1.2 カスタムJavaハンドラ
エラー処理の別のオプションでは、エラーを転送する定義済の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.22.2.1.3 JMSキュー
拒否メッセージは、適切なコンテキストとペイロードとともに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>
2.22.2.1.4 ファイル
拒否されたメッセージをファイルに格納することによって、メッセージのエラー・ハンドラを作成します。次の例に示すように、適切なコンテキストとともにペイロードを格納できます。ペイロード・ファイルは、構成した場所に作成されます。
<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コンソールを介してペイロード表示機能を使用できます。デフォルトのエラー・ハンドラへのペイロードの指定に加えて、メッセージ/ペイロードは構成された各エラー・ハンドラに完全に指定されます。
2.22.2.2 インバウンドの再試行可能なエラー
インバウンドの再試行可能なエラーは通常、一時的な接続エラーです。インバウンド・アダプタによって再試行が行われるのは、アウトバウンド・バインディングによってスローされた同期プロセスの再試行可能なエラーのみです(回数はデフォルトでは無制限であり、jca.retry.count
プロパティの設定によって制限されます)。JTAトランザクションはいずれも再試行の前にロールバックされます。
アウトバウンド・アダプタによってスローされる再試行可能なエラーの例には、接続エラーだけでなく、一時的な権限エラーまたはリソース制限エラー、あるいはその両方も含まれます。
「データがすでに存在します」
などのエラー(主キー・エラーなど)は再試行できません。また、メッセージ相関IDエラーは再試行できません。
設定された再試行回数の上限に達した場合、拒否メカニズムによってエラーが処理されます。
2.22.2.2.1 再試行可能なエラーを処理するインバウンド・アダプタの構成
インバウンド・アダプタを構成して、インバウンドの再試行可能なエラーを処理できます。次のプロパティはインバウンド相互作用の再試行可能な例外のためにサポートされており、composite.xml
ファイル内に指定できます。
デフォルトでは、インバウンド・エラーは無制限に再試行されますが、アダプタの再試行はコンポジット(ローカル)アプリケーションのレベル、またはグローバル・レベルで行われます。
コンポジットでプロパティを構成した後、サービス・レベルではプロパティの構成に意味があります。(たとえば、拒否前に再試行回数を構成すると、間隔プロパティの値はデフォルト値になります)。
composite.xmlファイルでは、次のプロパティを指定できます。
-
jca.retry.count
拒否までの再試行回数の最大値を指定します。この値の指定は、他のプロパティの値を指定するための前提条件です。
-
jca.retry.interval
再試行間の時間間隔(秒単位)を指定します。
-
jca.retry.backoff
再試行間隔の増加係数(正の整数)を指定します。
-
jca.retry.maxInterval
再試行間隔の最大値、つまりバックオフ > 1の場合の上限を指定します。
2.22.2.2.2 composite.xmlファイルでのインバウンド再試行プロパティの指定
コンポジット・アプリケーションの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
の値が設定されていない場合、再試行は無制限に実行されます。これは再試行可能なエラーのデフォルトです。
ノート:
エラーに関してインバウンド・アダプタが無限に再試行すると、再試行のたびに別のコンポジット・インスタンスが作成されるため、複数のコンポジット・インスタンスが作成されることになります。
2.22.2.2.3 インバウンド・アダプタ・エンドポイントのjca.retry. countのデフォルト値の変更
再試行を制限するグローバル・プロパティを変更して、jca.retry.count
のデフォルト値を(無限から)有限数に変更できます。
この場合、jca.retry.count
のデフォルト値を有限数に設定すると、特定のインバウンド・アダプタのエンドポイントのjca.retry.count
プロパティ値を明示的に構成しない場合にも、グローバル・デフォルトが有効になります。
グローバル・デフォルトをcomposite.xmlの値とともに指定した場合、composite.xml
で指定した値によってグローバル値がオーバーライドされます。
Fusion Middleware ControlコンソールのMBeanブラウザ(アダプタMbean)を使用して、このグローバル・プロパティを変更できます。この変更は、すべての現在および将来のエンドポイントに対して即座に有効になります。
2.22.2.3 インバウンドの再試行不可能なエラー
再試行不可能なエラーは通常、変換またはメッセージ解析の結果生成されます。
インバウンド・アダプタはインバウンド・メッセージを拒否することによって、エンタープライズ情報システムからスローされた再試行不可能なエラーを処理します。エラーが再試行不可能な場合は、拒否ハンドラを使用して再試行不可能なエラーを処理する必要があります。
2.22.2.3.1 再試行不可能なエラーの例
エンタープライズ情報システムとの相互作用からスローされた再試行不可能なエラーの例には、次が含まれます。
-
主キーの違反
-
キューが存在しない
-
マスター・レコードが存在しない
-
ペイロードをシリアライズできない
再試行不可能なエラーは、単に再試行しても解決されないと予想されるため、再試行されません。たとえば、あるファイルからのメッセージがメディエータを介してインバウンド・ファイル・アダプタに送信される場合があります。メディエータには、データベース表にデータを挿入するアウトバウンド・データベース・アダプタへの順次ルーティングがあります。DBアダプタでは挿入操作が実行中であるため、固有の制限エラーが発生する場合があります。この固有の制限エラーは、次のように処理されます。
-
アウトバウンド・データベース・アダプタによって再試行不可能なエラーと見なされます。
-
伝播によってインバウンド・アダプタに戻ります。
-
拒否ハンドラを使用して、インバウンド・アダプタによっても再試行不可能なエラーと見なされます。定義されているフォルト・ポリシーがある場合は、アダプタによって使用されます。
メディエータで変換エラーが発生する可能性があります。この種のエラーは再試行不可能です。WSDLのシグネチャに応じて、エラーは処理を行うインバウンド・アダプタに戻されます。
2.22.3 アウトバウンド・アダプタ相互作用のエラー処理
アウトバウンド相互作用エラーは、アダプタからのアウトバウンド相互作用を持つメッセージで発生します。
この項では、これらのアウトバウンド相互作用エラーの再試行可能性と不可能性について説明し、関連する設定可能なプロパティの概要について示します。
2.22.3.1 アウトバウンド・アダプタ・エラー処理の再試行可能なエラー
アウトバウンドの再試行可能なエラーは、composite.xml
ファイルのjca.retry.count
の値に基づいて再試行できます。
2.22.3.1.1 composite.xmlファイルでのアウトバウンド・エラー処理の再試行可能プロパティの設定
アウトバウンド・エラー処理の再試行可能な例外については、jca.retry.count
の値を再試行の実行回数に設定する必要があります。
たとえば、jca.retry.count
の値を10に設定すると、再試行は10回行われます。
ただし、jca.retry.count
の値が設定されていない場合は、コンポジットの一部にフォルト・ポリシーが含まれていれば、フォルト・ポリシーによって再試行が実行されます。
2.22.3.1.2 例: アウトバウンド相互作用に関する再試行可能な例外の値の設定方法
次のコード・スニペットは、アウトバウンド相互作用に関する再試行可能な例外について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>
2.22.3.2 アウトバウンド相互作用処理に関する再試行不可能なエラー
アウトバウンド相互作用に関する再試行不可能な例外は、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.22.3.2.1 フォルトの伝播
サービス・インフラストラクチャ起動例外のタイプの伝播は、アウトバウンド・アダプタによって報告されたエラーに対して、インバウンド・アダプタが応答できるようにするために重要です。
図2-13は、アダプタによるサービス・インフラストラクチャの同期呼び出しにおけるフォルトの伝播を示します。Oracle BPEL Process ManagerとOracle Mediatorはこの後、下流のアダプタを呼び出します。
この図で、サービス・インフラストラクチャ起動例外は、下流のアダプタからOracle BPEL Process ManagerとOracle Mediatorを介して呼出し元のアダプタに伝播しています。
2.22.3.2.2 フォルト・ポリシー・メカニズムが動作しない2つのケース
次の2つのケースでは、フォルト・ポリシー・メカニズムが動作しません。
-
XAモードのアウトバウンド・アダプタ
-
メディエータの順次ルーティングでのアウトバウンド・アダプタ
XAモードのアウトバウンド・アダプタ
フォルト・ポリシー・メカニズムは、XAモードのアウトバウンド・アダプタでは機能しません。
たとえば、XAモードで、フォルト・ポリシーをアウトバウンド・アダプタの失敗時に再試行させる必要がある場合、フォルト・ポリシーは再試行されず、この失敗の発生前に成功していたアウトバウンド・アダプタはメッセージをロールバックしません。
メディエータの順次でのアウトバウンド・アダプタ
フォルト・ポリシーは、メディエータの順次ルーティングで起動されたアウトバウンド・アダプタでも機能しません。これは、メディエータのフォルト・ポリシーはパラレル・ルーティング・ルールにのみ適用可能であるためです。
2.23 JCAアダプタとOracle Web Services Managerの統合による監査証跡内の機密データの保護
アウトバンド・アダプタにメッセージを送るBPELプロセスに対してインバウンド・アダプタがメッセージを送信するシナリオにおいて、JDeveloperとFusion Middleware Controlを介してOracle Web Services Manager (OWSM)を使用し、ペイロードにPII (個人の身元を特定する情報)ポリシーを適用できます。
この方法でOWSMを使用すると、暗号化および復号化されるようにアダプタ・ペイロードを構成できます。BPEL監査証跡を調査する個人には、ユーザーが暗号化するように指定したデータは表示されません。
暗号化するインバウンドからペイロード要素を選択します。対応するエンドポイントに対して、復号化する同じ要素を選択する必要もあります。
一般的に、Webサービスのセキュリティには、認証、許可(またはアクセス制御)、機密およびプライバシ保護、整合性、否認防止などのいくつかの側面があります。
アダプタでこれを使用することは、個人の身元を特定する機密情報(PII)の維持に関連します。
2.24 アプリケーションのテスト
Oracle Enterprise Manager Grid Controlから、デプロイされたSOAコンポジット・アプリケーションのインスタンスを実行およびテストできます。
このようなインスタンスの実行およびテストにより、次のことが可能になります。
-
コンポジット・アプリケーションの管理
-
コンポジットのインスタンスの起動
-
コンポジットのインスタンスの追跡
-
詳細なコンポーネント・インスタンスの監査証跡の表示
アプリケーションのテストの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAコンポジット・アプリケーションのテストの自動化を参照してください。
2.25 Oracle JCAアダプタのトレース・レベルの設定
アダプタのトレース・レベルを設定します。
次に示すタイプのアダプタについて、トレース・レベルを次に定義されているように設定します。
-
Oracle JCAアダプタとOracle Adapter for Oracle Applications: ロガー
oracle.soa.adapter
でログ・レベルをTRACE:32
のように設定します。 -
パッケージ・アプリケーション・アダプタ: アウトバウンド相互作用の場合は、
weblogic-ra.xml
ファイル内でパッケージ・アプリケーション・アダプタのLoglevel
プロパティを設定します。 -
レガシー・アダプタ: Oracle Studioを使用して、Oracle Connectとメインフレーム・サーバーのトレース・レベルを設定できます。
2.26 アダプタ・ログの表示
次に定義されているように、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
-
パッケージ・アプリケーション・アダプタ: このタイプのアダプタは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アダプタのトレース・レベルの設定」を参照してください。
2.27 アダプタの診断能力ダンプ
アダプタの診断能力ダンプに関する情報を取得します。
診断能力ダンプの詳細は、Oracle SOA SuiteおよびOracle Business Process Management Suiteを管理するFusion MiddlewareガイドのOracle SOA Suite診断能力ダンプの実行に関する項を参照してください。
2.28 カスタム・アダプタの作成
カスタムJCAアダプタ・ウィザードをJDeveloper IDEで汎用アダプタ・ウィザードとして構成して、相互作用/アクティブ化の仕様、プロパティおよびデフォルト値を構成ファイルから読み取って表示できます。ウィザードでは仕様の選択、デフォルトのプロパティ値のオーバーライド、新しいプロパティの追加を行うことができます。
カスタム・アダプタ・ウィザードには、次のようないくつかの目的があります。
-
カスタム・アダプタ・ウィザードはそのままで使用して、カスタム・ランタイプ・アダプタをサポートできます。カスタム・アダプタを使用する場合は、カスタム・アダプタ構成ファイル
customAdapter-config.xml
を指定(または拡張)します。 -
より具体的なアダプタを作成する場合は、カスタム・アダプタ・クラスを変更または拡張できます(たとえば、アダプタにあわせてテキストを変更できます)。
-
カスタム・アダプタ・ウィザードを使用して、JCAアダプタ・フレームワークを使用し、SCAEndpointインタフェースにフックすることで、新しいアダプタ・ウィザードを作成する方法についての簡単な例を確認できます。
SOA JDeveloper拡張をインストールすると、カスタム・アダプタのJavaソース・ファイルは
<JAVA_HOME>/jdeveloper/integration/adapters/samples/custom
に配置されます
2.28.1 カスタム・アダプタの構成
カスタム・アダプタは、デフォルトでは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>
2.28.1.1 カスタム・アダプタ画面のフロー
JDeveloper内で「公開されたサービス」または「外部参照」スイムレーンに「カスタムJCAアダプタ」アイコンをドラッグ・アンド・ドロップすると、アダプタ構成の「ようこそ」ページがIDEに表示されます。「次へ」を選択して、カスタム・アダプタ構成ウィザードのワークフローを開始できます。
次の画面には、他のアダプタの構成ウィザードと同じようにサービスのタイプと名前が表示されます。この画面により、構成するアダプタにおいて意味のあるサービスの名前を指定できます。
config.xml
ファイルに <connection-factory>
エントリが(カスタム・ランタイム・アダプタで必要なため)含まれている場合は、ウィザードの「接続情報」ページにデフォルトの「コネクション・ファクトリの位置」が表示されます。config.xml
に<connection-factory>
エントリが(カスタム・ランタイム・アダプタで不要なため)含まれていない場合、ウィザードのこのページは表示されません。
次の「アダプタ・インタフェース」画面には、他のアダプタの構成ウィザードと同じように情報が表示されます。(各アダプタの構成ウィザードの詳細は個々の適切な章を参照してください。)この画面には、後で作成する操作およびスキーマで新しいWSDLを定義する方法、またはWSDLの名前、ポート・タイプおよび操作を使用して既存のWSDLをインポートする方法が示されています。
次の画面では、相互作用のタイプ、つまりインバウンドまたはアウトバウンドを選択できます。アウトバウンド相互作用を選択すると、ウィザードには相互作用クラス名(または、この例のような変換済の表示名)のリストが表示され、その中から選択できます。これらは事前に、customAdapter-config.xml
ファイルで指定した名前です。
次の画面では、JCAプロパティの名前と値を指定できます。選択したクラス名に応じて、customAdapter-config.xml
ファイル内でそのクラス名に関連付けられているプロパティが表示されます。この画面では、デフォルト値の変更やプロパティの追加と削除を行うことができます。
次の画面は、カスタム・アダプタ・ウィザードの「メッセージ」画面です。この画面では、他のアダプタ構成ウィザードと同じように、スキーマを指定するか、またはスキーマが不透明であることを宣言することで、ファイルの読取り操作に関するメッセージを定義できます。
次のページは、カスタム・アダプタ構成ウィザードの「最後」画面です。作成したWSDLファイルの名前が表示されます。
2.28.2 アダプタに関するよくある質問
次に、アダプタに関するよくある質問をいくつか挙げます。
2.28.2.1 アプリケーションがタイムアウトになる理由
コンポジット・アプリケーションがタイムアウトになるのはなぜですか。コンポジット・アプリケーションがアダプタを使用して実行するのに十分な時間を指定しても、アプリケーションは依然としてタイムアウトになります。
この一因に、WebLogicのタイムアウト値があります。ビジネス・プロセスでアダプタを使用する場合は、WebLogic Server JTAのタイムアウト値を考慮する必要があります。
たとえば、Timeout Seconds
の値が30秒に設定されているとします。Oracle WebLogic JTA属性Timeout Seconds
の値をデフォルトの30よりも大きい値、ビジネス・プロセスのコンテキスト全体で意味を持つ値に増やす必要があります。WebLogic Serverコンソールを使用して、「WLSコンソール」→SOADomain→「構成」→「JTA」
に移動し、JTAトランザクションのタイムアウト値を変更できます。しかく
2.28.2.2 トランザクション・アダプタと非トランザクション・アダプタの違いはなんですか。
Oracle JMSアダプタなどのトランザクション・アダプタはJTAトランザクション内で実行されます。トランザクションでは1つ以上の操作がアトミック作業ユニットとして実行されます。
トランザクション内の1つの操作が失敗すると、すべての操作がロールバックされて、アプリケーションは元の状態に戻ります。ビジネス・プロセス・ロジックがステートフルまたはステートレスのどちらで定義されているかによって、特定のビジネス・プロセス内には1つ以上のトランザクションが含まれている場合があります。
非トランザクション・アダプタはトランザクション・セマンティクスを使用せずに、配信を確保する固有のスキームを実装します。
サービス・エンジンはインバウンド・ディレクトリからファイルを取得して処理し、処理したファイルを出力ディレクトリに送信します。インバウンド・アダプタは、変換(構成されている場合)およびビジネス・シナリオの一部として処理された変換済コンテンツのパブリッシュに制限されています。ビジネス・シナリオではアダプタを使用して、出力ディレクトリへの書込みを行うことができます。ただし、Oracleファイル・アダプタには非トランザクションの性質があるため、このプロセス中に障害によってフェイルオーバーが発生すると、ファイルが失われる可能性があります。その結果、インバウンド・アダプタが読み取ったファイルの一部が出力ディレクトリに送信されない場合があります。当然ながら、単一ノード・クラスタ(またはクラスタなし)の場合は、フェイルオーバーのオプションはありません。
ファイル・アダプタは、メッセージの損失を防ぐ高可用性が構成されていないかわりに、ファイル・システムへの整合性のあるアクセスとクラスタ・ノード間のロード・バランシングを確保するように構成されています。単一ノードのセットアップの場合、ファイル・アダプタの高可用性は不要で、メッセージの損失は発生しません。
このように、非トランザクションの性質があるため、Oracleファイル・アダプタに高可用性を構成して、フェイルオーバーの発生時にファイルが重複しないようにする必要があります。ファイル・アダプタでメッセージが失われることはなくなりますが、(障害時リカバリにおいて)一部が重複する可能性があります。
また、処理のシナリオにトランザクション・アダプタと非トランザクション・アダプタが含まれている場合は、非トランザクション部分の処理内でのファイルの整合性を確保する必要があります。
JMSアダプタはローカル・トランザクションでも機能できます。これは、(グローバル)JTAトランザクションの境界内から独立して開始され、コミットされるトランザクションです。つまり、ローカル・トランザクションはアダプタの現在の起動においてのみ存続します。
2.28.2.3 アプリケーションの拒否されたメッセージとはなんですか。その処理は可能ですか。
拒否されたメッセージは、デフォルトではデータベース(具体的にはrejected_message
表)内に格納されます。デフォルトの拒否されたメッセージ・ハンドラは、メッセージをファイル・システム上に格納し、拒否されたメッセージを明示的に処理するポリシーが定義されていない場合に関与します。このハンドラは、WLS_HOME
の事前に定義された場所にあるファイル・システム上にメッセージのペイロードおよびプロパティを格納します。現在、Oracle SOA Suiteには拒否されたメッセージを再発行する機能がないため、ユーザーが再発行を処理します。
2.29 高度なトピック: テクノロジ間での実行コンテキストIDの使用
SOA Suiteのデプロイメントでは、FTP、データベースおよびファイルとの統合などの様々なアクティビティやその他のアクティビティに対してテクノロジ・アダプタの使用を組み込むことができます。これらのアダプタとの統合は簡単な上に機能を強化しますが、操作の観点からいくつかの課題が生じる可能性もあります。
その課題の1つに、SOAコンポーネント・インスタンス間で論理ビジネス・トランザクションを関連付ける方法があります。通常、この関連付けは実行コンテキストID ()を使用して実行されますが、ビジネス・トランザクションの範囲がFTP、データベース、ファイルなどのテクノロジにまで及ぶと、ECIDの関連付けが失われる可能性があります。
ECIDの伝播の基本概念は、ECIDを格納できるメッセージのペイロードで場所を識別することにあります。
次に、メッセージのECIDの場所に関連する2つの「バインディング・プロパティ」が「公開されたサービス」(コンポジットの左側)または「外部参照」(コンポジットの右側)のいずれかに追加されます。
これにより、メッセージからECIDを抽出するか、メッセージにECIDを追加するための十分な情報がJCAフレームワークに提供されます。
メッセージからECIDを抽出すると、そのECIDが新しいコンポーネント・インスタンスに使用されます。
2.29.1 ECIDの配置
メッセージでECIDの格納場所を決定する際には、次の2つのオプションがあります。
-
メッセージ・スキーマに新しいオプションの要素を追加します。
-
スキーマで使用されていない既存の要素を利用します。
メッセージにオプションの要素を追加できることが最善のシナリオです。未使用の要素を見つけることはほとんどの場合に難しいことがわかっています。スキーマには、次のように表示されるECID値が保持されています。
11d1def534ea1be0:7ae4cac3:13b4455735c:-8000-00000000000002dc
2.29.2 コンポジット・サービス/参照の構成
メッセージ内で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は、データベース、ファイルまたはキューなどのリソース・テクノロジに安全に格納された場合のみ表示可能となります。
2.29.3 データベース/ファイル/JMSの単純な例
この項には、データベース、表、ファイルおよび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によって関連付けられたすべてのインスタンスが表示されます。