| Oracle® Application Server Release Notes and New Features 10g Release 3 (10.1.3.5.1) Part Number E15342-03 |
|
|
View PDF |
This chapter describes issues associated with Oracle Enterprise Service Bus (ESB). It includes the following topics:
Section 6.4, "Renaming Files Using Oracle JDeveloper's Renaming Feature"
Section 6.5, "Deleting Outbound Services in Oracle JDeveloper"
Section 6.7, "Incomplete Resequencing After Server Shutdown"
Section 6.8, "Resequencer Locks Groups When ResequencerTimeout Is Reached"
Section 6.9, "Resequencer Behavior in High Availability Environments"
Section 6.11, "Deleting WebDAV Repository Artifacts and Oracle ESB Services"
Section 6.12, "DVM Functions Do Not Include the ORCL Namespace"
Section 6.15, "Oracle WebLogic Server Issues and Workarounds"
When you use a routing service in an ESB flow to invoke a BPEL process using specific properties, such as InvocationMode=local, you must add those properties to the BPEL process deployment descriptor.
For example, to ensure that the routing service can call a BPEL process using InvocationMode=local, you must make sure that property is available by adding the InvocationMode property to the BPEL process bpel.xml deployment descriptor, as shown in the following example.
<?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>
For more information about this issue, refer to Oracle bug 7294273.
If you receive a portType mismatch error for a WSDL in the server log, or if you are configuring an ESB service and no options are available in the Partner Role or My Role drop-down lists, the likely cause is an ESB service concrete WSDL that has different URIs for the targetNamespace and import namespace.
To address this issue, add the following parameter to the ORACLE_HOME/integration/esb/esb_config.ini file:
isConcreteSuffixRequired = true
Restart the server after you make the change.
For more information about this issue, refer to Oracle bug 8573592.
If you create and deploy a service with a multi-byte character set name, you see the service listed but receive an error when trying to view the service details.
Name ESB services using supported US-ASCII characters.
For more information about this issue, refer to Oracle bug 5411159.
If you rename an ESB resource file using Oracle JDeveloper's File > Rename or right-click rename functionality, references to that file are not updated in other resource files. After renaming an ESB resource file, you must manually change the references to that file wherever those references occur.
For more information about this issue, refer to Oracle bug 8605755.
When you delete an outbound service from an ESB project in Oracle JDeveloper and the service is also deployed on the ESB server, redeploying the project from Oracle JDeveloper does not removed the deleted service from the server.
When you delete a service in Oracle JDeveloper, make sure you also do the following:
Before you redeploy the project, delete routing rules to that service in your ESB flows.
Before you redeploy the project, delete the WSDL for that service in JDeveloper.
In the ESB Console, manually delete the service you deleted in JDeveloper.
For more information about this issue, refer to Oracle bug 8610058.
ESB sends rejected messages to the following directory: ORACLE_HOME/j2ee/home/jca/DefaultSystem.ReadS_RS.receive/rejectedMessages/.
For more information about this issue, refer to Oracle bug 8632308.
After a Resequencer operation begins, an abrupt server shutdown causes incomplete resequencing. Only a portion of the records are resequenced. Because of this abrupt failure, the group remains locked by a container, which has gone down. In a cluster environment, the Resequencer infrastructure on the other running nodes identifies the shutdown servers, automatically unlocks the group by pinning it to a live node, and, if the group is healthy, resumes processing. The state of the group is maintained. Resumed processing takes some time, which can be equal to or greater than value specified in ResequencerContainerIdLeaseTimeout property in esb_config.ini.
If a group goes into error state, it remains in error state until you unlock it. To unlock groups in an error state, execute the resequencer_restart_processing_group.sql script in <ORACLE_HOME>/integration/esb/sql/oracle folder.
For more information about this issue, refer to Oracle bug 8665217.
When you use the ESB Resequencer, you can specify a ResequencerTimeout endpoint property value (the default value is no limit). ResequencerTimeout lets you lock the groups for which a "next in sequence" message is not received after a specified time. When running heavy loads with a relatively small ResequencerTimeout set, groups yet to be processed can be prematurely locked and cannot be processed.
To avoid group locking based on a ResequencerTimeout, either increase the time of the timeout or do not specify a time value (default) so that no timeout occurs.
To unlock groups that were locked due to a ResequencerTimeout, execute the resequencer_restart_processing_group.sql script in <ORACLE_HOME>/integration/esb/sql/oracle folder.
For more information about this issue, refer to Oracle bug 8673539.
In a high availability environment, including an environment with multiple OC4J containers (or nodes), if an OC4J container crashes, any Resequencer groups being processed by that container continue to be processed by the surviving container. The groups continue to be processed on the surviving container even after the crashed container is restarted. Resequencer messages with new groups that arrive after the crashed container is restarted can be processed by either container.
For more information about this issue, refer to Oracle bug 8764008.
In advanced search, ESB throws an exception when you try to search for activity that occurred a certain number of seconds ago. To work around this issue, perform an activity search using a larger unit of time, such as minutes or hours.
For more information about this issue, refer to Oracle bug 8639976.
In prior releases, artifacts in the Web-based Distributed Authoring and Versioning (WebDAV) slide repository were not deleted when a project or service was deleted.
With this release, you can set the webDAV_delete property to true in the esb_config.ini file (the default setting is false). Then, restart the ESB server. These actions delete the artifacts directory whenever you redeploy an Oracle Enterprise Service Bus project from Oracle JDeveloper or ant. The unused artifacts are removed, leaving you with only up-to-date artifacts.
If you do not set this parameter to true, some artifacts present in the redeployed projects are updated and other artifacts are left untouched.
Note that artifacts are not deleted from the slide repository when you delete the service from Oracle ESB Control, because these artifacts may be referred to by other services.
When you delete an outbound service from an ESB project in Oracle JDeveloper and the service is also deployed on the ESB server, redeploying the project from Oracle JDeveloper does not remove the deleted service from the server.
When you delete a service in Oracle JDeveloper, make sure you also do the following:
Before you redeploy the project, delete routing rules to that service in your ESB flows.
Before you redeploy the project, delete the WSDL for that service in Oracle JDeveloper.
In Oracle ESB Control, manually delete the service you deleted in Oracle JDeveloper.
For more information about this issue, refer to Oracle bug 8669306.
When using the lookup-dvm function in Oracle JDeveloper to perform a domain-value map (DVM) lookup, the function does not automatically provide the orcl namespace. You must manually add the orcl namespace to the function.
For example, in the following lookup-dvm function, you must manually insert the highlighted namespace:
{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 }
For more information about this issue, refer to Oracle bug 8722231.
When attempting to perform a graceful shutdown of OPMN services using the opmnctl stopall command, a forceful shutdown occurs instead.
The recommended workaround is to increase the stop timeout in opmn.xml. You can also use the opmnctl shutdown command to gracefully shut down OPMN services.
For more information about this issue, refer to Oracle bug 8682471.
This section describes ESB documentation issues and workarounds.
The 10.1.3.4 Oracle Application Server Release Notes section on "ESB Logging Enhancement" uses the following incorrect example for adding the implementation class to the ESB classpath: server.xml/esb.common.
The correct classpath example should be: server.xml/oracle.bpel.common.
For more information about this issue, refer to Oracle bug 8230137.
This section describes issues and workarounds specific to using Oracle SOA Suite with Oracle WebLogic Server:
Section 6.15.1, "WebLogic Server Throws Stuck Thread Warning"
Section 6.15.3, "WebLogic Server Does Not Set MIME Content-Type"
ESB gets threads from WorkManager for polling incoming messages. These threads are daemon threads and once started, they are never returned back to the WorkManager. For ESB running on WebLogic Server, these threads are considered as stuck threads if they are not returned back for a period exceeding the default value of the StuckThreadMaxTime parameter of WebLogic Server, that is, 600 seconds and the Server starts showing warning messages about the stuck threads.
You can work around this issue by setting the value of the StuckThreadMaxTime parameter of WebLogic Server to a higher value, such as 14400 seconds, to delay the terming of these threads as stuck threads.
When an ESB process invokes a BPEL process through routing services, the BPEL process fails with the following errors displayed in the log file:
... "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"
This is because ESB at runtime tries to fetch an encrypted password from the admin.encrypted.password property available in the ant-orabpel.properties file and this property is not present in the file by default.
You can fix this issue by performing the following steps:
Encrypt the password for the admin.encrypted.password property by using the command prompt. For example, for setting the password to oracle, use the following commands:
[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
This will generate the encrypted password like the following:
WCRx6zgvsHh9yCswMh6hgQ==
Locate the SOA_HOME/bpel/utilities/ant-orabpel.properties file and perform a backup of the file.
Open the ant-orabpel.properties file and update it in the following way:
Comment out the admin.password property by placing a number sign (#) before it, if an entry for the property is available.
Add an entry for the admin.encrypted.password property with the value obtained on step 1. For example,
admin.encrypted.password = WCRx6zgvsHh9yCswMh6hgQ==
Restart the managed server from the WebLogic Server console.
WebLogic Server does not set content-type for files with .js and .xml extensions.
To work around this issue, you have to configure these mime types in your environment using one of the following two methods:
Method 1
Add these mime types in the web.xml file of the ESB Web Application.
Method 2
Set the mime type for the entire domain in the config/mimemapping.properties file by performing the following steps:
Login to the WebLogic Server console at
Click Domain, then Configuration, and then Web Applications.
Search for the Mime parameter.
The value of this parameter shows the location of the mimemappings.properties file.
Create the mimemappings.properties file if the file is not present already.
Add the following entries in the mimemappings.properties file:
xml=text/xml js=text/javascript
Restart the SOA Managed Servers.