[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: BP-30: B4P spec doesn't support sequential routing pattern
Assigned: http://www.osoa.org/jira/browse/BP-30 -----Original Message----- From: Ravi Rangaswamy [mailto:ravi.rangaswamy@oracle.com] Sent: Tuesday, September 02, 2008 19:42 To: bpel4people@lists.oasis-open.org Subject: [bpel4people] NEW ISSUE: B4P spec doesn't support sequential routing pattern TARGET: WS-HT, General DESCRIPTION: WS-HT should support sequential routing pattern. In the current WS-HT spec, people assignments are singular in notion. The potential owners in the sequential pattern can either be done through logical people groups, literals or an expression. Use Case: Consider an approval process for OnBoarding where a task has to be approved by following a management chain. Only if one user completes the task, it is assigned to the next in the chain. WS-HT should support the assignment of tasks to a sequence of users/groups. RELATED ISSUES: . Support for routing patterns and policies . Support for single routing pattern . Support for parallel routing pattern PROPOSAL: Provide a mechanism to assign the task sequentially to users/groups by introducing a sequential routing pattern. In the sequential pattern, the task is assigned to either a list of users or groups. In each assignment, if there are multiple potential owners than one can claim the task and become the actual owner. After the actual user completes the task, it is assigned to the next users/groups in the sequential pattern. The sequential routing pattern can either represent a list of sequential users/groups or a management chain. In the list of users/groups case, the users/groups to approve the task are specified in the <htd:from> element. After each task owner completes the task, the task will be assigned to next user(s)/group(s) in the list. The order of the htd:from children will be preserved and used in the ordering of the user/groups evaluated from the list of htd:from elements. Management chain indicates a sequence of task assignment that is a result of computing the management chain in the associated user directory. The management chain contains the optional first task assignment. This task assignment could result in one or more potential owners. If there are multiple potential owners, one user from the list of potential owners can claim the task and become the actual owner. When the actual owner completes the task, the actual owner is used as the base user to compute the management chain. If the first task assignment is not present, the user who previously completed the task will be used to compute the management chain. When the first task assignment is specified in the management chain, optionally the actual owner could also be specified to indicate who should be the default actual owner in case there is more than one user in the potential owners list. The management chain list is controlled by the 2 parameters: 1. Levels: The number of levels in the management chain to actually assign the task to. The count of level starts from the first assignment resulting from the evaluation of the management chain. This is an optional configuration. 2. Highest Title of Approver: The title of the last (highest) user in the management chain. This is an optional configuration. Syntax <xsd:complexType name="tSequential"> <xsd:complexContent> <xsd:extension base="tExtensibleElements"> <xsd:sequence> <xsd:element name="list" type="tList"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="optional"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="tList"> <xsd:complexContent> <xsd:extension base="tExtensibleElements"> <xsd:sequence> <xsd:choice maxOccurs="1"> <xsd:element name="from" type="tFrom" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="managementChain" type="tManagementChain" minOccurs="0" maxOccurs="1"/> </xsd:choice maxOccurs="1"> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="tManagementChain"> <xsd:complexContent> <xsd:extension base="tExtensibleElements"> <xsd:sequence> <xsd:element name="from" type="tFrom" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="levels" type="xsd:string" minOccurs="1"/> <xsd:element name="title" type="xsd:string" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> Examples In the example below, assuming that the task input ClaimApprovalRequest has 3 claimProcessingAgents children - jlondon, jstein, wfaulk, the task will first be assigned to jlondon. After jlondon completes the task, it will be assigned to jstein. After jstein completes the task, it will be assigned to wfaulk. <htd:sequential name="Claim Processing Agents"> <htd:list> <htd:from> htd:getInput("ClaimApprovalRequest")/claimProcessingAgents </htd:from> </htd:list> </htd:sequential> In the example below, the task will first be assigned to user achrist. After achrist completes the task, it will be assigned to achrist's manager jlondon. After jlondon completes the task, it will be assigned to his manager jstein. The management chain will stop at that level because it has gone 3 levels. If jlondon where the 'Vice President', the management chain will stop with jlondon. <htd:sequential name="Claim Processing Review"> <htd:list> <htd:managementChain> <htd:from> <htd:literal> <htd:organizationalEntity> <htd:users> <htd:user>achrist</htd:user> </htd:users> </htd:organizationalEntity> </htd:literal> </htd:from> <htd:levels>number(3)</htd:levels> <htd:title>string('Vice President')</htd:title> </htd:managementChain </htd:list> </htd:sequential> --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]