1 / 18

WS-HT People Assignment Extensions for Task Routing Patterns

WS-HT People Assignment Extensions for Task Routing Patterns. September 2008. Agenda. 1. Problem Statement and Goals. 2. Use Case. 3. Proposal. Problem Statement. There is no standard way for defining complex people assignment patterns in WS-HT itself

matty
Download Presentation

WS-HT People Assignment Extensions for Task Routing Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WS-HT People Assignment Extensions for Task Routing Patterns September 2008

  2. Agenda 1. Problem Statement and Goals 2. Use Case 3. Proposal

  3. Problem Statement • There is no standard way for defining complex people assignment patterns in WS-HT itself • WS-HT people assignment is singular in notion (from logical people group, literal or expression) • It does not allow specifying a sequence of potential owners or a group of potential owners that are allowed to work on the task in parallel

  4. Problem Statement • Complex people assignments must be modeled in the business process • Customers view sequential/parallel routing patterns as part of one task • Human task involves collaboration between multiple users – sharing comments, attachments, input, output, etc. • Ability to see the various actions of the users in one single audit trail or history of the task • As complexity of the workflow routing patterns increase modeling the business process get more challenging • Portability of BPEL processes is not feasible unless we standardize on the BPEL generation • Might distract the business analyst from the purpose of the process • Tools that generated BPEL that orchestrate routing patterns would have hard time with any kind of change in generated processes • The lifecycle of people assignments might be more dynamic than the lifecycle of a business process. Thus modifying an approval chain would result in modifying the business process.

  5. Goals • Make people assignment in WS-HT (and BPEL4People) more flexible by allowing specification of routing patterns in people assignments • Single • Sequential • Parallel

  6. Proposal

  7. Routing Patterns • Introduce 3 routing patterns • Single • Sequential • Parallel • People assignment can contain either • htd:potentialOwners • htd:routingSlip • Routing slip contains all the routing information of a task • Routing slip can contain atmost one of • htd:single • htd:sequential • htd:parallel • Any other vendor specific patterns

  8. Routing Patterns • htd:single contains htd:from • htd:sequential contains either • A list of users or groups specified using htd:list or • A list of other patterns • htd:parallel contains either • A list of users or groups specified using htd:list or • Branches where each branch is a routing slip • htd:list contains • htd:from or • htd:managementChain or • Vendor specific lists

  9. Routing Patterns • Complex task • A task with a routing slip associated with it • Executes the task using one or more sub tasks • Does not have potential owners directly in it • Remains in ‘Created‘ state until there are no more pending sub tasks • When all sub tasks are completed, the complex task is completed • Also controls the life cycle of sub tasks • Sub task • Each assignment in a complex task is implemented using a sub task • Sub tasks are clones of the owning complex task • Life cycle of the sub task is the same as in section 4.7 in the WS-HT specification

  10. Routing Patterns • Attachments and comments of owning complex task are visible to the sub task • Sub task attachments, comments and output message • Sequential – are made available to owing complex task and subsequent sub tasks • Parallel with collaboration – are made available to owning complex task and sibling and subsequent sub tasks • Parallel with no collaboration – remain private to each branch of the parallel pattern • Outcome of complex task • Sequential – is the outcome of the last sub • Parallel – is computed using parallel completion criteria

  11. Single Routing Pattern <htd:tasks> <htd:task name="ApproveClaim"> <htd:peopleAssignments> <htd:routingSlip> <htd:single> <htd:from> <htd:literal> <htd:organizationalEntity> <htd:users> <htd:user>achrist</htd:user> </htd:users> </htd:organizationalEntity> </htd:literal> </htd:from> </htd:single> </htd:routingSlip> </htd:peopleAssignments>  </htd:task> </htd:tasks>

  12. Sequential Routing Pattern – Sample 2 <htd:tasks> <htd:task name="ApproveClaim"> …………… <htd:peopleAssignments> <htd:routingSlip> <htd:sequential> <htd:list> <htd:from> htd:getInput("ClaimApprovalRequest")/agents </htd:from> </htd:list> </htd:sequential> </htd:routingSlip> </htd:peopleAssignments> ……………….. </htd:task> </htd:tasks>

  13. Sequential Routing Pattern <htd:tasks> <htd:task name="ApproveClaim"> …………… <htd:peopleAssignments> <htd:routingSlip> <htd:sequential> <htd:single> <htd:from> <htd:literal> <htd:organizationalEntity> <htd:users> <htd:user>achrist</htd:user> </htd:users> </htd:organizationalEntity> </htd:literal> </htd:from> </htd:single>

  14. Sequential Routing Pattern (cont.) <htd:single> <htd:from> htd:getInput("ClaimApprovalRequest")/agents </htd:from> </htd:single> </htd:sequential> </htd:routingSlip> </htd:peopleAssignments> ……………….. </htd:task> </htd:tasks>

  15. Parallel Routing Pattern <htd:tasks> <htd:task name="ApproveClaim"> <htd:peopleAssignments> <htd:routingSlip> <htd:parallel> <htd:vote> <htd:defaultOutcome> string('APPROVE')</htd:defaultOutcome> <htd:percentageOfOutcome> number(50)</htd:percentageOfOutcome> </htd:vote> <htd:list> <htd:from> htd:getInput("ClaimApprovalRequest")/ags </htd:from> </htd:list> </htd:parallel> </htd:routingSlip> </htd:peopleAssignments>   </htd:task> </htd:tasks> • Vote • First responder • All responder

  16. Parallel Routing Pattern – Sample 2 <htd:tasks> <htd:task name="ApproveClaim"> …………… <htd:peopleAssignments> <htd:routingSlip> <htd:parallel> <htd:vote> <htd:defaultOutcome> string('APPROVE')</htd:defaultOutcome> <htd:percentageOfOutcome> number(50)</htd:percentageOfOutcome> </htd:vote>

  17. Parallel Routing Pattern (cont.) <htd:branch> <htd:sequential> <htd:list> <htd:from> htd:getInput("ClaimApprovalRequest")/ags </htd:from> </htd:list> </htd:sequential> </htd:branch>

  18. Parallel Routing Pattern (cont.) <htd:branch> <htd:sequential> <htd:list> <htd:from> <htd:literal> <htd:organizationalEntity> <htd:users> <htd:user>achrist</htd:user> <htd:user>bpalmer</htd:user> </htd:users> </htd:organizationalEntity> </htd:literal> </htd:from> </htd:list> </htd:sequential> </htd:branch> </htd:parallel> </htd:routingSlip> </htd:peopleAssignments>   </htd:task> </htd:tasks>

More Related