Generic ADF 11g Human Task Handler Concept for Oracle BPM

One of the main complexities with Oracle BPM - how to organize Human Task projects and components. Is preferable to avoid code duplication and having lots of generated ADF Data Control files in different ADF UI projects. Reusability problem can be solved by having generic Human Task handler - I will describe its concept in this blog.

One of the main principles defined in this post - pass through BPM payload only key attributes. Key attribute should identify business object in the process, but associated data for this business object always will be queried from database. This allows to implement reusable ADF UI for Human Tasks and avoid data transformation complexity in BPM. Of course this approach will work, if you will be granted access to the data.

Concept is tested and implemented as sample application, available for download - EmployeeManagementLab_v2.zip. This application implements BPM process with two Human Tasks, but there is only one ADF UI project (it serves both Human Tasks):

Human Task activities available in BPM process:

Now if you want to generate ADF UI for these Human Tasks - stop, wait a bit. Instead of generating separate ADF UI for each of these Human Task activities - create another dummy Human Task activity and we generate generic ADF UI from it. This generic Human Task should be configured with all required actions for any Human Task from the process:

Dummy Human Task is defined - GenericHumanTask:

We generate GenericHumanTaskUI project from this dummy Human Task:

Once ADF UI project was generated - delete dummy Human Task, we don't need it anymore. Change generated ADF Task Flow - add Router activity. Router decides to open page directly or set current row first (suppose first Human Task shows list of employees and second Human Task needs to display only one specific employee):

ADF UI Generic Human Task application is enabled with ADF Security, it defines application role to differentiate users from Router activity in the Task Flow - task-creator-role, this role is granted to the user who have access to the first Human Task - Assign Employee:

ADF Task Flow Router activity checks application security role granted to the user and navigates accordingly:

If flow goes through the method, where current row is set - key value is retrieved from BPM payload variable:

There is only one ADF UI page, it serves both Human Tasks:

Data is rendered conditionally for each of the tasks. First Human Task displays editable data and second - readonly. This is controlled on ADF BC EO level with ADF Security. Employees EO is enabled with Update security operation:

Update permission is granted to the task-creator-role, the same role which is allowed to open ADF UI page directly. This means user granted with such role will be able to change data:

Remember we exposed all operations for generic Human Task, now we can see all these operations available in Data Control:

ADF UI page for the Human Task is auto generated to support all these operations. Based on condition and Human Task configuration, ADF will render only available operations for specific Human Task. This is how we can maintain generic Human Task ADF UI for different BPM Human Task definitions:

Generic ADF UI is deployed as separate application:

The trick is to point both Human Task instances to the same ADF UI - ADF Task Flow.

AssignEmployee task points to EmployeeGenericHumanTaskUI:

ApproveEmployee task points to EmployeeGenericHumanTaskUI:

Test ADF UI with user - redsam1, this user have access to AssignEmployee task:

This user gets editable access, can select Employee data and send for further for processing:

Submit task:

Login as another user, who have access to the ApproveEmployee task:

Task data is rendered in readonly mode and only row based on submitted key from BPM process. Task actions are also different from previous Human Task: