upgrading oracle soa suite 10g to 11g (whitepaper)

UPGRADING ORACLE SOA SUITE 10G TO 11G A White Paper prepared by Raastech for IOUG and presented at Collaborate 11

Author

Ahmed Aboulnaga

Copyright

Raastech 2011

UPGRADING ORACLE SOA SUITE 10G TO 11G

Raastech White Paper 2 / 33

INTRODUCTION

This white paper walks through an approach that assists in the complicated process of upgrading from Oracle SOA Suite 10g (10.1.3.x) to Oracle SOA Suite 11g (11.1.1.3+).

Although the phrases are used interchangeably in this paper, the effort from moving from Oracle SOA Suite 10g to 11g is both an upgrade and a migration. The upgrade is result of moving to a new version of the same product, namely to Oracle SOA Suite 11g. The migration is the process of converting existing SOA Suite 10g code to enable it to deploy and execute on SOA Suite 11g.

Thus, the two main aspects related to the upgrade process are typically:

Infrastructure upgrade

Code migration

This paper focuses on the code migration process, and in specific the migration of BPEL and ESB code to their 11g equivalents in the form of BPEL and Mediator composites. The process is sometimes unclear, laborious, and introduces risk as a result of the underlying code being altered.

The challenges of upgrading don’t end there. Several core concepts have fundamentally changed with the introduction of SOA Suite 11g, and there is not enough direction as to what to do. Understandably, the Oracle documentation cannot cover every possible scenario. Also, not every area is covered in this white paper, such as human workflow or business rules.

Applicable Versions

The majority of SOA Suite 10g installations run on Oracle Application Server while the majority of SOA Suite 11g installations run on Oracle WebLogic Server, thus several instructions documented in this paper are specific to those application servers.

This document can apply to most versions of Oracle SOA Suite 10g, including both 10.1.2.x and 10.1.3.x, but focuses mostly on upgrading to the following Oracle Fusion Middleware 11g components:

Oracle WebLogic Server 11g (10.3.3+)

Oracle SOA Suite 11g (11.1.1.3+)



Audience

This paper is intended for individuals who have prior development and/or administration experience with Oracle SOA Suite 10g, with a basic understanding of SOA Suite 11g, and thus is geared towards:

Oracle SOA Architects

Oracle SOA Developers

Oracle SOA Suite Administrators

Overview of the Raastech Upgrade Process

Raastech has developed an 8-step approach to upgrading from Oracle SOA Suite 10g to 11g. This white paper and its proposed underlying approach are not meant to replace the existing Oracle upgrade process or its documentation, but rather to augment it.

The upgrade approach is divided into the following 8 sequential steps:

1. Understand the Upgrade Process

2. Infrastructure Installation

3. Application Server Setup

4. Develop the Deployment Process

5. Import Artifacts to the MDS

6. Upgrade the Projects

7. Post-Upgrade Steps

8. Test

These steps will be described in varying detail throughout this white paper. But as shown here, we recommend performing certain infrastructure and configuration tasks (steps 2-5) before beginning the actual migration of the code itself (steps 6-7).



1. UNDERSTAND THE UPGRADE PROCESS

Prior to engaging in the upgrade project, it is important to gain an overall understanding of the upgrade process from existing Oracle documentation. Oracle has provided excellent documentation (referenced below) to assist you in the planning phase and points you to the appropriate technical documentation.

The Oracle Upgrade Approach

Oracle provides several documents that detail the entire upgrade effort, beginning at a high-level (as shown in Figure 1) and subsequently delving into details.

Review the following Oracle documentation prior to beginning the upgrade project:

Oracle Fusion Middleware Upgrade Planning Guide 11g Release 1 (11.1.1)

http://download.oracle.com/docs/cd/E17904_01/upgrade.1111/e10125/toc.htm

Oracle Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter, and ADF 11g Release 1 (11.1.1)


Oracle Fusion Middleware Developer’s Guide for Oracle SOA Suite 11g Release 1 (11.1.1)

http://download.oracle.com/docs/cd/E12839_01/integration.1111/e10224/title.htm

Goal of Step 1

Obtain an overall understanding of the upgrade process by reviewing current Oracle documentation.

Review the various Oracle documents referenced in this section to gain a better understanding of the overall upgrade process.



http://download.oracle.com/docs/cd/E12839_01/integration.1111/e10224/title.htm



