| Oracle Application Serverリリース・ノート 10gリリース2（10.1.2）for Solaris Operating System (SPARC) B15829-14 |
|
 戻る |
 次へ |
| Oracle Application Serverリリース・ノート 10gリリース2（10.1.2）for Solaris Operating System (SPARC) B15829-14 |
|
戻る |
次へ |
この章では、Oracle Application Server Adapterに関する問題について説明します。この章の内容は次のとおりです。
第14.1項「Oracle Application Server Adapter for Files/FTPに関する問題と対処方法」
第14.2項「Oracle Application Server Adapter for Java Message Serviceに関する問題と対処方法」
第14.3項「Oracle Application Server Adapter for Advanced Queuingに関する問題と対処方法」
第14.4項「Oracle Application Server Adapter for Databaseに関する問題と対処方法」
第14.5項「Oracle Application Server Adapter for MQSeriesに関する問題と対処方法」
第14.6項「Oracle Application Server Adapter for Oracle Applicationsに関する問題と対処方法」
この項では、Oracle Application Server Adapter for Files（ファイル・アダプタ）およびOracle Application Server Adapter for FTP（FTPアダプタ）に関する問題とその対処方法について説明します。
ファイル・アダプタで（空のBPELプロジェクト・テンプレートを使用して）相関セットを使用した場合、パートナ・リンクのWSDLファイルにプロパティの別名が作成されます。ただし、アダプタのパートナ・リンクを編集すると、プロパティの別名はWSDLファイルから削除されます。これにより、BPELプロジェクトのコンパイルになんらかの問題が発生する場合があります。
この問題を解決するには、ソース・ビューを使用してパートナ・リンクのwsdlファイルを手動で編集する必要があります。
同じBPELプロセスから複数のファイル・アダプタの起動をバッチ処理すると、データが正しくバッチ処理されません。
同じBPELプロセスから複数のファイル・アダプタの起動をバッチ処理する必要がある場合は、別のシェルのBPELプロセスを介して、2番目以降の起動を実行します。これにより、ファイル・アダプタが起動します。つまり、元のBPELプロセスの2番目のパートナ・リンクが、ファイル・アダプタ・サービスのかわりに、小さいBPELプロセスを指すように変更します。このBPELプロセスでは、問題なくファイル・アダプタを起動できます。
この項では、次の問題とその対処方法について説明します。
インバウンドとアウトバウンドのAQ-JMSアダプタでは別々のリソース・プロバイダを使用する必要があります。
cacheConnectionsという新規のパートナ・リンク・プロパティ（BPEL）またはエンドポイント・プロパティ（ESB）をfalseに設定する必要があります。これを指定しないと、デフォルト値は（10.1.2および10.1.3の両方で）trueになります。
同一のグローバル・トランザクションに関与しているインバウンドおよびアウトバウンドのJMS宛先（キューまたはトピック）には、別々のOJMSリソース・プロバイダ（J2EE_HOME/config/application.xmlに定義）を使用してください。
JMSアダプタはWSDLからの接続情報を使用して非管理モードで実行することはできません。コネクション・ファクトリがないとレポートされます。
非管理モードであっても、アダプタによってはサーバー構成などの前提条件があります。たとえば、JMSアダプタではリソース・プロバイダはapplication.xmlで（さらに、リソース・プロバイダがデータソースを参照している場合はdata-sources.xmlでも）構成する必要があります。こうした前提条件があらかじめ存在していれば、ESBに対しても非管理モードでの実行が可能です。同じことはBPELにも当てはまります。これはOEMS JMSプロバイダにのみ適用されることに注意してください。
システム負荷が高い場合（AQ JMSアダプタのインバウンドおよびアウトバウンドの負荷が高い場合）、デキューはAQjmsException例外で失敗します。
この問題を解決するには、次の対処方法を使用します。
物理接続プールを別々に2つ作成します（つまり、2つの個別の（AQ）JMSリソース・プロバイダを使用します）。各JMS WSDL（エンキューとデキュー）が別々のJCA JNDIコネクション・ファクトリを指し、それらのコネクション・ファクトリが2つの別々のJMSコネクション・ファクトリを指すようにします。JMSコネクション・ファクトリはそれぞれ、2つあるリソース・プロバイダのうちの1つを使用します。次に例を示します。
エンキューWSDL
<jca:address location="eis/aqjms1" />
デキューWSDL
<jca:address location="eis/aqjms2" />
JmsAdapter/oc4j-ra.xml
<connector-factory location="eis/aqjms1" ... <config-property name="connectionFactoryLocation" value="java:comp/resource/aqjms1/QueueConnectionFactories/qcf"/> ... <connector-factory location="eis/aqjms2" ... <config-property name="connectionFactoryLocation" value="java:comp/resource/aqjms2/QueueConnectionFactories/qcf"/> ...
J2EE/home/config/application.xml
<resource-provider class="oracle.jms.OjmsContext" name="aqjms1"> <description>OJMS Context using thin JDBC</description> <property name="url"value="jdbc:oracle:thin:scott/tiger@localhost:1521:ORCL" /> <resource-provider class="oracle.jms.OjmsContext" name="aqjms2"> <description>OJMS Context using thin JDBC</description> <property name="url" value="jdbc:oracle:thin:scott/tiger@localhost:1521:ORCL" />
|
注意: 回帰ストレスの下でシナリオが正常に動作していても、ログにはAQJMSExceptionが記録されます。この対処方法を使用することで、この例外を回避できます。 |
OJMS（AQベースJMS）でトピックを使用すると、AQ- JMSトピックがハングし、トピックにメッセージがあってもデキューが実行されません。
JMSアダプタ・サブスクライバ（インバウンド）WSDLは、JCAコネクション・ファクトリを使用し（例: eis/OJms/myConnectionFactory1）、このJCAコネクション・ファクトリはOJMSリソース・プロバイダ（例: resprov1）を使用する必要があります。このリソース・プロバイダはURLに基づきます（例: jdbc:oracle:thin:@host:1521:orcl）。
次の一覧に、前述の対処方法の例を示します。
MyJmsSubsriber.wsdl
...
<service name="JmsSubscribe">
<port name="jmsSubscribe_pt" binding="tns:jmsSubscribe_binding">
<jca:address location="eis/OJms/myConnectionFactory1"/>
...
J2EE_HOME/application-deployments/default/JmsAdapter/oc4j-ra.xml
<connector-factory location="eis/OJms/myConnectionFactory1" connector-name="Jms Adapter"> <config-property name="connectionFactoryLocation" value="java:comp/resource/resprov1/QueueConnectionFactories/myQCF"/>
J2EE_HOME/config/application.xml
<orion-application ...
...
<resource-provider class="oracle.jms.OjmsContext" name="resprov1">
<property name="url" value="jdbc:oracle:thin:@host:1521:orcl" />
<property name="username" value="scott" />
<property name="password" value="tiger" />
</resource-provider>
Oracle BPEL Process Manager内では、JMSアダプタのメッセージ相関に次のタイプの相関スキーマを使用できます。
BPEL invokeの後にBPEL receiveが続く場合、BPELプロセス内でJMSアダプタのメッセージ相関に使用できる選択肢の1つがネイティブ・アダプタ相関です。
|
注意: ネイティブ・アダプタ相関は、AQ、JMSおよびMQ Seriesアダプタにのみ適用できます。 |
JMSなどのメッセージ・アダプタではネイティブ相関をサポートしており、リクエスト/レスポンスのシナリオを模倣して、アウトバウンド（BPEL invoke）メッセージとインバウンド（BPEL receive）メッセージの間の自動相関を実行します。受信メッセージの相関IDは、送信JMSメッセージのメッセージIDに設定する必要があります。これは送信先のJMSアプリケーションに実装する必要があります。基礎となるアダプタ・フレームワーク（AF）にはハッシュマップ表が格納されています。ハッシュマップ表のエントリは、送信JMSメッセージのメッセージIDをネイティブBPEL相関IDのメッセージIDにマップしています。ただし、アダプタのネイティブ相関は、invokeの後に同じPartnerLinkアクティビティを指すreceiveが続く特殊な場合にのみ使用できます。その他のすべてのケースではBPEL相関セットを使用する必要があります。
次の相関セットを使用できます。
JMSおよびAQヘッダーに基づく相関セット（JMSおよびAQアダプタにのみ使用可能）
ペイロードに基づく相関セット（すべてのアダプタに使用可能）
相関セットは、メッセージ本体の内容に基づく非同期メッセージの相関を提供するBPELメカニズムです。相互作用が単純なinvoke-receiveアクティビティでない場合、相関セットを定義する必要があります。
この項では、次の問題とその対処方法について説明します。
10万を超える大量のメッセージがAQキューに存在する場合、AQアダプタでのデキューは非常に遅くなることがあります。この問題は、リリース10.x.xのデータベースのパフォーマンスによるものです。ただし、以前のリリースのデータベースでは正常に動作します。
この問題が発生した場合、次のいずれかのコマンドを実行して、キューまたはトピック表の統計を生成します。
dbms_stats.gather_table_stats('JMSUSER', 'QTAB')
または次のように指定します。
dbms_stats.gather_schema_stats('JMSUSER')
QTABはキュー/トピック表、JMSUSERはユーザー/スキーマです。大量の行を更新、挿入または削除するたびに、統計をリフレッシュする必要があることに注意してください。
この項では、次の問題とその対処方法について説明します。
10.1.2.0.2の122.DBAdapter/InsertWithCatchの移行後、プロジェクトを開いてDBアダプタのパートナ・リンクをダブルクリックすると、UI接続が存在しないというメッセージが表示されます。UI接続の作成後、「次へ」ボタンをクリックすると、空白ページが表示されます。これは、Oracle JDeveloper 10.1.3.1で開いたときに発生します。
ここでの問題は、使用不可であるはずの「次へ」ボタンが使用不可になっていないということです。対処方法として、接続が存在し選択されていることを確認し、「次へ」ボタンはクリックしないようにします。
失敗したDBアダプタ・インスタンスがBPELコンソールに表示されないのは、BPEL監査がJTAトランザクションに連結されているためです。つまり、監査はJTAトランザクションがコミットされた場合にのみ実行されます。
XA/JTA DBアダプタの起動が失敗してJTAトランザクションがコミットできない（コミットされるべきではない）場合は、失敗したインスタンスは表示されません。この問題はサーバーのタイムアウトによっても発生し、その場合、JTAトランザクションはrollback onlyとマークされます。ただし、10.1.3.1ではDBアダプタは当初からJTA用に構成されており、この問題は常に明確にわかるようになっています。
成功または失敗のレポートはJTAと連動する必要がありますが、トランザクションの失敗のレポートとロールバックは同時には行えません。インスタンスが正常に動作した場合はJTAを介して監査が必要ですが、正常に動作しなかった場合の監査は論理的に不可能です（コミットされることのないトランザクションの一部として記述することになるため）。
OracleAS TopLinkではSYS.XMLTYPEをサポートしていません。
次の2つのプロセスを構成してタスクを実行すると、インバウンド・データベース・アダプタから読み取るデータに無効な文字が表示されます。
ファイル・アダプタでWord文書（不明瞭な書式）を読み取り、データベースのアウトバウンド方向に送信します。このデータは表に挿入されます。
データベースのインバウンド方向で同じデータを読み取り、アウトバウンド・ファイル・アダプタに送信します。これによりデータが文書に書き込まれます。
対処方法として、NCLOBのかわりにCLOBを使用します。
固有の値を提供するDATE、TIMESTAMP、TIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIMEZONEなどのデータ型を使用する場合、予期したとおりの書式で表示されません。これは、データベース・アダプタによって、これらのデータベースの型がXML型のdateTimeにマップされるためです。インスタンスXMLの受信値と生成されるXMLの出力値には、dateTimeが使用されます。これは、ISO 8601規格に一致する動作です。
次のSELECT問合せについて考えます。
select dept.*,emp.* from departments dept,employees emp where dept.department_id='50' and emp.manager_id=dept.MANAGER_ID;
この問合せを言葉で説明すると次のようになります。
部門内の任意の従業員がその部門自体と同じmanager_idを持つ部門50を検索します。
前述のSQLコマンドでは、問合せに一致する部門および従業員データのみが返されることに注意してください。アダプタで同じ結果を取得するには、Employeeをルート表として選択する必要があります。ルート表にDepartmentを選択すると、次のように、アダプタは論理的に個別のリレーションシップの問合せで従業員データを読み取ります。
select dept.* from departments dept,employees emp where dept.department_id='50' and emp.manager_id=dept.MANAGER_ID; select emp2.* from departments dept, employees emp, employees emp2 where dept.department_id='50' and emp.manager_id=dept.MANAGER_ID and emp2.department_id = dept.department_id;
この場合アダプタでは、問合せに一致する部門に加えて、その各部門のすべての従業員データ（mangager_id != dept.MANAGER_IDである従業員を含む）が返されます。
SQL構文ではルート表から返される行が指定されるだけという、単純なルールを忘れないでください。返されるディテール行は、返されるルートおよびマスター行によってのみ決まります。WHERE句を構成する2つの表から列を返すため、前述のSQL構文をアダプタで表現することは困難です。ルート表としてDepartmentのかわりにEmployeesを選択することは有効ですが、逆に選択すると問合せは機能しません。
JDeveloper BPEL Designerの「ダイアグラム・ビュー」からデータベース・アダプタのパートナ・リンクを削除し、リフレッシュを実行した後も、「アプリケーション・ナビゲータ」にはtoplink_mappings.xml、XSDおよびWSDLファイルが残ります。これは既知の問題です。
CLOBとして格納されているXMLファイルが読み取られ、スキーマに準拠する型の変数に割り当てられると、データベース・アダプタは、このCLOBのコンテンツをXML文書またはノードではなく文字列として返します。これは、XMLTypeがサポートされないための予期された動作です。
データベース・アダプタを使用している場合、複数のビューに対する問合せは実行できません。これは、ビュー間にリレーションシップを作成できないためです。JDeveloper BPEL Designerでは、この機能のオプションは提供されていません。また、単一の問合せで複数のビューおよび表に対して問合せを実行することもできません。
次のようなSQL問合せを入力します。
sqlquery : 'select count(*) from user_objects' rowset : false() row : false() datasource : 'jdbc:oracle:thin:system/welcome1@localhost:1521:ORCL'
これにより、次の例外エラーが発生します。
oracle.xml.sql.OracleXMLSQLException: Character ')' is not allowed in an XML tag name.
SQL問合せ文字列内でcount(*)、sum(price)またはavr(price)などの関数をコールする場合は、擬似エイリアス名を含めます。次に例を示します。
sqlquery : 'select count(*) as pseudo_alias_name_XXX from user_objects'
または次のように指定します。
sqlquery : 'select sum(price) as total_price from user_objects
この項では、次の問題とその対処方法について説明します。
Oracle Application Server Adapter for MQSeriesを使用する前に、パッチ5594751を適用する必要があります。このパッチは、次のサイトから入手できます。
https://www.metalink.oracle.com/
この項では、次の問題とその対処方法について説明します。
問題: Oracle Application Server Adapter for Oracle Applicationsを構成してビジネス・イベントのアウトバウンド・メッセージを作成する場合、ユーザーは、Oracle JDeveloperのアダプタ構成ウィザードを使用して、スキーマ・ファイルの場所を指定し、イベント・ペイロード用のメッセージを定義するスキーマ要素を選択する必要があります。ただし、イベント・ペイロードのデータ型またはスキーマ詳細が不明な場合、ユーザーは、選択したビジネス・イベントに対応して生成される正しいWDSLファイルを取得できない場合があります。
解決策: この問題を解決するために、Oracle Application Server Adapter for Oracle Applicationsでは更新済のスキーマ選択用ページを提供しています。このページで、ウィザードにより、次のオプションのいずれかによりビジネス・イベントのペイロード・スキーマを選択できます。
スキーマなし
任意のスキーマ
スキーマの指定
「スキーマなし」または「任意のスキーマ」のオプションを選択した場合、ビジネス・イベント・サービスに対してさらにスキーマ情報を指定する必要はありません。指定したビジネス・イベント・サービスに対応する関連のWSDLファイルが生成されます。「スキーマの指定」オプションを選択した場合、スキーマ・ファイルの場所を指定して、アウトバウンド・ビジネス・イベントのペイロードを定義するスキーマ要素を選択する必要があります。
詳細は、『Oracle Application Server Adapter for Oracle Applicationsユーザーズ・ガイド』を参照してください。
この項では、ドキュメントの記載内容の誤りについて説明します。この項の内容は次のとおりです。
『Oracle Application Server Adapters for Files, FTP, DatabasesおよびEnterprise Messagingユーザーズ・ガイド』の第6.4.2項「oc4j-ra.xmlファイルの変更」には、hostOSTypeおよびIndextypeパラメータの誤った値が記載されています。
hostOSTypeの値はz/osまたはZ/OSに指定し、MQSeriesキューのIndextypeはMQIT_GROUP_IDに設定する必要があります。
『Oracle Application Server Adapters for Files, FTP, DatabasesおよびEnterprise Messagingユーザーズ・ガイド』の第6.3.8項「メッセージのセグメンテーション」には、誤ったプロパティ名が記載されています。この項のプロパティ名はSegmentIfReqdとなる必要があります。次に例を示します。
SegmentIfReqd="true"
『Oracle Application Server Adapters for Files, FTP, DatabasesおよびEnterprise Messagingユーザーズ・ガイド』の第3.2.1.3項「パートナ・リンクの追加」には、データソースの使用に関する情報が欠落しています。AQアダプタ・サービスの定義時にサーバー接続を作成する場合は、oc4j-ra.xmlでコネクタ・ファクトリのJNDIロケーションが正しく構成されていなくても、データソースを使用できます。アダプタ・サービスWSDLから、次のコード部分を想定します。
<jca:address location="eis/AQ/aqSample" UIConnectionName="aqSample" />
アダプタ・サービスが上の例のように構成されており、oc4j-ra.xmlにeis/AQ/aqSampleのエントリがない場合は、データソースによって指定されたデータソース値が使用されます。また、data-sources.xmlファイルでもデータソースを定義する必要があります。
『Oracle Application Server Adapters for Files, FTP, DatabasesおよびEnterprise Messagingユーザーズ・ガイド』の第3.1.1.2項「デキュー機能とエンキュー機能」には、デキュー条件の意味に関する情報が欠落しています。
デキュー条件は、AQアダプタによって使用されるアドバンスト・キューイング製品の機能です。デキュー条件は、Dequeue AQ APIによって内部で使用されるAQDequeueOptionオブジェクトの一部として指定されます。デキュー条件が指定され、指定された条件を満たすメッセージがない場合は、デキューが実行されません。
デキュー条件の要素は、SQL問合せのWHERE句と同様の構文を使用するブール式です。このブール式には、メッセージ・プロパティ、ユーザー・オブジェクトのペイロード・データ・プロパティおよびPL/SQLまたはSQL関数を含めることができます。メッセージ・プロパティには、priority、corridおよびキュー表にあるその他の列が含まれます。
『Oracle Application Server Adapters for Files, FTP, DatabasesおよびEnterprise Messagingユーザーズ・ガイド』の第3.1.1項「AQアダプタの機能」には、AQアダプタでXMLタイプがサポートされないという誤った情報が記載されています。リリース10.1.3以降では、AQアダプタでXMLタイプがサポートされます。
