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

[Dave Ings <ings@ca.ibm.com>]

Forwarding to list.

Regards, Dave Ings,
Emerging Software Standards
Email: ings@ca.ibm.com
Yahoo Messenger: dave_ings
----- Forwarded by Dave Ings/Toronto/IBM on 2008/12/09 03:55 PM -----

From:	Yoichi Takayama <takayama.yoichi@gmail.com>
To:	Dave Ings/Toronto/IBM@IBMCA
Date:	2008/12/09 03:52 PM
Subject:	Fwd: [bpel4people] BP-44: Discovering the operations available for the task

---

Hi

I have posted but it still does not get to the list. Do you mind posting it, although Michaek and Priyantha must have gotten it?

According to the admin at OASIS, somehow my email address gets translated to my other email address when it is sent. Since it has not been registered, it was rejecting. Although now I have registered the secondary email address, it takes time for synchronization to occur apparently.

Thanks,
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.

Begin forwarded message:

From: Yoichi Takayama <yoichi@melcoe.mq.edu.au>
Date: 9 December 2008 3:39:33 PM
To: Michael Rowley <michael.rowley@activevos.com>
Cc: bpel4people@lists.oasis-open.org, "'Priyantha Jayanetti'" <priyantha.jayanetti@activevos.com>
Subject: Re: [bpel4people] BP-44: Discovering the operations available for the task

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