Figure 1 below provides a flow diagram of the main steps involved in the upgrade process. This approach is correct and the Oracle documentation does a good job of pointing you to other resources, but there are specific details missing that are addressed later in this white paper.

http://download.oracle.com/docs/cd/E17904_01/upgrade.1111/e10127/summary.htm#BABCFIEA

Figure 1. The Oracle Upgrade Process

http://download.oracle.com/docs/cd/E17904_01/upgrade.1111/e10127/summary.htm#BABCFIEA



2. INFRASTRUCTURE INSTALLATION

Though we do not walk through details regarding the infrastructure architecture, high availability setup, or cutover approach, this step in the process is meant to emphasize the fact that both the SOA Suite 10g and the newly installed SOA Suite 11g environments used for development should be running in parallel duration of the code upgrade effort. The same applies to Test, QA, and ultimately Prod environments, until the actual cutover is completed.

Install Oracle SOA Suite 11g

Installing Oracle SOA Suite 11g (11.1.1.4) in a single-node architecture is rather straightforward and typically takes between 1 to 2 hours. The product stack is installed in the following order:

Install Oracle Database 11g (11.2.0.x)

Install Oracle WebLogic Server 11g (10.3.4)

Create SOA database schemas using the Repository Creation Utility (RCU) 11g

Install Oracle SOA Suite 11g (11.1.1.4)

Create SOA domain

Refer to the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite 11g Release 1 (11.1.1) for details regarding high availability:

http://download.oracle.com/docs/cd/E12839_01/core.1111/e12036/toc.htm

Goal of Step 2

Ensure that both the Oracle SOA Suite 10g and 11g environments are accessible during the upgrade effort.

Since Oracle SOA Suite 11g is a new installation (not an in-place upgrade of the existing SOA Suite 10g), it is possible to maintain both environments temporarily, until the entire upgrade project is completed.

http://download.oracle.com/docs/cd/E12839_01/core.1111/e12036/toc.htm



Maintain Existing Oracle SOA Suite 10g Environment

Upgrading the Oracle SOA Suite 10g infrastructure to 11g involves installing a completely new stack, as it is not an in-place upgrade (i.e., the existing 10g infrastructure is untouched). Thus, once developers upgrade their SOA 10g code, it will be deployed on to a completely new environment. This simplifies the development, testing, and cutover process.

Keep the following in mind when setting up your development environment:

Data sources and connection factories for both the 10g and 11g infrastructures can point to same targets.

Turn off all services on the 10g infrastructure that does polling (e.g., JMS Adapter consume, AQ Adapter dequeue, DB Adapter polling). If not, polling services will compete on both the old and new infrastructures.

Validation also becomes easier for developers. Simply submit the same payload to both the old and new environments, and confirm that results are identical on both environments.



3. APPLICATION SERVER SETUP

Certain setup must be performed on the 11g application server prior to upgrading your code. All out-of-the-box configurations need not be touched, and only custom configuration will need to be set identically in the new environment. This mostly includes data sources and connection factories.

Partitions are a concept introduced with Oracle SOA Suite 11g (11.1.1.3), which helps better organize where to deploy your composites, and is addressed in the section. Any custom properties will also have to be migrated.

Migrate Custom Data Sources and Connection Factories

Data sources and Connection Factories are used by SOA code to connect to a resource or target system (e.g., AQ, JMS, database, etc.) without having the need to hardcode passwords within your code.

For example, your SOA projects may be leveraging custom created JNDIs that take the following format:

jdbc/db/PerfTest

eis/db/PerfTest

Goal of Step 3

Migrate all custom configuration from Oracle Application Server 10g to Oracle WebLogic Server 11g.

All custom application server and SOA server configuration that is required

for use by your SOA code should be migrated (manually) from Oracle Application Server 11g to Oracle WebLogic Server 11g.



1. Custom data sources are configured in Oracle Application Server 10g via the EM console by navigating the following screens:

Cluster Topology oc4j_soa Administration JDBC Resources

Figure 2. Page displaying the list of data sources in Oracle Application Server 10g

2. In Oracle WebLogic Server 11g, navigate to the following page to create all custom data sources using the same names and settings:

soa_domain Services Data Sources

Figure 3. Page displaying the list of data sources in Oracle WebLogic Server 11g



3. Navigate to the following screens to get a list of all Connection Factory in Oracle Application Server 10g via the EM console:

