| Oracle Application Serverリリース・ノートおよび新機能 10gリリース3（10.1.3.5.1） B57229-01 |
|
 戻る |
 次へ |
この章では、Oracle Enterprise Service Bus（ESB）に関連する問題について説明します。内容は次のとおりです。
ESBフローでルーティング・サービスを使用してInvocationMode=localなどの特定のプロパティを使用してBPELプロセスを起動する場合、これらのプロパティをBPELプロセスのデプロイメント・ディスクリプタに追加する必要があります。
たとえば、ルーティング・サービスがInvocationMode=localを使用してBPELプロセスをコールできるようにするには、次の例に示すように、InvocationModeプロパティをBPELプロセスのbpel.xmlデプロイメント・ディスクリプタに追加して、プロパティを必ず使用できるようにする必要があります。
<?xml version = '1.0' encoding = 'UTF-8'?>
<BPELSuitcase>
<BPELProcess id="BPElProcess1" src="BPElProcess1.bpel">
<partnerLinkBindings>
<partnerLinkBinding name="client">
<property name="wsdlLocation">BPElProcess1.wsdl</property>
</partnerLinkBinding>
</partnerLinkBindings>
<configurations>
<property name="InvocationMode">local</property>
</configurations>
</BPELProcess>
</BPELSuitcase>
この問題の詳細は、Oracle Bug#7294273を参照してください。
サーバー・ログでWSDLに対するportType不一致エラーを受け取る場合、またはESBサービスを構成していてパートナ・ロール・ドロップダウン・リストまたはロール・ドロップダウン・リストに使用可能なオプションが表示されない場合、原因として、ESBサービスの具体的なWSDLがtargetNamespaceとインポート・ネームスペースに対して異なるURIを持つことが考えられます。
この問題を解決するには、次のパラメータをORACLE_HOME/integration/esb/esb_config.iniファイルに追加します。
isConcreteSuffixRequired = true
変更後、サーバーを再起動します。
この問題の詳細は、Oracle Bug#8573592を参照してください。
サービスを作成してマルチバイト・キャラクタ・セットを使用した名前でデプロイすると、サービスはリストされますが、サービスの詳細を表示しようとするとエラーが発生します。
サポートされているUS-ASCII文字を使用してESBサービスに名前を付けます。
この問題の詳細は、Oracle Bug#5411159を参照してください。
Oracle JDeveloperの「ファイル」→「名前の変更」を使用して、または名前の変更機能を右クリックして、ESBリソース・ファイルの名前を変更する場合、そのファイルへの参照は他のリソース・ファイルでは更新されません。ESBリソース・ファイルの名前を変更した場合は、そのファイルを参照するときに必ずその参照を手動で変更する必要があります。
この問題の詳細は、Oracle Bug#8605755を参照してください。
Oracle JDeveloperのESBプロジェクトからアウトバウンド・サービスを削除し、そのサービスがESBサーバーにもデプロイされている場合、Oracle JDeveloperからプロジェクトを再デプロイしても、削除されたサービスはサーバーから消去されません。
Oracle JDeveloperでサービスを削除する場合は、必ず次の手順も実行します。
プロジェクトを再デプロイする前に、ESBフローでそのサービスへのルーティング・ルールを削除します。
プロジェクトを再デプロイする前に、JDeveloperでそのサービスのWSDLを削除します。
ESBコンソールで、JDeveloperで削除したサービスを手動で削除します。
この問題の詳細は、Oracle Bug#8610058を参照してください。
ESBによりORACLE_HOME/j2ee/home/jca/DefaultSystem.ReadS_RS.receive/rejectedMessages/ディレクトリに拒否メッセージが送信されます。
この問題の詳細は、Oracle Bug#8632308を参照してください。
リシーケンサ操作の開始後、サーバーが突然停止すると順序変更が不完全になります。レコードの一部のみが順序変更されます。この突然の障害により、グループは停止したコンテナによってロックされたままになります。クラスタ環境では、他の稼働しているノード上のリシーケンサ・インフラストラクチャは、停止したサーバーを識別し、動作しているノードに固定して自動的にグループのロックを解除し、そしてそのグループに問題がなければ処理を再開します。グループの状態は維持されます。再開処理にはある程度時間がかかり、これはesb_config.iniのResequencerContainerIdLeaseTimeoutプロパティで指定した値と同じかそれより長くなる可能性があります。
グループがエラー状態になると、グループのロックを解除するまでエラー状態のままです。エラー状態のグループのロックを解除するには、<ORACLE_HOME>/integration/esb/sql/oracleフォルダでresequencer_restart_processing_group.sqlスクリプトを実行します。
この問題の詳細は、Oracle Bug#8665217を参照してください。
ESBリシーケンサを使用する場合、ResequencerTimeoutエンドポイント・プロパティ値を指定できます（デフォルト値は制限なし）。ResequencerTimeoutにより、指定した時間後に次の順番メッセージが受信されないグループをロックすることができます。比較的短いResequencerTimeout設定で負荷の高い処理を実行すると、未処理のグループが永久的にロックされて処理できなくなる可能性があります。
ResequencerTimeoutによるグループのロックを回避するには、タイムアウトの時間を増やすか、または時間値を指定しないで（デフォルト）タイムアウトが発生しないようにします。
ResequencerTimeoutによりロックされたグループのロックを解除するには、<ORACLE_HOME>/integration/esb/sql/oracleフォルダでresequencer_restart_processing_group.sqlスクリプトを実行します。
この問題の詳細は、Oracle Bug#8673539を参照してください。
複数のOC4Jコンテナ（またはノード）を含む環境などの高可用性環境では、OC4Jコンテナがクラッシュすると、そのコンテナで処理されているリシーケンサ・グループは、存続しているコンテナにより続けて処理されます。そのグループは、クラッシュしたコンテナの再起動後も、存続しているコンテナで続けて処理されます。クラッシュしたコンテナの再起動後に到着した新しいグループのリシーケンサ・メッセージは、どちらのコンテナでも処理できます。
この問題の詳細は、Oracle Bug#8764008を参照してください。
高度な検索では、一定の秒数より前に発生したアクティビティを検索しようとすると、ESBにより例外がスローされます。この問題を回避するには、分や時間など、より大きい時間単位を使用して高度な検索を実行します。
この問題の詳細は、Oracle Bug#8639976を参照してください。
以前のリリースでは、WebDAV（Web-based Distributed Authoring and Versioning）のスライド・リポジトリにあるアーティファクトは、プロジェクト・サービスが削除されても削除されませんでした。
このリリースでは、esb_config.iniファイルのwebDAV_deleteプロパティをtrueに設定できます（デフォルト設定はfalse）。それから、ESBサーバーを再起動します。これらの操作により、Oracle JDeveloperまたはantからOracle Enterprise Service Busプロジェクトをデプロイするときに必ずアーティファクト・ディレクトリが削除されるようになります。使用されていないアーティファクトは削除され、最新のアーティファクトのみが残ります。
このパラメータをtrueに設定しない場合は、再デプロイされたプロジェクトに存在するアーティファクトは更新され、その他のアーティファクトはそのままの状態になります。
Oracle ESB Controlからサービスを削除しても、アーティファクトはスライド・リポジトリから削除されないことに注意してください。これはこれらのアーティファクトが他のサービスで参照されている可能性があるためです。
Oracle JDeveloperのESBプロジェクトからアウトバウンド・サービスを削除し、そのサービスがESBサーバーにもデプロイされている場合、Oracle JDeveloperからプロジェクトを再デプロイしても、削除されたサービスはサーバーから消去されません。
Oracle JDeveloperでサービスを削除する場合は、必ず次の手順も実行します。
プロジェクトを再デプロイする前に、ESBフローでそのサービスへのルーティング・ルールを削除します。
プロジェクトを再デプロイする前に、Oracle JDeveloperでそのサービスのWSDLを削除します。
Oracle ESB Controlで、Oracle JDeveloperで削除したサービスを手動で削除します。
この問題の詳細は、Oracle Bug#8669306を参照してください。
Oracle JDeveloperでlookup-dvm関数を使用してドメイン値マップ（DVM）参照を実行する場合、関数はorclネームスペースを自動で提供しません。orclネームスペースを関数に手動で追加する必要があります。
たとえば、次のlookup-dvm関数では、強調表示されたネームスペースを手動で挿入する必要があります。
{orcl:lookup-dvm('myDVM','ShortName',/top:T3Collection/top:T3/top:op,'LongName
','NotFound') = 'Karnataka'};{ namespace
top=http://xmlns.oracle.com/pcbpel/adapter/db/top/insLongName namespace
orcl=http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc }
この問題の詳細は、Oracle Bug#8722231を参照してください。
opmnctl stopallコマンドを使用してOPMNサービスの正常シャットダウンを実行しようとすると、かわりに強制シャットダウンが発生します。
推奨する回避方法として、opmn.xmlで停止タイムアウトを増やします。また、opmnctl shutdownコマンドを使用してOPMNサービスを正常にシャットダウンすることもできます。
この問題の詳細は、Oracle Bug#8682471を参照してください。
この項では、ESBドキュメントの問題と回避方法について説明します。
10.1.3.4のOracle Application Serverのリリース・ノートのESBロギングの強化に関する項で、実装クラスのESBクラスパスへの追加について間違った例（server.xml/esb.common）が使用されています。
正しいクラスパス例は、server.xml/oracle.bpel.commonです。
この問題の詳細は、Oracle Bug#8230137を参照してください。
この項では、Oracle WebLogic ServerでのOracle SOA Suiteの使用に特有の問題とその回避方法について説明します。
ESBは、着信メッセージのポーリングのためにWorkManagerからスレッドを取得します。これらのスレッドはデーモン・スレッドであり、いったん起動されるとWorkManagerに返されません。WebLogic Serverで実行するESBの場合、このようなスレッドがStuckThreadMaxTimeパラメータのデフォルト値（600秒）を超えて返されないと、スタック・スレッドとみなされます。サーバーは、スタック・スレッドに関する警告メッセージの表示を開始します。
この問題を回避するには、WebLogic ServerのStuckThreadMaxTimeパラメータを大きな値（14400秒など）に設定して、これらのスレッドがスタック・スレッドとみなされるのを遅らせます。
ESBプロセスがルーティング・サービスを介してBPELプロセスを起動すると、BPELプロセスは失敗し、次のエラーがログ・ファイルに表示されます。
... "java.lang.Exception: Failed to create "ejb/collaxa/system/DeliveryBean" bean; exception reported is: "javax.naming.AuthenticationException [Root exception is javax.security.auth.login.FailedLoginException: [Security:090304]Authentication Failed: User soaadmin javax.security.auth.login.LoginException: [Security:090301]Password Not Supplied] weblogic.jndi.internal.ExceptionTranslator.toNamingException#44"
これは、ESBが実行時にant-orabpel.propertiesファイル内のadmin.encrypted.passwordプロパティから暗号化されたパスワードをフェッチしようとするが、そのプロパティがデフォルトではこのファイルに存在しないためです。
次の手順を実行してこの問題を修正できます。
コマンド・プロンプトを使用してadmin.encrypted.passwordプロパティのパスワードを暗号化します。たとえば、パスワードをoracleに設定するときは、次のコマンドを使用します。
[SOA:~/product/mw_home/OracleAS_1/bpel/bin]$ . ./devprompt.sh
[SOA:~/product/mw_home/OracleAS_1/bpel/bin]$ $JAVA_HOME/bin/java com.collaxa.cube.util.EncryptPassword oracle
この場合、暗号化された次のようなパスワードが生成されます。
WCRx6zgvsHh9yCswMh6hgQ==
SOA_HOME/bpel/utilities/ant-orabpel.propertiesファイルを探し、ファイルのバックアップを実行します。
ant-orabpel.propertiesファイルを開き、次のように更新します。
admin.passwordプロパティのエントリがある場合は、シャープ記号（#）を前に付けてこのプロパティをコメント・アウトします。
手順1で得た値を指定して、admin.encrypted.passwordプロパティのエントリを追加します。たとえば、次のようになります。
admin.encrypted.password = WCRx6zgvsHh9yCswMh6hgQ==
WebLogic Serverコンソールから管理対象サーバーを再起動します。
WebLogic Serverは、.jsや.xmlの拡張子が付いたファイルについてコンテンツタイプを設定しません。
この問題を回避するには、次の2つの方法のいずれかを使用して環境でこれらのMIMEタイプを構成する必要があります。
方法1
これらのMIMEタイプをESB Webアプリケーションのweb.xmlファイルに追加します。
方法2
次の手順を実行し、config/mimemapping.propertiesファイルでドメイン全体にMIMEタイプを設定します。
次のURLを使用してWebLogic Serverコンソールにログインします。
「ドメイン」→「構成」→「Webアプリケーション」をクリックします。
Mimeパラメータを探します。
このパラメータの値は、mimemappings.propertiesファイルの場所を示します。
mimemappings.propertiesファイルがまだ存在していない場合は作成します。
次のエントリをmimemappings.propertiesファイルに追加します。
xml=text/xml js=text/javascript
SOA管理対象サーバーを再起動します。
