An inline task is defined in the BPEL process implementation. It can be implemented as a staff activity modeled on the business process level, and as task on various activities (invoke, pick, receive, event handler, on message).
Following reason why one should go for Inline Human Tasks :
Potential owner : Group Members without Named Users
NamedUsers : %wf:activity(Ratecredit).potentialOwners%
Where Ratecredit is the name of the business process activity (The first human task)
Following reason why one should go for Inline Human Tasks :
- Inline tasks offer the advantage that they have access to the context of the business process they belong to.
- We need information from the process logic to execute human interaction.
- We want to execute administrative tasks.
- We want to define authorization rights on specific activities.
- This enables scenarios like the “4-eyes principle”, also known as “separation of duties”. A usage example for the 4-eyes principle is an approval flow with two approval steps, both assigned to the same group of people, but with the additional rule that the approvals need to be given by two different people. The second approval’s staff query is defined such that it explicitly excludes the actual starter of the first approval. This can be done because as inline tasks, both approval tasks know about the enclosing process and its context, and hence the second task can access information from the first task.
Potential owner : Group Members without Named Users
NamedUsers : %wf:activity(Ratecredit).potentialOwners%
Where Ratecredit is the name of the business process activity (The first human task)
- Having the ability to access process context also allows assigning tasks directly to the process starter something very useful for example in employee self service applications.
No comments:
Post a Comment