Cluster Topology oc4j_soa Applications default (adapter) Connection Factories

4. Navigate to the following screens to create the equivalent Connection Factory in Oracle WebLogic Server 11g:

soa_domain Deployments (Adapter) Configuration Outbound Connection Pools

Create Partitions (as a substitute for BPEL Domains)

BPEL domains in 10g are used to group BPEL processes. Each BPEL domain has its own configuration and logging, and is created by logging in to the BPEL Admin console at a url similar to the following:

http://soasandbox.raastech.com:7777/BPELAdmin

There is no concept of BPEL domains in Oracle SOA Suite 11g (technically, there is a single BPEL domain). Beginning with Oracle SOA Suite 11.1.1.3, the concept of a “partition” is introduced. Partitions, unlike BPEL domains, do not have their own configuration or logging. However, from a code grouping aspect, they can be treated identically to BPEL domains.

For example, if you have a BPEL domain called “Accounting”, simply create a partition called “Accounting”.

Figure 4. Creating and deleting “partitions” in SOA Suite 11g can be done by right-clicking on ‘soa-infra’



1. Create a “partition” in 11g with the same name for each BPEL domain in 10g.

Create Partitions (as a substitute for ESB Services and Service Groups)

Systems and Service Groups are used in ESB 10g to group ESB services.

There is no concept of ESB Systems and Service Groups in Oracle SOA Suite 11g. Beginning with Oracle SOA Suite 11.1.1.3, the concept of a “partition” is introduced. Partitions, unlike ESB Systems and Service Groups, do not have listeners. However, from a code grouping aspect, they can be treated similarly to ESB Systems and Service Groups.

However, Services Groups in ESB 10g can be cascading (i.e., a Service Group can have another Service Group). Thus cascading hierarchies will need to be flattened. For example, if you have a System called “HR” with two Service Groups “Europe” and “United States”, it will have to be flattened as shown. Also note that partition names cannot have spaces.

Figure 5. ESB 10g System and Service Group (left) and Oracle Fusion Middleware 11g Partitions (right)

1. Create a “partition” in 11g with the same name for each ESB System and Service Group in 10g.

a. Ensure that the hierarchy is flattened.

b. Do not use spaces in partitions names.

Migrate BPEL Domain Properties



There is technically a single domain in Oracle SOA Suite 11g (versus potentially multiple domains in SOA Suite 10g), so properties will affect the entire server (affecting both BPEL and Mediator components).

1. Begin by getting a copy of all BPEL Process Manager 10g properties for all domains. This is located on the Oracle_Home of the BPEL Process Manager 10g:

$ORACLE_HOME/bpel/domains/<domain>/config/domain.xml

If you have multiple BPEL domains and different settings for the properties on each of those domains, you will have to decide which setting you want to use in 11g.

2. The properties should then be manually added to one of these 11g configuration files:

$DOMAIN_HOME/config/soa-infra/configuration/bpel-config.xml

$DOMAIN_HOME/config/<domain_name>/configuration/soa-infra-config.xml

The table below shows properties that have changed between 10g and 11g. All other properties behave the same.

10g Property 11g Property

dspInvokeAllocFactor No longer exists

dspMaxThreads No longer exists

processCheckSecs No longer exists

txDatasourceJndi No longer exists

uddiLocation oracle.soa.uddi.registry.inquiryUrl

uddiPassword oracle.soa.uddi.registry.password

uddiUsername oracle.soa.uddi.registry.username

Table 1. BPEL properties that have changed from 10g to 11g

For more information, check out chapter 10.2.6 Specifying Domain Descriptor Properties in Oracle BPEL Process Manager 11g at the following link:

http://download.oracle.com/docs/cd/E17904_01/upgrade.1111/e10127/upgrade_bpel_apps.htm#CHDFDEDB

Other Custom Configuration





There may be other configuration that would need to be made on the new 11g environment, and this may include custom configuration from the Oracle HTTP Server, Oracle Database, operating system, etc. Ensure that any other custom configuration is applied to the new environment.



4. DEVELOP THE DEPLOYMENT PROCESS

Make sure that all Ant scripts are ready at this stage. This is not only needed when importing artifacts to the MDS (in Step 5), but will simplify and speed up your future deployments.

Oracle SOA Suite 11g ships all Ant scripts needed, and they’re quite good. The most important targets needed for the upgrade project are highlighted in the table below.

Description Ant Script Ant Target

