I was working recently on integrating ADF 11.1.2.4 and BPM 11.1.1.7 environments. This worked pretty well, all configuration was done based on my previous blog post for similar topic, only previous ADF and BPM versions - BPM 11g R1 Worklist Integration (Hacking Experiment) Into Non-SOA ADF 11g R2 Domain. Goal of this post is to describe dynamic ADF form approach associated with BPM process human task.
BPM payload contains additional element called voInstanceName. This element is supposed to contain ADF VO instance name, this instance will be used later to render dynamic ADF UI for the currently selected task:
Sample application - adfbpm11gr4.zip, is based on two separate applications. One implements simple BPM process with payload including ADF VO instance name and another implements standalone dynamic ADF application with BPM API.
There are two human tasks in BPM process. Each of these human tasks accepts a payload element with ADF VO instance name. This allows to control ADF UI from BPM process, by providing ADF VO instance name to be used in ADF. The first human task is set to work with EmployeesView1 instance:
Second human task is set to work with different ADF VO instance - EmployeesROView1:
I'm reading voInstanceName payload variable value in ADF application, to construct dynamic ADF UI accordingly. Accessing currently selected task by ID and retrieving payload information for voInstanceName. Later this information will be used to construct dynamic ADF iterator:
Value from voInstanceName payload is used as a parameter for the ADF task flow rendering dynamic ADF UI. Task flow is configured to refresh each time, when parameter value is changed - new UI will be rendered for each new task selected:
ADF task flow checks if parameter for voInstanceName is not empty (it could be empty, if there are no tasks from BPM or payload value was not set). If there is no value, user will be redirected to the empty fragment:
Dynamic ADF UI is constructed in the bindings, instead of using static ADF iterator - we are initialising iterator from task flow parameter value passed through voInstanceName. This is how we can switch between different VO's from the ADF BC, depending on BPM task selected:
ADF UI is rendered with dynamic ADF form component. There are several ways to implement dynamic ADF UI, it can be all custom or using out of the box ADF UI components (depends on use case requirements). Here I'm using out of the box dynamic component, because UI is fairly simple:
This is how it looks like. Initially there are no tasks, no dynamic ADF UI - blank screen:
Start a new task in BPM, task is started through BPM API from standalone ADF application:
ADF UI form is rendered for the task. User can select a task and then select Employee, by navigating with Next/Previous buttons. As soon as Employee is selected (ID: 103), task can be submitted for further processing:
Login with different user - redsam2 and you are going to see new task in the inbox. Employee data is rendered from different VO instance and is readonly now. Employee ID was taking from the payload, this is how a row with ID: 103 is selected (the same as selected in the previous step):
Employee data in the second step is rendered from different read-only VO, including Job Title attribute:
There are two human task activities in the process, both are rendered with different dynamic ADF UI:
BPM payload contains additional element called voInstanceName. This element is supposed to contain ADF VO instance name, this instance will be used later to render dynamic ADF UI for the currently selected task:
Sample application - adfbpm11gr4.zip, is based on two separate applications. One implements simple BPM process with payload including ADF VO instance name and another implements standalone dynamic ADF application with BPM API.
There are two human tasks in BPM process. Each of these human tasks accepts a payload element with ADF VO instance name. This allows to control ADF UI from BPM process, by providing ADF VO instance name to be used in ADF. The first human task is set to work with EmployeesView1 instance:
Second human task is set to work with different ADF VO instance - EmployeesROView1:
I'm reading voInstanceName payload variable value in ADF application, to construct dynamic ADF UI accordingly. Accessing currently selected task by ID and retrieving payload information for voInstanceName. Later this information will be used to construct dynamic ADF iterator:
Value from voInstanceName payload is used as a parameter for the ADF task flow rendering dynamic ADF UI. Task flow is configured to refresh each time, when parameter value is changed - new UI will be rendered for each new task selected:
ADF task flow checks if parameter for voInstanceName is not empty (it could be empty, if there are no tasks from BPM or payload value was not set). If there is no value, user will be redirected to the empty fragment:
Dynamic ADF UI is constructed in the bindings, instead of using static ADF iterator - we are initialising iterator from task flow parameter value passed through voInstanceName. This is how we can switch between different VO's from the ADF BC, depending on BPM task selected:
ADF UI is rendered with dynamic ADF form component. There are several ways to implement dynamic ADF UI, it can be all custom or using out of the box ADF UI components (depends on use case requirements). Here I'm using out of the box dynamic component, because UI is fairly simple:
This is how it looks like. Initially there are no tasks, no dynamic ADF UI - blank screen:
Start a new task in BPM, task is started through BPM API from standalone ADF application:
ADF UI form is rendered for the task. User can select a task and then select Employee, by navigating with Next/Previous buttons. As soon as Employee is selected (ID: 103), task can be submitted for further processing:
Login with different user - redsam2 and you are going to see new task in the inbox. Employee data is rendered from different VO instance and is readonly now. Employee ID was taking from the payload, this is how a row with ID: 103 is selected (the same as selected in the previous step):
Employee data in the second step is rendered from different read-only VO, including Job Title attribute:
There are two human task activities in the process, both are rendered with different dynamic ADF UI:
No comments:
Post a Comment