Re: [bpel4people] BP-44: Discovering the operations available for the task

[Yoichi Takayama <takayama.yoichi@gmail.com>]

Hi Michael,

Thanks for the detailed Use Cases. That is very useful to understand what should happen.

I have some questions.

I think that it is a Task List Client who has to present Tasks for a user (there is only one user for that display) and Roles he/she has on Tasks and therefore what operations are available for the user on those Tasks? I think that Task Client is meant to deal with the Task Application supplied from the Task Service.

I thought that a person may be in only one of these Roles at a time. For example, the Potential Owner and the Actual Owner do never have a union. It happens one after another and mutually exclusive. Although I have to say there may be a union of some Roles and I am not 100% sure of all aspects of it yet.

I am not certain about the term Task Initiator. Does it exist? I don't see the Operation "Initiate" in the diagram in Draft 2 of BPEL4People 1.1. A Potential Owner -> claims a Task (it becomes Ready to Reserved Task - The user becomes a Task Claimant? Or does he/she become an Actual Owner at this time? Or, is this called the Initiator, although the Task has not yet been initiated really?) -> Start a Task (the user becomes an Actual Owner at this stage?). Or, one of the Potential Owners "starts" the Ready state Task. Also, if the user is to become an Actual Owner only by "starting" the Task, he/she may not "start" the Task again as you indicate in the table that an Actual Owner can start the Task. So does this mean that Reserving a Task may mean that the person becomes an Actual Owner?

Also, the Task Stakeholders to Claim, Stop, Release, Suspend, Release, Skip, Delegate or Forward does not make sense to me. I think that it would be better if these are allowed to only the Potential Owners (Ready state), Actual Owner (Reserved/InProgress states) and the Business Administrator(s)? This, of course, may depend on how we specify what Logical Human Group may handle the Escalation? Only the difference in the table is that the Business Administrator may do Activate and Nominate. Otherwise, these two look very similar. Maybe Task Stakeholders should have less privileges or must become Business Administrators to perform some Operations? I may be missing Business Use Cases in these?

Also, I thought that the Task Stakeholders and the Potential Owners were mutually exclusive.  Since the Potential Owners may become the Actual Owner, often it may not be suitable to allow one to be a manager of one-self (e.g. approves own work steps). Maybe there should be a mechanism to reassign Potential Owners who did not take the Actual Owner Role to become Business Administrator(s) or Task Stakeholders? (i.e. I think that they may not be in both at the same time). Although I am not certain how to handle dynamic Role shifts at this stage. This is just a food for thought. Michael, you must have some excellent Use Cases and if you can include them and the table below in BPEL4People recent draft, wouldn't that be clearer?

Actual Owner and the Business Administrator Roles may be also mutually exclusive in general?

The Task Life-Cycle diagram in BPEL4People has Suspend/Resume from InProgress state (not only from the Ready state). I think that this is for the Actual Owner and the Business Administrator.

Finally, I am still not sure whether Fail can be an Operation for the Actual Owner. Usually, I think that it has nothing to do with explicit user operations. When some error conditions are encountered in the Task, the Fault state happens and reported to the Task Manager? This is because I can see that setFault operation, that may set external triggering of the Fail state? Has Dieter raise this today in fact to unify them???

By any rate, I think that Roles may not be so clean in this definition including static and dynamic concepts together.

Regards,

Yoichi

On 10/12/2008, at 9:18 AM, Michael Rowley wrote:

In order for the task client to create the union of all operations are allowed, it would have to call getPotentialOwners, getActualOwner, etc for all the generic roles.  It would then have to have access to user/group information for all groups mentioned in the returned organizationalEntities (which some task clients may not have access to).

The task processor already has to have computed what operations are available for this user, so it is better if the server just passes that information to the client.

Michael

Yoichi Takayama wrote:

499B164D-1E6C-4C6B-8312-83C4AEF6F361@gmail.com" type="cite">I see. Now I understand. Those Roles!

In that case, my comment is that, do we need getOperations call for this? If it is all known, the both system and the Task List Client can implement without using the getOperations call?

Yoichi

On 10/12/2008, at 8:53 AM, Michael Rowley wrote:

Here is the complete list of the different operations that are available to each role:

WS-HT Operation	Task Initiator	Task Stakeholders	Potential Owners	Actual Owner	Excluded Owner	Business Administrator
Claim		X	X			X
Start			X (from Ready state)	X
Stop		X		X		X
Release		X		X		X
Suspend		X	X (from Ready state)	X		X
Resume		X	X (from Ready state)	X		X
Complete				X
Fail				X
setPriority		X	X (from Ready state)	X		X
addAttachment		X	X (from Ready state)	X		X
getAttachmentInfos		X	X	X		X
getAttachments		X	X	X		X
deleteAttachments		X		X		X
addComment		X	X	X		X
getComments		X	X	X		X
skip	X	X		X		X
forward		X	X	X		X
delegate		X	X (from Ready state)	X		X
getRendering	X	X	X	X		X
getRenderingTypes	X	X	X	X		X
getTaskInfo	X	X	X	X		X
getTaskDescription	X	X	X	X		X
setOutput				X
deleteOutput				X
setFault				X
deleteFault				X
getInput		X	X	X		X
getOutput		X		X		X
getFault		X		X		X
activate						X
nominate						X
setGenericHumanRole						X

Michael

Yoichi Takayama wrote:

312A0382-92E4-4BBB-A7EF-36CF159595C7@gmail.com" type="cite">Thanks.

Can you give me Use Cases of what operations may belong to one Role and others to another of those Operations (start, create, suspend, skip, etc)?

The description is more suitable to Task Application related operations, which are not on of these.

Thanks,

Yoichi

On 10/12/2008, at 8:38 AM, Michael Rowley wrote:

Yoichi,

The role is the role that the current logged in user has with respect to this task.  For example, a user is a business administrator for a task if that user is listed in the organizationalEntity assigned to the business administrator role for that task, or if the user is a member of a group that is listed in that organizationalEntity.

Naturally, a user may have several roles with respect to an activity, so the returned set of allowed operations will be the union of the operations allowed for all of the roles that apply to that user.

For a list of which operation apply to each role, you can see the matrix that was accepted in the resolution of issue 43.

Michael

Yoichi Takayama wrote:

Hi

Probably I have not been following this stream of discussion, but can you clarify what Roles you are concerned?

As far as I can see there is nothing in BPEL4People 1.0 to define any Roles regarding to Tasks and Task Life-Cycle related operations.

The only thing I can see is that it is possible to pre-assign Tasks to people that is defined by the People Assignment (logical persons or groups) and to deny them whether they can claim or not, or to allow those potential users to "claim" Tasks. This will change what operations they may perform on Task life-cycle control.

However, this must be rather self-evident as to what "operations" they are allowed. Is the proposal still addressing this to use getTaskOperations(taskID), to simply return what operations are possible depending on the State the Task is in? Eg. The Task which has not "Started" obviously cannot be "Exited". Although this should be also self-evident.

Maybe the specification can present the State Machine state transition table for this as a guide? I am not aware of any other "roles" that may change possible  "buttons" to depict on the client UI of the Task Inbox application (or Task List application as in BPEL4People, that will communicate with a Task Manager - although Task Manager or its address is not defined in BPEL4People).

Also, If it is rather to do with freely defined Roles with different abilities given, one must be able to define those Roles somewhere first. Is that in the BPEL4People 1.1 or the recent Sub-task proposal?

I wonder whether there may be a confusion about Roles used in Task application implementations? As far as I know, their names can be used in Task definitions to assign Logical People but they are not related to Task life-cycle Operations, because only one person is allowed to do those Tasks (even in the parallel Task situations and they are all the same "Role" in the Task).

Although I know in human activities in other applications, the ability to use Task defined Roles is really important and I was going to bring it up later, but the email talking about the Operations below (Task life-cycle Operations) does not sound like anything to do with it.

Yoichi

--------------------------------------------------------------------------

Yoichi Takayama, PhD

Senior Research Fellow

RAMP Project

MELCOE (Macquarie E-Learning Centre of Excellence)

MACQUARIE UNIVERSITY

Phone: +61 (0)2 9850 9073

Fax: +61 (0)2 9850 6527

www.mq.edu.au

www.melcoe.mq.edu.au/projects/RAMP/

--------------------------------------------------------------------------

MACQUARIE UNIVERSITY: CRICOS Provider No 00002J

This message is intended for the addressee named and may contain confidential information.  If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of Macquarie E-Learning Centre Of Excellence (MELCOE) or Macquarie University.

On 09/12/2008, at 2:19 PM, Michael Rowley wrote:

[For the original issue, see the bottom of this email]

PROPOSAL:

1) Introduce a new operation called: getTaskOperations(taskID).

 

This operation returns list of operations that are available to the authorized user given the user's role and the state of the task.

 

The response element getTaskOperationsResponse contains the set of elements whose name is the same as the operation. For example, for a task in Ready state:

 

<getTaskOperationsResponse>

  <taskOperations>

    <claim/>

    <start/>

    <addComment/>

    <addAttachment/>

    <setPriority/>

  </taskOperations>

</getTaskOperationsResponse>

 

A task inbox/listing application can use the existence of these task operation elements to determine whether to render the operation UI buttons such as claim and start. Without this information, the inbox application may have to implement its own logic on the client side to determine the available operations.

 

2) Include <taskOperations/> element in tasks that are returned in getMyTask operation (Sec 6.1.2).

 

The proposed changes to the task api wsdl and schemas are:

 

<!-- taskOperations port type in ws-humantask-api.wsdl  -->

<wsdl:operation name="getTaskOperations">

   <wsdl:input message="getTaskOperations" />

   <wsdl:output message="getTaskOperationsResponse" />

   <wsdl:fault name="illegalArgumentFault"

     message="illegalArgumentFault" />

   <wsdl:fault name="illegalAccessFault"

     message="illegalAccessFault" />

</wsdl:operation>

 

<!-- messages in ws-humantask-api.wsdl  -->

<wsdl:message name="getTaskOperations">

  <wsdl:part name="getTaskOperations" element="htdt:getTaskOperations" />

</wsdl:message>

<wsdl:message name="getTaskOperationsResponse">

  <wsdl:part name="getTaskOperationsResponse" element="htdt:getTaskOperationsResponse" />

</wsdl:message>

 