Compile composite ant-sca-package.xml package

Deploy composite ant-sca-deploy.xml deploy

Export MDS ant-sca-deploy.xml exportSharedData

Import artifacts to MDS ant-sca-deploy.xml deploy

Table 2. Key Ant targets needed for the upgrade

Compile (Package) Composites

This command demonstrates how to set the environment, change to the appropriate directory, and execute Ant to compile a “HelloWorld” composite project. This creates a deployable JAR file under the project’s ~/deploy subdirectory. This JAR file can be deployed via the Fusion Middleware console or through Ant.

export MW_HOME=/u01/app/middleware

export ORACLE_HOME=$MW_HOME/Oracle_SOA1

export JAVA_HOME=$MW_HOME/jdk160_18

export ANT_HOME=$MW_HOME/modules/org.apache.ant_1.7.1

export PATH=$ANT_HOME/bin:$ANT_HOME/lib:$PATH:.

cd $ORACLE_HOME/bin

Goal of Step 4

Prepare all Ant scripts, as it is required for Step 5.

SOA Suite 11g provides great Ant script to ease the deployment process. This is required primarily for Step 5, but will also tremendously simplify your future deployments.



ant -f ant-sca-package.xml package

-DcompositeDir=/u01/HelloWorld

-DcompositeName=HelloWorld

-Drevision=1.0

Deploy Composites

This command demonstrates how to execute Ant to deploy a “Hello” composite to the SOA server. The full path to the deployable JAR file must be specified.

ant -f ant-sca-deploy.xml deploy

-DserverURL=http://soadev:8001/soa-infra/deployer

-Duser=weblogic

-Dpassword=welcome1

-DsarLocation=/u01/HelloWorld/deploy/sca_HelloWorld_rev1.0.jar

-Dpartition=default

-Doverwrite=true

-DforceDefault=true

-Dconfigplan=/tmp/cfgplan.xml

Export MDS

This command demonstrates how to execute Ant to export the entire MDS to a JAR file. The JAR file can be unzipped and browsed through the file system. By manipulating the “pattern” parameter, it is possible to limit what you want to export.

ant -f ant-sca-deploy.xml exportSharedData


-Duser=weblogic

-Dpassword=welcome1

-DjarFile=/tmp/RaastechMetaData.jar

-Dpattern=**

Import Artifacts to MDS

This command demonstrates how to zip a directory structure, and use Ant to import the contents to the MDS, maintaining the same folder structure.

zip -r RaastechMetaData.jar /u01/MDS/RaastechMetaData

ant -f ant-sca-deploy.xml deploy

-Dwl_home=/u01/app/middleware/wlserver_10.3

-Doracle.home=/u01/app/middleware/Oracle_SOA1




-Duser=weblogic

-Dpassword=welcome1

-Doverwrite=true

-DsarLocation=/tmp/RaastechMetaData.jar

For more information regarding the Ant build scripts shipped with Oracle SOA Suite 11g, refer to chapter 43.6.2 How to Manage SOA Composite Applications with ant Scripts:

http://download.oracle.com/docs/cd/E12839_01/integration.1111/e10224/sca_lifecycle.htm#sthref2497





5. IMPORTS ARTIFACTS TO THE MDS

In Oracle SOA Suite 10g, the majority of configuration were stored on the file system. This meant that any change to any configuration file must be made on all midtiers. Now, in Oracle SOA Suite 11g, these artifacts are stored centrally in the MDS.

The MDS, or Meta Data Services, is a database-based repository and all artifacts are now centralized across all midtier servers. The content in the MDS is represented and navigated identically to a file system layout. Artifacts may include DVMs, schemas, WSDLs, and fault policies.

Browsing the MDS

The MDS can be browsed through any of the following ways:

Through a SOA-MDS connection in JDeveloper 11g

After exporting its contents through the Fusion Middleware console

After exporting its contents as a JAR file using Ant

Goal of Step 5

Import all shared artifacts such as custom DVMs, schemas, WSDLs, and fault policies to the MDS prior to upgrading the SOA code.

Oracle SOA Suite 11g has introduced the concept of a database-based

repository, referred to as the MDS (Meta Data Services). All custom artifacts should be imported to the MDS prior to the code upgrade, as the code will need to be updated to reference them.



Figure 6. MDS content can be browsed through JDeveloper 11g (left) or on the file system after exporting it (right)

