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

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.

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

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.

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_lifecycl
e.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:appsCustomMetaDatadvm
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:appsCustomMetaDatafaultPolicies
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:antCustomMetaDataxsdAccountAccount.xsd
c:antCustomMetaDataxsdCustomCustomAccount.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:OracleMiddlewarejdeveloperupgradelogs*.*
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:OracleMiddlewarejdeveloperupgradelogs*.*

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.

Upgrading Oracle SOA Suite 10g to 11g (whitepaper)

Recommended

More Related Content

What's hot (20)

Similar to Upgrading Oracle SOA Suite 10g to 11g (whitepaper) (20)

More from Revelation Technologies (20)

Recently uploaded (20)

Upgrading Oracle SOA Suite 10g to 11g (whitepaper)