この章では、Oracle Enterprise Service Bus(ESB)に関連する問題について説明します。内容は次のとおりです。
UDDIサービスの呼出し用にESBを構成するには、次の手順を実行します。
esb_config.ini
ファイルを編集し、次の行を追加します。
uddiInquiryURL=http://<host>:<port>/registry/uddi/inquiry
サーバーを再起動します。
JDeveloperで、SOAPサービスからUDDIサービスを選択します。
エンドポイント・サービスで、エンドポイント・プロパティregistryServicekey
をregistryServiceKey=uddikey
として追加します。
これは、プロジェクトがデプロイされるとESBコントロールに表示されます。
注意: セキュアなUDDIのHTTPS呼出しは、このリリースではサポートされていません。 |
この問題の詳細は、Oracle Bug#7122328を参照してください。
遅延メッセージ・リスナーを2つ以上に増やすと、JSMでは同じ名前を持つ複数のサブスクライバがサポートされていないため、ESBではJMS例外がスローされて機能しなくなります。これは既知の問題です。
この問題を解決するために、Oracle Application Serverリリース10.1.3.4では、次の点が強化されました。
遅延リスナーには、メッセージ・セレクタに接尾辞を付けた名前が付けられるようになりました。次に例を示します。
n_systemname
n
は、システムのリスナー数です。
ESBコントロールを使用してリスナーを増やすと、リスナー数に自動的に影響が及びますが、値を減らしてもサーバーの再起動が必要になります。
ESBコントロールを開き、図6-1のように、リスナー数を設定できます。
エンキュー元では、次のようにして、受信者名をエンキューするようになりました。
n_systemname
n
は、1からシステムのリスナー数までの任意の数です。
エンキュー元プールのサイズを設定するための新しいパラメータenqueuer_number
が$ORACLE_HOME/integration/esb/config/esb_config.ini
ファイルに導入されました。
注意: リスナーまたはエンキュー元の数を増やした後、サーバーを再起動する必要があります。 |
$ORACLE_HOME/integration/esb/esb_config.ini
ファイルのenqueuer_number
パラメータを設定します。全システムのエンキュー元キャッシュ・サイズを特定の値に設定する場合、enqueuer_number
プロパティにより設定できます。次に例を示します。
enqueuer_number = number
number
は、全システムに必要なエンキュー元キャッシュ・サイズです。
特定のシステムのエンキュー元キャッシュ・サイズを特定の値に設定する場合、<SYSTEM_NAME>
_enqueuer_number
プロパティにより設定できます。次に例を示します。
DefaultSystem_enqueuer_number = number
number
は、特定のシステムに必要なエンキュー元キャッシュ・サイズです。
注意: このオプション・パラメータの設定は、インバウンド・サービスがメッセージを複数のスレッドで同時に受信するときのスループットを最適化するのに役立ちます。理想としては、このパラメータは、インバウンド・スレッドの最大限の数に設定します。 |
システム数が増えると、エンキュー元のキャッシングが使用可能な接続数を超える可能性があります。したがって、パフォーマンスのためのエンキュー元のキャッシングは、esb_config.ini
ファイルでcache_enqueuer
プロパティがtrue
に設定されている場合にのみ使用可能です。
OC4JJMS
の接続数を増やすには、j2ee/<instance>/connectors/OracleASjms/OracleASjms/META-INF/oc4j.ra.xml
ファイルでコネクタ・ファクトリMyTCF
およびMyXATCF
のmaxConnections
プロパティをより大きな値に設定する必要があります。次に例を示します。
<connector-factory location="OracleASjms/MyTCF" connector-name="OracleASjms"> <config-property name="jndiLocation" value="jms/TopicConnectionFactory"/> <connection-pooling use="private"> <property name="waitTimeout" value="300" /> <property name="scheme" value="fixed_wait" /> <property name="maxConnections" value="200" /> <property name="minConnections" value="0" /> </connection-pooling>
この問題の詳細は、Oracle Bug#6489703を参照してください。
空白を含むシステム名でESBシステムを作成すると、WebサービスURLが無効になります。
この問題の詳細は、Oracle Bug#7016982を参照してください。
SOA 10.1.3.3.1へのアップグレード後、プロパティおよび使用情報の詳細を得るために、サーバー・コンソールでESB Webサービスをテストすると、間違ったサービス・エンドポイントが開きます。
この問題は、次のいずれかの方法を実行することで解決できます。
方法1
プロジェクトesbsvc
ファイルに次のプロパティを手動で追加し、プロジェクトを再デプロイします。
<endpointProperties> <property name="includeESBBinding" value="false"/> </endpointProperties>
方法2
サービス・デザイナを開き、図6-2のように、includeESBBinding
プロパティをfalse
に設定します。
この問題の詳細は、Oracle Bug#6753524を参照してください。
リリース10.1.3.4にアップグレードした後、BPELプロセスはロードに失敗します。これは、BPELプロセスがESBプロセスの前にロードされ、その時点では使用できないESB WSDLファイルにアクセスしようとするためです。
この問題は、次のようにserver.xml
ファイルでアプリケーションの順序を変更し、コンテナを再起動することにより回避できます。
ESB-DT
ORABPEL
ESB-RT
次の例は、server.xml
ファイルのサンプルSnippetを示しています。
<application name="javasso" path="../../home/applications/javasso.ear" parent="default" start="false" /> <application name="ascontrol" path="../../home/applications/ascontrol.ear" parent="system" start="false" /> <application name="datatags" path="../../home/applications/datatags.ear"parent="default" start="true" /> <application name="orainfra" path="../applications\orainfra.ear" parent="default" start="true" /> <application name="esb-dt" path="../applications\esb-dt.ear" parent="default" start="true" /> <application name="orabpel" path="../applications\orabpel.ear" parent="default" start="true" /> <application name="hw_services" path="../applications\hw_services.ear" parent="orabpel" start="true" /> <application name="ruleauthor" path="../applications\ruleauthor.ear" parent="default" start="true" /> <application name="rulehelp" path="../applications\rulehelp.ear" parent="default" start="true" /> <application name="esb-rt" path="../applications\esb-rt.ear" parent="esb-dt" start="true" /> <application name="gateway" path="../applications\gateway.ear" parent="default" start="true" /> <application name="ccore" path="../applications\ccore.ear" parent="default"start="true" /> <application name="policymanager" path="../applications\policymanager.ear" parent="default" start="true" /> <application name="coreman" path="../applications\coreman.ear" parent="default" start="true" />
この問題の詳細は、Oracle Bug#6965309を参照してください。
リリース10.1.3.4では、ストリーミング添付およびRPCエンコードWebサービスのサポートが導入されました。
この問題の詳細は、Oracle Bug#6607987を参照してください。
Antスクリプトを使用してESBリポジトリをデプロイしようとする場合、正しいOracle RACデータソースが$ORACLE_HOME/j2ee/oc4j_esbdt/config/data-sources.xml
ファイルに作成されません。ここで、oc4j_esbdt
はESBリポジトリがAntスクリプトを使用してデプロイされたOC4Jコンテナの名前です。
注意: この不具合は、ESB用のスキーマをストアするためにOracle RACデータベースを使用する場合にのみ該当します。 |
この問題を回避するには、Antスクリプトの完了後、次のように、ESBPoolとESBAQJMSPoolの両方の接続プールを構成するために、手動でdata-sources.xml
ファイルを編集する必要があります。
<connection-factory factory-class="oracle.jdbc.pool.OracleDataSource" url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=
(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=tcp)(HOST=abc1.us.oracle.com)(PORT=1521))(ADDRESS=(PROTOCOL=tcp)(HOST=
abc2.us.oracle.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=ORCL.us.oracle.com)))" user="oraesb" password="passwordfororaesb">
この問題の詳細は、Oracle Bug#7030056を参照してください。
Oracle Application Serverリリース10.1.3.4から起動する際の、ESBロギング機能が強化されました。この強化されたロギング機能を利用するには、パッチのインストール後に次の手順を実行する必要があります。
oracle.tip.esb.server.common.interceptor.IEsbMessageInterceptor
インタフェースを実装します。
実装クラスをESBクラスパス(たとえば、server.xml/esb.common
)に追加します。
esb_config.ini
ファイルに次の構成変数を追加します。
inboundMessageInterceptor = oracle.tip.esb.server.common.interceptor.test.TestInterceptor outboundMessageInterceptor = oracle.tip.esb.server.common.interceptor.test.TestInterceptor
この問題の詳細は、Oracle Bug#6995195を参照してください。
リリース10.1.3.4から、ESBでは、DT_OC4J_PROTOCOL
パラメータをESB_PARAMETER
表に追加することにより、ランタイム・プロトコルを選択できるようになりました。このパラメータのデフォルト値はhttp
です。このパラメータの値は、使用中のプロトコルの接頭辞に変更する必要があります。たとえば、HTTP Secure Socket Layer(SSL)通信を使用している場合、このパラメータの値はhttps
に設定します。これは次の手順で実行できます。
ORAESB
スキーマに接続します。
次のように、ESB_PARAMETER
表を更新します。
SQL> Update ESB_PARAMETER set param_value="https_port_number" where param_name=' DT_OC4J_HTTP_PORT'; SQL> insert into ESB_PARAMETER values('DT_OC4J_PROTOCOL','https'); Commit;
opmn
プロセスを再起動します。
この問題の詳細は、Oracle Bug#7027470を参照してください。
10.1.3.4パッチの適用後、OC4Jコンテナが初期化を終了する前にping数が超過するため、ESBサーバーがロードされません。その結果、アプリケーション・サーバーがopmnctl startall
オプションで再起動されると、ESBサーバーが正常に起動しません。
この問題は、esb_config.ini
ファイルとorion-application.xml
ファイルで次の設計時サーブレットping制御属性を適切な値に設定することにより解決できます。
PingCount = <desired_value> PingInterval = <desired_value>
この問題の詳細は、Oracle Bug#7115442を参照してください。
OC4J_SOAコンテナが正常に停止せず、default_group~<
OC4J_Container_Name
>~default_group~1.log
ファイルの停止ログには、コンテナがESBアダプタのエンドポイントの非アクティブ化で常に停止することが示されています。
これは、opmn.xml
ファイルに指定されたOC4Jのデフォルトの停止タイムアウトが120であり、その時間のほとんどが初期プロセス、つまりBPELの停止に消費されるためです。したがって、ESBには停止のために十分な時間がなく、Oracle Process Management Notification(OPMN)により強制的に停止されます。この問題は、opmn.xml
ファイルでOC4Jの停止タイムアウトを増やすことで解決できます。
この問題の詳細は、Oracle Bug#6930111を参照してください。
SOAを10.1.3.1から10.1.3.3にアップグレードした後、ESBサービスからBPELプロセスを呼び出すと、ESBが間違ったインスタンスを指し、例外をスローします。これは、クラスタ環境で正しいインスタンス名を見つけるには、cluster
パラメータとlocal.oc4jinstancename
パラメータが$ORACLE_HOME/bpel/utilities/ant-orabpel.properties
ファイルで次のように設定されている必要があるためです。
cluster
属性の設定
cluster = true
local.oc4jinstancename
パラメータの設定
local.oc4jinstancename = <oc4jinstance_name>
この問題の詳細は、Oracle Bug#6487856を参照してください。
BPELプロセスは、RMI接続および2フェーズ・コミットのパフォーマンスを強化するために、SOAPアダプタからではなく、ESBルーティング・サービスから直接呼出しできます。しかし、BPELプロセスを再デプロイすると、ESBではリンクされたBPELプロセスが認識されなくなり、ESBフローが予期しない形でBPELプロセスをコールします。この問題を解決するには、<SOA_HOME>/integration/esb/config/esb_config.ini
ファイルで次のプロパティを指定します。
bpelSvcAutoDeletion=false
この問題の詳細は、Oracle Bug#6455812を参照してください。
10.1.3.4より前のリリースでは、リポジトリのリセットは、Oracle Database Liteでのみサポートされていました。Oracle Application Serverリリース10.1.3.4から、Oracle Databaseでリポジトリのリセットがサポートされるようになりました。
この問題の詳細は、Oracle Bug#6336442を参照してください。
Oracle Application Serverリリース10.1.3.4から、マルチパート・メッセージを含むWSDLファイルを使用して、ルーティング・サービスまたはSOAPサービスを作成できるようになりました。
この問題の詳細は、Oracle Bug#7029422を参照してください。
インスタンスの追跡を有効にして、デプロイ済プロジェクトに対して1時間を超えるSOAストレス・テストを実行すると、OutOfMemory
例外が発生します。この問題は、次のいずれかの方法を使用して、ESB_PARAMETER
表のTrackingMessageFlushInterval
パラメータおよびMaxPersistentMessages
パラメータを更新することで解決できます。
注意:
|
方法1: URLを使用して表を更新
次のURLを使用して、TrackingMessageFlushInterval
パラメータの値を更新します。
http://abc.us.oracle.com:8888/esb/esbConfiguration/executeCommand?action=UpdateProperty&name=TrackingMessageFlushInterval=150
次のURLを使用して、MaxPersistentMessages
パラメータの値を更新します。
http://abc.us.oracle.com:8888/esb/esbConfiguration/executeCommand?action=UpdateProperty&name=MaxPersistentMessages&value=200
方法2: コマンドラインから表を更新
注意: ESB_PARAMETER表を更新する場合、変更を有効にするには、ESB DTサーバーおよびRTサーバーを再起動する必要があります。 |
次のコマンドを使用して、TrackingMessageFlushInterval
パラメータの値を更新します。
SQL> insert into ESB_PARAMETER (param_name, param_value) values ('TrackingMessageFlushInterval', '150');
次のコマンドを使用して、MaxPersistentMessages
パラメータの値を更新します。
SQL> insert into ESB_PARAMETER (param_name, param_value) values ('MaxPersistentMessages', '200');
この問題の詳細は、Oracle Bug#7026575を参照してください。
インスタンスの追跡を有効にして、デプロイ済プロジェクトに対してSOAストレス・テストを実行すると、インスタンス監視に遅れが生じ、処理成功直後にインスタンスが表示されなくなります。
この問題は、次のいずれかの方法により解決できます。
方法1
次のURLを使用して、ActivityMessageReceiverCount
プロパティを更新します。
http://abc.us.oracle.com:8888/esb/esbConfiguration/executeCommand?action=UpdateProperty&name=ActivityMessageReceiverCount&value=5
方法2
注意: ESB_PARAMETER表を更新する場合、変更を有効にするには、ESB DTサーバーおよびRTサーバーを再起動する必要があります。 |
ESB_PARAMETER
表を直接操作することにより、ActivityMessageReceiverCount
プロパティを更新します。
SQL> insert into ESB_PARAMETER (param_name, param_value) values ('ActivityMessageReceiverCount', '5');
この問題の詳細は、Oracle Bug#6130734を参照してください。
注意: 現在のところ、ActivityMessageReceiverCount プロパティは、Oracle Advanced Queuing(AQ)でのみサポートされています。 |
ESBリポジトリのリセットの一部として、リセット・スクリプトにより、XREF_DATA
表が他のESBリポジトリ表とともに削除され、再作成されます。リセット・スクリプトを実行する前に、XREF_DATA
表のデータをバックアップする必要があります。
この問題の詳細は、Oracle Bug#7131202を参照してください。
セキュアなWebサービスをコールするESBサービスがある場合、環境を10.1.3.4にアップグレード後、ESBサービスでWebサービスのコールに失敗します。
この問題は、次の手順を実行することで回避できます。
JDeveloperで元のプロジェクトを開きます。
プロジェクトをサーバーと同期化します。
ヘッダーがアウトバウンドSOAPメッセージに割り当てられる.xsl
ファイルを開きます。
既存のヘッダーXPathは、次のようなものです。
<xsl:variable name="UserName" select="ehdr:setOutboundHeader('/wsse1:Security/wsse1:UsernameToken/ wsse1:Username',$UserName,'wsse1=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;')"/>
最初に/Header
が加わるようにこのXPathを変更します。XPathは次のようになります。
<xsl:variable name="UserName" select="ehdr:setOutboundHeader('/Header/wsse1:Security/wsse1:UsernameToken/ wsse1:Username',$UserName,'wsse1=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;')"/>
サービスが変更されることを示すために、コメントのルーティング・サービスを変更します。
すべてのアーティファクトをJDeveloperに保存します。
JDeveloperからプロジェクトを再デプロイします。
この問題の詳細は、Oracle Bug#7172146を参照してください。
同期エラー処理を有効にしようとすると、ESBランタイムから例外がスローされます。
この問題は、userthreads
オプションを使用してESBランタイムを起動することで解決できます。これには、ESBプロセスをホストし、ESB同期エラー処理を使用するOC4Jサーバーの$ORACLE_HOME/opmn/conf/opmn.xml
ファイルの<category id="start-parameters">
の下に-Doc4j.userThreads=true
を追加する必要があります。同期エラー処理の詳細は、『Oracle Enterprise Service Bus開発者ガイド』を参照してください。
この問題の詳細は、Oracle Bug#7194096を参照してください。
プロジェクトに異なるサービスを使用する複数のルーティング・ルールがあり、サービスの1つが無効の場合、その他のサービスのルーティング・ルールも機能を停止します。
この問題を解決するには、無効になっているサービスに対応するルーティング・ルールを削除し、プロジェクトを再デプロイして、プロジェクトを再定義する必要があります。
この問題の詳細は、Oracle Bug# 7176595を参照してください。
ESBフィルタ式に二重引用符が付いたXRef関数がある場合、関数は意図したとおりに機能しません。たとえば、次の関数は正常に機能します。
{xref:lookupXRef('apps_intg','common','common-12345',/imp1:Root-Element/imp1:Root-Element/imp1:appname,true()) = 'sap_01-678910'}; {namespace xref=http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRefXPathFunctions namespace imp1=http://TargetNamespace.com/readFile}
同じ関数を二重引用符を使用して次のように変更します。
{xref:lookupXRef("apps_intg","common","common-12345",/imp1:Root-Element/imp1:Root-Element/imp1:appname,true()) = 'sap_01-678910'}; {namespace xref=http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRefXPathFunctions namespace imp1=http://TargetNamespace.com/readFile}
このように変更された関数は正常に機能せず、ESBコントロールにも完全には表示されません。「ルーティング・ルール」ダイアグラムに移動し、「ルーティング・ルール」タブをクリックすると、'{xref:lookupXref('
のみが表示されています。
この問題の詳細は、Oracle Bug#7211022を参照してください。
HTTPS UDDIサーバーを設定し、WSDLファイルを呼び出そうとすると、例外がスローされます。
この問題の詳細は、Oracle Bug# 7199163を参照してください。
ESBは、Oracle RACの計画停止に対して実行されると、同じファイルを2回処理する場合があります。これは、ファイル・アダプタがXA準拠アダプタでないためです。そのため、これがグローバル・トランザクションに加わると、各ファイルを1回だけ処理するというXAインタフェース仕様に従わない可能性があります。
この問題の詳細は、Oracle Bug#7131998を参照してください。
Oracle Database Liteでは、次の順でWindowsの基本インストールを行うと、ESBコントロールにログインできなくなります。
10.1.3.1 --> 10.1.3.3 --> 10.1.3.4
この問題は、$ORACLE_HOME/opmn/conf/opmn.xml
ファイルでJavaオプション-Doc4j.formauth.redirect=true
を-Doc4j.formauth.redirect=false
に更新することで回避できます。
この問題の詳細は、Oracle Bug#7190190を参照してください。
コマンドラインからドメイン値マップをインポートした場合、SOAサーバーを再起動するまで、インポートしたマップがESBコントロールに表示されません。
この問題の詳細は、Oracle Bug# 7211441を参照してください。
ESB同期シナリオで失敗したインスタンスが、無制限に再試行される場合があります。たとえば、データをデータベースからファイルにルーティングする際、特定のメッセージを繰り返し配信できないというESBからのシグナルがデータベース・アダプタでリスニングされない場合、この問題が発生する可能性があります。
この問題を回避するには、次のいずれかを実行します。
ESBを非同期シナリオに構成します。
メッセージが配信不能になる状況を防ぎます。たとえば、ファイル・アウトバウンド操作の場合、ファイル書込み許可を構成します。
この問題の詳細は、Oracle Bug#7203558を参照してください。
ESBルーティング・サービスでは、XSL変換が存在する場合、SOAPヘッダーがESBによりパススルーされません。この問題は、次のエンドポイント・プロパティを対応するESBルーティング・サービスに追加することにより解決できます。
<service> ..... <endpointProperties> <property name="passThruHeaders" value="true"/> </endpointProperties> </service>
この問題の詳細は、Oracle Bug#6877702を参照してください。
JMSは、jms_receive_timeout
パラメータに指定された期間、メッセージ・キューにあるメッセージのデキューをブロックまたは待機します。jms_receive_timeout
パラメータの値が、Oracle_Home/integration/esb/esb_config.ini
ファイルのxa_timeout
パラメータおよびOracle_Home/j2ee/home/config/transaction-manager.xml
ファイルのtransaction-timeout
パラメータの値より大きい場合は、例外が発生します。これは、jms_receive_timeout
パラメータに指定された期間中JMSトピックにメッセージがない場合、待機状態またはブロック状態が終了し、その時にはトランザクションも終了しているためです。
この問題の詳細は、Oracle Bug#7257928を参照してください。
transaction=participate
プロパティをオーバーライドできないことは、ESBからBPELを呼び出すときの既知の問題です。
この問題は、次のいずれかの方法により回避できます。
方法1
ESBコントロールにログインします。
「サービス」リストでtransaction
プロパティをオーバーライドするBPELプロセスに対応するBPELサービスを選択します。
選択したBPELサービスの「プロパティ」タブに移動し、notParticipate
としてTransactionMode
エンドポイント・プロパティを追加します。
「OK」をクリックします。
方法2
次のSnippetで示すように、bpel.xml
でTransactionMode
というプロパティを指定することにより、transaction
プロパティをオーバーライドするBPELプロセスを再デプロイします。
<?xml version = '1.0' encoding = 'UTF-8'?> <BPELSuitcase> <BPELProcess id="TestingVersioning" src="TestingVersioning.bpel> ............. <property name="TransactionMode">notParticipate</property> </BPELProcess> </BPELSuitcase>
この問題の詳細は、Oracle Bug#6367355を参照してください。
Oracle Application Serverリリース10.1.3.4では、ESBでのエラー処理の追加サポートが提供されています。詳細は、『Oracle Enterprise Service Bus開発者ガイド』およびOracle Bug#6878979を参照してください。
この項では、Oracle Application Serverのこのリリースで解決された問題について説明します。この項の内容は次のとおりです。
lookupPopulatedColumns()
関数でデータが見つからない場合、needAnException
フラグがfalse
に設定されていれば、関数は空のノードセットを返します。10.1.3.4より前のリリースでは、このような場合、lookupPopulatedColumns()
関数は<column name=""/>
を返していました。
この問題の詳細は、Oracle Bug#6445370を参照してください。
BPELとESBの相互作用で、ターゲットのESBサービスが複数操作用であり、BPELが同じプロセス内の異なるパートナ・リンクを介してすべての操作をコールする場合、10.1.3.4より前のリリースではエラーが発生しました。
この問題の詳細は、Oracle Bug#6367285を参照してください。
10.1.3.4より前のリリースでは、ESBサービスからEJBをコールすると、java.lang.ClassCastException
が発生しました。
この問題の詳細は、Oracle Bug# 6314009を参照してください。
10.1.3.4より前のリリースでは、ESBエンドポイントで公開されている.Net 3.0 SOAPサービスを呼び出すと、NullPointerException
がスローされました。
この問題の詳細は、Oracle Bug#6473280を参照してください。
10.1.3.4より前のリリースでは、ヘッダーベースの変換およびルーティングのサポートが限定されていました。リクエスト・ヘッダーは、アウトバウンド・ヘッダーへはパススルーされませんでした。
この問題の詳細は、Oracle Bug#6638648を参照してください。
この項では、リリース10.1.3.4でのOracle ESBの新機能について説明します。この項の内容は次のとおりです。
Oracle Application Serverリリース10.1.3.4では、ESBでのユーザー定義拡張関数の作成がサポートされるようになりました。ユーザー定義拡張関数は、その他の関数と同様です。独自のJava関数セットをインポートでき、これがユーザー定義拡張関数カテゴリの下の関数パレットに表示されます。詳細は、『Oracle Enterprise Service Bus開発者ガイド』およびOracle Bug#5880920を参照してください。
Oracle Application Serverリリース10.1.3.4では、UIでのエンドポイント・プロパティの変更がサポートされるようになりました。この機能により、UIで任意のプロパティ名を手動で入力できるため、すべてのESBサービスでプロパティを変更できます。
Oracle Application Serverリリース10.1.3.4では、ESBでのリシーケンサの実装がサポートされるようになりました。リシーケンサは、関連するが順序どおりでないメッセージのストリームを再配置し、正しい順序に戻すために使用されます。詳細は、『Oracle Enterprise Service Bus開発者ガイド』およびOracle Bug#6856169を参照してください。
重要: リシーケンサは、preview モードで使用可能であり、デフォルトでは無効です。無効の場合、既存の製品機能には影響しません。リシーケンサを使用する場合は、ESB構成パラメータEnableResequencer の値をtrue に設定して有効にする必要があります。詳細は、『Oracle Enterprise Service Bus開発者ガイド』を参照してください。 |
Oracle Application Serverリリース10.1.3.4では、JDeveloper ESBデザイナでのマルチパートWSDLのインポートがサポートされるようになりました。
マルチパート・メッセージを含むWSDLファイルを使用して、ルーティング・サービスまたはSOAPサービスを作成できます。これにより、メッセージがマルチパート・メッセージであるか、ESBでサポートされていないタイプがあるという警告がスローされます。マルチパート・メッセージは、RPCエンコードSOAPサービスでのみサポートされており、どのパートでも変換またはフィルタリングが使用されません。
ルーティング・ターゲットの入力および出力ペイロードが、SOAPサービスの入力および出力ペイロードと同一であることを確認するのはユーザーです。このオプションは、JDeveloperが-J"-Dpreview_mode=true"
モードで起動している場合にのみ使用可能です。
この問題の詳細は、Oracle Bug#6621183を参照してください。
Oracle Application Serverリリース10.1.3.4では、ESB Antデプロイ機能がサポートされるようになりました。Antデプロイ機能には、ESBサービス・デプロイの自動化に使用されるカスタムAntタスクのセットが含まれています。詳細は、『Oracle Enterprise Service Bus開発者ガイド』を参照してください。