Skip Headers
Oracle® Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter Portal, and ADF
11g Release 1 (11.1.1.6.0)

Part Number E10127-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

14 Upgrading Other Oracle SOA Suite Technologies

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:

14.1 Upgrade Tasks Associated with Oracle Enterprise Service Bus

Refer to the following sections for information about upgrading Oracle Enterprise Service Bus 10g to Oracle Mediator 11g:

14.1.1 Upgrading Oracle Enterprise Service Bus Routing Rules That Are Not Exposed as Services

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.

14.1.2 Upgrading Oracle Enterprise Service Bus Domain Value Maps (DVMs) and Cross References

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.8.7, "Upgrading Domain Value Maps (DVMs) and Cross References (XREFs) in the ESB Repository".

14.1.3 Upgrading Oracle Enterprise Service Bus Projects with SOAP Headers to Oracle Mediator 11g

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.

14.1.4 Upgrading Projects with Multiple Routing Services That Use the Same Namespace

Oracle Enterprise Service Bus 10g supports multiple routing services that have WSDLs that reference the same targetNameSpace within a single ESB project.

For example, at least one of the sample 10g applications available on the Oracle Technology Network (the samples_102_responseForward sample application) supported this scenario.

However, Oracle Mediator 11g no longer supports this configuration. During the upgrade of the application in Oracle JDeveloper 11g, whenever a second service is found to have the WSDL pointing to the same targetNameSpace, the namespace is modified by suffixing _service-qname to the namespace. In addition, a warning message is added to the log file.

For example, in the Samples_102_ResponseForward sample application, the targetNameSpace of the service DispatchShipmentDetails is:

@ http://oracle.com/esb/namespaces/Samples_102_ResponseForward

After the upgrade of the application, it appears as follows:

@ http://oracle.com/esb/namespaces/
  Samples_102_ResponseForward_Samples.102_ResponseForward.DispatchShipmentDetails

In this example, Samples.102_ResponseForward.DispatchShipmentDetails is the qname of service DispatchShipmentDetails.

14.1.5 Upgrading Routing Services to Use Asynchronous Routing

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.

14.1.6 Upgrading Filtering or Setting Message Headers in Oracle Enterprise Service Bus

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 t in 11g:

<assign>
    <copy expression="$in.CustomerData/CustomerData/Country"
          target="$out.CustomerData/jhdr:JMSOutboundHeadersAndProperties
          /jhdr:JMSOutboundProperties/jhdr:Property[position()=1]/@value"/>
</assign>

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 the equivalent condition or assign element and equivalent mplan artifacts.

For more information, see "Getting Started with Oracle Mediator" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

14.1.7 Using the Sync From ESB Server Command Before Upgrading ESB Projects

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:

  1. Click the Sync from ESB Server icon at the top of the Design tab in Oracle JDeveloper 10g.

  2. 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

14.2 Upgrade Tasks Associated with Technology Adapters

The following sections describe upgrade tasks you might need to perform when upgrading Technology Adapters to Oracle Fusion Middleware 11g:

14.2.1 Verifying Adapters with the Oracle JDeveloper 11g Adapter Configuration Wizard

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.

14.2.2 Upgrading Adapter Header Variables

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.

14.2.3 Upgrading Non-Managed Connection Information in the Adapter JCA File

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.

14.2.4 Description Lost After Upgrade of Technology Adapter

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.

14.2.5 Upgrading an Inbound Synchronous Request-Reply Use Case

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.

14.2.6 Upgrading Projects That Use Outbound Dequeue

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.

14.2.7 Upgrading AQ Adapter Headers

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:

    1. Define a new variable 'vInboundHeaders' of type string.

      For example:

      <variable name="vInboundHeaders" type="xsd:string"/>
      
    2. 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"/>
      
    3. 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>
      

14.2.8 Additional Steps When Upgrading Technology Adapter Headers

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="'&lt;?xml version =
  &quot;1.0&quot; standalone= &quot;yes&quot;?>&lt;tns:Header
  @ xmlns:tns=&quot;http://xmlns.oracle.com/pcbpel/adapter/aq/outbound/">
  <tns:PayloadHeader>&lt;MSG_ID>&lt;
     /MSG_ID>&lt;INREPLYTO_MSG_ID>&lt;
     /INREPLYTO_MSG_ID>&lt;FROM_PARTY>GlobalChips&lt;
     /FROM_PARTY>&lt;TOPARTY>Acme&lt;
     /TO_PARTY>&lt;ACTION_NAME>&lt;/ACTION_NAME>&lt;DOCTYPE_NAME>ORDERS&lt;
     /DOCTYPE_NAME>&lt;DOCTYPE_REVISION>D98A&lt;
     /DOCTYPE_REVISION>&lt;MSG_TYPE>1&lt;
     /MSG_TYPE>&lt;PAYLOAD>&lt;
     /PAYLOAD>&lt;/tns:PayloadHeader>&lt;/tns:Header>'"/>

Example Steps to Perform After Upgrading to Oracle BPEL Process Manager

After upgrading to Oracle BPEL Process Manager 11g:

  1. Define a new variable "headerVariable" of type string.

    For example:

    <variable name="headerVariable" type="xsd:string"/>
    
  2. Create an assign block, such as the one shown in Example 14-1.

  3. 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="'&lt;?xml version = &quot;1.0&quot;standalone = &quot;yes&quot;
  standalone = &quot;yes&quot;?>&lt;tns:Header
  @ xmlns:tns=&quot;http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/">
  <tns:PayloadHeader>&lt;MSG_ID>12345&lt;
     /MSG_ID>&lt;INREPLYTO_MSG_ID>54321&lt;
     /INREPLYTO_MSG_ID>&lt;FROM_PARTY>Acme&lt;
     /FROM_PARTY>&lt;TO_PARTY>GlobalChips&lt;
     /TO_PARTY>&lt;ACTION_NAME>contentType:application/octet-stream;filename:abc.xml&lt;
     /ACTION_NAME>&lt;DOCTYPE_NAME>850&lt;
     /DOCTYPE_NAME>&lt;DOCTYPE_REVISION>4010&lt;
     /DOCTYPE_REVISION>&lt;MSG_TYPE>1&lt;/MSG_TYPE>&lt;PAYLOAD>&lt;
     /PAYLOAD>&lt;/tns:PayloadHeader>&lt;/tns:Header>'"/>
     <to variable="headerVariable"/>
  </copy>
</assign>

14.2.9 Upgrading Composite Applications That Rely on Payload Header Functionality

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.

14.2.10 Upgrading an AQ Outbound Request-Reply Scenario

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:

  1. 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>
    
  2. 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>
    
  3. Remove any unused WSDL references from the .bpel file.

14.2.11 Upgrading Database Adapters Used for Stored Procedures

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.

14.3 Upgrade Tasks Associated with Human Workflow Tasks

The following upgrade tasks should be considered when you are upgrading Oracle SOA Suite applications that use human workflow tasks:

14.3.1 Upgrading Task Details for an Associated 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.

14.3.2 Upgrading Multiple Projects That Share a Common Human Workflow Task

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.

14.3.3 Editing Human Workflow Tasks After Upgrade

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.

14.4 Upgrade Tasks Associated with Oracle Business Rules

When you upgrade projects that use Oracle Business Rules, refer to the following documentation resources:

14.5 Upgrading Oracle SOA Suite Client Applications

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: