Best Practices from Oracle Development's A‑Team

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


We recently engaged with one of our customers to deploy a Service Oriented Architecture (SOA) composite to one of the domains in their Fusion Applications (FA) 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 Application Development Framework (ADF) form of that task in order to work on it from the Business Process Management (BPM) work list.

After troubleshooting, it was discovered the Task User Interface (UI)/workflow application context root (/workflow) was not defined in the web host 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 the web host. In this case the /workflow location in FusionVirtualHost_prj.conf (Project domain) of the web host 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 Human Capital Management (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 oracle Web Services Manager (OWSM) policy. The Management chain still goes through Lightweight Directory Access protocol (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 Oracle Platform Security Services (OPSS) life cycle listeners are available and can create an application policy node and migrate application policy data. However, in Fusion Applications domains, these listeners are turned off which means that Enterprise Archives (EARs) that include jazn-data.xml will not be processed. You must manually migrate the Java Authorization (JAZN) policies.

Be the first to comment

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