| Oracle® Application Server Release Notes and New Features 10g Release 3 (10.1.3.4) Part Number E12523-05 |
|
|
View PDF |
This chapter describes issues associated with Oracle Enterprise Service Bus (ESB). It includes the following topics:
Section 6.2, "JMS Exception Thrown While Increasing the Number of Deferred Listeners"
Section 6.3, "Space in ESB System Name Results in Invalid Web Service URL"
Section 6.4, "Wrong Service Endpoint Opens While Testing ESB Web Service"
Section 6.5, "BPEL Process Fails to Load After Upgrade to 10.1.3.4"
Section 6.6, "Support for Streaming Attachment and RPC Encoded Web Service"
Section 6.10, "ESB Server Does Not Load After Applying the 10.1.3.4 Patch"
Section 6.11, "10.1.3.4 OC4J_SOA Container Never Shuts Down Gracefully"
Section 6.12, "ESB Points to Incorrect Instance and Throws Exceptions"
Section 6.13, "Direct Invocation from ESB Routing Service Fails When BPEL Process Is Called"
Section 6.15, "Unable to Register ESB Project Having SOAP Attachment Web Service"
Section 6.16, "Running SOA Stress Test Throws OutOfMemory Exception"
Section 6.17, "Instances Are Not Seen Immediately After Processing"
Section 6.19, "ESB Service Calling Secured Web Service Fails After Upgrading to 10.1.3.4"
Section 6.20, "ESB Run-Time Throws Exception While Enabling Synchronous Error Handling"
Section 6.21, "Disabling One Service Affects Other Routing Rules in the Project"
Section 6.22, "XRef Functions with Double Quotation Marks Do Not Work"
Section 6.23, "HTTPS Invocation of WSDL Using UDDI Throws Exception"
Section 6.24, "ESB Processes Same File Twice When Run Against Oracle RAC Planned Outages"
Section 6.25, "Login to ESB Control Fails for Oracle Lite Database with Windows Basic Installation"
Section 6.26, "Imported Domain Value Maps Are Not Displayed in ESB Control"
Section 6.27, "Failed Instance Gets Retried Indefinitely in an ESB Synchronous Scenario"
Section 6.28, "SOAP Headers Are Not Passed Through by ESB When XSL Transformation Is Present"
Section 6.30, "Inability to Override Transaction=Participate Property in ESB"
Perform the following steps to configure ESB for invoking UDDI service:
Edit the esb_config.ini file and add the following line:
uddiInquiryURL=http://<host>:<port>/registry/uddi/inquiry
Restart the server.
In JDeveloper, select a UDDI service from SOAP Service.
In endpoint service, add endpoint property registryServicekey as registryServiceKey=uddikey.
This will be visible in the ESB control when the project is deployed.
Note:
HTTPS invocation of secured UDDI is not supported in this release.For more information about this issue, refer to Oracle bug 7122328.
If you increase the number of deferred message listeners to more than one, then ESB fails throwing JMS exception because JMS does not support more than one subscriber with the same name. This is a known issue.
To solve this issue, the following enhancements have been made in Oracle Application Server release 10.1.3.4:
Now, deferred listeners are named with a suffix to the message selector. For example:
n_systemname
where, n is the number of listeners for the system.
Now, increasing the listener value using ESB control automatically affects the number of listeners, but decreasing the value still requires restarting the server.
You can set the listener number by opening the ESB control and setting the number of listeners as shown in Figure 6-1:
Figure 6-1 Setting Number of Listeners from ESB Control

