This document provides an overview of migrating from Oracle SOA 10g to 11g. Key steps include installing the 11g server components, configuring prerequisites, and determining the migration method. There are two primary options - using the JDeveloper migration wizard to migrate projects one by one, or using command line utilities to migrate multiple projects at once. A post-migration checklist outlines steps to verify processes, adapters, metadata, and fault handling configuration.

1. Overview:
•
A number of enhancements, improvements and additions are included in Oracle SOA 11g as
compared to 10g
•
10g does not have a Service Bus and SCA compatible components, while 11g includes a Service Bus
and SCA components
•
Inclusion of Service Bus in 11g completes the SOA architecture and promotes reuse, virtualization,
decoupling and faster time to market
•
Application Server: 10g uses OC4J, while 11g uses WebLogic which uses JRockit as the JVM
•
Using WebLogic/JRockit can give a performance improvement of ~20% over 10g server
•
In 11g, components like BPEL, OWSM and ESB can be included in a single composite, allowing for
logical grouping of the components
•
Central Metadata Store (MDS) and Local MDS can be used to store common artifacts in 11g
•
Oracle 10g is nearing end of life / end of support from Oracle
These reasons make it imperative to migrate from 10g to 11g
This document discusses the migration options, guidelines to follow, challenges and points to take care of when
migrating.
Pre-Migration Steps
1.
Ensure all code is upgraded/migrated to Oracle 10g Release 3 (10.1.3) version. Only code in version
10.1.3 can be migrated to Oracle 11g
2.
•
Install Oracle SOA Suite 11g
Server components:
•
Install Oracle Database
•
Install WebLogic Server
•
Create database schemas using the Repository Creation Utility (RCU)
•
Install Oracle SOA Suite

2. •
Create SOA Domains
•
Developer components:
•
Oracle JDeveloper 11g
•
SOA Extensions 11g for JDeveloper
3.
Configuration pre-requisites
•
Configure resources needed on Oracle SOA 11g server, such as JMS Queues/Topics, DB
Connection pools, Security Policies, Work Managers etc
•
Ensure all projects, and dependent projects, are running of Oracle SOA 10g server
•
If the project has dependencies on external web services, need to ensure these web services
are also up and running
4.
Determine the method of migration to use
Migration Options
1.
Migrate using Oracle JDeveloper 11g – Use the migration wizard in JDeveloper to migrate from 10g to
11g
•
Manual process – can migrate only one project at a time
•
Open the Oracle SOA 10g project to be migrated in Oracle JDeveloper 11g
•
JDeveloper Migration wizard comes up
•
Select options to ‘Migrate Component IDs’ and ‘Randomize IDs’
•
Confirm and finish the migration wizard
•
JDeveloper will migrate the project to be compatible with Oracle SOA 11g server
•
Once a project is migrated, it cannot be opened with Oracle SOA 10g developer tools or
deployed to 10g server
2.
Migrate using Command Line Utility – Use the ant-based migration command line utility that is
available with Oracle SOA 11g
•
Ant-based upgrade utility – can migrate multiple SOA 10g projects to 11g
•
Scripts are included with Oracle SOA 11g suite
•
Provide source/target directory and application name to the script
•
After migration script, run the SCA compiler script to verify the migrated project(s)
•
Run the ant package and deploy scripts to package and deploy the project

3. Limitations of Command Line Utility
•
The JDeveloper files such as *.jpr (project file) and *.jws (application file) cannot be migrated by the
command line utility
•
The project needs to be opened in Oracle JDeveloper 11g, saved and closed to migrate these files
•
To migrate any adapter configurations, need to use the configuration wizards of the adapters – thus,
any project with adapter needs to be opened in Oracle JDeveloper and migrated
•
Separate ADF projects will be created for each Human Workflow task forms
•
The command line utility doesn’t support the deployment of ADF projects.
Comparing the Migration Options
MIGRATION USING JDEVELOPER
MIGRATION USING COMMAND LINE UTILITY
Can merge various BPEL projects into a single composite in order
to achieve the logical grouping of the components based on
Cannot merge multiple BPEL projects into a single composite
business case.
Can automate part of the migration process using scripts or other
Cannot automate the migration process
command-line automation tools.
Cannot migrate multiple projects at a time
Can migrate multiple projects at a time
Cannot deploy the ADF projects from Command line utility after
Can deploy the ADF projects from JDeveloper after migration
migration
The JDeveloper artifacts like .jws and .jpr files are migrated
The JDeveloper artifacts are not migrated; these need to be
along with the SOA artifacts.
migrated manually
Post Migration Checklist
Generic
1.
When Command Line Utility is used, open the upgraded project in Oracle JDeveloper 11g to migrate
the *.jpr and *.jws files
2.
When Command Line Utility is used, open project in Oracle JDeveloper 11g and run the adapter
migration utility

