SOA 10g to 11g Migration Best Practices

Oracle SOA Suite 11g was released couple of years ago and companies are using it to develop integration solutions since then. Those who have developed their integration solutions using SOA Suite 10g they have upgraded their infrastructure and code base to SOA Suite 11g or they are planning to upgrade it to 11g.

SOA Suite 11g has significant differences from SOA Suite 10g. In this post I am writing about the best practices for upgrading SOA 10g code base to SOA Suite 11g.

Pre Migration Best Practices

Ensure that 10g Projects are Up and Running on Latest SOA 10g Release

Before migrating a 10g project its better to verify that the project is up and running. If your project have dependencies on the external web services than make sure that all the external web service are up and running.

Install JDeveloper 11g:

Download latest JDeveloper 11g release and upgrade it with SOA composite editor extension.

Install latest SOA 11g Version:

Download and install latest SOA Suite 11g release (Latest SOA Suite 11g version now is 11.1.1.5 also named as SOA 11g PS4).

Start with One Business Case:

Don’t try to upgrade the complete 10g code base. Select one business case and start upgrading projects needed for the selected business case.

Configure Resources:

Configure all the resources you need to run your application on newly installed SOA 11g server (JMS Queues/Topics, DB Connection pools, Security Policies, Work Managers etc).

Use Scripts to Migrate 10g Projects:

If you are migrating just one project than using JDeveloper migration wizard is a clever choice. If you want to migrate all of your 10g projects into 11g format than using ant-sca-upgrade.xml is a better option. You can write a shell/ant script to upgrade all 10g projects leveraging ant-sca-upgrade.xml. In the next article I will provide an ant script to migrate 10g projects to 11g.

Post Migration Best Practices

Compile Migrated Projects and Fix Compilation Errors.

11g BPEL compiler is stricter than 10g. You might get compilation error for XPath functions or for XPath expressions. Check the compilation logs for errors and fix them. In 11g they changed namespace prefixes for some of the XPath functions, you need to correct the XPath function signature. For example ora:parsexml() is oraext:parsexml now. You can have a look on the 11g XPath functions definitions in <JDEVELOPER_HOME>/integration/seed/soa/configuration folder. This folder contains XPath function definitions for bpel, mediator, mapper etc.

Rearrange Artifacts Into Corresponding Folders.

For a BPEL project, JDeveloper 10g keeps all the artifacts inside bpel folder. JDeveloper 11g organizes artifacts in folders. For example it keeps .xsd files in xsd folder, .wsdl files in wsdl folder and so on. When you upgrade a 10g project to 11g project neither JDeveloper Migration Wizard nor ant-sca-upgrade.xml reorganizes the project artifacts in their corresponding folders. Copy artifacts into corresponding foder. It doesn’t make any difference in the functionality but it will make your 11g projects much cleaner and organized. Don’t forget to modify the path of xsd's, xslt's, wsdl's in the files referring these artifacts.

Create JDeveloper Applications and Projects

When you upgrade a 10g project using ant-sca-upgrade.xml script it won’t generate .jws and .jpr files in the upgraded projects. You need to create applications and projects in JDeveloper manually.

Run 11g Adapter Configuration Wizard to Verify the Adapters

Run 11g adapter configuration wizard for each adapter in an upgraded project to make sure that all the adapter configurations are correct and contains all the required properties. It will also validate the adapter connections to SOA 11g environment.

Update JCA adapter Header Variables

SOA 11g manages JCA adapter header variables in a different manner. JCA adapter header variables are invoke activity properties now. If you are using adapter header variables in SOA 10g projects you need to manually set these adapter header properties on the Properties tab of the Invoke activity dialog box. You can see all the available adapter header properties on the properties tab of the invoke activity. Recompile the modified project to ensure that everything is fine.

Create Configuration Plans for Deployment.

JDeveloper 11g migration wizard or 11g migration script doesn’t upgrade any SOA 10g deployment plan and build scripts. You need to manually create configuration plans for SOA 11g projects. Configuration plans help you to customize environment specific values (i.e. hostname, port, resource locations etc). Click here to find out how to generate and use deployment plans.

Manage Common Artifacts Using MDS

In Fusion Middleware 11g oracle introduces a new way of managing application meta data using MDS (Meta Data Service). MDS is a single unified repository to store all the shared artifacts. MDS provides a unified URL to access an artifact across all the environments. No local copies and no string replacements are required. For example, to access CommonObjects.xsd you need to use the following URL across all the environments:

oramds:/apps/common/xsd/CommonObjects.xsd

If you are accessing any file from bpel xmllib you need to change the URL to MDS URL. For example if you were accessing RuntimeFault.wsdl in 10g BPEL project using URL - http://localhost:80/orabpel/xmllib/RuntimeFault.wsdl you need to change it manually in your code to oramds:/soa/shared/bpel/RuntimeFault.wsdl.

Do the following to leverage MDS repository to efficiently manage your shared resources:

• Remove local copies of shared artifacts (XSD, WSDL, DVM, XSLT etc)

• Copy Common artifacts to local JDeveloper MDS repository. Local MDS repository location is <JDEVELOPER_HOME>/integration/seed

• Change common artifacts URL to MDS URL in the files referring them.

• Deploy shared artifacts to MDS repository on SOA 11g Server. Click here to learn to deploy and remove artifacts on MDS repository using ant.

Group Upgraded Projects in a Single Composite Application

When you upgrade SOA 10g projects to SOA 11g you will have one SOA composite per upgraded project. In other words you will have as many SCA Composites as many project you have. An SCA composite is used to assemble SCA components in logical groupings. You can not leverage SCA benefits by having many fine grained composites.

Grouping SCA components into an SCA composite is heavily depends on the business case and requirements you have but you can use the following as reference points:

• Evaluate the functionality provided by the SCA components and then group the related SCA components in a single SCA composite.
  

• Assemble a reusable component alone in an SCA composite. Expose the component as a service using service bindings so other SCA components/composites can reuse it.
  

• Consider message size and complexity of the component implementation as well while assembling SCA Composite.
  

Create Partitions to Group Composites

In SOA 10g you have BPEL domains to logically organize BPEL processes and ESB System and Service Group for organizing ESB flows. In SOA 11g you need to create partitions to logically group SOA composites. Partitions are similar to the BPEL 10g domains. You can perform bulk life-cycle management operations on all SOA composites deployed on a partition. In SOA 11g you need to set the entire configuration (audit level, threading etc) at SOA infrastructure level so you can not perform any BPEL Engine specific configuration tasks on partitions. Click here for more details on creating and managing partitions.

Deploy SOA Projects to Server and Test

Deploy SOA composites and test them to verify that the upgraded code is working as expected.

Tune SOA 11g Infrastructure

After verifying that the migrated and modified code is working as expected you can start performance tuning SOA 11g infrastructure. Click here for details about BPEL Engine properties. I will write on SOA 11g Performance tuning best practices in my next posts.

SOA 10g to 11g migration requires lot more to do than simply executing migration script/wizard. You need to carefully plan your upgrade strategy. You can use these best practices as a reference. In next series of blog posts I will write about best practices of upgrading other SOA 10g projects (ESB, BAM, Business Rules etc).

References:

Oracle MDS White Paper

SOA Suite 11g Developer Guide

SOA Suite 11g Migration Guide

SOA Suite 11g Composite Deployment Guide