This chapter provides important supplementary information upgrading Oracle SOA applications to Oracle Fusion Middleware 11g.
Use Chapter 8, "Overview of Upgrading Oracle SOA Suite, WebCenter, and ADF Applications" for the tasks required to upgrade any Oracle SOA Suite, WebCenter, and ADF application.
Use the following sections to understand tasks specific to upgrading Oracle SOA applications:
Refer to the following sections for information about upgrading Oracle Enterprise Service Bus 10g to Oracle Mediator 11g:
Upgrading Oracle Enterprise Service Bus Routing Rules That Are Not Exposed as Services
Upgrading Oracle Enterprise Service Bus Domain Value Maps (DVMs) and Cross References
Upgrading Oracle Enterprise Service Bus Projects with SOAP Headers to Oracle Mediator 11g
Upgrading Filter, Transformation, or Setting Message Headers in Oracle Enterprise Service Bus
Using the Sync From ESB Server Command Before Upgrading ESB Projects
If you upgrade an Oracle Enterprise Service Bus 10g project that contains an ESB routing service that is not exposed as a Web service, then the routing service and related composites cannot be invoked after upgrade.
To resolve this issue, modify the routing service in Oracle Mediator 11g so it is exposed as a Web service. For more information, see "Creating Mediator Routing Rules" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Alternatively, you can ensure that all routing services in your Oracle Enterprise Service Bus 10g projects are exposed as Web services before you begin the upgrade process.
If you use domain value maps in your and Oracle Enterprise Service Bus 10g projects, then note that while the xPath functions for DVMs and cross-references are upgraded automatically, you must perform a post-upgrade task to upgrade the DVM and cross reference metadata to 11g.
For more information, see Section 9.4.9.7, "Upgrading Domain Value Maps (DVMs) and Cross References (XREFs) in the ESB Repository".
If you used XSLT functions to manipulate SOAP headers in Enterprise Service Bus (ESB) 10g, then after you upgrade your application, those header manipulation will be modeled as assignments in Oracle Mediator 11g.
For complex header manipulations, you should manually verify the SOAP headers before deploying the upgraded Oracle Mediator 11g projects.
For more information, see "Creating Static Routing Rules" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
In Oracle Enterprise Service Bus 10g, there was no support for asynchronous routing services. Instead, when Oracle Enterprise Service Bus called an Oracle BPEL Process Manager asynchronous process, then a OneWay service was created.
If you created a project that uses such a OneWay service, then after you open and upgrade the application in Oracle JDeveloper 11g, you can remove the old routing service and recreate the routing service to use an Oracle Mediator 11g asynchronous routing instead of the OneWay invocation.
Oracle Enterprise Service Bus 10g supports filtering or setting message headers for standard and custom header properties for adapters, such as SOAP, JCA, JMS, and AQ adapters. Filtering in Oracle Enterprise Service Bus is done as part of the <filterExpression> tag of the routing rule.
Many filter expressions are automatically upgraded, but for complex filters, the upgrade might be partial.
When you open your Oracle Enterprise Service Bus projects in Oracle JDeveloper 11g, each routing rule is upgraded into case, and the filter expression is converted to condition. These changes can be found in the mplan file of the Routing Service.
For example, the following code snippet shows the filter expression in an Oracle Enterprise Service Bus 10g routing rule:
<filterExpression>{ehdr:getRequestHeader
('/fhdr:InboundFileHeaderType/fhdr:fileName') = 'Mobile.xml'};{ namespace
fhdr=http://xmlns.oracle.com/pcbpel/adapter/file/ namespace
ehdr=http://www.oracle.com/XSL/Transform/java
/oracle.tip.esb.server.headers.ESBHeaderFunctions }
</filterExpression>
During upgrade, this example is converted to the equivalent condition of the case in the mplan file:
<condition language="xpath" xmlns:ehdr="http://www.oracle.com/XSL
/Transform/java/oracle.tip.esb.server.headers.ESBHeaderFunctions"
xmlns:fhdr="http://xmlns.oracle.com/pcbpel/adapter/file/">
<expression>$in.property.jca.file.FileName ='Mobile.xml'</expression>
</condition>
Setting message headers is accomplished as part of the transformation files and these are upgraded to assign statements.
The following code snippet shows an example of setting message headers in Oracle Enterprise Service Bus 10g:
<xsl:variable name="inputCountry" select="/imp1:CustomerData/Country"/>
<select="ehdr:setOutboundHeader
('/jhdr:JMSOutboundHeadersAndProperties
/jhdr:JMSOutboundProperties/jhdr:Property[position()=1]/@value',$inputCountry,
'jhdr=http://xmlns.oracle.com/pcbpel/adapter/jms/;')"/>
During upgrade, this example is converted to the following equivalent assign element in 11g:
<assign>
<copy expression="$in.CustomerData/CustomerData/Country"
target="$out.CustomerData/jhdr:JMSOutboundHeadersAndProperties
/jhdr:JMSOutboundProperties/jhdr:Property[position()=1]/@value"/>
</assign>
You must verify if the filters and XSL are upgraded successfully. Most of the standard header properties are upgraded to their equivalent 11g headers. Customized headers are upgraded using a best effort approach, but it is not possible to upgrade all the variations of customized headers. As a result, you must manually upgrade any customized headers to the equivalent condition or assign element and equivalent mplan artifacts.
The following are the ESB header functions which were available in 10g, are deprecated in 11g as they are not supported in 11g:
ehdr:getRequestHeader
ehdr:setRequestHeader
Filter expressions that contain ehdr headers are automatically migrated. However, all the customized filters cannot be migrated automatically.
The setHeader function that was available in 10g is not supported in 11g.
In XSL, if the deprecated functions does not fall under the conditional elements like if, for, and so on, they are migrated to the mediator assign, and hence, the same behavior is achieved. In this case, the content of XSL is removed and migrated to mediator assign, that is, it is moved from .xsl to .mplan file. This applies for recognized headers.
In XSL, if the deprecated functions fall under the conditional elements like if, for, and so on, the recognized headers are migrated to 11g property, however this does not guarantee the successful migration. In this case, the migration happens in .xsl file, and the content is not moved to .mplan file. Hence, you must manually migrate the conditions in the XSL file if they are not already migrated. For example:
In 10g,
<xsl:if test="$INFILENAME!=''">
<xsl:variable name="OUTFILENAME"
select="ehdr:setOutboundHeader('/fhdr:OutboundFileHeaderType/fhdr:fileName', 'sample.xml', 'fhdr=http://xmlns.oracle.com/pcbpel/adapter/file/;')"/>
</xsl:if>
In 11g,
<xsl:if test="$INFILENAME!=''">
<xsl:variable name="OUTFILENAME"
select="mhdr:setProperty('out.property.jca.file.FileName', 'sample.xml')"/>
</xsl:if>
When you upgrade the deprecated functions that fall under the conditional elements, the following warning is displayed in the upgrade logs:
"WARNING: UPGMED-02060: Encountered XSL conditional element like xsl:if or xsl:for-each. All ehdr functions may not be migrated properly from the XSL. Manually check the XSL PSFTProduct_To_SFOStoreProduct.xsl and modify accordingly"
For more information, see "Getting Started with Oracle Mediator" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
To avoid issues when upgrading your Oracle Enterprise Service Bus 10g projects to Oracle SOA Suite 11g, make sure that you have synchronized the services on the ESB server with the services currently in your ESB Oracle JDeveloper project.
To perform this task:
Click the Sync from ESB Server icon at the top of the Design tab in Oracle JDeveloper 10g.
Click Yes in the Confirm Sync from ESB Server dialog.
For more information, see "Syncing Services From ESB Server" in the Oracle Enterprise Service Bus Developer's Guide, which is available in the Oracle Application Server 10g Release 3 (10.1.3.1.0) on the Oracle Technology Network (OTN):
http://www.oracle.com/technology/documentation/middleware.html
The following sections describe upgrade tasks you might need to perform when upgrading Technology Adapters to Oracle Fusion Middleware 11g:
Verifying Adapters with the Oracle JDeveloper 11g Adapter Configuration Wizard
Upgrading Non-Managed Connection Information in the Adapter JCA File
Additional Step When Upgrading Database Adapters Using Command Line
After upgrading your Oracle SOA Suite 10g projects to Oracle SOA Suite 11g, Oracle recommends that you use the adapter configuration wizard to verify the upgrade of your technology adapters. This will ensure that all required fields in your 11g are populated and that the adapter connections to your new Oracle Fusion Middleware 11g environment are valid.
For more information, see the information the specific adapters you are using in the Oracle Fusion Middleware User's Guide for Technology Adapters.
After you upgrade an application that uses adapter headers, you will likely receive an error after you open the application in Oracle JDeveloper 11g. The error will indicate that a variable or parameter was not recognized while it was parsing a header function.
This is caused by a change in the way adapter header variables are defined in Oracle Fusion Middleware 11g.
In Oracle Application Server 10g Release 3 (10.1.3), you create adapter header variables in a wsdl file that has a name such as the following, or a similar name for the direction and adapter type you are using:
fileAdapterOutboundHeader.wsdl
In Oracle Fusion Middleware 11g, adapter header variables are now properties that you set on the Properties tab of the Invoke dialog box in Oracle JDeveloper.
For example, the properties you can set for the JCA Adapter for Files/FTP are described in the section, "Inbound Headers" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
After you open your project in Oracle JDeveloper 11g, the wsdl header files you created for Oracle Application Server 10g will no longer be attached to the project. You must define each of the variables in the wsdl files as properties for each adapter type that uses header variables.
For more information, refer to the appropriate chapter for each adapter type in the Oracle Fusion Middleware User's Guide for Technology Adapters.
In Oracle Application Server 10g, you can use non-managed connections in the JCA file to point to your development resources. For example, data source definitions can be specified using the non-managed-connection element in the JCA file.
In Oracle Application Server 10g, using non-managed connections was reserved for development only. In Oracle Fusion Middleware 11g, non-managed connections are not supported.
Ideally, before upgrading your Oracle Application Server 10g projects to Oracle Fusion Middleware 11g, you should already be using JCA files that include only JNDI references to connections that are defined properly in the datasources.xml or oc4j-ra.xml files.
If you attempt to upgrade applications that use non-managed connections for adapter connections, you must modify the projects after upgrade to use proper connections defined by using supported administration tools, such as the Oracle WebLogic Server Administration Console.
If you created an 10g Release 3 (10.1.3) technology adapter using the Adapter Configuration Wizard, and you entered a description for the adapter in the Description field of the wizard, the description will be lost when you open and migrate the project in Oracle JDeveloper 11g.
This is because the documentation element in removed from the WSDL file during the upgrade.
If the adapter is important, you can use the Oracle JDeveloper 11g Adapter Configuration Wizard to add the description after you have upgraded the project.
In Oracle SOA Suite 10g, if you used the MQSeries Adapter inbound synchronous request-reply use case, you will notice that there is only one message type, which is REQUEST.
In Oracle SOA Suite 11g, the MQAdapter supports two message types: REQUEST and NORMAL. The REQEUST MQ message type always has replyToQueue set on its header so there is no need for FallbackQueueName and FallbackQueueManagerName. On the other hand, a NORMAL Message may or may not have FallbackQueueName and FallbackQueueManagerName.
So, when a 10g inbound synchronous request-reply scenario is upgraded to 11g, then the Message Type remains as REQUEST type. Therefore, at runtime, there is no need for FallbackQueueName and FallbackQueueManagerName, even though these properties would resides in the .jca file. If you want to use these properties, you must set the message type to NORMAL.
For more information about the inbound synchronous request-reply use case, see "Oracle MQ Series Adapter Use Cases" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
If you used the MQSeries Adapter outbound dequeue use case, which was a documented use case scenario in 10g Release 3 (10.1.3), then note that these types of projects cannot be upgraded by Oracle JDeveloper 11g.
Instead, you must recreate these types of projects after the upgrade to Oracle JDeveloper 11g. While recreating the project you must ensure that you set the value for UITransmissionPrimitive to SynchronousDequeue.
For more information, see "Outbound Dequeue Scenario" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
If you are upgrading an application that uses the Oracle Application Server Adapter for Advanced Queuing (AQ adapter), then note that the AQ Adapter header is accessed differently in Oracle Fusion Middleware 11g.
Specifically, you must perform the following post-upgrade steps for AQ adapter headers after you upgrade to Oracle SOA Suite 11g. This procedure is required for both Oracle BPEL Process Manager and for Oracle Enterprise Service Bus projects that are upgraded to Oracle Mediator.
After upgrading to Oracle Mediator, assign the "jca.aq.HeaderDocument" value from inbound to outbound in the .mplan file of the Oracle Mediator file.
After upgrading to Oracle BPEL Process Manager 11g:
Define a new variable 'vInboundHeaders' of type string.
For example:
<variable name="vInboundHeaders" type="xsd:string"/>
In the receive activity, make sure that the jca.aq.HeaderDocument property gets written to the above variable.
For example:
<bpelx:property name="jca.aq.HeaderDocument"
variable="vInboundHeaders"/>
At the time of invocation, make sure that the "vInboundHeaders" value is copied back to the jca.aq.HeaderDocument property:
<invoke name="Invoke_1"
inputVariable="Invoke_1_Enqueue_InputVariable"
partnerLink="EnqueueClobPayload" portType="ns2:Enqueue_ptt"
operation="Enqueue">
<bpelx:inputProperty name="jca.aq.HeaderDocument"
variable="vInboundHeaders"/>
</invoke>
Use the following procedure when you are not using an AQ adapter, and as a result you are not obtaining the value of the jca.aq.HeaderDocument property. In this scenario, you must populate the property manually.
This involves two steps. Perform one step after you upgrade Oracle Enterprise Service Bus to Oracle Mediator 11g, and perform the second step after you upgrade to Oracle BPEL Process Manager 11g.
Note that these examples show how you might invoke Oracle B2B from the adapter header.
Example Steps to Perform After Upgrading to Oracle Mediator
After upgrading to Oracle Mediator, assign the jca.aq.HeaderDocument value from inbound to outbound in the .mplan file of the Oracle Mediator file.
For example:
<copy target="$out.property.jca.aq.HeaderDocument" expression="'<?xml
version = "1.0" standalone= "yes"?><tns:Header
xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/aq/outbound/">
<tns:PayloadHeader><MSG_ID><
/MSG_ID><INREPLYTO_MSG_ID><
/INREPLYTO_MSG_ID><FROM_PARTY>GlobalChips<
/FROM_PARTY><TOPARTY>Acme<
/TO_PARTY><ACTION_NAME></ACTION_NAME><DOCTYPE_NAME>ORDERS<
/DOCTYPE_NAME><DOCTYPE_REVISION>D98A<
/DOCTYPE_REVISION><MSG_TYPE>1<
/MSG_TYPE><PAYLOAD><
/PAYLOAD></tns:PayloadHeader></tns:Header>'"/>
Example Steps to Perform After Upgrading to Oracle BPEL Process Manager
After upgrading to Oracle BPEL Process Manager 11g:
Define a new variable "headerVariable" of type string.
For example:
<variable name="headerVariable" type="xsd:string"/>
Create an assign block, such as the one shown in Example 14-1.
At the time of invocation, make sure that the "headerVariable" value is copied back to the jca.aq.HeaderDocument property:
<invoke name="Send_PO" partnerLink="X12_4010_850_ENQ_Service"
portType="ns2:Enqueue_ptt"
operation="Enqueue"
inputVariable="Send_PO_Enqueue_InputVariable">
<bpelx:inputProperty name="jca.aq.HeaderDocument"
variable="headerVariable"/>
</invoke>
Example 14-1 Assign Block When Upgrading Adapter Headings
<assign name="assign header">
<copy>
<from expression="'<?xml version = "1.0"standalone = "yes"?><tns:Header
xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/">
<tns:PayloadHeader><MSG_ID>12345<
/MSG_ID><INREPLYTO_MSG_ID>54321<
/INREPLYTO_MSG_ID><FROM_PARTY>Acme<
/FROM_PARTY><TO_PARTY>GlobalChips<
/TO_PARTY><ACTION_NAME>contentType:application/octet-stream;
filename:abc.xml<
/ACTION_NAME><DOCTYPE_NAME>850<
/DOCTYPE_NAME><DOCTYPE_REVISION>4010<
/DOCTYPE_REVISION><MSG_TYPE>1</MSG_TYPE><PAYLOAD><
/PAYLOAD></tns:PayloadHeader></tns:Header>'"/>
<to variable="headerVariable"/>
</copy>
</assign>
Section 14.2.7, "Upgrading AQ Adapter Headers" describes how to use the jca.aq.HeaderDocument property that is required in Oracle Fusion Middleware 11g when your application needs to access Payload Headers. The procedure described in that section must be performed for all Oracle Application Server 10g BPEL and ESB processes that access the payload headers functionality.
Note that in addition to the information in Section 14.2.7, the target namespace of <Header> and <PayloadHeader> elements have changed Oracle Fusion Middleware11g Release 1 (11.1.1.3.0). As a result, for any BPEL and ESB processes that involve accessing payload headers and that were designed using Oracle SOA Suite 10g, you must use the adapter wizard to regenerate its service and reference artifacts, also known as partner links in Oracle Application Server 10g.
You must regenerate the artifacts so the correct target namespace is used for the definition of the <Header> element. This step is required in addition to the steps covered in Section 14.2.7 to access payload headers.
In addition, you must change any Assign and Transformations that use the <Header> element. If you do not perform this step, then a namespace mismatch between design time and runtime results in XPath failures, as well as message enqueue failures.
In Oracle Fusion Middleware 11g, the procedure you use to create AQ outbound request-reply scenarios for Oracle BPEL Process Manager projects has changed.
As a result, when you upgrade an Oracle SOA Suite 10g application that uses this scenario, the WSDL file that is created during the upgrade does not contain the required binding information.
To correct this problem, do the following after you open and upgrade the application in Oracle JDeveloper 11g:
Add the JCA entry to the WSDL file created by the upgrade, as follows:
<?binding.jca CombinedRequestReply_aq.jca?> <wsdl:definitions name="CombinedRequestReply" ... > . . . </wsdl:definitions>
Add the binding entry in the composite.xml file:
<reference ui:wsdlLocation="CombinedRequestReply.wsdl"
name="CombineRequestReply">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel
/adapter/aq/EnqueueRequest/#wsdl.interface(Enqueue_ptt)"
callbackInterface="http://xmlns.oracle.com/pcbpel
/adapter/aq/DequeueReply/#wsdl.interface(Dequeue_ptt)"
xmlns:ns="http://xmlns.oracle.com/sca/1.0"/>
<binding.jca config="CombinedRequestReply_aq.jca"/>
</reference>
Remove any unused WSDL references from the .bpel file.
As described in Section 9.2, "About Using the Oracle JDeveloper 11g Migration Wizard for Oracle SOA Suite Applications", Oracle recommends that you apply the latest patch sets to your Oracle SOA Suite environment and use the latest 10g Release 3 (10.1.3) Oracle JDeveloper before upgrading to 11g.
However, if you are upgrading from 10g Release 3 (10.1.3.3) or earlier, note the following if you are using a database adapter for stored procedures.
In Oracle SOA Suite 10g Release 3 (10.1.3.3) and earlier, the XSD generator of the adapter generated an XSD that contained unqualified elements. You can identify unqualified elements by viewing the InputParameters root element in the XSD file. The unqualified element appears as follows:
<db:InputParameters ... ></db:InputParameters>
The db: namespace is specified in the definition of the schema, which is the same as the target namespace.
In 10g Release 3 (10.1.3.4) and later, the XSD generator generates qualified elements, which appear as follows in the InputParameters root element:
<InputParameters ..></InputParameters>
Note that the db: namespace has been removed.
If you were using a version of Oracle JDeveloper 10g Release 3 (10.1.3) that was incompatible with the Oracle SOA Suite version, you could also encounter a scenario where the elements are removed:
<null>(some value)</null>
The solution is as follows:
First, make sure that you are using a version of Oracle JDeveloper that matches the version of your Oracle SOA Suite environment.
Second, after you upgrade to Oracle JDeveloper and Oracle SOA Suite10g Release 3 (10.1.3.4) or to Oracle SOA Suite and Oracle JDeveloper 11g, regenerate the XSD.
After you upgrade and regenerate the XSD, you must then modify any related assign activities and any xPath expressions accordingly.
When you upgrade Database Adapter 10g projects using command line, the upgrade plug-in changes DBAdapterOutboundHeader.wsdl to DBAdapterOutboundHeader.wsdl.orig post upgrade. You must manually rename DBAdapterOutboundHeader.wsdl.orig to DBAdapterOutboundHeader.wsdl.
DBAdapterOutboundHeader.wsdl.orig file can be found in the directory where you have composite.xml file.
Note:
This task is not required when you upgrade Database Adapter using JDeveloper.The following upgrade tasks should be considered when you are upgrading Oracle SOA Suite applications that use human workflow tasks:
Upgrading Task Details for an Associated Human Workflow Task
Upgrading Multiple Projects That Share a Common Human Workflow Task
When you are upgrading Oracle SOA Suite 10g applications that include task details for a human task, note the following:
In Oracle SOA Suite 10g Release 3 (10.1.3), task details were generated inside same composite project and was deployed during composite deployment.
In Oracle SOA Suite 11g, task details are generated as a separate project that must be deployed separately.
As a result, during the upgrade of Oracle Human Workflow, Oracle JDeveloper 11g automatically creates a new project for the task details UI and upgrades the task detail pages. You must then deploy this project separately, after deploying the associated composite application.
If you are upgrading an application that contains multiple Oracle JDeveloper projects that share a common human workflow task, then be sure to review the upgraded application carefully in Oracle JDeveloper 11g.
In some cases, because the projects are moved into a common directory during the upgrade, data associated with the workflow task in one project may overwrite data from another project if the workflow task in the second project uses the same name.
When you are prompted to migrate Oracle SOA Suite 10g project to 11g in Oracle JDeveloper, ensure that you create the application in a different directory than the SOA project. If the application and SOA project are in the same directory, and you deploy the composite, the regenerated task flow in the composite is not successfully displayed in Oracle BPM Worklist.
To ensure successful deployment, perform the following steps:
Open an Oracle SOA Suite 10g project in Oracle JDeveloper 11g.
The Create Application to Contain Project dialog is displayed.
Specify a different directory for the application than the directory in which the SOA project is located, and click OK. The Migration Wizard is displayed.
Migrate the 10g project to an 11g format.
Regenerate the task flow.
Deploy the SOA composite application with the newly generated task flow. Verify that the deployment is successful.
Invoke an instance of the SOA composite application in Oracle Enterprise Manager.
Log in to Oracle BPM Worklist.
Click the task to view the task details, which are correctly displayed. Note that if you had specified the same directory for the application and SOA project in Step 2, the following exception would have been displayed.
OracleJSP error: java.io.FileNotFoundException:
If you use Oracle JDeveloper 11g to upgrade an application with human workflow tasks, and then use the Task Editor to edit the task file, Oracle JDeveloper automatically generates a new payload XSD file.
However, the existing WorkflowTask XSD file contains references to the payload XSD file used in the 10g version of the application.
To fix this problem, edit the WorkflowTask XSD file to be sure it references the new payload XSD file.
For example:
Change the following entry from:
<include schemaLocation="***_payload.xsd" xmlns=""/>
To:
<include schemaLocation="***Payload.xsd" xmlns=""/>
Change the following entry from:
<element name="payload" type="tns:payloadType" minOccurs="0"maxOccurs="1"/>
To:
<element name="payload" type="tns:***PayloadType" minOccurs="0"maxOccurs="1"/>
In these examples, replace the asterisk with the appropriate name and type defined in the payload XSD file.
When you upgrade projects that use Oracle Business Rules, refer to the following documentation resources:
While you are in the process of upgrading your Oracle SOA Suite applications to 11g, and while your Oracle SOA Suite 10g environment is still up and running, you should begin to review, upgrade, and test the client applications that depend upon your Oracle SOA Suite environment.
Use the following list to analyze your client applications for required updates that will allow them to work with your newly upgraded 11g Oracle SOA Suite environment:
Review the client applications to understand which remote Oracle SOA Suite APIs they are using.
For more information, refer to Section 9.4.1, "Understanding Oracle SOA Suite API Changes for Oracle Fusion Middleware 11g".
Search your client applications for any references to Oracle SOA Suite HTTP URLs. The syntax of the Oracle SOA Suite 11g HTTP URLs has changed from 10g.
To obtain the new URL that a client can use to access a deployed Oracle SOA Suite 11g application, use the home page of the application deployment in Oracle Enterprise Manager Fusion Middleware Control. For more information, see "Monitoring SOA Composite Applications" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.
Review your client applications for references to message targets, such as JMS queues and data source. Any references to these resources must be updated to point to the upgraded, Oracle SOA Suite 11g environment.
If a client application is using Oracle Service Bus (OSB) to invoke an Oracle BPEL Process Manager process with the optimized transport, you must modify the client application so it uses SOAP/HTML to invoke the Oracle BPEL Process Manager process.
For more information, see the Oracle Service Bus 10g Release 3 (10.3) documentation, which is available on the Oracle Technology Network (OTN):
http://www.oracle.com/technology/documentation/bea.html