4. 3.
Migrate the processes in the order of dependency. if ‘A’ invokes ‘B’, ‘B’ has be migrated first
4.
Change the WSDL end point URL to point to new upgraded sub process URL.
5.
Move the artifacts into their respective folders. Change the location in referencing artifacts accordingly
6.
Group related upgraded Projects in a Single Composite Application (wherever applicable)
7.
Create configuration plan for SOA 11g composites (10g deployment plans will not be upgraded)
8.
Create Partitions to group 11g composites (similar to domain in 10g)
Adapter
1.
Recreate adapters
2.
Update 10g JCA adapter header variable to 11g invoke adapter property
3.
File adapter- Chunk read logic has to be changed
4.
Add validateXML property to partner link that requires request message validation and set the value to
‘true’
Function/Preference property
1.
getDomainId() – BPEL domain concept is no longer applicable in 11g. Remove/modify the function in
11g code
2.
Modify the XPath function namespace. (check the
<JDEVELOPER_HOME>/integration/seed/soa/configuration folder for prefixes)
10g: ora:parsexml()
11g: oraext:parsexml
3.
setCompositeInstanceTitle/getCompositeInstanceId Function(to customise the instance id) has to be
changed if it is used in 10g
4.
Modify any custom property in composite.xml10g: <property name=”retryInterval”>60</property>
(Check 10g bpel.xml)
11g: <property name=”jca.retry.interval”>60</property>
5.
Modify BPEL preference property names if it contains space.
6.
Modify ora:getProcessID condition. Process name gets renamed (sometimes) after migration10g: ABC
11g: ABCProcess
Thus, ora:getProcessID() = ‘ABC’ condition which is valid in 10g code, will fail in 11g.
7.
Check for data type of variables. In 10g, we can use the string type in place of integer type (like in
index variable) but not in 11g.

5. 8.
Modify xsd:date to xs:dateTime if input contains time as well (10g accepts both date and time for
xs:date function)
MDS
1.
Move the common artifacts (XSD/WSDL/ DVM files) to MDS. Accordingly change local reference to
oramds reference(oramds://location_of_resource)
2.
For BPEL xmllib reference files, change the http URL to MDS URL
DVM
1.
DVM – remove duplicate rows. 10g fetches the last updated value for duplicate key. but 11g throws
error.
2.
Modify DVM lookup function and location of file.10g: orcl:lookup-dvm(“Currency “, ” Country “, ” US “, ”
Currency “, ” USD “)
11g: dvm:lookupValue (” oramds:/apps/CustomMetaData/dvm/Currency.dvm “, ” Country “, ” US “, ”
Currency “, ” USD “)
Fault Handling
1.
Create fault binding/policy files if not implemented in 10g
2.
Edit composite.xml file to add composite preference property “oracle.composite.faultPolicyFile” and
“oracle.composite.faultBindingFile” (should be manually added, since there is no concept of global fault
policy in 11g)
3.
Fault binding Migration:
1.
Change the version in fault-bindings.xml from “2.0.1” to “3.0”
2.
Change the <process> element to <composite>
4.
Fault policy Migration:
1.
Rename the 10g fault policy file to fault-policies.xml
2.
Change the version from “2.0.1” to “3.0”
3.
Add a higher level <faultPolicies> node above <faultPolicy> element.
ANT Script for migrating BPEL project(s)
ant -f %ORACLE_HOME%binant-sca-upgrade.xml bpel
-Dsource “C:projects10gEmployeeEmpSalary;C:projects10gEmployeeEmpInfo”
-Dtarget C:projects11g
-DappName Employee
ANT Script for migrating DVM

6. 1.
In 10g, Export DVM metadata to archive
<Oracle_Home>/export.sh metadata10g.zip
2.
Convert zip to Oracle SOA Suite archive file
ant -f %ORACLE_HOME%binant-sca-upgrade.xml upgrade-xrefdvm
-Dsource=zip_file_location
-Dtarget=new_soaArchive_location
3.
Output will be saved as sca_XrefDvmFiles10g_rev1.0.jar
4.
Create a new application in Jdev11g and import the SOA Archive into SOA project
5.
Create jar file with DVM metadata and deploy to MDS
Summary
SOA 10g to 11g migration requires lot more to do than simply executing migration script/wizard. You can use
these best practices as a reference.

7. 1.
In 10g, Export DVM metadata to archive
<Oracle_Home>/export.sh metadata10g.zip
2.
Convert zip to Oracle SOA Suite archive file
ant -f %ORACLE_HOME%binant-sca-upgrade.xml upgrade-xrefdvm
-Dsource=zip_file_location
-Dtarget=new_soaArchive_location
3.
Output will be saved as sca_XrefDvmFiles10g_rev1.0.jar
4.
Create a new application in Jdev11g and import the SOA Archive into SOA project
5.
Create jar file with DVM metadata and deploy to MDS
Summary
SOA 10g to 11g migration requires lot more to do than simply executing migration script/wizard. You can use
these best practices as a reference.