| Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド 11g リリース1（11.1.1） B55918-01 |
|
 戻る |
 次へ |
この付録では、Oracle BPEL Process ManagerとOracle Mediatorのトラブルシューティング方法について説明します。
この付録には、次の項が含まれます。
次の項では、Oracle JCA Adapter for Database（Oracleデータベース・アダプタ）の使用中に予想される問題と解決策について説明します。
この項には、次の項目が含まれます。
問題
実行時に、TopLinkセッションを作成できなかったという例外が発生する場合があります。
解決策
この一般的なエラーは、実行時の接続が適切に構成されていない場合に発生します。 詳細は、「デプロイメント」を参照してください。
問題
eis/DB/my_connection/....のアダプタを検出できなかったという例外が発生する場合があります。
解決策
詳細は、「デプロイメント」を参照してください。
問題
Customers_table.xsdへの変更が反映されない場合は、例外が発生します。
解決策
Oracleデータベース・アダプタが生成する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)])
通常、ウィザードで問題があったことを示します。
解決策
最も簡単な解決策は、まずデータベースにすべての制約を作成することです。 また、問題によっては、オフライン表の問題を修正してウィザードを再度実行するのみでよい場合もあります。
問題
「終了」をクリックした後、またはデプロイメント時に、次の例外が発生する場合があります。
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に主キーが定義されていないことを意味します。
解決策
この例外が、ターゲット外部キーがないというエラーとともに表示された場合、「ターゲット外部キーがないというエラー」を参照し、まずその問題を解決します。それ以外の場合は、次のようにします。
usesStringBinding=trueプロパティをweblogic-ra.xmlファイルに追加し、さらにこのプロパティをra.xmlファイルで宣言します。 BLOBの場合は、かわりにプロパティusesStreamsForBinding=trueおよびUsesByteArrayBinding=trueを設定する必要があります。
問題
Oracleデータベース・アダプタにxs:dateTime値を渡す際に変換の例外が発生する場合があります。
解決策
属性がタイプxs:dateTimeの場合、Oracleデータベース・アダプタは次のいずれかの書式の文字列を要求します。
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列が存在する場合があります。ただし、これはOracleデータベース・アダプタで受け入れられる日付書式ではありません。次に示すのは、TopLinkにのみ適用可能な解決策です。
25-DEC-1999日付書式を渡す場合には、属性を単純な文字列としてマッピングします。 Oracleデータベース・アダプタはその値を単純な文字列として受け入れます。
これを実行するには、オフライン・データベース表を編集し、列のデータ型を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は実際にはバイナリ値ですが、Oracle JDeveloperのオフライン表ではdateTime型として解釈されます。そのため、型を変更する必要があります。
XMLおよびbase64エンコードへの変換後、TIMESTAMPにはバイナリ値としての意味も使用方法もありません。
TIMESTAMP値は変更できないため、少なくとも読取り専用としてマークしておく必要があります。
TIMESTAMPは擬似列ROWIDに似ています。ROWIDは技術的には列ですが、Oracleデータベース・アダプタによってデフォルトでマッピングされることはありません。
挿入における一意の制約違反、またはデータベースやネットワークを一時的に使用できないなどのフォルトの処理方法を理解するには、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があり、不適切な表を修飾すると、検出の難しい問題につながります。このため、Oracleデータベース・アダプタでは表名をスキーマ名で修飾します。 |
詳細は、「デプロイメント」を参照してください。
問題
従業員が多数所属する多数の部門を読み取りましたが、部門ごとに表示される従業員が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などのツールは要求どおりに動作しますが、Oracleデータベース・アダプタではこの問合せが機能しません。
解決策
最善の方法は、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句を使用できません。 AからBへのバッチ属性読取りを無効化すると、DISTINCTを回避できます。バッチ読取りでは、以前問い合せたすべてのAからすべてのBの同時読取りを試行してパフォーマンスを拡張します。この問合せではDISTINCT句を使用します。 結合読取りを使用するか、結合読取りもバッチ属性読取りも使用しません。
DISTINCTおよびCLOBのどちらも一般的であるため、この問題は別のシナリオでも発生します。たとえば、次のような式ではDISTINCT句を使用します。
SELECT DISTINCT dept.* from Department dept, Employee emp WHERE ((dept.ID = emp.DEPTNO) and (emp.name = 'Bob Smith'));
問題
ラージ・オブジェクト（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プロパティのリストは、表9-9「データベース・プラットフォーム名」を参照してください。
詳細は、次のサイトの「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の問題がある場合は、Oracleデータベース・アダプタをデータソースを使用するように構成し、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の起動操作を使用すると、Oracleデータベース・アダプタに100行渡されます。ただし、すべての行が適切にデータベース表に挿入されるわけではありません。
この問題の詳細は、「MERGEによるUPDATE処理とINSERT処理の誤作動」を参照してください。MERGEの存在チェックの不具合により、挿入が必要な際に行が挿入されないケースが許可されるため、メッセージが失われたように見えます。
解決策
WeakIdentityMapではなくNoIdentityMapを使用します。
JDeveloper BPEL Designerでプロジェクトを開きます。
「アプリケーション - ナビゲータ」で、プロジェクトの「アプリケーション・ソース」の下の「TopLinkマッピング」ノードをダブルクリックします。
「TopLinkマッピング - 構造」ペインに、TopLinkプロジェクトが表示されます。
「TopLinkマッピング - 構造」ペインの各ディスクリプタをクリックすると、メイン・ウィンドウに表示されます。
メイン・ウィンドウの上部には、「ディスクリプタ情報」、「問合せ」、「問合せキー」および「アイデンティティ」タブがあります。
「アイデンティティ」タブをクリックします。
「アイデンティティ・マップ」リストから、NoIdentityMapを選択します。
「データベースのチェック」（デフォルト）に「存在チェック」を設定します。
キャッシュが使用されない場合、値「キャッシュのチェック」は無効になります。
「ファイル」から「すべて保存」を選択します。
アダプタ構成ウィザードを編集モードで再度実行し、toplink_mappings.xmlを再生成します。
（オプションで）toplink_mappings.xmlを閉じて再度開き、解決策の効果を確認します。
NoIdentityMapがWeakIdentityMapにグローバルに変更されています。
その処理を再デプロイします。
問題
子レコードで、DeletePollingStrategyの整合性違反が検出されます。
行を削除する際には、整合性制約に注意する必要があります。たとえば、DEPARTMENTにEMPLOYEEへの1対多リレーションシップがある場合、DEPTIDはEMPLOYEEの外部キーです。 DEPARTMENTレコードを削除して従業員を削除しないと、DEPTIDは破損したリンクとなり、整合性制約の原因となります。
この問題は、表のみがインポートされ、それに関連する表がインポートされなかったために発生します。たとえば、データベースからDEPARTMENT表のみをインポートし、列DEPTIDに整合性制約のあるEMPLOYEE表をインポートしない場合、Oracleデータベース・アダプタは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;
問題
問合せを実行すると、正しい行数を取得できますが、行が複数回表示されることや表示されないことがあります。
この動作は、主キーの構成が不適切なことが原因です。Oracleデータベース・アダプタで同一とみなされる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つの表が同一である場合、または目的のデータが同一の場合は、前述の手順に従う必要はありません。
問題
アダプタ構成ウィザードの「リレーションシップ」ウィンドウでは、主キーのすべての要素が表示され削除できません。そのため、コンポジット主キーの一部のみを参照する外部キーは作成できません。
解決策
外部キー制約は、（サブセットではなく）主キーのすべての部分をマッピングする必要があるため、解決策はありません。Oracleデータベース・アダプタでは、参照先として対応する主キーのある外部キーのみが許可されます。
ウィザードでは、曖昧なリレーションシップは作成できません。 たとえば、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型はサポートされていません。
問題
表を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デザイナで次の手順を実行します。
エラーのダイアログで「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.txtファイルでは、バインディング・フォルト（すでに存在する行の挿入など）およびリモート・フォルト（ネットワークまたはデータベースが使用できない場合の行の挿入など）の2種類のフォルトを説明しています。 Readme.txtファイルには、例外の捕捉手順、および一般的なOracleデータベースのエラー・コードのリストが提供されています。
問題
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に適切な値が使用されていることを確認します。 様々なデータベース値の詳細は、表9-9「データベース・プラットフォーム名」を参照してください。使用しているデータベースが表にリストされている場合は、表示されている値を使用します。たとえば、DB2データベースを使用している場合は、DatabasePlatformではなくDB2Platformを使用します。
ウィザードでのUpdate Only操作では、子レコードに対する挿入または削除が実行されることがあります。
Insert OnlyおよびUpdate Only操作は、子レコードの再帰的な挿入/更新という点で異なります。 Insert Only操作では、トップレベルの表および関連するすべての子レコードが挿入されます。 トップレベルのレコードおよびすべての関連レコードは新規であるものと想定されます。Update Onlyは、トップレベル・レコードの更新のみを実行することが保証されています。 その後、子レコードを挿入/更新するか、削除するかがチェックされます。想定されるのは、トップレベル要素の存在のみです。Merge操作では、トップレベル・レコードや子レコードの存在は想定されません。
この例として、データベースに2人のユーザー（table1_ownerおよびtable1_user）と1つの表（table1）があるとします。
設計時の接続ユーザー（Oracle JDeveloper内）がtable1_ownerで、実行時の接続ユーザー（JDBCデータソース）がtable1_userの場合は、表またはビューが存在しないことを示す実行時例外がスローされます。
生成されたSQLファイルをチェックすると、次のことがわかります。
設計時にtable1_ownerを使用している場合、table1はtable1として参照されます。
設計時にtable1_userを使用している場合、table1はtable1_owner.table1として参照されます。
この問題の解決策は、weblogic-ra.xmlまたはra.xml内で、実行時にあいまいな名前を明確化するようにtableQualifierプロパティを構成することです。
次の項では、ストアド・プロシージャに対するOracleデータベース・アダプタの使用中に予想される問題と解決策について説明します。
問題
選択した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;
SCHEMA2のアクセス・タイプOBJへの権限がSCHEMA1に付与されていない場合、SCHEMA1でストアド・プロシージャを作成しようとすると、次の例のようなPL/SQLエラーが発生します。
PLS-00201: identifier SCHEMA2.OBJ must be declared
解決策
次のように、SCHEMA1がSCHEMA2からタイプOBJを参照できるように、SCHEMA2はSCHEMA1に権限を付与する必要があります。
SQL> GRANT EXECUTE ON OBJ TO SCHEMA1;
詳細は、「別のスキーマのタイプの参照」を参照してください。
問題
インスタンスXMLによって提供された仮パラメータと、ストアド・プロシージャのシグネチャで定義されている実際のパラメータの不一致は、一般的な実行時の問題です。このタイプのエラーが発生すると、引数の数または型が正しくないというメッセージがAPIに渡されるため、ストアド・プロシージャの実行を試行するinvokeアクティビティが失敗します。この問題の予想される原因は次のとおりです。
必要なパラメータのいずれかに対応する要素が、インスタンスXMLファイルに指定されていなかった。
解決策: 必要な要素を追加して問題を解決します。
XSDで指定された数を超える要素がインスタンスXMLファイルに含まれていた。
解決策: XMLファイルから余分な要素を削除します。
XSDファイルでストアド・プロシージャのシグネチャが適切に説明されていない。 たとえば、パラメータのタイプの1つが変更され、XSDがその変更を反映するために再生成されなかった場合、要素のdb:typeと変更されたパラメータの新しいタイプでタイプの不一致が生じます。
解決策: パラメータがAPIのシグネチャに一致することを確認します。
問題
ストアド・プロシージャの実行が試行された際に、そのストアド・プロシージャがデータベースに定義されていない場合にも、失敗が発生します。 たとえば、ADDEMPLOYEESストアド・プロシージャが起動され、このストアド・プロシージャがデータベースで定義されていない場合、invokeアクティビティは失敗します。
識別子ADDEMPLOYEESを宣言する必要があるというエラーが発生します。これは、データベースにストアド・プロシージャが定義されていない可能性を示しています。 これは、プロセスがデプロイされてからプロシージャが起動されるまでの間に、プロシージャが削除された場合などに発生します。また、ストアド・プロシージャの実行に必要な権限が付与されていなかった場合にも発生します。
解決策
データベースでAPIが定義されていることと、そのプロシージャの実行に適切な権限が付与されていることを確認してください。
インスタンスXMLが選択されたAPI用に生成されたXSDと一致しない場合は、複数の実行時エラーが発生する可能性があります。
インスタンスXMLファイルの各値が、生成されたXSDのInputParametersルートの各要素の定義に従っていることを確認してください。
次の項では、Oracle JCA Adapter for Files/FTP（Oracleファイル・アダプタおよびOracle FTPアダプタ）の使用中に予想される問題と解決策について説明します。
前に指定された論理名を別の名前に変更すると、bpel.xmlファイルに新旧両方の論理名が表示されます。古い論理名を削除するには、bpel.xmlファイルを手動で編集する必要があります。
ネイティブ・フォーマット・ビルダー・ウィザードでは、空白のあるネイティブ・スキーマ・ファイル名の作成は制限されていませんが、ファイル名には空白を使用しないことをお薦めします。
ネイティブ・フォーマット・ビルダーでは、ネイティブ・フォーマット・ビルダー以外で生成された既存のXSDファイル、またはネイティブ・フォーマット・ビルダー・コンストラクトを使用してハンドコーディングされていない既存のXSDファイルは編集できません。 また、NXSDコンストラクトを使用して作成されたXSDをネイティブ・フォーマット・ビルダー・ウィザードで編集する必要がある場合は、そのXSDの注釈に有効なサンプル・ファイル名を指定する必要があります。
ファイルを30000以上処理した後は、表領域が拡張されません。 上限に達した時点で、表領域に対してAUTOEXTENDを有効化する必要があります。 ベスト・プラクティスは、表領域についてAUTOEXTENDを推奨値に設定することです。
Oracleファイル・アダプタが複数のファイルを処理して入力ディレクトリにコピーする際に、このインバウンド・ディレクトリが別のOracleファイル・アダプタにより新規ファイルを取得するためにポーリングされている場合、一部のファイルが処理されず、アーカイブ・フォルダにコピーされる場合があります。 次にエラー・メッセージのサンプルを示します。
oracle.integration.platform.blocks.adapter.fw.log.LogManagerImpl log INFO: File Adapter FlatStructure ORABPEL-11117 minOccurs not satisfied. minOccurs="1" not satisfied for the node "<element name="Root-Element">". Loop terminated with cardinality "0". Insufficient or invalid data. Please correct the NXSD schema. at oracle.tip.pc.services.translation.xlators.nxsd.NXSDTranslatorImpl.parseNXSD(NXSDTranslatorImpl.java:1269)
このエラーが発生するのは、Oracleファイル・アダプタは潜在的に書込み中のファイルを取得できない場合があるためです。 この問題を回避するには、アダプタ構成プロパティMinimumAgeの設定値を大きくする必要があります。
この項では、一般的なユーザー・エラーを説明します。
アダプタ構成ウィザードの「メッセージ」ウィンドウ（図4-19）で、「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」チェック・ボックスを選択できます。Opaqueは一方向のみには選択できません。 Opaqueは、インバウンドおよびアウトバウンドの両方向で選択する必要があります。
メッセージは、インバウンドとアウトバウンドのいずれであるかによって意味が異なります。たとえば、次のような選択をするとします。
インバウンド・ファイルにレコードが2つある場合は、2つのメッセージに分割（デバッチ）されます。ただし、3はアウトバウンド方向で指定されたため、ファイルは作成されません。これは、使用可能なアウトバウンド・メッセージが3つあるわけではないためです。これらのオプションを選択する前に、インバウンドおよびアウトバウンド・メッセージの意味を理解していることを確認してください。
Oracleファイル・アダプタまたはOracle FTPアダプタで個々にファイルの読取りや取得ができない場合は、正規表現（regex）を使用したファイル名の一致を選択したが、名前が正しく指定されていないことが原因である可能性があります（図4-17）。 詳細は、表4-3を参照してください。
そのまま送信する必要のあるトランスレーション不要のコンテンツ（JPGまたはGIF画像など）がある場合があります。ファイルはBase64エンコーディングで渡されます。これは、不透明（Opaque）なコンテンツと呼ばれます。 これを実行するには、アダプタ構成ウィザードの「メッセージ」ウィンドウ（図4-19）で、「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」チェック・ボックスを選択します。このチェック・ボックスを選択すると、トランスレーション用のXSDファイルを指定する必要がありません。
ファイルの個別の読取りまたは取得には、Oracleファイル・アダプタまたはOracle FTPアダプタ用のインバウンド・ディレクトリが存在する必要があります。
Oracle FTPアダプタがリモート・ホストに接続できない場合は、Oracle_Home\bpel\system\appserver\oc4j\j2ee\home\application-deployments\default\FtpAdapter\oc4j-ra.xmlデプロイメント・ディスクリプタ・ファイルをアダプタ・インスタンスJNDI名およびFTPサーバー接続情報用に構成済であることを確認してください。 詳細は、「Oracle 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プロセス・ファイルに出現するヘッダー変数も設定できます。ヘッダー変数は特定のシナリオで役に立ちます。 たとえば、ファイルの伝播シナリオで、Oracleファイル・アダプタを使用して、ファイルがあるファイルシステムから別のファイルシステムへ移動されるとします。この場合、2つのシステム全体でファイル名を保持する必要があります。 どちらの方向でもファイル・ヘッダーを使用し、アウトバウンド・ファイル・ヘッダーにファイル名を設定して、インバウンド・ファイル・ヘッダーでファイル名を使用します。
詳細は、invoke、receive、reply、およびpickアクティビティのOnMessageブランチの「プロパティ」タブで使用可能なオンライン・ヘルプを参照してください。
アダプタ構成ウィザードの「ファイル変更時間」ウィンドウ（図4-35）では、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 JCA Adapter for AQ（Oracle AQアダプタ）の使用中に予想される問題と解決策について説明します。
次の項では、Oracle AQアダプタを使用中のインバウンド・エラーに関して予想される問題と解決策について説明します。
サンプル・エラー
Unable to locate the JCA Resource Adapter via .jca binding file element <connection-factory/> The JCA Binding Component is unable to startup the Resource Adapter specified in the <connection-factory/> element: location='eis/AQ/aqSample2'.
問題
このエラーの原因として最も可能性が高いのは、次のいずれかです。
リソース・アダプタのRARファイルが、WebLogic J2EEアプリケーション・サーバーに正常にデプロイされていない。
WebLogic JCAのデプロイメント・ディスクリプタのJNDI <jndi-name>設定が、eis/AQ/aqSample2に設定されていない。
後者の場合は、デプロイメント・ディスクリプタに新しくconnector-factoryエントリ（接続）を追加する必要があります。 これを修正してから、Oracle WebLogicアプリケーション・サーバーを再起動してください。
解決策
Oracle AQアダプタがデプロイ済で実行されていることを確認します。 これは、Oracle WebLogic Server管理コンソールを使用して確認できます。
前述のJNDI名を持つ接続インスタンスがweblogic-ra.xmlファイルに定義されていることを確認します。 これは、次の例に示すように、Oracle WebLogic Server管理コンソールを使用して確認できます。
<connection-instance>
<jndi-name>eis/AQ/aqSample2</jndi-name>
<connection-properties>
<properties>
<property>
<name>XADataSourceName</name>
<value>jdbc/aqSample2</value>
</property>
<property>
<name>DataSourceName</name>
<value></value>
</property>
<property>
<name>ConnectionString</name>
<value></value>
</property>
<property>
<name>UserName</name>
<value></value>
</property>
<property>
<name>Password</name>
<value></value>
</property>
<property>
<name>DefaultNChar</name>
<value>false</value>
</property>
<property>
<name>UseDefaultConnectionManager</name>
<value>false</value>
</property>
</properties>
</connection-properties>
</connection-instance>
サンプル・エラー
Apr 19, 2009 11:52:23 PM oracle.integration.platform.blocks.adapter.fw.log.LogManagerImpl log SEVERE: JCABinding=> Raw Error while performing endpoint Activation: BINDING.JCA-11975 AQ_INVALID_QUEUE. Unable to obtain queue table name. Queue does not exist or not defined correctly. Drop and re-create queue.
解決策
キューを作成し、プロセスを再デプロイします。このプロセスがサンプルからデプロイされる場合、すべてのキュー作成スクリプトは各プロジェクトの下のsql\create_queues.sqlに配置されています。
一般的な注意事項として、アウトバウンド・スレッドは発信されるメッセージがある場合にのみアクティブ化されるため、アウトバウンド・ディレクトリの問題はデプロイメント時には捕捉されません。
サンプル・エラー
NOTIFICATION: Purge-Repos Diagnostics [auto-purge, partition-name, partition-id, #versions purged]: [true, soa-infra, 1, 2]. Apr 20, 2009 12:03:00 AM oracle.integration.platform.blocks.adapter.fw.log.LogManagerImpl log WARNING: JCABinding=> JCABinding=> Raw:Outbound [ Enqueue_ptt::Enqueue(opaque) ] JNDI lookup of 'eis/AQ/aqSample3' failed due to: Unable to resolve 'eis.AQ.aqSample3'. Resolved 'eis.AQ' Apr 20, 2009 12:03:00 AM oracle.integration.platform.blocks.adapter.fw.log.LogManagerImpl log SEVERE: JCABinding=> Raw:Outbound [ Enqueue_ptt::Enqueue(opaque) ] Could not invoke operation 'Enqueue' against the 'null' due to: BINDING.JCA-12511 JCA Binding Component connection issue. JCA Binding Component is unable to create an outbound JCA (CCI) connection. Raw:Outbound [ Enqueue_ptt::Enqueue(opaque) ] : The JCA Binding Component was unable to establish an outbound JCA CCI connection due to the following issue: BINDING.JCA-12510 JCA Resource Adapter location error. Unable to locate the JCA Resource Adapter via .jca binding file element <connection-factory/> The JCA Binding Component is unable to startup the Resource Adapter specified in the <connection-factory/> element: location='eis/AQ/aqSample3'.
問題
このエラーには、次のいずれかの原因が考えられます。
リソース・アダプタのRARファイルが、Oracle WebLogic Serverに正常にデプロイされていない。
weblogic-ra.xmlの<jndi-name>要素がeis/AQ/aqSample3に設定されていない。
後者の場合は、新しいWebLogic JCAコネクション・ファクトリを追加（RARをデプロイ）する必要があります。 これを修正してから、Oracle WebLogic Serverを再起動してください。
ログ・ファイルでその他の原因を調べます。 Oracle Enterprise Managerコンソールを使用して、FINESTアダプタ・ロギングを有効化します。
解決策
「インバウンド・エラー」で説明されているように、インバウンドの項にある同じ問題の解決策を参照してください。
INFO: AQ Adapter Raw:Outbound [ Enqueue_ptt::Enqueue(opaque) ] begin() ignored... Apr 20, 2009 12:08:02 AM oracle.integration.platform.blocks.adapter.fw.log.LogManagerImpl log SEVERE: JCABinding=> Raw:Outbound [ Enqueue_ptt::Enqueue(opaque) ] Could not invoke operation 'Enqueue' against the 'AQ Adapter' due to: BINDING.JCA-11975 AQ_INVALID_QUEUE. Unable to obtain queue table name. Queue does not exist or not defined correctly. Drop and re-create queue.
解決策
解決策は、インバウンドでキューが見つからない問題と同じです。キューを作成し、プロセスを再デプロイします。このプロセスがサンプルからデプロイされる場合、すべてのキュー作成スクリプトは各プロジェクトの下のsql\create_queues.sqlに配置されています。
JMSプロバイダのエラー
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"