Enqueuers now enqueue the recipient name in the following way:
n_systemname
where, n is a random number between one and the number of listeners for the system.
A new parameter enqueuer_number is introduced in the $ORACLE_HOME/integration/esb/config/esb_config.ini file to set the size of the enqueuer pool.
Note:
You must restart the server after increasing the number of listeners or enqueuers.Set the enqueuer_number parameter in the $ORACLE_HOME/integration/esb/esb_config.ini file. If you want to set the enqueuer cache size for all systems to any particular value, then you can do it by setting the enqueuer_number property. For example:
enqueuer_number = number
where, number is the required enqueuer cache size for all systems.
If you want to set the enqueuer cache size of a particular system to a particular value, then you can do it by setting the <SYSTEM_NAME>_enqueuer_number property. For example:
DefaultSystem_enqueuer_number = number
where, number is the required enqueuer cache size for the particular system.
Note:
This optional parameter setting helps to optimize throughput when inbound services get messages in multiple threads simultaneously. Ideally, this parameter should be set to the maximum possible number of inbound threads.For higher number of systems, caching the enqueuer may exceed the number of connections available. So, caching the enqueuer for performance is enabled only when the cache_enqueuer property is set to true in the esb_config.ini file.
For increasing the number of connections of OC4JJMS, you must set the maxConnections property of connector-factory MyTCF and MyXATCF in the j2ee/<instance>/connectors/OracleASjms/OracleASjms/META-INF/oc4j.ra.xml file to some higher value. For example:
<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>
For more information about this issue, refer to Oracle bug 6489703.
Creating an ESB system with any space in the system name results in an invalid Web service URL.
For more information about this issue, refer to Oracle bug 7016982.
After upgrading to SOA 10.1.3.3.1, when you test ESB Web service in the server console for details of property and usage information, then a wrong service endpoint opens.
You can fix this issue by performing any one of the following methods:
Method 1
Add the following property manually to your project esbsvc file and then redeploy the project:
<endpointProperties> <property name="includeESBBinding" value="false"/> </endpointProperties>
Method 2
Open the Service Designer and set the includeESBBinding property to false as shown in Figure 6-2:
Figure 6-2 Setting the Endpoint Property includeESBBinding

