X

Best Practices for SOA Suite 11g to 12c Upgrade

By: Jay Kasi | Director, Product Management

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.

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.

If your SOA domain includes BAM, then the upgrade is more
complex because BAM does not support inplace upgrade. Please read the
documentation carefully.
The basic idea is to migrate the whole BAM
deployment to a seperate 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.

There are six top steps that should be performed before
upgrade of your production system as a best practice.

  • Carefully
    review the prerequisites for upgrade in the documentation. Some of the
    prerequisites are checked upfront before we upgrade the schema in Upgrade
    Assistant but not all. Read all relevant upgrade documentation before
    starting on upgrade.
    Some of the key prerequisites are:
  • Can only upgrade a
    domain that is 11.1.1.6 or 11.1.1.7. Migrate to a supported starting point
    before upgrade.
  • Can only
    upgrade a deployment using a 64 bit JVM. Migrate to 64 bit JVM before upgrade.
  • Can only
    upgrade a production domain not using XE DB and is not an admin server only domain.
  • Can only upgrade a domain using LDAP or DB OPSS policy store. Migrate file based policy store to DB or LDAP
    based policy store before upgrade.
  • Can only 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.
  • Can only upgrade a domain based on weblogic server.
  • Can
    only 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).
  • Cannot
    upgrade a domain at this time created with T2P or pack/unpack before SOA Suite
    11.1.1.6.
  • Cannot
    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.

  • Only JDK 7 is supported. 

  • 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. Documentation
    for T2P can be found here:

Oracle Fusion Middleware Administrator's Guide 11g
Release 1 (11.1.1)
Chapter 21 Moving from a Test to a Production Environment

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

Upgrade documentation and videos can be found at the
following URLs.

Docs Link

Videos Link

Join the discussion

Comments ( 2 )
  • Sriram Wednesday, August 27, 2014

    Doc Link above doesn't work.. it says

    404 Not Found!

    Sorry, that page does not exist. Please try another location or you can search...


  • J.D. Korporaal Thursday, May 28, 2015

    hi,

    Is there already a tool for upgrade a lot of JDeveloper projects in a script?

    Jan


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha