Oracle SOA 11G Upgrade to SOA 12C, Do's and Don't In Developer Perspective

Hello Everyone,

Hope you all are doing well.

This blog is written based on below up-gradation blogs.

http://blogs.astcorporation.com/middleware/2016/08/30/soa-12c-upgrade-development-team-dos-donts/

https://docs.oracle.com/middleware/1213/cross/upgradetasks.htm

https://blogs.oracle.com/soa/best-practices-for-soa-suite-11g-to-12c-upgrade

Purpose of writing this blog to summarize information from all of these blogs and provide a best migration points.

Why we need to SOA up-gradation:

A lot of effort has been put in by Oracle to make this major upgrade as smooth and easy as possible. The basic approach is to install SOA Suite 12c in a new oracle home and upgrade the domain and schemas in place.
Customers undertaking the upgrade are primarily interested in a smooth upgrade,
minimizing the number of manual steps in the upgrade, reduce the down time to a
minimum, and minimize or eliminate any changes to client apps that use SOA APIs or web interfaces. 

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.

Keep it remind!!!!

"The key to a successful and smooth upgrade experience are
the preupgrade preparations that you perform. The upgrade must be planned
carefully. If the preupgrade preparations are not performed, there is a
possibility that upgrade will fail in the middle or the system does not behave
properly post upgrade. The only recourse to a failed production system upgrade
is to roll it back from a full backup. "

BAM Specific upgrade information:

If your SOA domain includes BAM, then the upgrade is more
complex because BAM does not support in-place upgrade.The basic idea is to migrate the whole BAM deployment to a separate domain using export/import, remove BAM from the soa domain during upgrade, and upgrade your soa domain to interop with the bam 11g domain. Later slowly and carefully migrate to BAM 12c from BAM 11g.

Check List for Upgrade:

1. Domain that is 11.1.1.6 or 11.1.1.7. Migrate to a supported starting point
   before upgrade.
2. Upgrade a deployment using a 64 bit JVM. Migrate to 64 bit JVM before upgrade.
3. Upgrade a production domain not using XE DB and is not an admin server only domain.
4. Upgrade a domain using LDAP or DB OPSS policy store. Migrate file based policy store to DB or LDAP based policy store before upgrade.
5. Upgrade a domain using a oracle DB of a version supported by the SOA Suite 12c certification matrix. Migrate to a supported DB version before upgrade.
6. Upgrade a domain based on weblogic server.
7. Upgrade a domain at this time with products deployed that were released in
   12c. Example of products not released are OER, OSR, Webcenter, and SOA task UI exposed as portlets (which uses webcenter libraries).
8. Upgrade a domain at this time created with T2P or pack/unpack before SOA Suite 11.1.1.6.
9. Upgrade a domain at this time with multiple products in 12c in separate
   unclustered managed servers using UMS. Examples are BAM, OSB and SOA. The reason is because after upgrade UMS configuration is at the domain level or the cluster level, but not at a unclustered managed server level.
10. JDK 7 is supported.
11. Always test upgrade first before actually upgrading your production system. Test with a clone of your production system either created with T2P or test with a existing test environment which mirrors your production environment. T2P does not clone the transactional store. It only creates an environment that is identical in configuration to the source. If you create an environment by doing T2P of production, you will first need to populate that environment with sufficiently representative transactions.
12. Use the upgraded test environment to test all the composites without redeploying, and to determine the performance tuning to be done to your production system post upgrade. Tuning in SOA Suite 12c is different than 11g. For example work managers are used extensively for threads in SOA Suite 12c.
13. Always backup everything before upgrading your production system and test restoring from the backup in your test system. If the upgrade fails in the middle, you might have to restore the backup.
14. Before upgrade of your production system, purge as many instances as possible that are
    not essential to keep to make the upgrade faster. Upgrade will upgrade all the
    open instances when running the Upgrade assistant and closed instances are
    upgraded lazily post schema upgrade in the
    background. This can take significant time and disk space. There is currently
    no estimation tool for amount of disk space or time, so be conservative so
    upgrade does not run out of disk space.
15. Upgrade all your SOA projects in JDeveloper and test them on your upgraded test system.
    This is so there is no surprises later when you need to change the project to
    add a new feature or fix a bug. Currently though there is no tool to bulk
    upgrade a lot of JDeveloper projects in a script. We are exploring
    such a tool. However compile and deployment can be scripted.

Code Migration:

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, it is advisable to use the getFlowID() function where the FlowID of the instance needs to be tracked.

Replace:

getCompositeInstanceID() →  getFlowID()

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:

Error:

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.

Solution:

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’.

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:

1	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:

1 2	<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.

Enjoy blogging!!