| Oracle Application Server Adapters for Files, FTP, DatabasesおよびEnterprise Messagingユーザーズ・ガイド 10g （10.1.3.1.0） B31889-01 |
|
 戻る |
 次へ |
| Oracle Application Server Adapters for Files, FTP, DatabasesおよびEnterprise Messagingユーザーズ・ガイド 10g （10.1.3.1.0） B31889-01 |
|
戻る |
次へ |
この付録では、Oracle BPEL Process ManagerとOracle Enterprise Service Busのトラブルシューティング方法について説明します。
この付録には、次の項目が含まれます。
第A.1項「Oracle Application Server Adapter for Databasesのトラブルシューティング」
第A.2項「ストアド・プロシージャを使用中のOracle Application Server Adapter for Databasesのトラブルシューティング」
第A.3項「Oracle Application Server Adapter for Files/FTPのトラブルシューティング」
第A.4項「Oracle Application Server Adapter for Advanced Queuingのトラブルシューティング」
第A.5項「Oracle Application Server Adapter for Java Message Service（JMS）のトラブルシューティング」
次の項では、Oracle Application Server Adapter for Databases（データベース・アダプタ）を使用中に予想される問題と解決策を説明します。
この項には、次の項目が含まれます。
問題
実行時に、TopLinkセッションを作成できなかったという例外が発生する場合があります。
解決策
この一般的なエラーは、実行時の接続が適切に構成されていない場合に発生します。 詳細は、「デプロイ」を参照してください。
問題
eis/DB/my_connection/....のアダプタを検出できなかったという例外が発生する場合があります。
解決策
詳細は、「デプロイ」を参照してください。
TopLink Workbenchを使用した変更では、「アダプタ構成ウィザード」を編集モードで再度実行し、toplink_mappings.xmlファイルのリフレッシュを強制する必要があります。
obantを使用して再デプロイする場合、bpel.xmlまたは.bpelファイルが変更されていないかぎり、設計時に再デプロイはスキップされます。
問題
Customers_table.xsdへの変更が反映されない場合は、例外が発生します。
解決策
データベース・アダプタが生成するXSD形式は指定できません。 詳細は、「XMLスキーマ定義（XSD）」を参照してください。
問題
「終了」をクリックした後、またはデプロイ時に、次の例外が発生する場合があります。
Caused by Exception [TOPLINK-0] (OracleAS TopLink - 10g (9.0.4.4) (Build 040705)): oracle.toplink.exceptions.IntegrityException Descriptor Exceptions: ---------------------- Exception [TOPLINK-64] (OracleAS TopLink - 10g (9.0.4.4) (Build 040705)): oracle.toplink.exceptions.DescriptorException Exception Description: No target foreign keys have been specified for this mapping. Mapping: oracle.toplink.mappings.OneToManyMapping[phonesCollection] Descriptor: Descriptor(Test.Customers --> [DatabaseTable(CUSTOMERS)])
通常、ウィザードで問題があったことを示します。
解決策
最も簡単な解決策は、まずデータベースにすべての制約を作成することです。また、問題によっては、オフライン表の問題を修正してウィザードを再度実行するのみでよい場合もあります。
CUSTOMERSからPHONESへの1対多マッピングを作成する場合、PHONESには外部キー制約が必要です。
この手順では、この制約がデータベースに存在せず、ウィザードでの作成を試行して例外を生成したことを前提としています。
JDeveloper BPEL Designerプロジェクトで、「アプリケーション・ナビゲータ」のプラス記号（+）をクリックして、プロジェクトにファイルを追加します。database→schemaName→schemaName.schemaを選択します。これにより、すべてのデータベース・オブジェクトがインポートされます。
PHONES表を開いて、PHONESからCUSTOMERSへの外部キー制約を手動で作成します。
すべてを保存します。
TopLinkプロジェクトを開きます。JDeveloper BPEL Designerで、「アプリケーション・ソース」→「TopLink」→「TopLinkマッピング」へ移動します。「構造」ウィンドウで、CUSTOMERSを開いてphonesCollectionマッピングをダブルクリックします。
メイン・ウィンドウに「表参照」タブが表示されます。前は空白でした。メニューから、作成した外部キー制約を選択します。
再度保存します。
データベースのパートナ・リンクを編集します。
「次へ」をクリックしてウィザードを終了し、「終了」→「閉じる」をクリックします。
これにより、プロジェクトのtoplink_mappings.xmlがリフレッシュされます。
JDeveloper BPEL Designerでtoplink_mappings.xmlファイルを開きます。まず、プロジェクトに追加する必要がある場合があります。
phonesCollectionを検索します。
次のようなタグが見つかります。
<database-mapping> <attribute-name>phonesCollection</attribute-name>
下へスクロールすると、次の内容があります。
<source-key-fields> <field>CUSTOMERS.someColumn</field> </source-key-fields> <target-foreign-key-fields> <field>PHONES.someColumn</field> </target-foreign-key-fields>
これらのタグがない場合は、手動で追加します。toplink_mappings.xmlは生成されるファイルであり、データベースのパートナ・リンクを編集するたびリフレッシュされるため、これはお薦めできる方法ではありません。
Oracle BPEL Controlの古いプロセスをアンデプロイし、新しいリビジョン番号で固定プロセスを再デプロイします。
問題
「終了」をクリックした後、またはデプロイ時に、次の例外が発生する場合があります。
Caused by Exception [TOPLINK-0] (OracleAS TopLink - 10g (9.0.4.4) (Build 040705)): oracle.toplink.exceptions.IntegrityException Descriptor Exceptions: ---------------------- Exception [TOPLINK-46] (OracleAS TopLink - 10g (9.0.4.4) (Build 040705)): oracle.toplink.exceptions.DescriptorException Exception Description: There should be one non-read-only mapping defined for the primary key field [PHONES.ID]. Descriptor: Descriptor(Test.Phones --> [DatabaseTable(PHONES)])
PHONESに主キーが定義されていないことを意味します。
解決策
この例外が、ターゲット外部キーがないというエラーとともに表示された場合、「ターゲット外部キーがないというエラー」を参照し、まずその問題を解決します。それ以外の場合は、次のようにします。
「アプリケーション・ソース」→「TopLink」→「TopLinkマッピング」を開きます。
「構造」ウィンドウで、PHONESをダブルクリックします。
最初のページに「主キー」があります。列が選択され、プロジェクトにマッピングされていることを確認します。
保存します。
データベースのパートナ・リンクを編集します。
「次へ」をクリックしてウィザードを終了し、「終了」→「閉じる」をクリックします。
toplink_mappings.xmlを開きます。PHONESディスクリプタの場合、次のようなタグがあります。
<primary-key-fields> <field>PHONES.ID</field> </primary-key-fields>
少なくともフィールドが1つあることと、そのフィールドがtoplink_mappings.xmlファイルの別の場所にもあることを確認します。別の場所にもあった場合、データベース・アダプタで検出できます。ない場合には、このフィールドをマッピングする必要があります。
「アプリケーション・ソース」→Test→Phonesを開きます。
Javaコードが表示されます。次の行を追加します。
long id;
保存します。
「アプリケーション・ソース」→「TopLink」→「TopLinkマッピング」を開きます。
PHONESをダブルクリックし、「構造」ウィンドウへ移動します。
DirectToFieldというIDをマッピングし、「ID」にデータベース・フィールドを設定します。
保存してデータベースのパートナ・リンクを編集します。
「次へ」をクリックしてウィザードを終了し、「終了」→「閉じる」をクリックします。
Oracle BPEL Controlの古いプロセスをアンデプロイし、新しいリビジョン番号で固定プロセスを再デプロイします。
問題
データベース・アダプタにxs:dateTime値を渡す際に変換の例外が発生する場合があります。
解決策
属性がタイプxs:dateTimeの場合、データベース・アダプタは次のいずれかの書式の文字列を要求します。
1999-12-25T07:05:23-8:00 1999-12-25T07:05:23.000-8:00 1999-12-25T15:05:23:000Z 1999-12-25T15:05:23
有効なxs:dateTime値ではありませんが、書式1999-12-25は受け入れられます。xs:dateTime書式はyyyy-MM-ddTHH:mm:ss.SSSZで、それぞれの意味は次のとおりです。
yyyyは年（2005年など）です。
MMは月（01から12）です。
ddは日にち（01から31）です。
HHは時間（00から23）です。
mmは分（00から59）です。
ssは秒（00から59）です。
SSSはミリ秒（000から999）で、オプションです。
Zはタイムゾーン識別子（+hh:mmまたは-hh:mm）で、オプションです。
Oracleデータベースでは、25-DEC-1999日付書式を使用できるDATE列が存在する場合があります。ただし、これはデータベース・アダプタで受け入れられる日付書式ではありません。次に示すのは、TopLinkにのみ適用可能な解決策です。
25-DEC-1999日付書式を渡す場合には、属性を単純な文字列としてマッピングします。データベース・アダプタはその値をそのまま受け入れます。
これを実行するには、オフライン・データベース表を編集し、列のデータ型をDATEからVARCHAR2に変更する必要があります。
保存します。
データベースのパートナ・リンクを編集します。
「次へ」をクリックしてウィザードを終了し、「終了」→「閉じる」をクリックします。
有効なxs:dateTime書式ではありませんが、書式yyyy-mm-ddは有効なxs:date書式です。
問題
oracle.toplink.internal.databaseaccess.DatabasePlatformを使用する場合、DATEフィールドの時間部分は、Oracle9以上のプラットフォームでは切り捨てられます。たとえば、2005-04-28 16:21:56は2005-04-28T00:00:00.000+08:00になります。
または、oracle.toplink.internal.databaseaccess.Oracle9Platformを使用する場合、DATEフィールドのミリ秒部分は、Oracle9以上のプラットフォームでは切り捨てられます。たとえば、2005-04-28 16:21:56.789は2005-04-28T16:21:56.000+08:00になります。
または、TIMESTAMPTZ（タイムゾーンのタイムスタンプ）またはTIMESTAMPLTZ（ローカル・タイムゾーンのタイムスタンプ）に問題があります。
解決策
Oracleでの日時の値の処理には特別な解決策があるため、OracleプラットフォームにはplatformClassNameを設定する必要があります。そのため、Oracle9プラットフォームに接続している場合は、それにあわせてplatformClassNameを設定する必要があります。
Oracle9 JDBCドライバで切り捨てられるDATEの時間部分の問題のため、任意のOracleプラットフォームのクラス名を使用している場合には、プロパティoracle.jdbc.V8Compatibleが設定されていました。そのため、oracle.toplink.internal.databaseaccess.Oracle9Platformを使用して時間の切捨ての問題を解決します。
ただし、Oracle9をはじめ、日付にはミリ秒精度が含まれるようになっています。Oracle8データベースと同じように、レスポンスにoracle.jdbc.V8Compatibleを設定すると、ミリ秒が000として返されるという問題がありました。（これは、ストアド・プロシージャをサポートするためのNULLのIN/OUT DATEパラメータの問題の原因にもなっています。）Oracle9Platformクラスを使用している場合には、（時間部分やミリ秒の）切捨ては行われません。
また、TIMESTAMPTZおよびTIMESTAMPLTZがある場合には、Oracle9Platformクラスを使用する必要があります。
DATEを（時間部分なしの）日付と同じように処理する場合には、toplink_mappings.xmlの属性の分類をjava.sql.Dateに設定します。
一般的に、特定のデータベースで問題がある場合は、TopLinkにそのデータベースに対するカスタムのplatformClassName値があるかどうか、また、それを使用しているかどうかを確認します。
詳細は、「デプロイ」を参照してください。
TIMESTAMPデータ型がサポートされていないため、最善の方法はTIMESTAMP列をアンマップすることです。TIMESTAMPのアンマップのサポートでは、次の事項に注意してください。
TIMESTAMP値は、主キーとして使用できません。
TIMESTAMPは実際にはバイナリ値ですが、JDeveloperのオフライン表ではdateTime型として解釈されます。そのため、型を変更する必要があります。
XMLおよびbase64エンコードへの変換後、TIMESTAMPにはバイナリ値としての意味も使用方法もありません。
TIMESTAMP値は変更できないため、少なくとも読取り専用としてマークしておく必要があります。
TIMESTAMPは擬似列ROWIDに似ています。ROWIDは技術的には列ですが、データベース・アダプタによってデフォルトでマッピングされることはありません。
「TopLink Workbenchプロジェクト」を参照し、マッピングをアンマップする手順に進んでください。
挿入における一意の制約違反、またはデータベースやネットワークを一時的に使用できないなどのフォルトの処理方法を理解するには、Oracle_Home\bpel\samples\tutorials\122.DBAdapterにあるInsertWithCatchチュートリアルを参照してください。
問題
あるデータベースに対してモデル化されたBPELプロセスは、別のデータベースに対して実行できません。
この問題のほとんどの原因は、第2データベースで異なるスキーマを使用していることです。たとえば、ウィザードを実行して表SCOTT.EMPLOYEEをインポートすると、toplink_mappings.xmlファイルにSCOTT.EMPLOYEEが表示されます。別のデータベースでUSERスキーマのサンプルを実行すると、表が見つからないという例外が発生します。
解決策
スキーマ名によるすべての表名の修飾がオプションになるまで、手動でtoplink_mappings.xmlを編集し、次の例で示すようにSCOTT.を削除します。
変更前:
<project>
<project-name>toplink_mappings</project-name>
<descriptors>
<descriptor>
<java-class>BPELProcess1.A</java-class>
<tables>
<table>SCOTT.A</table>
</tables>
変更後:
<project>
<project-name>toplink_mappings</project-name>
<descriptors>
<descriptor>
<java-class>BPELProcess1.A</java-class>
<tables>
<table>A</table>
</tables>
アダプタ構成ウィザードを実行するたびに、この手順を繰り返す必要があります。
|
注意: SCOTTおよびUSERスキーマの両方にEMPLOYEEがあり、不適切な表を修飾すると、検出の難しい問題につながります。このため、データベース・アダプタでは表名をスキーマ名で修飾します。 |
詳細は、「デプロイ」を参照してください。
問題
従業員が多数所属する多数の部門を読み取りましたが、部門ごとに表示される従業員が1人のみです。
解決策
for-each文を使用して変換を行う必要があります。簡略化したXPath問合せを使用したassignアクティビティでは、コピーされるのは最初の従業員のみです。
データベース・アダプタの出力に対する変換の使用方法の例は、次の場所へ移動してください。
Oracle_Home\bpel\samples\tutorials\122.DBAdapter\MasterDetail
問題
firstName = some_parameterであるすべての従業員の検出にアウトバウンドのSELECTを使用すると、データベースでfirstNameが、VARCHAR2列とは反対の型としてのCHAR列の場合には問題が発生します。
CHAR(8)フィールドに（'Jane'などの）CHAR値を挿入すると、データベースにより値に余白（'Jane 'など）が追加されるのは、いくつかのデータベースでは既知の問題です。
次の問合せを実行したとします。
SELECT ... WHERE firstName = 'Jane';
行は返されません。挿入したのと同じ値を問い合せており、SQL*PlusおよびSQL Worksheetなどのツールは要求どおりに動作しますが、データベース・アダプタではこの問合せは機能しません。
解決策
最善の方法は、CHAR列をSSNなどの固定長の必要があるフィールドに使用し、VARCHAR2はfirstNameなどの可変長を使用できる列に使用することです。
値を変換して余白を追加するのは難しく、（文字列の反対側に余白を追加するのとは対照的に）SELECTを使用してデータベースの値を削除するにはSQL文を使用する必要があります。次に例を示します。
SELECT ... WHERE trim(firstName) = #firstName;
#は、入力パラメータを表す際のTopLinkの表記規則です。
問題
CLOBを含むBへの1対1リレーションシップを持つ表Aで問合せを行うと、次の例外が発生します。
Exception Description: java.sql.SQLException: ORA-00932: inconsistent datatypes: expected - got CLOB
解決策
CLOB値を返すSELECTでは、DISTINCT句を使用できません。DISTINCTを回避する最も簡単な方法は、AからBへのバッチ属性読取りを無効化することです。バッチ読取りでは、以前問い合せたすべてのAからすべてのBの同時読取りを試行してパフォーマンスを拡張します。この問合せではDISTINCT句を使用します。結合読取りを使用するか、結合読取りもバッチ属性読取りも使用しません。
DISTINCTおよびCLOBのどちらも一般的であるため、この問題は別のシナリオでも発生します。たとえば、次のような式ではDISTINCT句を使用します。
SELECT DISTINCT dept.* from Department dept, Employee emp WHERE ((dept.ID = emp.DEPTNO) and (emp.name = 'Bob Smith'));
バッチ読取りおよび結合読取りの詳細は、「リレーショナルからXMLへのマッピング（toplink_mappings.xml）」を参照してください。
問題
ラージ・オブジェクト（LOB）の挿入時に、次のような例外が発生する場合があります。
java.sql.SQLException: setString can only process strings of less than 32766 characters Error Code: 17157
解決策
oc4j-ra.xmlファイルのplatformClassNameプロパティを確認します。Oracleデータベースの場合、プロパティをOracle8Platform（Oracle8の場合）またはOracle9Platform（Oracle9iおよびOracle10gの場合）に設定します。 Oracleおよびサード・パーティのデータベースのplatformClassNameプロパティのリストは、表4-17「データベース・プラットフォーム名」を参照してください。
詳細は、次のサイトの「How-To: Map Large Objects (LOBs) to Oracle Databases with OracleAS TopLink」を参照してください。
http://www.oracle.com/technology/products/ias/toplink/technical/tips/lob/index.html
Oracle Database 10gを使用していてCLOBの問題がある場合は、データベース・アダプタをデータソースを使用するように構成し、OC4J data-sources.xmlファイルの<data-source>要素に<propertyname="SetBigStringTryClob" value="true" />を追加します。
また、次のサイトの「Handling CLOBs - Made Easy with Oracle JDBC 10g」も参照してください。
http://www.oracle.com/technology/sample_code/tech/java/codesnippet/jdbc/clob10g/handlingclobsinoraclejdbc10g.html
問題
MERGEにより、INSERT処理が行われる必要がある際にUPDATE処理が行われることや、その逆に処理が行われることがあります。
解決策
MERGEでは、XMLの各要素に対して、対応するデータベース行が存在するかどうかを確認してから処理が行われます。各行では、存在チェックが行われます。存在チェックには、2つの既知の制限があります。
まず、存在チェックを「キャッシュのチェック」または「データベースのチェック」に構成できます。これは、Mapping Workbenchプロジェクトの各ディスクリプタ（マップされた表）に対して構成できます。デフォルトは「データベースのチェック」ですが、TopLinkのデータベースのチェックではパフォーマンス上の理由で、キャッシュがチェックされてからデータベースがチェックされます。キャッシュには行が存在するがデータベースからは削除されている場合（キャッシュが失効している場合）には、INSERT処理を予期している際にUPDATEが行われます。キャッシュを構成するとデフォルトでWeakIdentityMapが使用され、処理中の行はメモリーにのみ保持されます。ただし、アダプタではJavaガベージ・コレクションが制御されません。そのため、短時間の間に行を挿入して別のプロセスで削除し、再度挿入すると、INSERTの後にUPDATEが行われます。解決策の1つはNoIdentityMapを使用することです。ただし、パフォーマンスが低下する可能性があります。また、複雑なサイクルのマップされたスキーマでSELECT文を実行すると、XMLの作成時にアダプタが無限ループに陥る可能性があります（複雑なサイクルは回避する必要があります）。
次に、読取りを先に行い、その後にINSERTまたはUPDATEを行うタイミングの問題があります。複数の起動で同じ行が同時に挿入されると、falseを返す存在チェックがそれぞれに実行され、すべてがINSERTを試行します。これは現実的ではありませんが、次のシナリオが考えられます。
ポーリングの受信で、データベースAから従業員とその所属先の部門を100行読み取ります。maxRaiseSizeが1に設定された状態で、100のビジネス・プロセス・インスタンスが初期化されます。これにより、データベースBに各従業員行に対して1つ、100のインスタンスが同時に起動されます。従業員の存在チェックでは問題は発生しませんが、複数の従業員に同じ部門があります。そのため、部門の存在チェックが事実上同時になり、100の起動の多くが失敗します。
この問題には2つの解決策があります。1つ目はそれを回避することです。データ同期型のアプリケーションでは、maxRaiseSizeをunlimitedに設定すると、パフォーマンスが向上しこの問題がなくなります。2つ目の解決策は、BPELプロセスでMERGEを再試行することです。オプティミスティック・ロックおよび同時実行性の例外は一般的で、最善の解決策は待機して少し後に再試行することです。
問題
MERGEの起動操作を使用すると、データベース・アダプタに100行渡されます。ただし、すべての行が適切にデータベース表に挿入されるわけではありません。
この問題の詳細は、「MERGEによるUPDATE処理とINSERT処理の誤作動」を参照してください。MERGEの存在チェックの不具合により、挿入が必要な際に行が挿入されないケースが許可されるため、メッセージが失われたように見えます。
解決策
WeakIdentityMapではなくNoIdentityMapを使用します。
JDeveloper BPEL Designerでプロジェクトを開きます。
「アプリケーション - ナビゲータ」で、プロジェクトの「アプリケーション・ソース」の下の「TopLinkマッピング」ノードをダブルクリックします。
「TopLinkマッピング - 構造」ペインに、TopLinkプロジェクトが表示されます。
「TopLinkマッピング - 構造」ペインの各ディスクリプタをクリックすると、メイン・ウィンドウに表示されます。
メイン・ウィンドウの上部には、「ディスクリプタ情報」、「問合せ」、「問合せキー」および「アイデンティティ」タブがあります。
「アイデンティティ」タブをクリックします。
「アイデンティティ・マップ」リストから、NoIdentityMapを選択します。
「データベースのチェック」（デフォルト）に「存在チェック」を設定します。
キャッシュが使用されない場合、値「キャッシュのチェック」は無効になります。
「ファイル」から「すべて保存」を選択します。
アダプタ構成ウィザードを編集モードで再度実行し、toplink_mappings.xmlを再生成します。
（オプションで）toplink_mappings.xmlを閉じて再度開き、解決策の効果を確認します。
NoIdentityMapがWeakIdentityMapにグローバルに変更されています。
その処理を再デプロイします。
基礎となるTopLinkプロジェクトの編集の詳細は、「TopLink Workbenchプロジェクト」を参照してください。
問題
子レコードで、DeletePollingStrategyの整合性違反が検出されます。
行を削除する際には、整合性制約に注意する必要があります。たとえば、DEPARTMENTにEMPLOYEEへの1対多リレーションシップがある場合、DEPTIDはEMPLOYEEの外部キーです。DEPARTMENTレコードを削除して従業員を削除しないと、DEPTIDは破損したリンクとなり、整合性制約の原因となります。
この問題は、表のみがインポートされ、それに関連する表がインポートされなかったために発生します。たとえば、データベースからDEPARTMENT表のみをインポートし、列DEPTIDに整合性制約のあるEMPLOYEE表をインポートしない場合、データベース・アダプタはEMPLOYEEを認識できず、DEPARTMENTからレコードを削除できません。例外が発生します。
解決策
マスター表およびプライベートに所有されているリレーションシップをすべてインポートしてください。または、データベースに削除をカスケードする制約を設定するか、削除以外のポーリング計画を使用します。
DEPARTMENTおよびEMPLOYEEの1対多リレーションシップが、プライベートに所有されるよう構成してください。これはデフォルトで行われますが、失敗した場合には、実行時のX-Rマッピング・ファイルを確認してください。 詳細は、「リレーショナルからXMLへのマッピング」を参照してください。
問題がこれほど単純ではない場合、TopLinkではシャロー/2フェーズ・インサートをサポートしています（DELETEではサポートされていません）。たとえば、AにBを指す外部キーがあり、BにはAを指す外部キーがある場合、AおよびBの両方を削除する適切な順序はありません。Aを先に削除すると、Bが孤立します。Bを先に削除すると、Aが孤立します。最も安全なDELETEは、次に示すように、まずUPDATEを実行する2フェーズのDELETEです。
UPDATE B set A_FK = null; DELETE from A; DELETE from B;
問題
問合せを実行すると、正しい行数を取得できますが、行が複数回表示されることや表示されないことがあります。
この動作は、主キーの構成が不適切なことが原因です。データベース・アダプタで同一とみなされる2つの異なる行（同じ主キーなど）を読み取ると、両方の行が同じインスタンスに書き込まれ、1つの目の行の値が2つ目の行の値で上書きされます。
解決策
「アプリケーション・ソース」→「TopLink」→「TopLinkマッピング」を開きます。「構造」ウィンドウで、PHONESをダブルクリックします。最初のページに「主キー」があります。一意の制約を作成するための正しい列が選択されていることを確認します。
保存してデータベースのパートナ・リンクを編集します。
「次へ」をクリックして終了し、「終了」→「閉じる」をクリックします。
toplink_mappings.xmlファイルを開きます。PHONESディスクリプタの場合、次のようなタグがあります。
<primary-key-fields> <field>PHONES.ID1</field> <field>PHONES.ID2</field> </primary-key-fields>
問題
あるホスト上のデータベースから表をインポートし、別のホスト上のデータベースから同じ名前で同じスキーマ名の表もインポートするとエラーが発生します。
解決策
データベース#1に対して1つ目のプロジェクトを作成し、アダプタ・サービスをモデル化します。次に、データベース#2に対して2つ目のプロジェクトを作成し、アダプタ・サービスをモデル化します。（データベースは異なるホストにあるため、異なるデータベース接続を使用します。）3つ目のプロジェクトを作成しますが、アダプタ構成ウィザードは実行しません。かわりに、1つ目および2つ目のプロジェクトからBPEL成果物（WSDL、XSDおよびtoplink_mapings.xml）をコピーします。3つ目のプロジェクトのみをデプロイします。
2つの表が同一である場合、または目的のデータが同一の場合は、前述の手順に従う必要はありません。
問題
アダプタ構成ウィザードの「リレーションシップ」ウィンドウでは、主キーのすべての要素が表示され削除できません。そのため、コンポジット主キーの一部のみを参照する外部キーは作成できません。
解決策
外部キー制約は、（サブセットではなく）主キーのすべての部分をマッピングする必要があるため、解決策はありません。データベース・アダプタでは、参照先として対応する主キーのある外部キーのみが許可されます。
ウィザードでは、曖昧なリレーションシップは作成できません。たとえば、PurchaseOrderにContactへの1対1のbillToリレーションシップがあるとします。一意性のため、Contactの主キーはnameおよびprovinceです。これは、PurchaseOrderには2つの外部キー（bill_to_nameおよびbill_to_province）が必要であることを意味します。外部キーが1つのみ（bill_to_name）の場合、ウィザードでは曖昧な1対1リレーションシップを作成できません。それ以外の場合は、同じ注文書を複数人に請求できます。
BFILE、USER DEFINED、OBJECT、STRUCT、VARRAYおよびREF型はサポートされていません。
同じプロジェクト内で表が他のサービスに使用されているため、インタフェース内で削除できません。不要な表がプロジェクトの一部として残っていても問題は発生しません。
問題
アダプタ構成ウィザードの実行中に、TopLinkプロジェクトに影響のある変更（表のインポート、マッピングの作成または削除、式の指定など）を行うとすぐに適用されます。ウィザードを取り消しても元に戻りません。
解決策
自動生成されたリレーションシップを1つ以上削除して後で必要になった場合には、対応するデータベース制約を含む表を再度インポートする必要があります。
問題
同じウィザード・セッションで、リレーションシップを削除して、すぐに同じ名前のリレーションシップを作成すると、データベース・アダプタが不安定になる場合があります。
解決策
次のいずれかを実行できます。
新しいリレーションシップに削除したものとは異なる名前を付けます。
最初のリレーションシップの削除後にウィザードを終了します。その後、ウィザードを編集モードで再度開始し、削除したリレーションシップと同じ名前を使用して新しいリレーションシップを追加します。
問題
サード・パーティのデータベースから表をインポートする際に、特定のデータ型の処理においてJDeveloperで問題が発生する場合があります。「VARCHAR型の列は指定されたサイズにできません。」または「主キーまたは一意キーでは、少なくとも1つの列を定義します。」などのエラー・メッセージが表示されます。「null」などのエラー・メッセージも、データ型がサポートされていないことを意味します。
解決策
次の解決策を使用します。
「OK」をクリックしてエラー・メッセージを閉じ、アダプタ構成ウィザードを取り消します。
オフライン表の定義を編集して、エラー・メッセージに表示された列の型をサポートされている型で最も近いものに変更します。
プロジェクトのオフライン表の定義は、JDeveloper BPEL Designerの「アプリケーション・ナビゲータ」の「データベース・オブジェクト」→「schema name」ノードの下にあります。
次の表に、オフライン・データベース表の最も近いデータ型の検索方法をまとめます。
| サード・パーティのデータベースのデータ型 | オフライン・データベース表のデータ型 | XMLデータタイプ |
|---|---|---|
VARCHAR、CLOBなど |
VARCHAR2 |
xs:string |
RAW、BYTE、BLOB |
BLOB |
xs:base64Binary |
| 不明確な数値 | FLOAT |
xs:double |
| 任意の数値 | NUMERIC |
xs:decimal |
| 任意の時間値 | DATE |
xs:dateTime |
前の表では、表4-4「データベースのデータ型のXMLのプリミティブ型へのマッピング」をまとめています。表4-4を使用して、サード・パーティのデータベースでサポートされている最も近いデータ型を検索します。たとえば、xs:stringでは、データベース・タイプ列にリストされている任意のタイプを使用します。データ型を変更する際には、対応するXMLタイプのみが関連します。VARCHAR2、VARCHAR、CLOBおよびNVARCHAR型は、すべてxs:stringにマッピングします。
アダプタ構成ウィザードを再度実行して、ウィザードの残りの設定を続行します。
表のインポート後に「アプリケーション・ナビゲータ」に「データベース・オブジェクト」→「schema name」ノードが表示されない場合は、「アプリケーション・ナビゲータ」で「project name.jprに追加」ボタンをクリックして手動で追加します。database→schemaName→schemaName.schemaファイルを選択します。
詳細は、「オフライン・データベース表の構成」を参照してください。
適切なサード・パーティJDBCドライバの使用方法の詳細は、「設計時: コマンドライン・ユーティリティの使用方法」を参照してください。
問題
現在JDeveloperでは、オブジェクト表のインポートはサポートしていません。オブジェクト表のインポートを試行すると、「次の表はオブジェクト表であるため、オフラインはサポートされません。」というメッセージが表示されます。
解決策
現在、この問題には解決策はありません。
問題
表を1つずつインポートすると、データベースに外部キー制約が存在する場合でも、リレーションシップが自動生成されません。
解決策
リレーションシップ・マッピングが自動生成されるのは、関連するすべての表が一度にインポートされる場合のみです。表をインポートする際には、複数の表の1つのグループとしてのインポートを選択できます。関連する表がある場合は、すべて同時にインポートする必要があります。
問題
主キー・フィールド名と同じ名前のリレーションシップの作成を試行すると、主キー・フィールドがアンマップされるという問題が発生します。
解決策
主キー・マッピングを手動で追加するには、次のようにします。
マッピングを追加するディスクリプタのJavaソース（Movies.javaなど）を開きます。
マッピングするフィールドに適切な新しいJava属性を追加します。たとえば、Movies表の主キーがTITLEという名前のVARCHARフィールドの場合、private String title;という新しい属性を作成します。
Javaファイルを保存します。
「アプリケーション - ナビゲータ」ペインで、「TopLinkマッピング」ノードをクリックします。「TopLinkマッピング - 構造」ペインから「識別子」を選択します。新しく作成された属性が、アンマップされた状態で「識別子」に表示されます（この例ではtitle）。
新しい属性を右クリックして、「マップ」→「フィールドへ直接」を選択します。
新しい属性をダブルクリックします。JDeveloperのメイン・ウィンドウにTopLink Mappings Editorが表示されます。データベース・フィールドをデータベースの主キー・フィールドに一致するように変更します（この例ではTITLE）。
「TopLinkマッピング - 構造」ペインで「識別子」をクリックします。「主キー」リストで、主キー・フィールドの隣にチェック・ボックスがあることを確認します。
アダプタ構成ウィザードを再度実行して、ウィザードの残りの設定を続行します。
問題
名前がJavaキーワードの列を含むデータベース表をインポートすると、次のエラー・メッセージが表示されます。
The following error occurred: null
解決策
JDeveloper BPEL Designerで次の手順を実行します。
エラーのダイアログ・ボックスで「OK」をクリックします。
アダプタ構成ウィザードで「取消」をクリックします。
「パートナ・リンクの作成」ダイアログ・ボックスで「取消」をクリックします。
失敗したインポート中に生成された.javaファイルを開きます。「アプリケーション・ナビゲータ」で、「アプリケーション」→WorkspaceName→ProcessName→「アプリケーション・ソース」→ProcessName→TableName.javaをクリックします。
エラーのあるJavaフィールドの名前を変更します。たとえば、次のような行があるとします。
private String class;
構文エラーの強調表示機能がオンになっている場合は、行に赤い下線が引かれ、Javaエラーがあることが示されます。行を次のように変更します。
private String myClass;
（または、予約されていない他の単語を使用します。）
Javaクラスからすべてのメソッドを削除します。この手順は通常データベース・アダプタによって自動的に処理されますが、インポート中にエラーが発生したため、ここでは手動で行う必要があります。メソッドを削除すると、クラスは次のようになります。
package MyBPELProcess;
public class MyDatabaseTable {
private String fieldOne;
private String fieldTwo;
...
private String fieldN;
}
手順5で名前を変更したフィールドを再マップします。Javaクラス・エディタの下部にある「マッピング」タブをクリックします。「構造」ペインが更新され、Javaクラス属性が表示されます。手順5で名前を変更したフィールド（他のフィールドとは異なり、アンマップされたことを示す単一のドットのアイコンがあります）を右クリックし、「マップ」→「フィールドへ直接」を選択します。エディタのメイン・ウィンドウで、このJavaフィールドがマッピングするデータベース・フィールドを選択します（フィールドは、名前を変更する前の属性と同じ名前です）。Javaクラス・エディタを終了します。
「ファイル」から「すべて保存」を選択します。
アダプタ構成ウィザードに戻ります。「表の選択」ページに移動すると、リストにデータベース表が含まれています。その表を選択してウィザードを続行します。表を再度インポートしないでください。
問題
BPELプロセスにフォルト処理を追加するには追加の手順が必要です。
解決策
データベース例外を捕捉する手順は、122.DBAdapterチュートリアルで説明されています。次の場所に移動してください。
Oracle_Home\bpel\samples\tutorials\122.DBAdapter\InsertWithCatch
InsertおよびInsertWithCatchディレクトリのreadme.txtファイルを両方参照してください。
InsertWithCatchチュートリアルのreadmeでは、バインディング・フォルト（すでに存在する行の挿入など）およびリモート・フォルト（ネットワークまたはデータベースが使用できない場合の行の挿入など）の2種類のフォルトを説明しています。readmeには、例外の捕捉手順、および一般的なOracleデータベースのエラー・コードのリストが提供されています。
エラー・コードの完全なリストは、『Oracle Databaseエラー・メッセージ』を参照してください。
問題
Oracle Liteの使用中に、次のようなエラーが表示される場合があります。
java.sql.SQLException: [POL-3261] there are too many transactions
これは、データベースからの最大接続数を超過したことを意味します。
Oracle BPEL Serverでは、大きな接続プール・サイズで構成されたBPELServerDataSourceというデータソースを使用します。接続がすべてBPELエンジンに割り当てられるため、データベース・アダプタで使用可能な接続が残りません。
解決策
推奨順に並んでいる次の解決策を試行してください。
解決策1
Oracle LiteではなくOracleデータベースを使用します。このエラーは、Oracle Liteでのみ発生します。
解決策2
max-connectionsおよび特にmin-connectionsの値を減らします。使用環境で効果のある値を見つけるために、実験を行う必要があります。max-connectionsおよびmin-connectionsの両方で値5から開始し、パフォーマンスが適切かどうかを確認します。本番データベースでは、より大きな値を使用する必要があります。
max-connectionsおよびmin-connectionsに値を設定するには次のようにします。
次の場所にあるdata-sources.xmlを開きます。
Oracle_Home\bpel\appserver\oc4j\j2ee\home\config
Oracle Liteのデータソースのセクションで、max-connectionsおよびmin-connectionsを設定します。
<!-- Use these datasources to connect to Oracle Lite -->
<data-source class="com.evermind.sql.DriverManagerDataSource"
name="BPELServerDataSource"
location="loc/BPELServerDataSource"
xa-location="BPELServerDataSource"
ejb-location="jdbc/BPELServerDataSource"
connection-driver="oracle.lite.poljdbc.POLJDBCDriver"
username="system"
password="any"
max-connections="5"
min-connections="5"
connection-retry-interval="30"
max-connect-attempts="10"
url="jdbc:polite4@127.0.0.1:100:orabpel"/>
解決策3
Oracle Liteにアクセスするアプリケーションの数を減らします。複数の同時BPELプロセスは1つのアプリケーションですが、すべての接続を使用する可能性があります。
oc4j-ra.xmlファイルで、platformClassNameに適切な値が使用されていることを確認します。 様々なデータベース値の詳細は、表4-17「データベース・プラットフォーム名」も参照してください。使用しているデータベースが表にリストされている場合は、表示されている値を使用します。たとえば、DB2データベースを使用している場合は、DatabasePlatformではなくDB2Platformを使用します。
ウィザードでのUpdate Only操作では、子レコードに対する挿入または削除が実行されることがあります。
Insert OnlyおよびUpdate Onlyは、子レコードの再帰的な挿入/更新という点で異なります。 Insert Onlyでは、トップレベルの表および関連するすべての子レコードが挿入されます。 トップレベルのレコードおよびすべての関連レコードは新規であるものと想定されます。 Update Onlyは、トップレベル・レコードの更新のみを実行することが保証されています。 その後、子レコードを挿入/更新するか、削除するかがチェックされます。 想定されるのは、トップレベル要素の存在のみです。 Merge操作では、トップレベル・レコードや子レコードの存在は想定されません。
次の項では、ストアド・プロシージャに対するデータベース・アダプタの使用中に予想される問題と解決策を説明します。
問題
選択したAPIでサポートされていない、または定義されていないパラメータ・タイプを使用するのは、一般的な問題です。次のプロシージャを例にします。
PROCEDURE PROC (O OBJ) AS BEGIN … END;
この例では、OBJは定義されていないタイプを表します。
ウィザードの最後のページで「終了」をクリックすると、XSDの生成が試行され、次のエラー・メッセージが生成されます。
このメッセージは、タイプOBJのOという名前のパラメータが定義されていないか、アクセス不可能であることを意味します。
ユーザー定義タイプのパラメータを含むAPIのXSDを生成するには、それらのタイプをまずデータベースで定義し、関連するサービス接続を介してアクセス可能な状態にする必要があります。このエラーは、データベースでそのようなタイプが作成（実装）されていない場合や、データベースがアクセス不可能な場合にも発生します。
解決策
APIの選択時に、サポートされているデータ型のみがパラメータのタイプとして使用されていることを確認します。ユーザー定義タイプの場合には、タイプがデータベースに定義されており、XSDの生成が試行されたときにデータベースがアクセス可能であることを確認します。
問題
選択したAPIで1つ以上のパラメータのタイプが異なるスキーマに属するユーザー定義タイプの場合、設計時の問題が発生します。
次のようにして、SCHEMA2でタイプOBJが作成されたとします。
CREATE TYPE OBJ AS OBJECT (X NUMBER, Y VARCHAR2 (10));
また、次のようにして、タイプがSCHEMA2.OBJのパラメータを持つSCHEMA1でプロシージャが作成されたとします。
CREATE PROCEDURE PROC (O SCHEMA2.OBJ) AS BEGIN … END;
プロシージャPROCにXSDの作成を試行すると、次のエラーが表示されます。
PLS-00201: identifier SCHEMA1.OBJ must be declared
解決策
次のように、SCHEMA2がSCHEMA1からタイプOBJを参照できるように、SCHEMA1はSCHEMA2に権限を付与する必要があります。
SQL> GRANT EXECUTE ON OBJ TO SCHEMA2;
詳細は、「別のスキーマのタイプの参照」を参照してください。
問題
インスタンスXMLによって提供された仮パラメータと、ストアド・プロシージャのシグネチャで定義されている実際のパラメータの不一致は、一般的な実行時の問題です。図A-1に示すように、このタイプのエラーが発生すると、ストアド・プロシージャの実行を試行するinvokeアクティビティが失敗します。
bindingFaultには、code、summaryおよびdetailの3つの部分があります。これらの部分の情報は、ストアド・プロシージャの実行が試行される際に、JDBCによってスローされるjava.sql.SQLExceptionから導出されます。図A-1に表示されているようにcodeは6550というORAエラー番号で、summaryとdetailの部分はORA-06550です。summaryには、SQLExceptionからのメッセージが続くアダプタ固有のエラー・メッセージや、問題の推奨される解決策が含まれます。detailには、SQLExceptionからのメッセージのみが含まれます。
図A-1に示すように、APIに引数の数または型が正しくないというメッセージが渡されるため、ADDEMPLOYEESストアド・プロシージャは実行に失敗します。この問題の予想される原因は次のとおりです。
必要なパラメータのいずれかに対応する要素が、インスタンスXMLに指定されていなかった。
解決策: 必要な要素を追加して問題を解決します。
XSDで指定された数を超える要素がインスタンスXMLに含まれていた。
解決策: XMLから余分な要素を削除します。
XSDでストアド・プロシージャのシグネチャが適切に説明されていない。たとえば、パラメータのタイプの1つが変更され、XSDがその変更を反映するために再生成されなかった場合、要素のdb:typeと変更されたパラメータの新しいタイプでタイプの不一致が生じます。
解決策: bindingFaultのsummaryの部分に示されているように、パラメータがAPIのシグネチャに一致することを確認します。
問題
bindingFaultは、実行が試行された際に、そのストアド・プロシージャがデータベースに定義されていない場合にも発生します。この例では、ADDEMPLOYEES APIが起動されますが、定義されていないため実行に失敗します。図A-2に示すように、invokeアクティビティが失敗します。
PL/SQLでは、識別子ADDEMPLOYEESを宣言する必要があるというメッセージが表示されています。これは、データベースにストアド・プロシージャが定義されていない可能性を示しています。これは、プロセスがデプロイされてからプロシージャが起動されるまでの間に、プロシージャが削除された場合などに発生します。また、ストアド・プロシージャの実行に必要な権限が付与されていなかった場合にも発生します。
解決策
summaryで示されているように、データベースでAPIが定義されていることと、そのプロシージャの実行に適切な権限が付与されていることを確認してください。
インスタンスXMLが選択されたAPI用に生成されたXSDと一致しない場合は、複数の実行時エラーが発生する可能性があります。APIの実行と一致するパートナ・リンクでXML検証を有効化できます。太字で示されているように、プロセスのbpel.xmlファイルにあるBPELスーツケースのpartnerLinkBindingを編集します。
<partnerLinkBinding name="PROC">
<property name="wsdlLocation">Proc.wsdl</property>
<property name="validateXML">true</property>
</partnerLinkBinding>
validateXMLプロパティを追加してtrueに設定すると、APIを実行するパートナ・リンクに関連付けられたサービスに渡されるすべてのインスタンスXMLのXML検証が有効になります。
XML検証は、Oracle BPEL Controlでもグローバルに有効化できます。「BPELドメインの管理」をクリックして、validateXMLプロパティを検索します。値をtrueに設定すると、すべてのXMLが検証されます。XML検証をオンにすると、（アダプタ実行時ではなく）インスタンスXMLに関連する問題の捕捉と回避に役立ちます。
次の項では、Oracle Application Server Adapter for Files/FTP（ファイルおよびFTPアダプタ）を使用中に予想される問題と解決策を説明します。
アダプタ構成ウィザードを後から再度実行し、前に指定された論理名を別の名前に変更すると、bpel.xmlファイルに新旧両方の論理名が表示されます。古い論理名を削除するには、bpel.xmlファイルを手動で編集する必要があります。
ネイティブ・フォーマット・ビルダー・ウィザードでは、空白のあるネイティブ・スキーマ・ファイル名の作成は制限されていませんが、ファイル名には空白を使用しないことをお薦めします。
この項では、一般的なユーザー・エラーを説明します。
「アダプタ構成ウィザード - メッセージ」ウィンドウ（図2-9）で、「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」チェック・ボックスを選択できます。Opaqueは一方向のみには選択できません。Opaqueは、インバウンドおよびアウトバウンドの両方向で選択する必要があります。
メッセージは、インバウンドとアウトバウンドのいずれであるかによって意味が異なります。たとえば、次のような選択をするとします。
インバウンド・ファイルにレコードが2つある場合は、2つのメッセージに分割（デバッチ）されます。ただし、3はアウトバウンド方向で指定されたため、ファイルは作成されません。これは、使用可能なアウトバウンド・メッセージが3つあるわけではないためです。これらのオプションを選択する前に、インバウンドおよびアウトバウンド・メッセージの意味を理解していることを確認してください。
ファイル・アダプタまたはFTPアダプタで個々にファイルの読取りや取得ができない場合は、正規表現（regex）を使用したファイル名の一致を選択したが、名前が正しく指定されていないことが原因である可能性があります（図2-7）。 詳細は、表2-3を参照してください。
そのまま送信する必要のあるトランスレーション不要のコンテンツ（JPGまたはGIF画像など）がある場合があります。ファイルはBase64エンコーディングで渡されます。これは、不透明（Opaque）なコンテンツと呼ばれます。 これを実行するには、「アダプタ構成ウィザード - メッセージ」ウィンドウ（図2-9）で、「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」チェック・ボックスを選択します。このチェック・ボックスを選択すると、トランスレーション用のXSDファイルを指定する必要がありません。
ファイルの個別の読取りまたは取得には、ファイル・アダプタまたはFTPアダプタ用のインバウンド・ディレクトリが存在する必要があります。
FTPアダプタがリモート・ホストに接続できない場合は、Oracle_Home\bpel\system\appserver\oc4j\j2ee\home\application-deployments\default\FtpAdapter\oc4j-ra.xmlデプロイメント・ディスクリプタ・ファイルをアダプタ・インスタンスJNDI名およびFTPサーバー接続情報用に構成済であることを確認してください。 手順は、「FTPアダプタのGet Fileの説明」を参照してください。
Oracle_Home\bpel\system\appserver\oc4j\j2ee\home\application-deployments\default\FtpA
dapter\oc4j-ra.xml
po.txtなどの完全に静的な名前は、アウトバウンド・ファイルには使用できません。そのかわり、発信ファイル名は静的部分と動的部分で構成されている必要があります。これは発信ファイル名の一意性を保つためで、ファイルが意図せず上書きされるのを防ぎます。 正しいアウトバウンド・ファイル名の作成手順は、「アウトバウンド・ファイル・ネーミング規則の指定」を参照してください。
両方向でアダプタ構成ウィザードの実行が完了すると、「アプリケーション・ナビゲータ」に2つのヘッダー・ファイルが作成されます。
typeAdapterInboundHeader.wsdl
ヘッダー操作を定義するメッセージおよびパーツのデータとともに、処理されるファイルの名前およびそのディレクトリ・パスなどの情報を提供します。
typeAdapterOutboundHeader.wsdl
アウトバウンド・ファイル名の情報を提供します。
ここで、typeはftpまたはfileです。
これらのヘッダー・ファイルにプロパティを定義できます。たとえば、typeAdapterInboundHeader.wsdlおよびtypeAdapterOutboundHeader.wsdlファイルのそれぞれの、InboundHeader_msgとOutboundHeader_msgメッセージ名を使用して、動的なインバウンドおよびアウトバウンド・ファイル名を指定できます。
BPELプロセス・ファイルに出現するヘッダー変数も設定できます。ヘッダー変数は特定のシナリオで役に立ちます。たとえば、ファイルの伝播シナリオで、ファイル・アダプタを使用して、ファイルがあるファイルシステムから別のファイルシステムへ移動されるとします。この場合、2つのシステム全体でファイル名を保持する必要があります。どちらの方向でもファイル・ヘッダーを使用し、アウトバウンド・ファイル・ヘッダーにファイル名を設定して、インバウンド・ファイル・ヘッダーでファイル名を使用します。
詳細は、invoke、receive、reply、およびpickアクティビティのOnMessageブランチの「アダプタ」タブで使用可能なオンライン・ヘルプを参照してください。
「アダプタ構成ウィザード - ファイル変更時間」ウィンドウ（図2-24）では、FTPサーバーでのファイル変更時間の取得方法の選択を要求されます。
この情報を取得するには、次の手順を実行する必要があります。
コマンドmdtmまたはls -al（オペレーティング・システムでサポートされている方のコマンド）を実行して、FTPサーバーでサポートされている変更時間の形式を確認します。
システム時間（Oracle BPEL Serverが稼働している時間）およびファイル変更時間の時差を確認します。FTPサーバーでmdtmまたはls -alを実行してファイル変更時間を取得します。
bpel.xmlにプロパティとして手動で時差を追加します。
<activationAgents> <activationAgent ...> <property name="timestampOffset">2592000000</property>
FTPサーバーでmdtmまたはls -alコマンドを実行し、「サブストリング開始索引」フィールドおよび「終了索引」フィールドの値を指定します。
次の項では、Oracle Application Server Adapter for Advanced Queuing（AQアダプタ）を使用中に予想される問題と解決策を説明します。
次の項では、AQアダプタを使用中のインバウンド・エラーに関して予想される問題と解決策を説明します。
サンプル・エラー
<timestamp> <WARN> <default.collaxa.cube.activation> <AdapterFramework::Inbound>
JNDI lookup of 'eis/AQ/aqSample2' failed due to: eis/AQ/aqSample2 not found
<timestamp> <ERROR> <default.collaxa.cube.activation> <AdapterFramework::Inbound>
Error while performing endpoint Activation: ORABPEL-12510
Unable to locate the JCA Resource Adapter via WSDL port element jca:address.
The Adapter Framework is unable to startup the Resource Adapter specified in the
WSDL jca:address element: {http://xmlns.oracle.com/pcbpel/wsdl/jca/}address:
location='eis/AQ/aqSample2'
問題
リソース・アダプタのRARファイルが、OC4Jアプリケーション・サーバーに正常にデプロイされていないか、$J2EE_HOME/application-deployments/default/deployed-adapter-name /oc4j-ra.xmlのlocation属性がeis/AQ/aqSample2に設定されていない可能性があります。後者が理由の場合は、oc4j-ra.xmlに新しくconnector-factoryエントリ（接続）を追加する必要があります。これを修正してから、BPELまたはOC4Jアプリケーション・サーバーを再起動してください。
解決策
ファイル$J2EE_HOME/application-deployments/default/aqAdapter/oc4j-ra.xmlを検索します。
このファイルは、Oracle BPEL Process Managerの最初の起動時に実行されるアダプタのデプロイ時に作成されます。アダプタがデプロイされていない場合には、次のコマンドを使用してアダプタをデプロイし、手順2に従います。
java -jar $J2EE_HOME/admin.jar ormi://localhost admin welcome -deployconnector -file <path to AQAdapter.rar> -name AqAdapter>
$J2EE_HOME/application-deployments/default/aqAdapter /oc4j-ra.xmlが存在する場合には、oc4j-ra.xmlにJNDIロケーションが定義されていることを確認します。
次に例を示します。
<connector-factory location="eis/AQ/aqSample2" connector-name="AQ Adapter">
<config-property name="connectionString"
value="jdbc:oracle:thin:@myhost:1521:appdb2"/>
<config-property name="userName" value="scott"/>
<config-property name="password" value="tiger"/>
</connector-factory>
サンプル・エラー
<timestamp> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> DBConnection_connect: database error while try to connect to jdbc:oracle:thin:@localhost:1521:ORCL : Io exception: The Network Adapter could not establish the connection
解決策
connectionStringが正しい場合には、データベースおよびリスナーが稼働していることを確認し、プロセスを再デプロイします。
connectionStringが正しくない場合には、次のようにします。
$J2EE_HOME\application-deployments\default\AqAdapter\oc4j-ra.xmlのconnectionStringを変更します。
Oracle BPEL Process Managerを再起動します。
サンプル・エラー
<timestamp> <ERROR> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Error while performing endpoint Activation: ORABPEL-11929 SQL error while creating managed (database) connection. SQL error while creating managed (database) connection: Error while trying to connect to database. Error while trying to connect to database using connect string "jdbc:oracle:thin:@localhost:1521:appdb2 - java.sql.SQLException: ORA-01017: invalid username/password; logon denied
解決策
$J2EE_HOME\application-deployments\default\AqAdapter\oc4j-ra.xmlのユーザー名とパスワードが正しいことを確認します。
Oracle BPEL Process Managerを再起動します。
サンプル・エラー
<timestamp> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> oracle.AQ.AQException: JMS-190: Queue SCOTT.AQ_SUPPORTED_ADT_IN not found at oracle.AQ.AQUtil.throwAQEx(AQUtil.java:196) at oracle.AQ.AQOracleSession.getQueue(AQOracleSession.java:720) at oracle.tip.adapter.aq.database.Queue.connect(Queue.java:102) at oracle.tip.adapter.aq.database.MessageReader.init(MessageReader.java:575)
解決策
キューを作成し、プロセスを再デプロイします。このプロセスがサンプルからデプロイされる場合、すべてのキュー作成スクリプトは各プロジェクトの下のsql\create_queues.sqlに配置されています。
サンプル・エラー
2005-04-20 16:10:52,695> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> oracle.AQ.AQOracleSQLException: ORA-06550: line 1, column 7: PLS-00201: identifier 'DBMS_AQIN' must be declared ORA-06550: line 1, column 7: PL/SQL: Statement ignored at oracle.AQ.AQOracleQueue.dequeue(AQOracleQueue.java:1795) at oracle.AQ.AQOracleQueue.dequeue(AQOracleQueue.java:1307) at oracle.tip.adapter.aq.database.MessageReader.readMessage(MessageReader.java:399) at oracle.tip.adapter.aq.inbound.AQActivationSpecDequeuer.run(AQActivationSpecDequeue r.java:163) at oracle.tip.adapter.fw.jca.work.WorkerJob.go(WorkerJob.java:51) at oracle.tip.adapter.fw.common.ThreadPool.run(ThreadPool.java:267) at java.lang.Thread.run(Thread.java:534)
解決策
sys as sysdbaを使用してデータベースにログインし、GRANT EXECUTE ON SYS.DBMS_AQIN to <username>;を実行します。このエラーは接続に成功した後に発生するため、デプロイは不要です。エラーがなくなるまで、またはプロセスがアンデプロイされるまでは、アダプタにより自動的に再接続されます。
サンプル・エラー
<timestamp> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> MessageReader_readMessage: Received TranslationException <timestamp> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> ORABPEL-11211 DOM Parsing Exception in translator. DOM parsing exception in inbound XSD translator while parsing InputStream. Check the error stack and fix the cause of the error. Contact oracle support if error is not fixable. at oracle.tip.pc.services.translation.xlators.xsd.XSDTranslator.translateFromNative(X SDTranslator.java:131)
解決策
拒否されたメッセージを検索し、トランスレーションに失敗した理由を調査します。たとえば、メッセージがXMLでない場合、XMLルート要素が不適切な場合、またはメッセージが空白の場合があります。このプロセスに拒否ハンドラが定義されている場合は、その拒否ハンドラ内のメッセージを検索します。それ以外の場合は、次の場所にある、デフォルトの拒否ハンドラ内のメッセージを検索します。
Oracle_Home\bpel\domains\default\archive\jca
\AQMessageRejectionHandler\rejectedMessages
ユーザーによる拒否ハンドラの定義方法の例は、次の場所を検索してください。
ORACLE_HOME\bpel\samples\tutorials\124.AQAdapter\AQMessageRejectionHan
dler
サンプル・エラー
<timestamp> <INFO> <default.collaxa.cube.activation> <AQ Adapter::Inbound>
Subscriber PriorityOneDequeuer already exists in the database. If the subscriber
does not contain the rule that you want, please undeploy the business process,
drop the subscriber with the following sql*plus command, and redeploy. DECLARE
subscriber sys.aq$_agent;
BEGIN
subscriber := sys.aq$_agent('<subscriber_name>', NULL, NULL);
DBMS_AQADM.REMOVE_SUBSCRIBER(
queue_name => '<queue_name>',
subscriber => subscriber); END;
解決策
サブスクライバが、ユーザーが予想するルールを使用して生成されている場合には問題ではありません。アダプタではルールベースの新しいサブスクライバは作成できますが、既存のサブスクライバは変更できません。そのため、MessageSelectorRuleにNULL以外の値を使用して初めてアダプタをデプロイする際にコンシューマが存在しない場合には、サブスクライバとしてのコンシューマとルールとしてのMessageSelectorRuleを使用してサブスクライバが作成されます。このメッセージは、後続の再デプロイまたはOracle BPEL Process Managerの再起動時に表示されます。
次のSQLコマンドを入力して、サブスクライバに必要なルールかどうかを確認できます。
SQL> select name, rule, queue from AQ$RuleBased_Raw_In_R; NAME ------------------------------ RULE -------------------------------------------------------------------------------- QUEUE ------------------------------ PRIORITYONEDEQUEUERpriority = 1 RULEBASED_RAW_IN
一般的な注意事項として、アウトバウンド・スレッドは発信されるメッセージがある場合にのみアクティブ化されるため、アウトバウンド・ディレクトリの問題はデプロイ時には捕捉されません。
サンプル・エラー
Adapter Framework unable to create outbound JCA connection.
file:/C:/050420/bpel/domains/default/tmp/.bpel_File2AQBLOB_
1.0.jar/EnqueueBlobPayload.wsdl [ Enqueue_ptt::Enqueue(opaque) ] - : The Adapter
Framework was unable to establish an outbound JCA connection due to the following
issue: ORABPEL-12510
Unable to locate the JCA Resource Adapter via WSDL port element jca:address.
The Adapter Framework is unable to startup the Resource Adapter specified in the
WSDL jca:address element: {http://xmlns.oracle.com/pcbpel/wsdl/jca/}address:
location='eis/AQ/aqSample3'
リソース・アダプタのRARファイルが、OC4Jアプリケーション・サーバーに正常にデプロイされていないか、$J2EE_HOME/application-deployments/default/deployed-adapter-name/oc4j-ra.xmlのlocation属性がeis/AQ/aqSample3に設定されていない可能性があります。後者が理由の場合は、oc4j-ra.xmlに新しくconnector-factoryエントリ（接続）を追加する必要があります。これを修正してから、BPELまたはOC4Jアプリケーション・サーバーを再起動してください。
解決策
「インバウンド・エラー」で説明されているように、インバウンドの項にある同じ問題の解決策を参照してください。
2005-04-20 18:41:40,570> <ERROR> <default.collaxa.cube.ws> <AdapterFramework::Outbound> file:/C:/050420/bpel/domains/default/tmp/.bpel_File2AQBLOB_ 1.0.jar/EnqueueBlobPayload.wsdl [ Enqueue_ptt::Enqueue(opaque) ] - Could not invoke operation 'Enqueue' against the 'AQ Adapter' due to: ORABPEL-12511 Adapter Framework unable to create outbound JCA connection. file:/C:/050420/bpel/domains/default/tmp/.bpel_File2AQBLOB_ 1.0.jar/EnqueueBlobPayload.wsdl [ Enqueue_ptt::Enqueue(opaque) ] - : The Adapter Framework was unable to establish an outbound JCA connection due to the following issue: ORABPEL-11929 SQL error while creating managed (database) connection. SQL error while creating managed (database) connection: Error while trying to connect to database. Error while trying to connect to database using connect string "jdbc:oracle:thin:@localhost:1521:appdb - java.sql.SQLException: Io exception: The Network Adapter could not establish the connection"
解決策
connectionStringが正しくない場合には、次のようにします。
$J2EE_HOME\application-deployments\default\AqAdapter\oc4j-ra.xmlのconnectionStringを変更します。
Oracle BPEL Process Managerを再起動します。
connectionStringが正しい場合には、データベースおよびリスナーが稼働していることを確認します。アウトバウンドの再試行を有効にしている場合、データベースとリスナーの稼働中にメッセージの再試行が自動的に行われます。アウトバウンドの再試行を構成するには、bpel.xmlのパートナ・リンクのretryMaxCountプロパティおよびretryIntervalプロパティを設定します。たとえば、次の構成は、60秒間隔で再試行が10回行われることを意味します。
<partnerLinkBinding name="EnqueueBLOBPayload">
<property name="wsdlLocation">EnqueueBlobPayload.wsdl</property>
<property name="retryMaxCount">10</property>
<property name="retryInterval">60</property>
</partnerLinkBinding>
<timestamp> <ERROR> <default.collaxa.cube.ws> <AQ Adapter::Outbound>
oracle.AQ.AQException: JMS-190: Queue SCOTT.BLOBPAYLOAD_QUEUE not found
at oracle.AQ.AQUtil.throwAQEx(AQUtil.java:196)
at oracle.AQ.AQOracleSession.getQueue(AQOracleSession.java:720)
at oracle.tip.adapter.aq.database.Queue.connect(Queue.java:102)
at oracle.tip.adapter.aq.database.MessageWriter.init(MessageWriter.java:231)
解決策
解決策は、インバウンドでキューが見つからない問題と同じです。キューを作成し、プロセスを再デプロイします。このプロセスがサンプルからデプロイされる場合、すべてのキュー作成スクリプトは各プロジェクトの下のsql\create_queues.sqlに配置されています。
サンプル・エラー
file:/C:/050420/bpel/domains/default/tmp/.bpel_File2AQBLOB_ 1.0.jar/EnqueueBlobPayload.wsdl [ Enqueue_ptt::Enqueue(opaque) ] - : The Adapter Framework was unable to establish an outbound JCA connection due to the following issue: ORABPEL-11929 SQL error while creating managed (database) connection. SQL error while creating managed (database) connection: Error while trying to connect to database. Error while trying to connect to database using connect string "jdbc:oracle:thin:@localhost:1521:appdb2 - java.sql.SQLException: ORA-01017: invalid username/password; logon denied.
解決策
$J2EE_HOME\application-deployments\default\AqAdapter\oc4j-ra.xmlのユーザー名とパスワードが正しいことを確認します。
Oracle BPEL Process Managerを再起動します。
サンプル・エラー
<timestamp> <ERROR> <default.collaxa.cube.ws> <AQ Adapter::Outbound>
oracle.AQ.AQOracleSQLException: ORA-06550: line 1, column 7:
PLS-00201: identifier 'DBMS_AQIN' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
at oracle.AQ.AQOracleQueue.enqueue(AQOracleQueue.java:1267)
解決策
sys as sysdbaを使用してデータベースにログインし、GRANT EXECUTE ON SYS.DBMS_AQIN to <username>;を実行します。このパートナ・リンクの構成を再試行済の場合にも、自動的に再試行が行われます。
サンプル・エラー
<timestamp> <ERROR> <default.collaxa.cube.ws> <AQ Adapter::Outbound> ORABPEL-11101 Translation Failure. Translation to native failed. Invalid text 'blahblah' in element: 'Root-Element'. Check the error stack and fix the cause of the error. Contact oracle support if error is not fixable. at oracle.tip.pc.services.translation.xlators.nxsd.NXSDTranslatorImpl.translateToNati ve(NXSDTranslatorImpl.java:502) at oracle.tip.adapter.aq.database.MessageWriter.translateToNative(MessageWriter.java: 1102) at oracle.tip.adapter.aq.database.MessageWriter.doEnqueue(MessageWriter.java:494)
解決策
Oracle BPEL Controlで、「インスタンス」タブをクリックします。
失敗したインスタンスをクリックして、「デバッグ」を選択します。
失敗したinvokeアクティビティに渡された変数を検索します。この変数はスキーマ定義に一致します。「デバッグ」ウィンドウで元に戻り、理由を調査します。
AQインバウンドからAQアウトバウンドへのエンドツーエンドのシナリオです。インバウンド・キューの優先度は、どのようにしてアウトバウンド・キューへコピーすればよいでしょうか。
解決策: インバウンド・ヘッダーとアウトバウンド・ヘッダーの両方を作成し、assignアクティビティを使用して優先度をコピーします。
インバウンド・ヘッダーを作成するには、次のようにします。
AQインバウンドのパートナ・リンクにリンクされているreceiveアクティビティをクリックします。
「アダプタ」タブを選択し、「ヘッダー変数」フィールドの右にある懐中電灯アイコンをクリックします。
「変数」を右クリックし、「変数の作成」を選択します。
inbound_headerなどの名前を入力します。
「メッセージ・タイプ」および懐中電灯アイコンをクリックします。
payloadHeaderが不要な場合は、次のようにします（ほとんどの場合）。
「タイプの選択」ウィンドウで、「タイプ・エクスプローラ」→「メッセージ・タイプ」→「パートナ・リンク」→inbound_partnerlink_name→inbound_service.wsdl→「インポートしたWSDL」→aqAdapterInboundHeader.wsdl→「メッセージ・タイプ」→Headerをクリックします。手順8に進みます。
payloadHeaderが必要な場合には、次のようにします（service_name.wsdlのJCA操作セクションがPayloadHeaderRequired="true"の場合のみ）。
「タイプの選択」ウィンドウで、「タイプ・エクスプローラ」→「メッセージ・タイプ」→「パートナ・リンク」→inbound_partnerlink_name→「メッセージ・タイプ」→Header_msgをクリックします。
「OK」をクリックして、「タイプの選択」ウィンドウを終了します。
変数が強調表示されている間は、「OK」をクリックしてその変数を選択できます。
その変数がヘッダー変数として表示されます。
「OK」をクリックして、receiveアクティビティを終了します。
アウトバウンド・ヘッダーを作成するには、次のようにします。
AQアウトバウンドのパートナ・リンクにリンクされているinvokeアクティビティをクリックします。
「アダプタ」タブを選択し、「ヘッダー変数」フィールドの右にある懐中電灯アイコンをクリックします。
「変数」を右クリックし、「変数の作成」を選択します。
outbound_headerなどの名前を入力します。
「メッセージ・タイプ」および懐中電灯アイコンをクリックします。
payloadHeaderが不要な場合は、次のようにします（ほとんどの場合）。
「タイプの選択」ウィンドウで、「タイプ・エクスプローラ」→「メッセージ・タイプ」→「パートナ・リンク」→outbound_partnerlink_name→outbound_service.wsdl→「インポートしたWSDL」→aqAdapterOutboundHeader.wsdl→「メッセージ・タイプ」→Headerをクリックします。手順8に進みます。
payloadHeaderが必要な場合には、次のようにします（service_name.wsdlのJCA操作セクションがPayloadHeaderRequired="true"の場合のみ）。
「タイプの選択」ウィンドウで、「タイプ・エクスプローラ」→「メッセージ・タイプ」→「パートナ・リンク」→outbound_partnerlink_name→「メッセージ・タイプ」→Header_msgをクリックします。
「OK」をクリックして、「タイプの選択」ウィンドウを終了します。
変数が強調表示されている間は、「OK」をクリックしてその変数を選択できます。
その変数がヘッダー変数として表示されます。「OK」をクリックして、receiveアクティビティを終了します。
assignアクティビティでは、次のようにします。
「コピー・ルール」タブをクリックして「作成」を選択します。
「From」セクションで、インバウンド・ヘッダー変数の「優先度」にドリルダウンします。
「To」セクションで、アウトバウンド・ヘッダー変数の「優先度」にドリルダウンします。
「OK」をクリックして「コピー・ルールの作成」ウィンドウを終了します。
「OK」をクリックして「Assign」ウィンドウを終了します。
アダプタのヘッダー変数を削除するにはどうすればよいでしょうか。
アダプタ用のヘッダー変数を次のように作成した場合、その変数は同じ「receive」ウィンドウでは削除できません。 解決策は、BPELソース・コード内でヘッダー変数を削除することです。
BPELプロジェクトを作成します。
「receive」アクティビティをダブルクリックします。
「アダプタ」タブをクリックし、アダプタのヘッダー変数を定義します。
再度ウィザードを実行して、アダプタWSDLを再定義しました。なぜservice_name.wsdlが変更されないのでしょうか。
解決策:
再定義の内容は有効ですが、JDeveloper BPEL Designerでファイル・プロパティがリフレッシュされていません。service_name.wsdlファイルを閉じて、再度開いてください。
ウィザードを使用して、アダプタ・サービスWSDLを再定義しました。デプロイ時に次のエラーが表示されました。
Process "AQSupportedADTTypes" (revision "1.0") compilation failed.<timestamp> <ERROR> <default.collaxa.cube.engine.deployment>
<CubeProcessLoader::create> BPEL validation failed.
BPEL source validation failed, the errors are:
[Error ORABPEL-10007]: unresolved messageType
[Description]: in line 16 of
"C:\050420\bpel\domains\default\tmp\.bpel_AQSupportedADTTypes_
1.0.jar\AQSupportedADTTypes.bpel", WSDL messageType
"{http://xmlns.oracle.com/pcbpel/adapter/aq/Enqueue/}Header_msg" of variable
"out_header" is not defined in any of the WSDL files.
[Potential fix]: Make sure the WSDL messageType
"{http://xmlns.oracle.com/pcbpel/adapter/aq/Enqueue/}Header_msg" is defined in
one of the WSDLs referenced by the deployment descriptor.
解決策:
アダプタ・サービスWSDLを再定義する際には、ヘッダー変数の再定義も必要です。ヘッダー変数を作成すると、ヘッダーを定義するJCAバインディング・セクションにinput要素が追加されます。
次に例を示します。
<input> <jca:header message="tns:Header_msg" part="Header"/> </input>
アダプタ・サービスが再定義されると、古いWSDLファイルが上書きされます。古いヘッダー変数を削除して、再度作成してください。
サンプル・エラー
<timestamp> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> MessageReader_readMessage: Received TranslationException <timestamp> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> ORABPEL-11211 DOM Parsing Exception in translator. DOM parsing exception in inbound XSD translator while parsing InputStream. Check the error stack and fix the cause of the error. Contact oracle support if error is not fixable. at oracle.tip.pc.services.translation.xlators.xsd.XSDTranslator.translateFromNative(X SDTranslator.java:131)
解決策:
拒否されたメッセージを検索し、トランスレーションに失敗した理由を調査します。メッセージがXMLでない場合、XMLルート要素が不適切な場合、またはメッセージが空白の場合があります。このプロセスに拒否ハンドラが定義されている場合は、その拒否ハンドラ内のメッセージを検索します。それ以外の場合は、次の場所にある、デフォルトの拒否ハンドラ内のメッセージを検索します。
ORACLE_HOME\bpel\domains\default\archive\jca\AQMessageRejectionHandler\rejectedMessages
ユーザーによる拒否ハンドラの定義方法の例は、次の場所を検索してください。
ORACLE_HOME\bpel\samples\tutorials\124.AQAdapter\AQMessageRejectionHandler
新しいアダプタ*.RARファイルがあります。どのようにアダプタを再デプロイすればよいでしょうか。
エンドポイントの情報を保持するために、$J2EE_HOME\application-deployments\default\AqAdapter \oc4j-ra.xmlのコピーを保存します。
次のコマンドを入力してアダプタを再デプロイします。
java -jar $JE22_HOME\admin.jar ormi://localhost admin welcome -undeployconnector -name AqAdapter
次のコマンドを入力して新しい.rarファイルをデプロイします。
java -jar $J2EE_HOME/admin.jar ormi://localhost admin welcome -deployconnector -file <rarfile> -name AqAdapter
$J2EE_HOME\application-deployments\default\AqAdapter \oc4j-ra.xmlを変更して、エンドポイントを追加します。
Oracle BPEL Process Managerを再起動します。ビジネス・プロセスを再デプロイする必要はありません。
MessageRuleSelectorの使用時に既存のサブスクライバがあります。
<timestamp> <INFO> <default.collaxa.cube.activation> <AQ Adapter::Inbound>
Subscriber PriorityOneDequeuer already exists in the database. If the
subscriber does not contain the rule that you want, please undeploy the
business process, drop the subscriber with the following sql*plus command,
and redeploy.
DECLARE
subscriber sys.aq$_agent;
BEGIN
subscriber := sys.aq$_agent('<subscriber_name>', NULL, NULL);
DBMS_AQADM.REMOVE_SUBSCRIBER(
queue_name => '<queue_name>',
subscriber => subscriber);
END;
解決策:
サブスクライバが、ユーザーが予想するルールを使用して生成されている場合には問題ではありません。アダプタではルールベースの新しいサブスクライバは作成できますが、既存のサブスクライバは変更できません。そのため、MessageSelectorRuleにNULL以外の値を使用して初めてアダプタをデプロイする際にコンシューマが存在しない場合には、サブスクライバとしてのコンシューマとルールとしてのMessageSelectorRuleを使用してサブスクライバが作成されます。このメッセージは、後続の再デプロイまたはOracle BPEL Process Managerの再起動時に表示されます。
select name, rule, queue from AQ$ QUEUE_TABLE_NAME_R;というSQLコマンドを入力して、サブスクライバに必要なルールかどうかを確認できます。
SQL> select name, rule, queue from AQ$RuleBased_Raw_In_R; NAME ------------------------------ RULE -------------------------------------------------------------------------------- QUEUE ------------------------------ PRIORITYONEDEQUEUER priority = 1 RULEBASED_RAW_IN
AQ Java APIで必要なDBMS_AQIN権限がありません。
2005-04-20 16:10:52,695> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> oracle.AQ.AQOracleSQLException: ORA-06550: line 1, column 7: PLS-00201: identifier 'DBMS_AQIN' must be declared ORA-06550: line 1, column 7: PL/SQL: Statement ignored at oracle.AQ.AQOracleQueue.dequeue(AQOracleQueue.java:1795) at oracle.AQ.AQOracleQueue.dequeue(AQOracleQueue.java:1307) at oracle.tip.adapter.aq.database.MessageReader.readMessage(MessageReader.java:399) at oracle.tip.adapter.aq.inbound.AQActivationSpecDequeuer.run(AQActivationSpecDeq ueuer.java:163) at oracle.tip.adapter.fw.jca.work.WorkerJob.go(WorkerJob.java:51) @ at oracle.tip.adapter.fw.common.ThreadPool.run(ThreadPool.java:267) at java.lang.Thread.run(Thread.java:534)
解決策:
sys as sysdbaを使用してデータベースにログインし、'GRANT EXECUTE ON SYS.DBMS_AQIN to username;'を実行します。このエラーは接続に成功した後に発生するため、デプロイは不要です。エラーがなくなるまで、またはプロセスがアンデプロイされるまでは、アダプタによる再接続が自動的に試行されます。
JNDI参照に失敗しました。
<timestamp> <WARN> <default.collaxa.cube.activation>
<AdapterFramework::Inbound> JNDI lookup of 'eis/AQ/aqSample2' failed due to:
eis/AQ/aqSample2 not found
<timestamp> <ERROR> <default.collaxa.cube.activation>
<AdapterFramework::Inbound> Error while performing endpoint Activation:
ORABPEL-12510
Unable to locate the JCA Resource Adapter via WSDL port element jca:address.
The Adapter Framework is unable to startup the Resource Adapter specified in
the WSDL jca:address element:
@ {http://xmlns.oracle.com/pcbpel/wsdl/jca/}address:
location='eis/AQ/aqSample2'
解決策:
失敗の原因は次のいずれかです。
リソース・アダプタのRARファイルが、OC4Jアプリケーション・サーバーに正常にデプロイされていない。
リソース・アダプタのRARファイルが、次のlocation属性に正常にデプロイされていない。
$J2EE_HOME/application-deployments/default/deployed-adapter-name/oc4j-ra.xml has not been set to eis/AQ/aqSample2
この場合は、oc4j-ra.xmlファイルに新しくconnector-factoryエントリ（接続）を追加する必要があります。正しいエントリを追加してから、BPELアプリケーション・サーバーを再起動してください。
解決策:
ファイル$J2EE_HOME/application-deployments/default/aqAdapter/oc4j-ra.xmlを検索します。このファイルは、Oracle BPEL Process Managerの最初の起動時に実行されるアダプタのデプロイ時に作成されます。アダプタがデプロイされていない場合には、次のコマンドを使用してアダプタをデプロイし、手順2に従います。
java -jar $J2EE_HOME/admin.jar ormi://localhost admin welcome -deployconnector -file <path to AQAdapter.rar> -name AqAdapter
$J2EE_HOME/application-deployments/default/aqAdapter/oc4j-ra.xmlが存在する場合には、oc4j-ra.xmlファイルにJNDIロケーションが定義されていることを確認します。
<connector-factory location="eis/AQ/aqSample" connector-name="AQ Adapter"> <config-property name="connectionString" value="jdbc:oracle:thin:@myhost:1521:appdb2"/> <config-property name="userName" value="scott"/> @ <config-property name="password" value="tiger"/> </connector-factory>
JMSプロバイダのエラー
<JMSAdapter::Outbound> ORABPEL-12165 ERRJMS_PROVIDER_ERR. Could not produce message due to JMS provider error. Please examine the log file to determine the problem. ....... ...... ....... Caused by: javax.jms.JMSException: MQJMS1013: operation invalid whilst session is using asynchronous delivery.
解決策:
この例外は、MQプロバイダのインバウンドJMSアダプタおよびアウトバウンドJMSアダプタで同じJNDI名が使用された場合に発生します。この例外を回避するには、MQプロバイダのインバウンドおよびアウトバウンドJMSアダプタのWSDLファイルで異なるJNDI名を指定します。
別の解決策は、インバウンドのWSDLファイルでUseMessageListenerプロパティをfalseとして指定することです。次に例を示します。
UseMessageListener="false"