Prior to upgrading your code, ensure that all artifacts are imported to the MDS. Examples of these artifacts include DVMs, fault policies, schemas, WSDLs, etc.

After importing these artifacts, the code will be updated to reference these now MDS-based artifacts (described later).

Migrating Shared Domain Value Maps (DVMs)

Although there are numerous ways to migrate DVMs from Oracle SOA Suite 10g to 11g, the approach here is one of the quicker and simpler ways.

1. In Windows XP:

a. Double-click on “My Network Places”

b. Double-click on “Add Network Place”

c. Navigate through the screens, and provide the URL to your ESB slide as shown in Figure 7.



Figure 7. Creating a Windows Network Place to access DVMs in the ESB slide

2. The contents of the ESB slide are now accessible via Windows Explorer, as shown in Figure 8.

Figure 8. Accessing the ESB slide from Windows Explorer

3. Download the DVMs and copy them to your local file system.



4. Copy the DVMs to a unix-based operating system.

5. Run the following command to rename all file extension from .xml to .dvm:

rename .xml .dvm *.xml

6. Perform a global search-and-replace to change the <dvm> attribute (this is a linux based command):

find . -type f -exec sed -i

"s%isNew=\"true\"%xmlns=\"http://xmlns.oracle.com/dvm\"

%" {} \;

This replaces an attribute in the DVM to convert it to the 11g compatible version. For example:

10g: <dvm name="Country_Code" isNew="true">

11g: <dvm name="Country_Code" xmlns="http://xmlns.oracle.com/dvm">

7. Create a folder on the local file system, and copy the DVMs to this location:

c:\apps\CustomMetaData\dvm

8. Zip up the contents of this folder (from the top level c:\apps\) and use Ant to import it to the MDS.

This would be imported to the MDS under the following location:

oramds:/apps/CustomMetaData/dvm

Migrate BPEL Fault Policies

It is possible to maintain multiple fault policies in Oracle SOA Suite 11g. This section describes, at a high-level, how to migrate a single, custom fault policy from 10g to 11g.

1. Identify all BPEL Process Manager 10g domains that have fault policies. For example, the default domain will have its own fault policy that may have been customized. The two relevant files are located here:

$ORACLE_HOME/bpel/domains/default/config/fault-bindings.xml

$ORACLE_HOME/bpel/domains/default/config/fault-policies/DefaultPolicy.xml



2. Change the version in fault-bindings.xml from “2.0.1” to “3.0” and change the

<process> element to <composite>, as highlighted in red below:

<?xml version="1.0" encoding="UTF-8"?>

<faultPolicyBindings version="3.0"

xmlns="http://schemas.oracle.com/bpel/faultpolicy"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<composite faultPolicy="DefaultPolicy"/>

</faultPolicyBindings>

3. Rename the 10g fault policy file to fault-policies.xml, change the version from “2.0.1” to “3.0”, and add a higher level <faultPolicies> node. For example, the text in red is new:

<?xml version="1.0" encoding="UTF-8"?>

<faultPolicies



<faultPolicy version="3.0" id="DefaultPolicy"

xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xs="http://www.w3.org/2001/XMLSchema"



.

.

.

</faultPolicy>

</faultPolicies>

4. Create a folder on the local file system, and copy both files to this location:

c:\apps\CustomMetaData\faultPolicies

5. Zip up the contents of this folder (from the top level c:\apps\) and use Ant to import it to the MDS.

This would be imported to the MDS under the following location:

oramds:/apps/CustomMetaData/faultPolicies



Import Shared Schemas and WSDLs

If you have shared schemas and/or WSDLs, import them to the MDS, maintaining the same directory structure. If you have imports that are fully qualified references, they must be changed to local references accordingly.

Let's say you have 2 schemas on your shared server in the following location:

http://server:7777/Account/Account.xsd

http://server:7777/Custom/CustomAccount.xsd

And let’s say that Account.xsd imports the CustomAccount.xsd schema as an HTTP reference as follows:

<schema import="http://server:7777/Custom/CustomAccount.xsd">

This reference in Account.xsd will need to be changed to a local reference, as:

<schema import="../Custom/CustomAccount.xsd">

Now both these schemas should be copied to your local file system, in preparation for import to the MDS:

c:\ant\CustomMetaData\xsd\Account\Account.xsd

c:\ant\CustomMetaData\xsd\Custom\CustomAccount.xsd

