Tuesday, March 19, 2013

From the Trenches 3 | Patching OSB and SOA Suite to PS5

In two previous blogs (part I and part II) I talked about a recent upgrade from Oracle Fusion Middleware 11g PS2 to 11g PS5. This blog finishes with a post-installation step that was required to complete the upgrade and a quick note.

All in all, after a good preparation the team was able to patch a production environment to PS5 in almost an afternoon. The environment runs several Fusion Middleware products (OSB, SOA Suite, OID, WebLogic Servers for JEE apps) and spans multiple WebLogic Domains and multiple WebLogic Managed Servers in single-node clusters.

Migrating running composite instances that use While activities

One of the new features in SOA Suite 11g PS3 is that the Enterprise Manager Fusion Middleware Console shows the loop count in the BPEL Audit Trail when using While activities. This is shown in the following figure.

This feature works for new instances that are created after applying the patchset and for running instances that haven't reached the While activity yet when the patchset is applied. However, when you have running instances that are executing a While activity (also when the instance is in the dehydration store), you see the following entry in the SOA Suite log after applying the patchset:


Variant not found.
The variable "__loopCondition" is not declared in the current scope. All variables must be declared in the scope before being accessed. This was an internal error. The flow was not generated correctly by the BPEL compiler.

The audit trail will show the following message:

The transaction was rolled back. The work performed for bpel instance "xxx" was rolled back to the previous dehydration point, but the audit trail has been saved. You can recover the instance from the recovery console by resubmitting the callback message or activity for execution.

It seems SOA Suite uses an internal variable to count the number of times a loop is executed. Probably, this variable is not initialized when using a SOA Suite 11g version predating PS3 and thus results in the error.

There are two solutions to this:

  • Validate there are no running instances that execute a While loop while patching your environment;
  • If not, use the patch as indicated in patch reference 1451018.1 at the Oracle Support Site.

After applying the patch and restarting SOA Suite you will notice the following log entry indicating the loop count exception is handled by SOA Suite:

<Warning> <oracle.soa.bpel.engine> <BEA-000000> <Handling Exception on setting __loopCondition. This is expected for in-flight instances created before SOA upgrade from PS3 or older versions. 

Default Human Worklist Application and OWSM

The out-of-the-box Human Worklist Application is configured to use the oracle/no_authentication_service_policy policy of Oracle Web Services Manager (OWSM). This policy became available in later patchsets, but isn't shipped with SOA Suite and OWSM PS2. Without updating your OWSM policy store you'll see the following error when logging into the Human Worklist Application after applying PS5:

An error occurred for port: {http://xmlns.oracle.com/bpel/services/IdentityService} IdentityServicePort: oracle.fabric.common.PolicyEnforcementException: PolicySet Invalid: WSM-06162 PolicyReference The policy referenced by URI "oracle/no_authentication_service_policy" could not be retrieved

This can be fixed by updating the OWSM policies using the upgradeWSMPolicyRepository() command. This is documented in Upgrading the Oracle WSM Policies in the Repository. Make sure the Managed (or Admin) Server on which the OWSM PM application is deployed is running. Otherwise you'll see an error indicating that an MBean that is used for the policy upgrade cannot be reached.

See the Oracle Fusion Middleware Security and Administrator’s Guide for Web Services 11g Release 1 ( for more information on OWSM and its policies.

1 comment:

  1. It could be that some running BPEL instances (that were in a loop) errored between applying the pathset and applying the patch for fixing the loop counter. If this is the case, you can easily recover these instances by using the new BPEL Recovery Console from EM and retrying the messages.