For more information about this issue, refer to Oracle bug 6753524.
After you upgrade to 10.1.3.4 release, the BPEL process fails to load. This is because the BPEL process loads before the ESB process and tries to access the ESB WSDL files, which are not available until that point.
You can work around this issue by changing the sequence of applications in the server.xml file in the following way and then restarting the container:
ESB-DT
ORABPEL
ESB-RT
The following example provides a sample snippet of the server.xml file:
<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" />
For more information about this issue, refer to Oracle bug 6965309.
Release 10.1.3.4 introduces support for streaming attachment and RPC encoded Web service.
For more information about this issue, refer to Oracle bug 6607987.
If you try deploying an ESB repository using the Ant script, then a correct Oracle RAC data source does not get created in the $ORACLE_HOME/j2ee/oc4j_esbdt/config/data-sources.xml file. Here, oc4j_esbdt is the name of the OC4J container where the ESB repository was deployed using the Ant scripts.
Note:
This bug is applicable only if you use an Oracle RAC database to store schemas for ESB.To work around this issue you should manually edit the data-sources.xml file, to configure the connection pool for both ESBPool and ESBAQJMSPool in the following way, after the Ant script is complete:
<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">
For more information about this issue, refer to Oracle bug 7030056.
Starting from Oracle Application Server release 10.1.3.4, ESB logging capability has been enhanced. To take advantage of this enhanced logging feature, you should perform the following steps after you install the patch:
Implement the oracle.tip.esb.server.common.interceptor.IEsbMessageInterceptor interface.
Add the implementation class into the ESB classpath, for example, server.xml/esb.common.
Add the following configuration variables in the esb_config.ini file:
inboundMessageInterceptor = oracle.tip.esb.server.common.interceptor.test.TestInterceptor outboundMessageInterceptor = oracle.tip.esb.server.common.interceptor.test.TestInterceptor
For more information about this issue, refer to Oracle bug 6995195.
Starting from release 10.1.3.4, ESB is enabled to pick a run-time protocol by adding the DT_OC4J_PROTOCOL parameter to the ESB_PARAMETER table. The default value of this parameter is http. You must change the value of this parameter to the prefix of the protocol in use. For example, if you are using HTTP Secure Socket Layer (SSL) communication, then the value of this parameter should be https. You can achieve this by performing the following steps:
Connect to the ORAESB schema.
Update the ESB_PARAMETER table in the following way:
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;
Restart the opmn process.
For more information about this issue, refer to Oracle bug 7027470.
After applying the 10.1.3.4 patch, the ESB server does not load because the number of pings gets over before the OC4J container finishes initializing. This prevents the ESB server from starting properly, when the application server is restarted with the opmnctl startall option.
You can fix this issue by setting the following design-time servlet ping control attributes to appropriate values in the esb_config.ini and orion-application.xml files:
PingCount = <desired_value> PingInterval = <desired_value>
For more information about this issue, refer to Oracle bug 7115442.
The OC4J_SOA container never stops gracefully and the stop log from the default_group~<OC4J_Container_Name>~default_group~1.log file shows that it always stops on deactivation of the endpoint for ESB adapters.
This is due to the fact that the default stop timeout for OC4J, as specified in the opmn.xml file, is 120, out of which most of the time is consumed by the initial process, that is, BPEL shutdown. So, ESB does not have much time for the shutdown, so the Oracle Process Management Notification (OPMN) shuts it down forcibly. You can solve this problem by increasing the stop timeout for OC4J in the opmn.xml file.
For more information about this issue, refer to Oracle bug 6930111.
After upgrading SOA from 10.1.3.1 to 10.1.3.3, if you invoke a BPEL process from an ESB service, then it points to an incorrect instance and throws exceptions. This is because, to find the correct instance name in a clustered environment, the cluster and the local.oc4jinstancename parameters need to be set in the $ORACLE_HOME/bpel/utilities/ant-orabpel.properties file in the following way:
Set the cluster attribute
cluster = true
Set the local.oc4jinstancename parameter
local.oc4jinstancename = <oc4jinstance_name>
For more information about this issue, refer to Oracle bug 6487856.
You can directly invoke a BPEL process from an ESB routing service, instead of from an SOAP adapter, to enhance the performance of RMI connection and two-phase commit. But if you redeploy the BPEL process, then ESB stops recognizing the linked BPEL process, and the ESB flow calls the BPEL process in an unexpected manner. Specify the following property in the <SOA_HOME>/integration/esb/config/esb_config.ini file to fix this issue:
bpelSvcAutoDeletion=false
For more information about this issue, refer to Oracle bug 6455812.
For releases prior to 10.1.3.4, reset of repository is supported only for Oracle Database Lite. Starting from Oracle Application Server release 10.1.3.4, reset of repository is supported for Oracle Database.
For more information about this issue, refer to Oracle bug 6336442.
Starting from Oracle Application Server release 10.1.3.4, you can create a routing service or an SOAP service using a WSDL file that has a multipart message.
For more information about this issue, refer to Oracle bug 7029422.
If you run SOA stress test on your deployed projects, with instance tracking on, for more than an hour, then you will get OutOfMemory Exception. This issue can be solved by updating the TrackingMessageFlushInterval and the MaxPersistentMessages parameters of the ESB_PARAMETER table, using either of the following methods:
Note:
The default value of the TrackingMessageFlushInterval parameter is 5000 milliseconds. This value can be decreased in high message in-flow scenario. Like in the following example, the value set for the parameter is 150 milliseconds.
The default value of the MaxPersistentMessages parameter is 100. This value can be increased in high message in-flow scenario. Like in the following example, the value set for the parameter is 200.
Method 1: Updating the Table Using URL
Use the following URL to update the value of the TrackingMessageFlushInterval parameter:
http://abc.us.oracle.com:8888/esb/esbConfiguration/executeCommand?action=UpdateProperty&name=TrackingMessageFlushInterval=150
Use the following URL to update the value of the MaxPersistentMessages parameter:
http://abc.us.oracle.com:8888/esb/esbConfiguration/executeCommand?action=UpdateProperty&name=MaxPersistentMessages&value=200
Method 2: Updating the Table from the Command Line
Note:
If you update the ESB_PARAMETER table, then you must restart the ESB DT and RT servers for the changes to take effect.Use the following command to update the value of the TrackingMessageFlushInterval parameter:
SQL> insert into ESB_PARAMETER (param_name, param_value) values ('TrackingMessageFlushInterval', '150');
Use the following command to update the value of the MaxPersistentMessages parameter:
SQL> insert into ESB_PARAMETER (param_name, param_value) values ('MaxPersistentMessages', '200');
For more information about this issue, refer to Oracle bug 7026575.
If you run SOA stress test on your deployed projects, with instance tracking on, then you will see a delay in instance monitoring and instances will not be seen immediately after successful processing.
You can fix this issue by following either of these methods:
Method 1
Update the ActivityMessageReceiverCount property by using the following URL:
http://abc.us.oracle.com:8888/esb/esbConfiguration/executeCommand?action=UpdateProperty&name=ActivityMessageReceiverCount&value=5
Method 2
Note:
If you update the ESB_PARAMETER table, then you must restart the ESB DT and RT servers for the changes to take effect.Update the ActivityMessageReceiverCount property by directly manipulating the ESB_PARAMETER table:
SQL> insert into ESB_PARAMETER (param_name, param_value) values ('ActivityMessageReceiverCount', '5');
For more information about this issue, refer to Oracle bug 6130734.
Note:
Currently, theActivityMessageReceiverCount property is supported only with Oracle Advanced Queuing (AQ).As part of resetting the ESB repository, the reset script drops and re-creates the XREF_DATA table along with other ESB repository tables. You must back up the data in the XREF_DATA table before running the reset script.
For more information about this issue, refer to Oracle bug 7131202.
If you have an ESB service that calls a secured Web service, then the ESB service fails to call the Web service successfully, after you upgrade your environment to 10.1.3.4.
You can workaround this issue by performing the following steps:
Open the original project in JDeveloper.
Synchronize the project with the server.
Open the .xsl file, where the header is assigned to the outbound SOAP message.
The existing header XPath looks like the following:
<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;')"/>
Modify this XPath to add /Header in the beginning. The XPath now looks like the following:
<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;')"/>
Modify the routing service in the comment to indicate that the service is changed.
Save all artifacts in JDeveloper.
Redeploy the project from JDeveloper.
For more information about this issue, refer to Oracle bug 7172146.
If you try to enable synchronous error handling, then ESB run-time will throw an exception.
You can fix this issue by starting the ESB run-time with the userthreads option. For this, you need to add -Doc4j.userThreads=true under <category id="start-parameters"> in the $ORACLE_HOME/opmn/conf/opmn.xml file for the OC4J server that hosts ESB processes and uses ESB synchronous error handling. For more information about synchronous error handling, refer to Oracle Enterprise Service Bus Developer's Guide.
For more information about this issue, refer to Oracle bug 7194096.
If there are multiple routing rules in your project that use different services and if one of the services is disabled, then the routing rules for other services also stop working.
To fix this issue, you must redefine the project by removing the routing rule corresponding to the disabled service and then redeploying the project.
For more information about this issue, refer to Oracle bug 7176595.
If you have XRef functions with double quotation marks in ESB filter expressions, then the functions do not have the desired effect. For example, the following function works fine:
{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}
Now, modify the same function, using double quotation marks, to the following:
{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}
This modified function does not work properly and is not even seen fully in the ESB control. If you navigate to the Routing Rule diagram and click the Routing Rules tab, then you will see only '{xref:lookupXref('.
For more information about this issue, refer to Oracle bug 7211022.
If you set up the HTTPS UDDI server and try to invoke a WSDL file, then an exception is thrown.
For more information about this issue, refer to Oracle bug 7199163.
ESB may process the same file twice when run against Oracle RAC planned outages. This is because a File adapter is a non-XA compliant adapter. So, when it participates in a global transaction, it may not follow the XA interface specification of processing each file once and only once.
For more information about this issue, refer to Oracle bug 7131998.
For Oracle Database Lite, if you perform Windows basic installations in the following order, then you will not be able to log in to the ESB control:
10.1.3.1 --> 10.1.3.3 --> 10.1.3.4
You can work around this issue by updating the java option -Doc4j.formauth.redirect=true to -Doc4j.formauth.redirect=false in the $ORACLE_HOME/opmn/conf/opmn.xml file.
For more information about this issue, refer to Oracle bug 7190190.
If you import domain value maps from the command line, then you will not see the imported maps in the ESB control until you restart the SOA server.
For more information about this issue, refer to Oracle bug 7211441.
A failed instance in an ESB synchronous scenario may get retried indefinitely. For example, while routing data from Database to File, if the Database Adapter does not listen to a signal from ESB that a particular message is repeatedly undeliverable, then this issue may arise.
Perform any of the following to avoid this issue:
Configure ESB to asynchronous scenario.
Prevent situations where message is undeliverable. For example, for file outbound operations, have file write permissions configured.
For more information about this issue, refer to Oracle bug 7203558.
For ESB routing services, SOAP headers are not passed through by ESB when XSL transformation is present. You can fix this issue by adding the following endpoint property to the corresponding ESB routing service:
<service> ..... <endpointProperties> <property name="passThruHeaders" value="true"/> </endpointProperties> </service>
For more information about this issue, refer to Oracle bug 6877702.
JMS blocks or waits to dequeue the messages in the message queue for the time specified in the jms_receive_timeout parameter. If the value of the jms_receive_timeout parameter is greater than the value of the xa_timeout parameter in the Oracle_Home/integration/esb/esb_config.ini file and the transaction-timeout parameter in the Oracle_Home/j2ee/home/config/transaction-manager.xml file, then you will get an exception. This is because, if there is no message on the JMS Topic for the duration specified in the jms_receive_timeout parameter, then it will come out of the wait or block state and the transaction will be over by that time.
For more information about this issue, refer to Oracle bug 7257928.
Inability to override the transaction=participate property is a known issue while invoking BPEL from ESB.
You can work around this issue by following either of the following methods:
Method 1
Log in to the ESB control.
Select the BPEL service corresponding to the BPEL process for which you want to override the transaction property in the Services list.
Go to the Properties tab of the selected BPEL service, and add the TransactionMode endpoint property with the value as notParticipate.
Click OK.
Method 2
Redeploy the BPEL process for which you want to override the transaction property by specifying a property named TransactionMode in bpel.xml as shown in the following snippet:
<?xml version = '1.0' encoding = 'UTF-8'?>
<BPELSuitcase>
<BPELProcess id="TestingVersioning" src="TestingVersioning.bpel>
.............
<property name="TransactionMode">notParticipate</property>
</BPELProcess>
</BPELSuitcase>
For more information about this issue, refer to Oracle bug 6367355.
Oracle Application Server release 10.1.3.4 provides additional support for error handling in ESB. For more information, refer to Oracle Enterprise Service Bus Developer's Guide and Oracle bug 6878979.
This section describes the issues that have been solved in this release of Oracle Application Server. This section includes the following topics:
Section 6.32.1, "lookupPopulatedColumns() Function Does Not Return Empty Nodeset"
Section 6.32.2, "BPEL Not Able to Invoke Multioperational ESB Service"
Section 6.32.3, "Invoking an EJB from ESB Throws ClassCastException"
Section 6.32.4, "Invoking a .Net 3.0 SOAP Service Exposed by an ESB Endpoint Throws Exception"
Section 6.32.5, "Request Headers Are Not Passed Through to the Outbound Header"
If the lookupPopulatedColumns() function does not find any data, then it should return an empty nodeset, provided the needAnException flag is set to false. For releases prior to 10.1.3.4, the lookupPopulatedColumns() function used to return <column name=""/> in such a scenario.
For more information about this issue, refer to Oracle bug 6445370.
BPEL to ESB interactions, where target ESB service is multioperational and BPEL calls all the operations through different partner links in the same process, resulted in error for releases prior to 10.1.3.4.
For more information about this issue, refer to Oracle bug 6367285.
For releases prior to 10.1.3.4, if you call an EJB from an ESB service, then java.lang.ClassCastException shows up.
For more information about this issue, refer to Oracle bug 6314009.
For releases prior to 10.1.3.4, if you invoke a .Net 3.0 SOAP service exposed by an ESB endpoint, then it will throw a NullPointerException.
For more information about this issue, refer to Oracle bug 6473280.
For releases prior to 10.1.3.4, ESB provides limited support for header-based transformation and routing. Request headers are not passed through to the outbound header.
For more information about this issue, refer to Oracle bug 6638648.
This section describes the new features in Oracle ESB in release 10.1.3.4. This section includes the following topics:
Section 6.33.1, "Support for User-Defined Extension Functions in ESB"
Section 6.33.2, "Endpoint Property Allows Any User to Enter Any Name"
Section 6.33.4, "Enabling Import of Multipart WSDL in JDeveloper ESB Designer"
Oracle Application Server release 10.1.3.4 includes support for creating user-defined extension functions in ESB. The user-defined extension functions are like any other function. You can import your own set of Java functions, which appear in the function palette under the User-defined Extension Functions category. For more information, refer to Oracle Enterprise Service Bus Developer's Guide and bug 5880920.
Oracle Application Server 10.1.3.4 release includes support for modifying the endpoint properties in the UI. This feature enables you to manually enter any property name in the UI, thus enabling you to modify the properties on all ESB services.
Oracle Application Server 10.1.3.4 release includes support for implementing the resequencer in ESB. A resequencer is used to rearrange a stream of related but out-of-sequence messages back into order. For more information, refer to Oracle Enterprise Service Bus Developer's Guide and Oracle bug 6856169.
Important:
The resequencer is available inpreview mode and is disabled by default. When disabled, it does not affect the existing product functionality. If you want to use the resequencer, then you must enable it by setting the value of the ESB configuration parameter EnableResequencer to true. For more information, refer to Oracle Enterprise Service Bus Developer's Guide.Oracle Application Server 10.1.3.4 release includes support for importing multipart WSDL in the JDeveloper ESB Designer.
You can create a routing service or an SOAP service using a WSDL file that has a multipart message. This throws a warning that the message is a multipart message or has a type that is not supported by ESB. A multipart message is supported only for an RPC-encoded SOAP service, and no transformation or filtering may be used on any part.
It is your responsibility to ensure that the routing targets' input and output payloads are identical to the SOAP service's input and output payloads. This option is available only if JDeveloper is started in the -J"-Dpreview_mode=true" mode.
For more information about this issue, refer to Oracle bug 6621183.
Oracle Application Server 10.1.3.4 release includes support for the ESB Ant deployment feature. The Ant deployment feature includes a set of custom Ant tasks that are used for ESB service deployment automation. For more information, refer to Oracle Enterprise Service Bus Developer's Guide.