SOA 12c Upgrade: Development Team Do’s and Don’ts

With the introduction of Oracle SOA Suite 12c, it has become imperative for any organization using Oracle SOA Suite 11g to migrate to the newer and better stack.  This upgrade offers a host of benefits, such as added features, bug fixes, and the ability to stay current with the latest technologies.  However, as is the case with any other software upgrade, appropriate and thorough planning is crucial to realizing the full benefit of the upgraded solution.

Recently, we’ve had the opportunity with some of our customers to migrate their SOA Suite 11g applications into Oracle SOA Suite 12c. This post is the first in a series that will provide the observations and lessons learned from these experiences, and we hope you find this information helpful in your application migrations.

In this first post, we tackle issues pertaining to the developer team.  As main characters in any migration, the developer team should understand the following obstacles, and their solutions, likely to be faced while performing the upgrade.

Migrating Code

One of the promises of Oracle SOA Suite 12c is its commitment to ensuring high developer productivity. This is evident with JDeveloper 12c having integrated servers and OSB Development support, among others.

To migrate any Oracle SOA Suite 11g applications, open the application file (e.g. HelloWorld.jws) in JDeveloper 12c. The editor automatically prompts for migration and completes the migration successfully.

Once the migration is completed by JDeveloper, the development team should begin looking into the following areas for fixing any issues, should they arise.

Usage of Older XPath Functions

Earlier releases of Oracle SOA Suite 11g encouraged the use of getCompositeInstanceID() as a way to identify and track the running instances. With the advent of the Flow ID concept, it is advisable to use the getFlowID() function where the FlowID of the instance needs to be tracked.

getCompositeInstanceID() →  getFlowID()

*The use of FlowID to track instances will be explained in a later blog post, and this post will be updated with the link.

Also, be observant for the change in the namespace prefix for some of the functions.  For example, bpelx:copyList() should be used instead of ora:copyList(), although both the functions are available.

Older Composites Failing to Migrate

If you have certain SOA composites built using JDeveloper 11.1.1.6.0, then you might face issues while migrating in JDeveloper 12c. The error type would be:

oracle.bali.xml.model.XmlContext_setSourceModel
 SEVERE: Exception thrown when initializing 
 model:oracle.tip.tools.ide.bpel.v1.designer.addin.model.BPELXmlModelImpl@5a2e258d
 java.lang.RuntimeException: SOA component BPELProcess does not have a <componentType> element.
 If you are opening a project created in 12C, you will need to manually migrate the project by copying the complete
 contents of the componentType file, including the root element, to the second
 child of the component element (after the implementation element) in the composite.xml.

The resolution for this error is to download and apply Patch 18532283, according to your SOA 12c version – for now, available on 12.1.3.0.1.

Composite Definition not Showing up in Enterprise Manager

A new feature in Oracle SOA Suite 12c EM is the ability to see the composite definition (the process flow) in EM. This is helpful for multiple reasons, such as testers understanding the various components, providing a high level view of the flow. For Oracle SOA Suite components/composites developed in JDeveloper 12c, one can easily see the composite definition in EM under the tab ‘Composite Definition’, as shown below.

However, since you will be working on migrating projects from previous versions to 12c, you might face an error message displayed as follows for any composites which were initially developed using JDeveloper 11g:

Unable to read the diagram details. This is likely because the SOA Composite was designed using an older version of JDeveloper. The problem should go away by re-opening the SOA application in the latest JDeveloper and redeploying it.

Solution:

In the composite.xml file, find the following two properties:

<property name=”originalProductVersion” type=”xs:string” many=”false”>11.0.0.0.0</property>
<property name=”productVersion” type=”xs:string” many=”false”>12.1.3.0.0.140013</property>

Remove the originalProductVersion property, then compile and deploy again to your 12c environment.  You should now be able to see the composite definition.

JDeveloper OSB Workspace Set Up

JDeveloper 12c is an excellent IDE, improving developer productivity with such features such as Integrated Server for quick start, as well as an integrated IDE, in which you can develop both SOA composites and OSB components.  When it comes to OSB development, one feature that makes JDeveloper 12c take a backseat compared to Oracle Enterprise Pack for Eclipse (for OSB Development), is the lack of ability to import projects from an existing workspace to the OSB application.

Plan your development set-up for OSB projects carefully.  Once you import OSB projects by selecting the option for “Import sbconfig”, the projects are created in JDeveloper’s own workspace, and you must then sync them with your central repository system.  Similarly, plan the development strategy accordingly, choosing whether to have OSB applications for each OSB project, or bundle them together into one application.  The latter approach is recommended since your projects might have inter-dependencies with each other.

XQuery Files Improperly Displayed in the Graphical Editor in JDeveloper

Once the OSB projects have been migrated, right-click on each project and select the option shown below:

Service Bus → Convert To XQuery 1.0

Your transformations will now be displayed in the graphical editor in JDeveloper 12c without any issues.

Using In-Memory Optimization

In-Memory Optimization was a feature present in SOA Suite 10g, but was dropped in SOA Suite 11g.  It has now been re-introduced in Oracle SOA Suite 12c and greatly improves the performance of transient BPEL processes; however, exercise caution with this implementation.  It is advisable to perform a load test on the sample application on which you plan to use In-Memory Optimization in order to verify whether the performance is, indeed, improved.

In one of our migration implementations, we found that the In-Memory Optimization was not providing the expected results.  Be sure to make a calculated decision as to whether you really need In-Memory Optimization and, if needed, follow up with Oracle Support should you not get expected results.

This blog series will continue to cover other areas in which the team should plan ahead, as well as additional issues for the Middleware team to look out for.  Also, be advised that this post will be updated as we discover new scenarios to be mindful of.