Finally, zip up the contents of this folder and use Ant to import it to the MDS. This would be imported to the MDS under the following location:

oramds:/apps/CustomMetaData/xsd/Account/Account.xsd

oramds:/apps/CustomMetaData/xsd/Custom/CustomAccount.xsd



6. UPGRADE THE PROJECTS

To upgrade BPEL and ESB projects developed originally in JDeveloper 10g to 11g involves going through pre-upgrade steps, migration of the project, and post-upgrade steps. This will migrate the project to an 11g composite that will consist of a single BPEL or Mediator component. inconsistent

Upgrade BPEL Projects

1. Ensure that projects are migrated in order of dependency.

For example, if HelloWorld1 invokes HelloWorld2, then HelloWorld2 must be upgraded and deployed to the Oracle SOA Suite 11g server prior to upgrading HelloWorld1.

2. Open the BPEL project in JDeveloper 10g.

3. Modify partner link endpoints to point to the 11g service.

For example, HelloWorld1 is currently pointing to HelloWorld2 deployed to the old SOA Suite 10g server, referencing it as follows:

http://soa10g:7777/orabpel/default/HelloWorld2/HelloWorld2?wsdl

Now that HelloWorld2 is upgraded and deployed to the new SOA Suite 11g server, modify the partner link in HelloWorld1 to point to the newly upgraded HelloWorld2:

http://soa11g:8001/soa_infra/services/default/HelloWorld2/He

lloWorld2_ep.wsdl

* Always use abstract WSDLs when referencing composites.

4. Save the project in JDeveloper 10g.

Goal of Step 6

Upgrade your SOA projects from the 10g version to the 11g version.

Oracle JDeveloper 11g provides a (somewhat unreliable) Migration Wizard

that will automatically upgrade your SOA code from 10g to 11g. Prior to doing this, some pre-upgrade steps are required and performed on JDeveloper 10g first.



5. Open the project in JDeveloper 11g.

6. Navigate through the Migration Wizard.

If an error occurs, the Migration Wizard does not give a specific reason for the failure of the migration.

In that case, check the logs at (or appropriate directory):

c:\Oracle\Middleware\jdeveloper\upgrade\logs\*.*

Upgrade ESB Projects

1. Ensure that projects are migrated in order of dependency.

For example, if HelloWorld1 invokes HelloWorld2, then HelloWorld2 must be upgraded and deployed to the SOA Suite 11g server prior to upgrading HelloWorld1.

2. Open the ESB project in JDeveloper 10g.

3. Modify partner link endpoints to point to the 11g service.

For example, HelloWorld1 is currently pointing to HelloWorld2 deployed to the old SOA Suite 10g server, referencing it as follows:

http://soa10g:7777/esb/wsil/DefaultSystem/HelloWorld2?wsdl

Now that HelloWorld2 is upgraded and deployed to the new SOA Suite 11g server, modify the partner link in HelloWorld1 to point to the newly upgraded HelloWorld2:

http://soa11g:8001/soa_infra/services/default/HelloWorld2/He

lloWorld2_ep.wsdl

* Always use abstract WSDLs when referencing composites.



4. If the routing rule does not have a SOAP service as the target, then manually add one (instead of referencing the ESB endpoint from the server).

5. Ensure that the “Invocable from an external web service” is selected for all ESB routing services.

6. Save the project in JDeveloper 10g.

7. Open all .esbsvc files in a text editor.

a. Delete all “parent” lines that have lines similar to the following:

<parent guid="96DD76C0971311DABF1A87858E4395A7"

qname="DefaultSystem" type="system"/>

b. Change all remaining “qname” references and remove the system and service groups as follows:

OLD: qname="DefaultSystem.Accounting.HelloWorld"

NEW: qname="HelloWorld"

8. Open the project in JDeveloper 11g.

9. Navigate through the Migration Wizard.

If an error occurs, the Migration Wizard does not give a specific reason for the failure of the migration.



In that case, check the logs at (or appropriate directory):

c:\Oracle\Middleware\jdeveloper\upgrade\logs\*.*



7. POST-UPGRADE STEPS

After the code has been successfully upgraded to 11g, based on the complexity of the project and features used, several post-upgrade steps may need to be performed. Be cognizant of the fact that it is impossible to exhaustively cover every post-upgrade steps required for your code.

This step also focuses on areas not directly addressed in Oracle documentation, but the Oracle Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter, and ADF 11g Release 1 (11.1.1) must also be followed to address other documented post-upgrade steps.

