Changes in SOA Human Task Flow (Run-Time) for Fusion Applications

Please note the Fusion Applications A-Team Blog has moved.  This blog posting has been migrated to:  http://www.ateam-oracle.com/changes-in-soa-human-task-flow-run-time-for-fusion-applications/

Recently I was engaged with one of the customers to deploy custom SOA composite to one of the domains in Fusion Applications environment. The SOA composite was basic and had a simple Human Task Flow component. At runtime, the human task was created successfully, but users were unable to load the ADF form of that task to work on it from BPM Worklist.

After troubleshooting, it was discovered the Task UI/workflow application context root (/workflow) was not defined in the webhost of the Project domain (where the SOA composite and respective ADF form application was deployed). This is necessary because Fusion Applications has internal and external URL's. The communication between the SOA Server and Task UI application goes through the internal URL. The requests are then forwarded to one of the Oracle HTTP Server's internal virtual hosts specific to each domain on webhost. In this case the /workflow location in FusionVirtualHost_prj.conf (Project Domain) of the webhost was missing. Please consult the Oracle Support Doc ID# 1459248.1 for more information.

In this troubleshooting process I discovered the following critical changes:

1. The runtime behavior of Human Task execution has changed in Fusion Applications. The supervisory and position hierarchies are looked up from HCM domain - irrespective of where SOA composite is deployed (for ex: CommonDomain or ProjectDomain). The HCM web service is called to identify approvers of the task and they are protected through OWSM policy. The Management chain still goes through LDAP.

Although this is an internal change of engine runtime instructions, it is critical to know for troubleshooting.

2. In most Weblogic domains (non Fusion Applications), the OPSS lifecycle listeners are available and can create application policy node and migrate application policy data. However, in Fusion Applications domains, these listeners are turned off which means that EARs that include jazn-data.xml will not be processed. You must manually migrate JAZN policies.