| Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド 11g リリース1（11.1.1） B55918-01 |
|
 戻る |
 次へ |
Oracle JCAアダプタはJ2EE Connector Architecture（J2CA）1.5標準に基づいており、Oracle WebLogic Serverにデプロイされます。 Oracle JCAアダプタのライフサイクルは、Oracle Fusion Middlewareに依存します。 これらのアダプタは、JCAバインディング・コンポーネントを介してOracle Fusion Middlewareと統合されます。
この章には、次の項が含まれます。
Oracle JCAアダプタとOracle Adapter for Oracle Applicationsは、Oracle Fusion Middlewareインストールの一部として使用可能です。 また、これらのアダプタでは、Oracle WebLogic Serverと中間層デプロイの両方がサポートされています。 パッケージ・アプリケーション・アダプタとレガシー・アダプタは、Oracle Applications Adapter CDに収録されています。これらのアダプタでは、中間層デプロイメントのみがサポートされています。
Oracle JCAアダプタは、JCA 1.5リソース・アダプタとしてデプロイされます。したがって、アダプタを起動または停止するには、すべてのリソース・アダプタでSPIインタフェースの一部としてstart (BootstrapContext)およびstopメソッドを実装する必要があります。 Oracle JCAアダプタは、それを使用するSOAコンポジットによりJCAアウトバウンド相互作用が開始されると起動されます。 また、インバウンド相互作用にSOAコンポジット自体がロードされるとき、またはアダプタによりイベントがOracle BPELプロセスにパブリッシュされるときにも、アダプタを起動できます。
アダプタの起動後に停止するには、Oracle WebLogic Serverを停止するか、またはOracle Fusion Middleware内でJ2EEアプリケーションを停止します。 このリリースでは、JCAバインディング・コンポーネントはJCA 1.5コンテナの一部として機能します。
Oracle JCAアダプタは、JCA 1.5リソース・アダプタとしてOracle WebLogic Serverコンテナにデプロイされます。アダプタは、Javaアーカイブ（JAR）フォーマットを使用してリソース・アダプタ・アーカイブ（RAR）ファイルとしてパッケージされます。 アダプタを物理的にデプロイするには、RARファイルを使用して、基礎となるOracle WebLogic Serverまたは中間層プラットフォームにアダプタをコネクタとして登録する必要があります。RARファイルには、リソース・アダプタに関するデプロイ固有の情報を含んだデプロイメント・ディスクリプタXMLファイルra.xmlが含まれています。 さらに、RARファイルには、Oracle WebLogic Serverとリソース・アダプタの間の規定に関する宣言情報も含まれています。
アダプタでは、.rarファイル内のra.xmlファイルのみでなく、weblogic-ra.xmlテンプレート・ファイルもパッケージされます。weblogic-ra.xmlファイルは、リソース・アダプタのConnectorFactoryオブジェクトの定義に使用されます（論理デプロイ）。weblogic-ra.xmlファイルは、リソース・アダプタ用のOracle WebLogic Server固有のデプロイメント・ディスクリプタです。このファイルにはリソース・アダプタをOracle WebLogic Serverにデプロイするためのデプロイ構成が含まれています。これには、リソース・アダプタのデプロイメント・ディスクリプタで指定されたバックエンド・アプリケーションの接続情報、使用するJava Naming and Directory Interface（JNDI）名、接続プーリング・パラメータ、リソースのプリンシパル・マッピング・メカニズムおよび構成などが含まれます。
コネクション・ファクトリの作成の詳細は、『Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server』を参照してください。
アダプタの論理デプロイとは、weblogic-ra.xmlデプロイメント・ディスクリプタ・ファイル内にConnectionFactoryオブジェクトを作成することです。 接続情報を追加してJNDI名に割り当てるには、Oracle WebLogic Server管理コンソールまたはWLSTスクリプトを使用して、リソース・アダプタの対応するweblogic-ra.xmlファイルを編集します。weblogic-ra.xmlファイルには、アダプタのランタイム接続パラメータが含まれています。
コネクション・ファクトリの作成の詳細は、『Oracle Fusion Middleware Installation Guide for 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データソース・オブジェクトがまとめられています。 このリストには、作成したデータソースが表示されます。
接続プールを作成する手順は、次のとおりです。
「ドメイン構造」の下で、「デプロイメント」をクリックします。
「デプロイメントの概要」ページが表示されます。
「デプロイメント」リストでデータベース・アダプタ名をクリックします。
「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」、「構成」および「アウトバウンド接続プール」を順にクリックします。
手順9で入力したxADataSourceプロパティの値が「接続ファクトリ・インタフェース」タブに表示されます。
|
注意: アウトバウンド接続プールについて新規の値を追加する場合、管理対象サーバーや管理サーバーを再起動する必要はありません。 ただし、既存の接続プールのプロパティを編集した場合は、サーバーを再起動する必要があります。 |
AdminserverがコンピュータAで実行中で、Oracle SOA ServerがコンピュータBで実行中の場合は、Oracle SOA Serverで行った変更内容をアクティブ化する前に、デプロイメント計画ファイルをコンピュータBにコピーする必要があります。 デプロイメント計画をOracle SOA Serverコンピュータにコピーせずに変更内容をアクティブ化しようとすると、NullPointerExceptionがスローされます。
トレース・レベルを次のように設定します。
Oracle JCAアダプタとOracle Adapter for Oracle Applications: ログ出力oracle.soa.adapterでログ・レベルをTRACE:32のように設定します。
アダプタのトレース・レベル設定の詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。
パッケージ・アプリケーション・アダプタ: アウトバウンド相互作用の場合は、weblogic-ra.xmlファイル内でパッケージ・アプリケーション・アダプタのLoglevelプロパティを設定します。
レガシー・アダプタ: Oracle Connectとメインフレーム・サーバーのトレース・レベルは、Oracle Studioを使用して設定できます。
Oracle Enterprise Managerコンソールを使用してトレース・レベルを設定する手順は、次のとおりです。
http://servername:portnumber/emにナビゲートします。
Oracle Enterprise Managerコンソールのホーム・ページが表示されます。
左ペインの「ナビゲータ」ツリーで「SOA」フォルダの「soa-infra」を右クリックします。
メニューが表示されます。
図2-1に示すように、「ログ」と「ログ構成」を順に選択します。
「ログ構成」ページが表示されます。
「ログ出力名」リストで「oracle.soa.adapter」を探し、「Oracle Diagnostic Loggingレベル(Javaレベル)」フィールドでログ・レベルを変更します。 この例では、図2-2に示すようにリストから「Trace:32 (FINEST)」を選択します。
|
注意: コンピュータの再起動と再起動の間もログ・レベルを確実に保持するには、「表示」リストから「永続ログ・レベル状態のログ出力」を選択します。 デフォルトでは、ログ・レベルはランタイム・ログ出力用に設定されます。 ランタイム・ログ出力は、コンポーネントの再起動と再起動の間に保持されません。 |
次のように、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 Connect管理ツールでもあるOracle Studioを使用して表示できます。Oracle Connectでは、デーモン・ログ、ワークスペース・ログおよびサーバー・プロセス・ログなど、各種のログが生成されます。
Oracle JCAアダプタにより、基礎となるバックエンド操作固有のプロパティがヘッダー要素として公開され、これらの要素をビジネス・プロセス内で操作できるようになります。
Oracle JCAアダプタの詳細は、付録A「Oracle JCAアダプタのプロパティ」を参照してください。
Oracle JCAアダプタのプロパティは、Oracle Enterprise Managerコンソールで追加または削除したり元に戻すことができます。 プロパティは、Oracle Enterprise Managerコンソールで追加、削除または更新する際のアダプタの動作に基づいて次のように分類されます。
これらのプロパティでは、アダプタのエンドポイントをリサイクルする必要があります。 このグループのプロパティの場合は、値をOracle Enterprise Managerコンソールで変更できます。 ただし、これらのプロパティを構成変更（追加または削除）するには、プロパティ依存性制約の検証のため、Oracle JDeveloperを使用する必要があります。
次の各項では、Oracle JCAアダプタのInteractionSpec/ActivationSpecおよびエンドポイント・プロパティを示します。
Oracle AQアダプタのプロパティの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のサービスと参照バインディング・コンポーネントの構成に関する項を参照してください。
Oracleデータベース・アダプタのプロパティの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のサービスと参照バインディング・コンポーネントの構成に関する項を参照してください。
Oracleファイル・アダプタのプロパティの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のサービスと参照バインディング・コンポーネントの構成に関する項を参照してください。
Oracle FTPアダプタのプロパティの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のサービスと参照バインディング・コンポーネントの構成に関する項を参照してください。
Oracle JMSアダプタのプロパティの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のサービスと参照バインディング・コンポーネントの構成に関する項を参照してください。
Oracle MQ Seriesアダプタのプロパティの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のサービスと参照バインディング・コンポーネントの構成に関する項を参照してください。
これらのプロパティを変更すると、エンドポイントの再起動なしにアダプタに通知されます。 このグループに属するプロパティは追加または削除できます。 エンドポイント・プロパティは、アダプタで公開できる補助チューニング・プロパティを表します。 補助チューニング・プロパティには、各種の時間間隔、しきい値および間隔などの値が含まれます。 これらのエンドポイント・プロパティは、interactionspecまたはactivationspecプロパティを介して公開されません。
エンドポイント・プロパティの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のサービスと参照バインディング・コンポーネントの構成に関する項を参照してください。
Oracle JCAアダプタのレコード実装はXMLRecordです。 すべてのアダプタの相互作用は、XMLRecordで開始されます。各JCAレコードは、oracle.tip.adapter.api.record.XMLRecordの実装であることが必要です。 XMLRecordの各インスタンスにはRecordElementが含まれています。 RecordElementペイロードにはデータが含まれています。 さらに、各RecordElementにはデータのBLOBが1つ含まれており、このBLOBはUTF-8でエンコードされたXML文字列の場合と、バイナリ8進バイト・ストリームの場合があります。
XMLRecordは次のメソッドで構成されています。
getPayloadRecordElement: ペイロードRecordElementを取得します。
setPayloadRecordElement: XMLRecordのペイロード・レコード要素を設定します。
Oracle JCAアダプタには、次の各項で説明するエラー処理機能が用意されています。
この項には、次の項目が含まれます。
サービス・インフラストラクチャにポストされる前にエラーになったメッセージは、拒否されたメッセージと呼ばれます。 たとえば、Oracleファイル・アダプタがCSVフォーマットのデータを含んだファイルを取得し、XMLフォーマットに（NXSDを使用して）変換しようとします。 その場合、変換中になんらかのエラーがあると、このメッセージは拒否され、ターゲット・コンポジットにはポストされません。 拒否されたメッセージを生成するのは、主としてアダプタとバインディング・コンポーネントです。
メッセージがサービス・インフラストラクチャ・レイヤーにポストされた後に発生するエラーやフォルトは拒否されません。 このように失敗したメッセージはサービス・インフラストラクチャ・コンポーネントにより処理され、拒否されたメッセージとはみなされません。
アダプタとその他のバインディング・コンポーネント（WSバインディング・コンポーネントなど）は、バインディング・レベルでエラーになったメッセージ、つまりサービス・インフラストラクチャ・レイヤーに入る前にエラーになったメッセージを拒否します。 拒否されたメッセージは、すべてペイロードとともにデータベースに格納されます。
この項には、次の項目が含まれます。
リリース10.xでは、拒否ハンドラはOracle BPELプロセスのデプロイメント・ディスクリプタ（bpel.xml）に定義されていました。 しかし、リリース11gでは、フォルト・ポリシーを使用して拒否ハンドラを定義する必要があります。
インバウンド拒否ハンドラの場合、指定できるアクション・ハンドラは1つのみです。
次の手順に示すように、fault-policies.xmlおよびfault-bindings.xmlという2つのファイルを作成し、Oracle JDeveloperのSOAプロジェクト・ディレクトリにコピーする必要があります。
拒否されたメッセージに関するフォルト・ポリシーをfault-policies.xmlファイル内で定義する必要があります。このファイルは、Oracle 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コンポジット・プロジェクトをデプロイします。
|
注意: 「拒否ハンドラの構成」の説明に従って拒否ハンドラを構成しなければ、デフォルトのファイル・ベース拒否ハンドラが開始され、拒否されたメッセージは<domain_home>/rejmsgs/<wls_server_name>/<composite_name>に移動されます。
また、Oracle BPEL Process Managerと同じフォルト・ポリシーで、メディエータ・コンポーネントで拒否されたメッセージを構成することもできます。 |
次の拒否メッセージ・ハンドラがあります。
使用可能なアクション・ハンドラ
次に示すのは、フォルト・ポリシーで構成できるシステム定義のエラー・ハンドラです。
Webサービス・ハンドラ
ターゲット・サービスでは事前定義済のWSDLインタフェースを実装する必要があります。
Webサービスの呼出しにはSOAPバインディングが使用されます。
次の例に示すように、ネイティブ・ペイロードをWS添付として渡すことができます。
<Action id="ora-ws"> <invokeWS uri="WebServiceURI"/> <!-- format - <Absolute wsdl path>│service name│port name --> </Action>
WSDLインタフェース詳細
次の例に示すように、ここでは単一のポート・タイプのみ、入力操作のみ、および入力メッセージ用スキーマが必要です。
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://xmlns.oracle.com/pcbpel/errorHandling" xmlns:tns="http://xmlns.oracle.com/pcbpel/errorHandling" elementFormDefault="qualified">
<element name="RejectedMessage" type="tns:RejectedMessageType">
<complexType name="RejectedMessageType"/>
<sequence>
<element name="MessageHeader" type="string"/>
<!-- base64 encoded string -->
<element name="MessagePayload" type="string"/>
<!-- base64 encoded string -->
<element name="RejectionReason" type="string"/>
</sequence>
<attribute name="RejectionId" type="string"/>
</complexType>
</schema>
カスタムJavaハンドラ
次の例に示すように、ターゲット・クラスは事前定義済のJavaインタフェースを実装する必要があります。
<Action id="ora-custom">
<javaAction className="mypackage.myClass" defaultAction="ora-terminate">
<returnValue value="SUCCESS" ref="ora-file"/>
<returnValue value="FAILED" ref="ora-ws"/>
</javaAction>
</Action>
Javaインタフェース詳細
次のコード・スニペットは一例です。
package oracle.integration.platform.faultpolicy;
public interface IFaultRecoveryJavaClass
{
public void handleRetrySuccess( IFaultRecoveryContext ctx);
public String handleFault( IFaultRecoveryContext ctx);}
キュー
拒否されたメッセージは、例1: スタンドアロン・データベースの使用および例2: RACデータベースの使用に示すように、適切なコンテキストおよびペイロードとともにJMSメッセージとしてキューにエンキューされます。
例1: スタンドアロン・データベースの使用
<Action id="ora-queue"> <enqueue uri="QueueURI"/> <!-- QueueURI format - jdbc:oracle:thin:@<host>:<port>:<sid>#<un>/<pw>#queue --> </Action>
例2: RACデータベースの使用
<Action id="ora-queue"> <enqueue uri="QueueURI"/> <!-- QueueURI format - jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host1>)(PORT=<port1>))(ADDRESS=(PROTOCOL=TCP)(HOST=<host2>)(PORT=<port2>)))(CONNECT_DATA=(SERVICE_NAME=<service_name>)))#<un>/<pw>#queue --> </Action>
ファイル
拒否されたメッセージは、次の例に示すように、適切なコンテキストおよびペイロードとともにファイルシステムに格納されます。 ペイロード・ファイルは、構成した場所に作成されます。
<Action id="ora-file">
<fileAction>
<location>FOLDER_LOCATION</location>
<fileName>FILE_NAME</fileName>
<!-- FILE_NAME will support %ID%(rejected message instance id) or %TIMESTAMP% wildcards -->
</fileAction>
</Action>
ファイル・アクション・ハンドラの場合にのみ、拒否されたメッセージのプロパティをすべて含んだメタデータ・ファイルが作成されます。 たとえば、Oracleファイル・アダプタの場合、このメタデータ・ファイルにはインバウンド方向やファイル名などの情報が含まれます。 メタデータ・ファイルの場所はペイロード・ファイルと同じで、ネーミング・パターンは<FILE_NAME>_metadataです。
|
注意: 拒否されたメッセージは、Oracle Enterprise Managerコンソールからは発行できません。 |
ペイロードの永続性
拒否されたメッセージを再発行する場合、ペイロードの永続性が必要です。 ペイロードはデータベースに格納され、Oracle Enterprise Managerコンソールを介してペイロード表示機能を使用できます。 自動エラー処理中に起動されるエラー・ハンドラも、起動時にペイロードを取得します。
データベース内のエラー・ペイロードの永続性はデフォルトで使用可能です。
拒否されたメッセージはrejected_message表に格納されます。 拒否されたメッセージは次のいずれかの手順でチェックできます。
データベースからのチェック
データベースにsoainfraスキーマとして接続し、次のSQLコマンドを実行する必要があります。
select * from rejected_message
Oracle Enterprise Managerコンソールからのチェック
「ダッシュボード」タブの「最新のフォルトと拒否メッセージ」セクションまたは「フォルト・メッセージと拒否メッセージ」タブで、拒否されたメッセージを表示できます。
Oracle Enterprise Managerコンソールを拒否されたメッセージのチェックに使用する方法の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のインバウンド・アダプタに関する最新のフォルト・メッセージと拒否メッセージの監視に関する項、およびインバウンド・アダプタに関するフォルト・メッセージと拒否メッセージの監視に関する項を参照してください。
Oracle JCAアダプタとOracle Adapter for Oracle Applicationsアダプタでは、次の相互作用の接続エラーが処理されます。
Oracle JCAアダプタとOracle Adapter for Oracle Applicationsでは、一時的な接続エラーに関してoracle.tip.adapter.api.exception.PCRetriableResourceException例外が発生します。これはリカバリ可能な接続エラーです。たとえば、データベース・リスナーを起動できないと、接続エラーが戻される場合があります。
拒否ハンドラには、再試行可能な例外と再試行不可能な例外という2つのタイプがあります。
再試行可能な例外の場合は、jca.retry.countの値を必要な再試行回数に設定する必要があります。 たとえば、jca.retry.countの値を10に設定すると、再試行は10回発生します。 ただし、jca.retry.countに値を設定しない場合、コンポジットの一部として組み込んでいれば、フォルト・ポリシーにより再試行が実行されます。
次のコード・スニペットは、アウトバウンド相互作用に関する再試行可能な例外についてcomposite.xmlファイルに値を設定する一例です。
<reference name="Outbound">
<interface.wsdl interface="http://xmlns...#wsdl.interface(Outbound_PortType)"/>
<binding.jca config="Outbound_jms.jca">
<property name="jca.retry.count">5</property>
<property name="jca.retry.interval">1</property>
<property name="jca.retry.backoff">2</property>
<property name="jca.retry.maxInterval">6</property>
<property name="jca.retry.maxPeriod">30</property>
</binding.jca>
</reference>
リプライ・アクティビティ失敗の再試行回数は、指定したjca.retry.count値よりも1少なくなることに注意してください。 たとえば、jca.retry.countが5であれば、アダプタによる再試行は6回（1回の試行と5回の再試行）になります。 ただし、再試行されるのは4回のみで、Oracle Enterprise Managerコンソールにはインスタンスが5つしか表示されません。
アウトバウンド相互作用に関する再試行不可能な例外は、fault-policy.xmlファイルを介して実行可能な再接続試行の最大回数を定義することで処理できます。 次の例に示すように、このファイルでは再接続試行のパラメータを指定します。
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault">
<condition>
<action ref="ora-retry"/>
</condition>
</faultName>
<Actions>
<Action id="ora-retry">
<retry>
<retryCount>10</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff>2</exponentialBackoff>
</retry>
</Action>
</Actions>
次の例に示すように、fault-bindings.xmlファイル内でフォルト・ポリシーをコンポジットの参照エンドポイントに関連付ける必要があります。
<?xml version="1.0" encoding="UTF-8"?>
<faultPolicyBindings version="2.0.1" xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<reference faultPolicy="ConnectionFaults">
<name>writeMessageToQueue</name>
</reference>
</faultPolicyBindings>
この例の再接続パラメータ設定では、JCAバインディング・コンポーネント・ランタイムの再試行回数を10回と指定しており、再試行間隔は2秒から始まって2の倍数ずつ増加します。
|
注意: フォルト・ポリシーは、XAモードのアウトバウンド・アダプタには機能しません。 たとえば、フォルト・ポリシーをアウトバウンド・アダプタの失敗時に再試行させる必要がある場合、フォルト・ポリシーは再試行されず、この失敗の発生前に成功していたアウトバウンド・アダプタはロールバックされません。 |
構成済の再試行回数に達すると、サービス・インフラストラクチャ起動例外がスローされます。 すべての時間測定は秒単位で指定されます。
アウトバウンド・アダプタによりレポートされたエラーにインバウンド・アダプタが応答できるようにするには、サービス・インフラストラクチャ起動例外のタイプの伝播が重要です。アダプタがOracle BPEL Process Managerを同期的にコールし、次にOracle BPEL Process Managerがダウンストリーム・アダプタをコールする場合のフォルトの伝播を示します。 図2-3では、サービス・インフラストラクチャ起動例外が、Oracle BPEL Process Managerを介してダウンストリーム・アダプタからコール元アダプタに伝播しています。
すべてのOracle JCAアダプタ（Oracleソケット・アダプタ以外）とレガシー・アダプタでは、バックエンド・アプリケーションに接続してイベントを受信するためのプル・モデルがサポートされています。 ただし、パッケージ・アプリケーション・アダプタ（Oracle Adapter for Oracle Applications以外）では、EIS（Enterprise Information System）からイベントを受信するためのプッシュ・モデルがサポートされています。 接続関連の問題はリカバリ可能とみなされ、ほとんどのインバウンド・アダプタはEISとの接続を確立できるまで再試行を続けます。 ただし、インバウンド・アダプタは、リカバリ不可能なエラーが発生した場合（インバウンド・アダプタがメッセージをパブリッシュ後にEISから削除できない場合など）、汚染されたメッセージを防ぐためにエンドポイントを非アクティブ化します。
パッケージ・アプリケーション・アダプタ（Oracle EBSアダプタ以外）では、バックエンド・アプリケーションからイベントを受信するためのプッシュ・モデルがサポートされています。したがって、接続の概念は適用されません。 通常、インバウンド・エンドポイントはHTTPリスナー、TCP/IPリスナー、FTPリスナー、MQSeriesリスナーなどで、イベントが発生すると、それぞれのonMessageメソッドがトリガーされます。
拒否ハンドラには、再試行可能な例外と再試行不可能な例外という2つのタイプがあります。
再試行可能な例外の場合は、jca.retry.countの値を必要な再試行回数に設定する必要があります。 たとえば、jca.retry.countの値を10に設定すると、再試行は10回発生します。 ただし、jca.retry.countに値を設定しなければ、再試行は無限に実行されます。
次のコード・スニペットは、インバウンド相互作用に関する再試行可能な例外の値を設定する一例です。
<service name="Inbound">
<interface.wsdl interface="http://xmlns...#wsdl.interface(Inbound_PortType)"/>
<binding.jca config="Inbound_db.jca">
<property name="jca.retry.interval">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値よりも1少なくなることに注意してください。 たとえば、jca.retry.countが5であれば、アダプタによる再試行は6回（1回の試行と5回の再試行）になります。 ただし、再試行されるのは4回のみで、Oracle Enterprise Managerコンソールにはインスタンスが5つしか表示されません。
|
注意: エラーに関してインバウンド・アダプタが無限に再試行すると、再試行のたびに別のコンポジット・インスタンスが作成されるため、複数のコンポジット・インスタンスが作成されることになります。 たとえば、メッセージをエンキューするインバウンド・アダプタを考えてみます。 このデータが2つの表AおよびBに挿入されるとします。なんらかの理由で表Bへの挿入操作に失敗すると、インバウンド・アダプタはロールバックするかわりに表Bへのデータ挿入を無限に再試行します。 |
次のプロパティはインバウンドでサポートされています。
jca.retry.count
拒否前の最大再試行回数を指定します。
jca.retry.interval
再試行間の時間間隔（秒単位）を指定します。
jca.retry.backoff
再試行間隔の増加係数（正の整数）を指定します。
jca.retry.maxInterval
再試行間隔の最大値、つまりバックオフ > 1の場合の上限を指定します。
jca.retry.all
このプロパティがtrueに設定されている場合は、再試行不可能な例外もjca.retry.countプロパティで指定した値に基づいて再試行されます。
前述のプロパティ・リストは、次の例に示すようにOracle 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.interval">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>
この項では、メッセージ・エラーの処理方法についてサンプル・シナリオを使用して説明します。
図2-4に示すように、2つのコンポジットComposite1およびComposite2があり、それぞれにOracle BPELプロセスがあり、ローカル・リソースとXAリソースが混在している例を考えてみます。
肯定的なシナリオ、つまりメッセージがすべてのキュー（Q1、Q2およびQ3）に正常に配信された場合、トランザクションは正常にコミットされます。
メッセージをQ1（またはいずれかのキュー）には配信できないが、キューQ2およびQ3に配信できる場合、3つのメッセージはすべてXAリソースであり、そのユニットの1つに例外があるため、トランザクションでは3つのメッセージをすべてロールバックする必要があります。 ロールバック例外はQ1が失敗した第2のコンポジットについてのみスローされ、トランザクションでは3つのキューすべてについてメッセージがロールバックされるかわりにQ2およびQ3がコミットされます。
失敗したキューが1つのみで他の2つにはメッセージが正常に配信された場合も、トランザクションですべてのキューをロールバックするには、コールされたコンポジット（Composite2）のcomposite.xmlファイルを次のように変更する必要があります。
Composite2のcomposite.xmlの変更
<component name="BPELProcess1"> <implementation.bpel src="BPELProcess1.bpel"/> <property name="bpel.config.transaction">required</property> </component>
bpel.config.transaction="required"に設定すると、Oracle BPELエンジンは新規トランザクションを作成せず、コール元のトランザクションを使用して同期リクエストを効果的に処理することに注意してください。 したがって、いずれかの時点でトランザクションがロールバックすると、そのトランザクションでの実行内容は何もコミットされません。
この項では、メッセージの損失がないことをアダプタで保証する方法について説明します。
トランザクション・アダプタにより、エンタープライズ情報システム（EIS）は1フェーズ・コミットまたは2フェーズ・コミット（ローカル・トランザクションまたはグローバル/分散トランザクション）に参加できるようになります。 これらのコミットは、アダプタ（インバウンド）またはOracle User Messaging Service（UMS）（アウトバウンド）により制御されます。非トランザクション・アダプタでは、トランザクションのセマンティクスを使用せずに配信を保証するために、独自のスキームが実装されます。
ローカル・トランザクションでは、Oracle WebLogic Serverでリソース・アダプタに対してローカルなリソースを管理できます。 アダプタでは、weblogic-ra.xmlファイル内でtransaction-support要素を指定することでトランザクション・サポートのタイプを定義します。 アプリケーション・コンポーネントがEIS接続をリクエストすると、Oracle WebLogic Serverは現行トランザクション・コンテキストに基づいてローカル・トランザクションを開始します。 アプリケーション・コンポーネントがその接続をクローズすると、Oracle WebLogic Serverはローカル・トランザクションをコミットします。 また、Oracle WebLogic Serverはトランザクションの完了後にEIS接続をクリーン・アップします。
ローカル・トランザクションの場合は、JTAトランザクションが引き続きアクティブであることが検出された場合で、ポリシーが例外をスローしたパートナ・リンクにバインドされていた場合に、フォルト・ポリシーが実行されます。 JTAチェックにより、BPELエンジンはデハイドレーションされる可能性のある処理に進む前に、サード・パーティによるトランザクションの操作を取得できます。
アダプタでは、基礎となるアプリケーション・サーバーのトランザクション・マネージャを利用するJCA 1.5 XA規定でグローバル・トランザクションがサポートされています。 これには、Oracle Adapter for Oracle Applications、Oracle Adapter for Database、Oracle Adapter for Advanced Queuing、Oracle Adapter for JMSおよびOracle Adapter for MQSeriesが含まれます。 非トランザクション・アダプタには、Oracleファイル・アダプタやOracle FTPアダプタがあります。
グローバル・トランザクションの場合、ロールバックを停止するために何か実行することはできません。 このフォルト・タイプは、JTAトランザクションを再試行する必要があることを示します（たとえば、RACノードが停止した場合は、トランザクションを再開して再試行する必要があります）。 この場合、フォルト・ポリシーが実行されます。 ただし、XA動作が必要な場合にフォルト・ポリシーを使用することはお薦めしません。これは、フォルト・ポリシーが独自トランザクションで実行され、グローバル・トランザクションには関与しないためです。
特に、フォルト・ポリシーは特定の参照の実行を開始する前に既存のJTAトランザクションをコミットします（Oracle BPEL Process ManagerにおけるInvokeアクティビティなど）。 既存のJTAトランザクションが一時停止されてから再開されることはありません。
非同期SCAサービスのエントリ・ポイントの場合、トランザクション・アダプタではグローバルJTAトランザクションが開始されてから、インバウンド・メッセージがコンポジットに送信されます。 制御がアダプタに戻ると、アダプタによりJTAトランザクションがコミットされるため、次の一連のアクションがアトミックの作業ユニットとして実行されます。
この実行中に何かに失敗すると、アクション1および2がロールバックされます。
同期プロセスの場合、アダプタにより開始されたグローバル・トランザクションは、メッセージ配信とコンポジットの実行にまたがります。
トランザクション・アダプタの場合、アウトバウンドJCA相互作用（Invokeアクティビティ）は、有効範囲としてグローバルなBPEL JTA（EJB）トランザクションを持ちます。 これは、Oracle JCAアダプタの起動を含め、すべてのコンポジット・アクティビティがグローバル・トランザクションの一部となるため、エラーが発生した場合は、すべてのアクティビティがコミットされるかロールバックされるかのいずれかになることを意味します。
たとえば、BPELプロセスでは、異なるinvokeアクティビティを介して（データベース・アダプタを起動して）、異なるデータベース上の複数の表にデータを挿入できます。BPELインスタンスの終了前に、JTAトランザクションがコミットされます。その時点でのみ、データベースの挿入操作がコミットされます。BPELインスタンスの実行中にエラーが発生すると、すべてのアクティビティ（およびデータベース操作）が最後のデハイドレーション・ポイントまでロールバックされます。
Oracle JCAアダプタは、インバウンド処理とアウトバウンド処理の両方で大きなペイロードの処理をサポートしています。 ただし、ストリーミング機能を明示的にサポートしているのは次のアダプタのみです。
Oracleファイル・アダプタ
詳細は、「Oracleファイル・アダプタのスケーラブルなDOM」を参照してください。
Oracle AQアダプタ
詳細は、「ストリーム・ペイロードのサポート」を参照してください。
Oracle JMSアダプタ
詳細は、「大きなペイロードのストリーミングのサポート」を参照してください。
Oracleデータベース・アダプタ
詳細は、「大きなペイロードのストリーミング」を参照してください。
他のアダプタには、両方の明示的なサポートはありません。
WebLogicプラットフォームではOracle WebLogic Serverの移行が使用されているため、管理サーバーやマシンに障害が発生した場合に、同じマシンまたは別のマシン上で自動的に再起動し、障害が発生したサーバー上のコンポジットへのインバウンド・アダプタの機能が再開されます。 その間に、他のクラスタ・メンバー上のインバウンド・アダプタはメッセージ・サービス処理を続行できます。
コンポジットの可用性とインバウンド・アダプタの詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。
この項では、jarファイルが関連付けられていないアダプタRARファイルを手動でデプロイする方法について説明します。
META-INF/ra.xmlおよびMETA-INF/weblogic-ra.xmlのみを含み、JNDIの作成に必要なjarファイル・アダプタを含んでいないアダプタRARファイルをデプロイする場合は、デプロイ時にデプロイ順序を大きい値（500など）に変更する必要があります。これにより、Oracle WebLogic Serverでは、このアダプタのjarファイルをロードした後でこのRARファイルをデプロイできます。
たとえば、META-INF/ra.xmlおよびMETA-INF /weblogic-ra.xmlのみを含み、新規JNDIのインスタンス化中に必要なjarファイル・アダプタ（DbAdapter.jar）を含んでいないDBAdapter_NewJndis.rarファイルをデプロイするとします。 この場合は、DBAdapter_NewJndis.rarファイルのデプロイ後にデプロイ順序を大きい値に変更する必要があります。 これにより、Oracle WebLogic Serverを再起動しても、Oracle WebLogic ServerによりDBAdapter_NewJndi.rarファイルが確実に正しくデプロイされます。
jarファイルが関連付けられていないアダプタRARファイルを手動でデプロイする手順は、次のとおりです。
Oracle WebLogic Server管理コンソールhttp://servername:portnumber/consoleにナビゲートします。
必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。
Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。
「ドメイン構造」ペインで「デプロイメント」を選択します。
Oracle WebLogic Server管理コンソールの「デプロイメントの概要」ページが表示されます。
「インストール」をクリックします。
「アプリケーション・インストール・アシスタント」ページが表示されます。
「パス」フィールドにアプリケーション・ディレクトリまたはファイルのパスを入力し、「次へ」をクリックします。
このアプリケーションのデプロイ先サーバーを選択し、「次へ」をクリックします。
「オプション設定」ページが表示されます。
これらの設定を変更するかデフォルトを受け入れて、「次へ」をクリックします。
「選択項目を確認して「終了」をクリック」ページが表示されます。
「終了」をクリックしてデプロイを完了します。
RARファイルをデプロイした後、「デプロイメントの概要」の下でデプロイしたRARファイルの名前をクリックします。
「設定」ページが表示されます。
「デプロイ順序」フィールドの値をデフォルト値よりも大きい値に変更します。 たとえば、500に変更します。
これにより、新規にデプロイしたRARファイルがロードされるのは、常にOracle WebLogic Serverにより関連クラスがロードされた後になります。
図2-5に示すように、次のいずれかの方法を使用して、「アダプタ構成ウィザード - アダプタ・インタフェース」ページでアダプタ・インタフェースを定義できます。
「アダプタ構成ウィザード - アダプタ・インタフェース」ページに続いて表示されるページで、指定した操作名とスキーマを使用して生成されるWSDLを使用します。
既存のWSDLをインポートします。
この項では、既存のWSDLをインポートしてアダプタ・インタフェースを定義する方法について説明します。 この機能を使用すると、既存のWSDLを使用してアダプタ・サービスまたは参照を作成できます。 既存のWSDLを選択するオプションは、次のアダプタについてのみサポートされています。
Oracle AQアダプタ
Oracleファイル・アダプタ
Oracle FTPアダプタ
Oracle JMSアダプタ
Oracle MQ Seriesアダプタ
Oracleソケット・アダプタ
既存のWSDLをインポートしてアダプタ・インタフェースを定義するというオプションを選択した場合、以降のウィザード・ページの一部の機能が無効になります。 たとえば、WSDLでは操作名とメッセージ・スキーマを定義するため、図2-6に示すように、以降の操作名フィールドとスキーマ要素フィールドには値が自動的に入力されて変更できません。 ただし、既存の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ファイルとしてインポートされます。ただし、この機能はスキーマ要素を使用するメッセージにのみ機能することに注意する必要があります。 単純型と複合型はサポートされていません。 |
設計時環境とデプロイ先サーバーの間の接続性を確立する必要があります。 このような接続性を確立するには、アプリケーション・サーバー接続を作成する必要があります。
次の手順に従ってアプリケーション・サーバー接続を作成します。
「ファイル」メニューから「新規」を選択します。
図2-7に示すように、「新規ギャラリ」ページが表示されます。
「すべてのテクノロジ」タブで、「一般」カテゴリの「接続」を選択します。
「新規ギャラリ」ページの右側にある「項目」ペインに、確立できる様々な接続のリストが表示されます。
「アプリケーション・サーバー接続」を選択し、「OK」をクリックします。
図2-8に示すように、「アプリケーション・サーバー接続の作成」ページが表示されます。
「接続名」フィールドに接続名を入力します。この例では、AppsServerConnection1と入力します。
「接続タイプ」で「WebLogic 10.3」を選択し、「次へ」をクリックします。
図2-9に示すように、「認証」ページが表示されます。
ユーザー名とパスワードを入力して「次へ」をクリックします。
図2-10に示すように、「アプリケーション・サーバー接続の作成 - 構成」ページが表示されます。
「構成」ページでホスト名、ポート詳細およびドメイン・サーバー名を入力します。
「次へ」をクリックします。
図2-11に示すように、「アプリケーション・サーバー接続の作成 - テスト」ページが表示されます。
「接続のテスト」をクリックします。「ステータス」ペインに成功メッセージが表示されます。
「終了」をクリックします。
サーバー接続が作成されました。
SOAコンポジット・アプリケーションはOracle JDeveloperからデプロイします。
Oracle JDeveloperでは、デプロイするSOAプロジェクトおよびアプリケーションに対してプロファイルを使用する必要があります。この項では、Oracle JDeveloperによるプロファイルの作成およびデプロイ方法について説明します。
この項では、SOAプロジェクトとアプリケーションのアプリケーション・プロファイルをデプロイする方法について説明します。
アプリケーションをデプロイする手順は、次のとおりです。
デプロイするプロジェクトを右クリックし、図2-12に示すように「デプロイ」→「project_name」→「デプロイ先」→「Application_Server_Connection_Name」を選択します。
「SOAデプロイメントと構成ダイアログ」が表示されます。
図2-13に示すように、デフォルト設定を使用します。
「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...
「Oracle Enterprise Manager Grid Control」コンソールから、デプロイされたSOAコンポジット・アプリケーションのインスタンスを実行およびテストする準備ができました。これにより次が可能になります。
コンポジット・アプリケーションの管理。
コンポジットのインスタンスの起動。
コンポジットのインスタンスの追跡。
詳細なコンポーネント・インスタンスの監査証跡の表示。
アプリケーションのテストの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。
バッチ処理機能とデバッチ処理機能は、Oracle JCA Adapter for Files、Oracle JCA Adapter for FTPおよびOracle JCA Adapter for Databasesでのみサポートされています。 Oracle JCA Adapter for FileとOracle JCA Adapter for FTPは、単一の大型ファイルを複数のバッチにデバッチ処理するためのReaderで構成されています。設計時構成中にバッチ・サイズを指定する必要があります。さらに、アダプタには一連のメッセージを単一ファイルにバッチ処理するためのライターも組み込まれています。
Oracle JCA Adapter for Databasesは、一連の表をポーリングしてイベントを検出するためのパブリッシュ・コンポーネントで構成されています。このコンポーネントでは、BPELプロセスの1度に1つのレコードまたは1度に複数のレコードに対してイベントを発生させることができます。
アダプタ構成ウィザードにより生成されるすべてのJCAファイルには、JNDI名への参照が含まれています。 この参照は、アダプタのデプロイメント・ディスクリプタであるweblogic-ra.xmlファイルで定義されています。 JNDI名は、開発環境からテスト環境へ、テスト環境から本番環境への移行が必要な場合のキーです。開発、テストおよび本番という3つの環境すべてで同じJNDI名を持つように、weblogic-ra.xmlファイルを更新する必要があります。再試行間隔や再試行カウントなどのデプロイメント時プロパティの値を指定してから、テスト環境または本番環境に再デプロイしてください。weblogic-ra.xmlでは、エンドポイントが開発EIS、テストEISまたは本番EISとして識別されます。 たとえば、データベース・アダプタ・サービス・ウィザードを介して実行中に、createCustomerサービスのJNDI名としてeis/DB/custStoreを指定するとします。 このアダプタ・サービスを使用してコンポジットをモデル化した後は、それを変更せずにそのまま開発、テストまたは本番環境にデプロイする必要があります。ただし、その前に、正しいEISインスタンスを指している各環境に、eis/DB/custStoreに対応するJNDIエントリがあることを確認してください。
この項では、Oracle JCAアダプタで使用する非XAデータソースとXAデータソースの推奨設定について説明します。
マルチ・データソースの推奨設定は、次のとおりです。
test-frequency-secondsを5に設定します。
algorithm-typeをLoad-Balancingに設定します。
data-source-listでは、カンマ区切りの子データソース・リストを指す必要があります。 たとえば、("JDBC Data Source-0,JDBC Data Source-1")を指定します。
エンドポイント・プロパティがRACデータベースに常駐する場合は、マルチ・データソースを使用することをお薦めします。
表2-1に、Oracle JCAアダプタで使用するXAデータソースと非XAデータソースの推奨設定を示します。
表2-1 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-1に示した設定は、単一インスタンスとRACデータベースの両方のタイプのデータベースに適用可能です。 RACデータベースの場合は、エンドポイント用に作成されたマルチ・データソースを構成するデータソースに、これらの設定を使用する必要があります。 |
表2-1に示した設定を適用するのみでなく、次のリンクで提供されている『Programming WebLogic JTA』に記載された手順を実行する必要があります。
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jta/thirdpartytx.html#wp1084836
これらの手順は、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