Modify DVM Lookups

Every DVM lookup must be manually modified.

1. Open all files in the project (e.g., .xsl) and locate any DVM lookup functions.

2. Manually modify the DVM function name and the location of the DVM as described.

For example, the 10g function may look as follows:

orcl:lookup-dvm ("Currency", "Country", "US", "Currency", "USD")

Both the DVM lookup function and the path to the DVM should be changed:

dvm:lookupValue

("oramds:/apps/CustomMetaData/dvm/Currency.dvm", "Country",

"US", "Currency", "USD")

Modify Schema Imports

Every schema import should be manually modified to use ORAMDS references instead of HTTP references. By doing this, not only does it improve performance, but there is no more hardcoding of hostnames and ports.

Goal of Step 7

Perform all post-upgrade steps to your BPEL and Mediator code.

Perhaps the most time-consuming step of the entire process, perform all post-upgrade steps, most of which have to be done manually.



Schemas local to the project do not have to be updated.

1. Open all schemas and WSDLs in the project and locate any import or location statements (except for local schemas, which remain unchanged).

2. Convert the HTTP reference to an ORAMDS reference.

For example, the 10g import may look as follows:

<schema import="http://soa10g:7777/CustomMetaData/xsd/Account.xsd">

The import would be changed as follows:

<schema import="oramds:/apps/CustomMetaData/xsd/Account.xsd">

Add Fault Policies and Bindings

Unlike 10g, there is no concept of a global fault policy in Oracle SOA Suite 11g that will automatically apply to all deployed composites. Therefore, you must manually reference the fault policy and fault binding in composite.xml.

1. Edit composite.xml

2. Add the following immediately below the </service> tag to reference your custom fault policy:

<property name="oracle.composite.faultPolicyFile">

oramds:/apps/CustomMetaData/faultPolicies/fault-policy.xml

</property>

<property name="oracle.composite.faultBindingFile">

oramds:/apps/CustomMetaData/faultPolicies/fault-bindings.xml

</property>

If you have more than one fault policy, you will have to decide which one you want your composite to reference.

Migrate bpel.xml Properties

Any custom properties in bpel.xml (10g) will have to be manually added to composite.xml (11g).

1. Open the 10g bpel.xml file, and locate any custom properties. For example:



<property name="retryInterval">60</property>

2. Open the 11g composite.xml file, and add the 11g version of the property:

<property name="jca.retry.interval">60</property>

The table below lists some 10g and 11g properties:

bpel.xml (10g) composite.xml (11g)

<property name="retryInterval">60</property> <property name="jca.retry.interval" type="xs:int" many="false" override="may">60</property>

<property name="retryCount">60</property> <property name="jca.retry.count" type="xs:int" many="false” override="may">60</property>

<property name="retryBackoff">60</property> <property name="jca.retry.backoff" type="xs:int" many="false" override="may">60</property>

Table 3. BPEL properties in 10g and their equivalent 11g version

Modify BPEL Sensors Connection Factory References

If using BPEL sensors, the connection factory has changed in Oracle SOA Suite 11g.

1. In JDeveloper 11g, choose the “Monitor” button to edit sensor detail:

2. Click on BPEL Sensor Action:

3. Modify the JMS Connection Factory and set it to “weblogic.jms.ConnectionFactory”:

Publish Type: JMS Queue

JMS Connection Factory: weblogic.jms.ConnectionFactory



Publish Target: jms/MyQueue

Review Mediator Filters

The JDeveloper 11g Migration Wizard does not work properly in some cases. For example, when ESB filters are migrated, brackets are missing which changes the meaning of the filter if a combination of logical operators are used (e.g., AND, OR). In other cases, dollar ($) signs are missing which results in incorrect XPaths.

1. Open the ESB project in JDeveloper 10g.

2. Review the filter.

3. Open the migrated Mediator project in JDeveloper 11g.

4. Review the filter.

5. Compare both filters and ensure that it is migrated properly.

Review and Modify Header Functions

Some ESB XPath header functions are made obsolete in 11g and replaced with alternate Mediator XPath functions. See Table 4 below.

ESB XPath Function (obsolete) Mediator XPath Function

ehdr:setOutboundHeader mhdr:setProperty

ehdr:getRequestHeader mhdr:getProperty

Table 4. Obsoleted ESB XPath functions and their equivalent 11g versions