<!-- htdt schema ws-humantask-api-wsdl.xsd (http://www.example.org/WS-HT/api/xsd) -->

<xsd:element name="getTaskOperations">

 <xsd:complexType>

   <xsd:sequence>

     <xsd:element name="identifier" type="xsd:anyURI" />

   </xsd:sequence>

 </xsd:complexType>

</xsd:element>

 

<xsd:element name="getTaskOperationsResponse">

   <xsd:complexType>

     <xsd:sequence>

         <xsd:element ref="api:taskOperations" />

     </xsd:sequence>

   </xsd:complexType>

</xsd:element>

 

<!-- definiton of taskOperations element in ws-humantask-api.xsd  (http://www.example.org/WS-HT/api) -->

<xsd:complexType name="tTaskOperation"/>

<xsd:element name="taskOperations">

   <xsd:complexType>

      <xsd:all>

         <xsd:element name="claim" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="start" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="stop" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="release" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="suspend" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="suspendUntil" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="resume" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="complete" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="remove" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="fail" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="setPriority" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="addAttachment" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="getAttachmentInfos" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="getAttachments" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="deleteAttachments" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="addComment" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="getComments" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="skip" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="forward" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="delegate" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="getRendering" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="getRenderingTypes" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="getTaskInfo" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="getTaskDescription" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="setOutput" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="deleteOutput" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="setFault" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="deleteFault" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="getInput" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="getOutput" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="getFault" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="activate" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="nominate" type="tns:tTaskOperation" minOccurs="0"/>

         <xsd:element name="setGenericHumanRole" type="tns:tTaskOperation" minOccurs="0"/>

      </xsd:all>

   </xsd:complexType>

</xsd:element>

 

<!--

   Changes to tTask complex type defined in ws-humantask-api.xsd (http://www.example.org/WS-HT/api)

   The addition here is the reference to the taskOperations element defined towards the end of the sequence.

 -->

 

<xsd:complexType name="tTask">

 <xsd:sequence>

   <xsd:element name="id" type="xsd:string" />

   <xsd:element name="taskType" type="xsd:string" />

   <xsd:element name="name" type="xsd:QName" />

   <xsd:element name="status" type="tStatus" />

   <xsd:element name="priority" type="xsd:nonNegativeInteger"

     minOccurs="0" />

   <xsd:element name="taskInitiator" type="htd:tUser"

     minOccurs="0" />

   <xsd:element name="taskStakeholders"

     type="htd:tOrganizationalEntity" minOccurs="0" />

   <xsd:element name="potentialOwners"

     type="htd:tOrganizationalEntity" minOccurs="0" />

   <xsd:element name="businessAdministrators"

     type="htd:tOrganizationalEntity" minOccurs="0" />

   <xsd:element name="actualOwner" type="htd:tUser" minOccurs="0" />

   <xsd:element name="notificationRecipients"

     type="htd:tOrganizationalEntity" minOccurs="0" />

   <xsd:element name="createdOn" type="xsd:dateTime" />

   <xsd:element name="createdBy" type="xsd:string" minOccurs="0" />

   <xsd:element name="activationTime" type="xsd:dateTime"

     minOccurs="0" />

   <xsd:element name="expirationTime" type="xsd:dateTime"

     minOccurs="0" />

   <xsd:element name="isSkipable" type="xsd:boolean" minOccurs="0" />

   <xsd:element name="hasPotentialOwners" type="xsd:boolean"

     minOccurs="0" />

   <xsd:element name="startByExists" type="xsd:boolean"

     minOccurs="0" />

   <xsd:element name="completeByExists" type="xsd:boolean"

     minOccurs="0" />

   <xsd:element name="presentationName" type="tPresentationName"

     minOccurs="0" />

   <xsd:element name="presentationSubject"

     type="tPresentationSubject" minOccurs="0" />

   <xsd:element name="renderingMethodExists" type="xsd:boolean" />

   <xsd:element name="hasOutput" type="xsd:boolean" minOccurs="0" />

   <xsd:element name="hasFault" type="xsd:boolean" minOccurs="0" />

   <xsd:element name="hasAttachments" type="xsd:boolean"

     minOccurs="0" />

   <xsd:element name="hasComments" type="xsd:boolean"

     minOccurs="0" />

   <xsd:element name="escalated" type="xsd:boolean" minOccurs="0" />

   <xsd:element name="primarySearchBy" type="xsd:string"

     minOccurs="0" />

  

   <!-- New element -->

   <xsd:element ref="tns:taskOperations" minOccurs="0" />  

    

   <xsd:any namespace="##other" processContents="lax" minOccurs="0"

     maxOccurs="unbounded" />

 </xsd:sequence>

</xsd:complexType>

Luc Clement wrote:
>
> Assigned: http://www.osoa.org/jira/browse/BP-44
>
>  
>
> From: Michael Rowley [mailto:michael.rowley@activevos.com]
> Sent: Wednesday, October 01, 2008 10:56
> To: bpel4people@lists.oasis-open.org
> Subject: [bpel4people] NEW ISSUE: Discovering the operations available for the task
>
>  
>
>  
>
> TARGET: WS-HT
>
>  
>
> DESCRIPTION:
>
>  
>
> The operations that are available for a task varies depending on the state that the task is in and the role of the person who might do the operation.  The task API should make it possible to ask which operations are currently available for a task for a specific user.
>
>  
>
> PROPOSAL:
>
>  
>
> None yet.

--------------------------------------------------------------------- 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

--------------------------------------------------------------------- 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

--------------------------------------------------------------------- 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