These functions impact areas such as header manipulation and dynamic routing.

For example, dynamic routing requires setting the outbound header via the ehdr:setOutboundHeader function as follows:

select="ehdr:setOutboundHeader('/shdr:ESBHeader/shdr:location',

$LocationIn, 'shdr=http://xmlns.oracle.com/esb;')"

In 11g, the equivalent would be:

select="mhdr:setProperty('out.property.endpointURI',$LocationIn)"



Header functions are one of the more problematic areas of the migration. In some cases, such as setting usernames and passwords in the header, these will flat out not work and those functions must be moved to the new “Assign Values” feature in Mediator 11g.

1. Checked and modify each header functions manually.

2. Review both Oracle and online documentation to research how to migrate header functions.

3. Test each case individually to ensure that the new header function operates identically to the 10g version of the code.

Review Usage of getDomainId()

Some BPEL XPath functions change in behavior as well, and can only be discovered during runtime (i.e., testing).

The BPEL XPath function getDomainId() behaves differently, since there is no longer the concept of BPEL domains. The function now returns NULL.

1. Find all code that is using the getDomainId() function.

2. Consider using an alternate function or modifying your code.

Other Stuff

The Oracle Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter, and ADF 11g Release 1 (11.1.1) has an enormous number of additional steps that may apply to your code.

Review the Oracle Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter, and ADF 11g Release 1 (11.1.1) at this location and follow all recommended upgrade steps not covered in this white paper:





8. TEST

Compilation errors will reveal a lot. Deployment errors will also reveal a lot.

Validation of the newly upgrade code is actually quite easy. As discussed earlier, both SOA Suite 10g and 11g infrastructures should remain available during the upgrade period. Use client tools to test such as SoapUI or the consoles (e.g., BPEL Console 10g, Oracle Fusion Middleware 11g Console).

Testing is straightforward:

Test payload on your service deployed to SOA Suite 10g

Test payload on your service deployed to SOA Suite 11g

Compare results; they should be identical

Goal of Step 8

Compile, deploy, and test every project.

Since the underlying code has largely changed, dedicate time to exhaustive unit and end-to-end testing. Fortunately, identifying and resolving issues

uncovered through the compilation and deployment of the JDeveloper 11g SOA projects addresses many of the coding issues, but it is not enough, as there many coding issues that will only be discovered at runtime.



FINAL THOUGHTS

The 8-step upgrade approache developed by Raastech is an excellent starting point and has aided in ensuring the success of SOA Suite 10g to 11g upgrade projects. Nonetheless, neither our proposed approach nor this white paper are meant to replace the Oracle documentation, which should also be relied on. Rather, this white paper should be used to augment Oracle’s existing documentation.

Expect to touch nearly 100% of your code and expect to encounter issues no one else has.

The reason we recommend our approach is because it provides certain areas which we believe should be completed before actually upgrading your code, and in specific, these are:

Develop the deployment process early on.

This is needed for the next step. ‘Nuff said.

Import all artifacts to the MDS.

If you don’t import your DVMs, fault policies, and shared schemas to the MDS, it will become a back-and-forth game between the developers (who will constantly complain of missing artifacts in the MDS) and the application administrators.

About Raastech:

Raastech is a fast growing company with diversified disciplines but specializing in information technology development and systems integration. We employ some of the top industry experts to help us achieve our mission. Founded in 2009, Raastech provides management consulting, systems development and integration, and managed services to both federal agencies and commercial organizations. We provide value to our clients by being innovative and dependable partners in achieving their objectives. For more information, please visit http://www.raastech.com.

About the Author:

Ahmed Aboulnaga is a Technical Director at Raastech and has extensive experience in Oracle Fusion Middleware. He has been involved in the architecting and implementation of large scale systems involving middleware technologies such as Oracle SOA Suite, Oracle Application Integration Architecture, Oracle Data Integrator, Oracle Integration B2B, Oracle Identity Management, and numerous other Oracle middleware technologies.

Raastech White Paper: Upgrading Oracle SOA Suite 10g to 11g April 2011

Raastech Headquarters: 2201 Cooperative Way, Suite 600 Herndon, VA 20171

www.raastech.com Copyright © 2011 Raastech, Inc. All rights reserved.

http://www.raastech.com/

http://www.raastech.com/

upgrading oracle soa suite 10g to 11g (whitepaper)

Technology