Table of Contents
List of Figures
- 6.1. State transitions
List of Tables
Table of Contents
In order to have something running, you need to do following steps:
Download HISE distribution
Then you need to unzip HISE WAR contents into your application server directory (like Apache Tomcat). Name it hise.
Copy example files from examples/claims-approval/* into WEB-INF/classes directory. HISE looks up *-hise-dd.xml files for Human Tasks definitions.
Start your application server. This will create H2 database schema in files hise-h2-db.*.db.
Enter hise URL into your browser. For Tomcat, this will be http://localhost:8080/hise. There will be a list of services exposed by HISE. It will contain approve operation from example task.
You can import WSDL http://localhost:8080/hise/ClaimsHandlingService/?wsdl into SoapUI to start interacting with Human Task. There is also a prepared project in examples/claimsHandling/claimsHandling-soapui-project.xml.
You need to import some user and group definitions. By default, HISE uses H2 file database named hise-h2-db. So you can run addUsers.sql script from HISE distribution, by following command:
java -cp webapps/hise/WEB-INF/lib/h2-1.1.108.jar org.h2.tools.RunScript -url 'jdbc:h2:file:hise-h2-db;DB_CLOSE_ON_EXIT=false' -user sa -showResults -script addUsers.sqladdUsers.sql looks like this:
insert into HISE_ENTITY (name, type, userpassword) values ('user1', 'USER', 'pass1'); insert into HISE_ENTITY (name, type, userpassword) values ('group1', 'GROUP', null); insert into HISE_USER_GROUPS (USERGROUPS_NAME, ORGENTITY_NAME) values ('user1', 'group1');This defines Organizational Entities and specifies associations between users and groups.
Next, you need to enter claimsHandling-soapui-project.xml and start Resolving Mock Service and run ClaimsHandling test suite. This will register a claim by sending approve operation and send back response to Mock Service on complete.
Note that approve operation is meant to be sent by external system to HISE deployed Human Task. This differs from TaskOperations Web Service, which is meant to be used by Task Operator. TaskOperations operations require operator's authentication via WS Security. So in SoapUI operators need to fill fields like "user", "password", "password type" (digest or plain text). When operator completes or fails a task, HISE sends response to external system. This yields to receiving a request in Resolving MockService in SoapUI. Additionally, when WS Addressing reply-to field is specified in approve request, HISE will send reply on task completion to a specified address.
Download HISE distribution and Apache Tomcat. This distribution was tested under Tomcat 5.5 and 7.0
Extract HISE and install Tomcat.
The catalog where HISE was extracted in futher part of the tutorial will be called HISE_DIR
The catalog of Tomcat instalation in futher part of the tutorial will be called TOMCAT_DIR
Copy war file from HISE_DIR to TOMCAT_DIR/webapps. Change name of the file to hise.war
Start Tomcat. Then on the basis of hise.war will be created directory TOMCAT_DIR/webapps/hise, and in TOMCAT_DIR/bin will be created files hise-h2-db.*.db for H2 database. After that shutdown Tomcat
You need to import some user and group definitions.By default, HISE uses H2 file database named hise-h2-db.So you can run addUsers.sql script from HISE distribution, by following command:
java -cp TOMCAT_DIR/webapps/hise/WEB-INF/lib/h2-1.1.108.jar org.h2.tools.RunScript -url 'jdbc:h2:file:TOMCAT_DIR/bin/hise-h2-db;DB_CLOSE_ON_EXIT=false' -user sa -showResults -script HISE_DIR/examples/addUsers.sqlCopy files from HISE_DIR/examples/war/claimsHandling/ to TOMCAT_DIR/webapps/hise/WEB-INF/classes
Copy files from HISE_DIR/examples/war/claimsHandling/ to TOMCAT_DIR/webapps/hise/WEB-INF/classes.
Now you can start Tomcat. If everything is fine at http://localhost:8080/hise you will see HISE services.
You can import WSDL http://localhost:8080/hise/ClaimsHandlingService/?wsdl into SoapUI to start interacting with Human Task. There is also a prepared project in HISE_DIR/examples/war/claimsHandling/claimsHandling-soapui-project.xml. At the first try run prepared test to make certain HISE is working properly.
HISE OSGi distribution works out of box under Apache ServiceMix 4.
It contains bundles directory with required dependencies.
In order to run it, you need to type in ServiceMix console: features:install hise-h2-test-example-osgi
Next, you can point your browser to http://localhost:8181/cxf address
and see deployed Web Services.
This distribution was tested under apache-servicemix-4.2.0-fuse-01-00.
HISE distribution contains claimsHandling example, which defines a single Human Interaction with one potential owner (Task Operator).
Task definition from claimsHandling.xml file contains following entries:
<htd:tasks>
<htd:task name="ClaimsHandlingTask">
<htd:interface portType="tns:ClaimsHandlingPT" operation="approve" responsePortType="tns:ClaimsHandlingPT" responseOperation="resolve"/>
...
<htd:peopleAssignments>
<htd:potentialOwners>
<htd:from>
<htd:literal>
<htd:organizationalEntity>
<htd:users>
<htd:user>user1</htd:user>
</htd:users>
</htd:organizationalEntity>
</htd:literal>
</htd:from>
</htd:potentialOwners>
</htd:peopleAssignments>
...
<htd:outcome>
<![CDATA[
<cla:resolve xmlns:cla="http://www.insurance.example.com/claims" xmlns:htd="http://www.example.org/WS-HT">
<claimId>{htd:getInput("request")/ClaimApprovalRequest/cla:cust/cla:id/text()}</claimId>
<ok>{$outcome}</ok>
</cla:resolve>
]]>
</htd:outcome>
</htd:task>
</htd:tasks>
htd:interface specifies Web Service via portType and operation attributes, which is exposed for listening for claims from external system. When such request arrives, it is assigned to potential owner user1, as specified in peopleAssignments: <htd:user>user1</htd:user>. Next, after Task Operator completes the claim, response is sent back to external system, specified by responsePortType and responseOperation. Following picture shows basic interation between parties involved.
Detailed information on endpoint addresses is defined in claimsHandling-hise-dd.xml file.
Table of Contents
Human tasks, or briefly tasks enable the integration of human beings in service- oriented applications. Human tasks are services “implemented” by people. They allow the integration of humans in service-oriented applications. A human task has two interfaces. One interface exposes the service offered by the task, like a translation service or an approval service. The second interface allows people to deal with tasks, for example to query for human tasks waiting for them, and to work on these tasks. A human task has people assigned to it. These assignments define who should be allowed to play a certain role on that task. Human tasks may also specify how task metadata should be rendered on different devices or applications making them portable and interoperable with different types of software. Human tasks can be defined to react on timeouts, triggering an apropriate escalation action. This also holds true for notifications. Notifications are a special type of human task that allows the sending of information about noteworthy business events to people. Notifications are always oneway, i.e., they are delivered in a fire-and-forget manner: The sender pushes out notifications to people without waiting for these people to acknowledge their receipt.
Presentation data – The data is derived from the task definition or the notification definition such as the name, subject or description.
Context data - A set of dynamic properties, such as priority, task state, time stamps and values for all generic human roles.
Operational data – The data includes the input message, output message, attachments and comments.
task state
priority
Values for all generic human roles, i.e. potential owners, actual owner and business administrators
Time stamps such as start time, completion time
Skipable indicator
task history language and indicator
Generic human roles define what a person or group of people resulting from a people query can do with tasks and notifications. The aplication distinguish fallowing generic human roles:
Task initiator is the person who creates the task instance. Depending on how the task has been instantiated the task initiator may or may not be defined. If task initiator is defined it is exactly one person.
Task stakeholders are the people ultimately responsible for the oversight and outcome of the task instance. A task stakeholder can influence the progress of a task, for example, by adding ad-hoc attachments, forwarding the task, or simply observing the state changes of the task. It is also allowed to perform administrative actions on the task instance and associated notifications, such as resolving missed deadlines. Compliant implementations MUST ensure that at least one person is associated with this role at runtime.
Potential owners of a task are persons who receive the task so that they can claim and complete it. A potential owner becomes the actual owner of a task by explicitly claiming it. Before the task has been claimed, potential owners can influence the progress of the task, for example by changing the priority of the task, adding ad-hoc attachments or comments. All excluded owners are implicitly removed from the set of potential owners.
Actual owneris the person actually performing the task. A task has exactly one actual owner. When task is performed, the actual owner can execute actions, such as revoking the claim, forwarding the task, suspending and resuming the task execution or changing the priority of the task.
Buisness administrators are the people who can play the same role as task stakeholders but at task type level. Therefore, business administrators can perform the exact same operations as task stakeholders. Business administrators may also observe the progress of notifications. Compliant implementations MUST ensure that at runtime at least one person is associated with this role.
Excluded owners may not become an actual or potential owner and thus they may not reserve or start the task. They can only doing statistic or information operations.
Recipients are persons who receive the notification, such as happens when a deadline is missed or when a milestone is reached. This role is similar to the roles potential owners and actual owner but has different repercussions because a notification recipient does not have to perform any action and hence it is more of informational nature than participation. A notification has one or more recipients.
A logical people groups is an element that could represents one person, a set of people, or one or many unresolved group of people. It is global element enclosed in a human interactions definition document. Multiple human tasks in the same document can utilize the same logical people group definition.
<htd:logicalPeopleGroups>
<htd:logicalPeopleGroup name="regionEmployees">
<htd:documentation xml:lang="en-US">Employee group.</htd:documentation>
<htd:parameter name="region" type="xsd:string"/>
</htd:logicalPeopleGroup>
</htd:logicalPeopleGroups>
Table of Contents
The fallowing basic attributs are defined for tasks:
This attribute is mandatory. It is used to specity the name of the task. The name, combined with namespace create a unique identifier the task definition.
This element is used to specify the priority of the task. It is an optional element which value is an integer expression. If not present, the priority of the task is set to 0 what is the highest priority. Larger numbers identify lower priorites.
This element allows enable automatic activation task (if it is possible) immediately after it is creation. It is binary type and optional. If not present the default value is false
It is used to assign people and group of people to different generic human role. This element is mandatory and is defined by "Using Literals" or "Logical people groups".
<htd:peopleAssignments>
<htd:potentialOwners>
<htd:from>
<htd:literal>
<htd:organizationalEntity>
<htd:users>
<htd:user>user1</htd:user>
</htd:users>
</htd:organizationalEntity>
</htd:literal>
</htd:from>
</htd:potentialOwners>
<htd:businessAdministrators>
...
</htd:businessAdministrators>
<htd:peopleAssignments>
...
<htd:potentialOwners>
<htd:from logicalPeopleGroup="regionalClerks">
<htd:argument name="region">
htd:getInput("part1")/region
</htd:argument>
</htd:from>
</htd:potentialOwners>
Table of Contents
Hise implements a deadline mechanism. Deadlines are defined inside task definitions and contains some escalation action. There are two types of deadlines:
Start deadline : Specifies the time until the task must start. It is defined as either the period of time or the point in time until the task must reach state inProgress. The time starts to be measured from the time at which the task enters the state Created. If the task does not reach state InProgress by the deadline an escalation action or a set of escalation actions is performed. Once the task is started, the deadline becomes obsolete and are removed.
Comletion deadline : Specifies the due time of the task. It is defined as either the period of time until the task gets due or the point in time when the task gets due. The time starts to be measured from the time at which the task enters the state Created. If the task does not reach one of the final states (Completed, Failed, Error, Exited, Obsolete) by the deadline an escalation action or a set of escalation actions is performed.
A task may have multiple start deadlines and completion deadlines associated with it. When the task reaches a final state (Completed, Failed, Error, Exited, Obsolete) all deadlines are deleted.
Simple example ot the deadline implementation:
<htd:deadlines>
<htd:startDeadline>
<htd:documentation xml:lang="xsd:language">
Text
</htd:documentation>
( <htd:for expressionLanguage="anyURI">
duration-expression
</htd:for>
| <htd:until expressionLanguage="anyURI">
deadline-expression
</htd:until>
)
<htd:escalation name="NCName">
...
</htd:escalation>
</htd:startDeadline>
<htd:completionDeadline>
...
</htd:completionDeadline>
</htd:deadlines>
Escalations is a definition of actions to be executed if a task's status is not reached within a certain time. An escalation must specify exactly one escalation action ( notification or reassignment). In one deadline could be defined many escalations.
<htd:escalation name="NCName">
...
</htd:escalation>
The escalatino definition may contain:
Condition is a element that allows (if evaluates to true) perform escalation. If the condition is not fulfilled during the cause deadline, the escalation is removed along with the deadline. Condition is an optional element.
<htd:condition expressionLanguage="anyURI"> boolean-expression </htd:condition>
Notifications are used to inform people about the status of the task. Notifications are explained in more detail in section “Notifications”. Notification can be either referred to, or defined inline. A notifications imported from a different namespace can be added by a localNotification element. A inlined notification is defined by a notification element. Notifications used in escalations may use the same type of input data as the surrounding task, or different type of data. If the same type of data is used then the input message of the task is passed to the notification implicitly. If not, then the toPart elements are used to assign appropriate data to the notification.
<!-- notification specified by reference -->
<htd:localNotification reference="QName">
<htd:priority expressionLanguage="anyURI">
integer-expression
</htd:priority>
<htd:peopleAssignments>
<htd:recipients>
...
</htd:recipients>
</htd:peopleAssignments>
</htd:localNotification>
...
<!-- notification specified inline -->
<htd:notification name="NCName">
...
</htd:notification>
ToParts is a element used when notifications in escalations use different type of data then input date. Then the toPart elements are used to assign appropriate data to the notification. If any of the toParts fails, the escalation action will not be performed and the execution of the task is not affected.
<htd:toParts>
<htd:toPart part="NCName" expressionLanguage="anyURI">
expression
</htd:toPart>
...
</htd:toParts>
Reassignments are used to replace the potential owners of a task when an escalation is triggered. The reassignment element is used to specify reassignment. If present, the element must specify potential owners. In the case where several reassignment escalations are triggered, the first reassignment (lexical order) will be considered for execution. The task is set to state Ready after reassignment.
<htd:reassignment>
<htd:potentialOwners>
...
</htd:potentialOwners>
</htd:reassignment>
Delegation element is used to specify constraints concerning delegation of the task. Attribute potentialDelegatees defines to whom the task may be delegated. The fallowing values are allowded:
- anybody - It is allowed to delegate the task to anybody
- potentialOwners - It is allowed to delegate the task to potential owners previously selected.
- nobody - It is not allowed to delegate the task.
- other - It is allowed to delegate the task to other people or group of people.
The delegation element is optional. If this element is not present the task is allowed to be delegated to anybody.
Simple example:
<htd:delegation potentialDelegatees="other">
<htd:from>
<htd:literal>
<htd:organizationalEntity>
<htd:groups>
<htd:group>group4</htd:group>
</htd:groups>
<htd:users>
<htd:user>user2</htd:user>
</htd:users>
</htd:organizationalEntity>
</htd:literal>
</htd:from>
</htd:delegation>
There are two features connecting with comments. Users can add comments to task and also view all task comments. The second feature is additional, it is not in specyfication - history of the task could be write as comments. This section describes this two features
User can add and view added comments. There is not oporunity to delete comment, thus comments are persistent. Comment consist:
date and time
user name
comment
The
comment
is assumed to be text.
The
user name
is set on value using during authorization.
It is a lile bit more complex. History of task consist information about state change and actual owner change. For every event comment is created. It consists every information like ordinary comment. Content of the comment describe situation that caused the comment creation. Default this feature is off.
Usually
user name
is set on value using during authorization. The first exception is
request
approve
, then users name is set on value of field
initiator
from request. The second exception is connected with deadLines.
Sometimes as a result of cross deadline may be initialize change
actual owner or change task state. Then the field
attachedBy
has value
Deadline crossed
Task history suppor internalization. User can choose language of comments that describe task history. Default language is english. If you want to change it, have to specified language for every task.
Example of settings active task history comments in polish language....
<htd:task name="exampleName">
..........
<htd:savingTaskHistory lang="PL">
<htd:active>true</htd:active>
</htd:savingTaskHistory>
..........
</htd:task>
and in english
<htd:task name="exampleName">
..........
<htd:savingTaskHistory>
<htd:active>true</htd:active>
</htd:savingTaskHistory>
..........
</htd:task>
It is assumed that a single task instance can be rendered by different task list clients so the task engine does not depend on a single dedicated task list client. Similarly it is assumed that one task list client can present tasks from several task engines in one homogenous list and can handle the tasks in a consistent manner.
There is not oportunity to set one rendering for every task, each of task should have own definition of rendering
The definition of rendering must contain type(name), and content. Connten is assumed to be XQuery or string.
Example of definition rendering:
<htd:task name="exampleName">
..........
<htd:rendering type="exampleType">
<expression>
<![CDATA[
declare namespace htd="http://www.example.org/example";
<example name="anyname" xmlns:cla="http://www.insurance.example.com/claims">
<param name="type" value="{htd:getInput("ClaimApprovalRequest")/cla:cust/cla:firstname/text()}"/>
</example>
</expression>
</htd:rendering>
..........
</htd:task>
There are two functions connected with rendering:
get rendering type
get rendering
Arbitrary additional data may be attached to a task. This additional
data is referred to as task ad-hoc attachments. An ad-hoc attachment
is specified by its name, its content. The
name
element is used to specify attachment name. Several attachments may
have the same name and can then be retrieved as a collection.
Note
TheaccesType
is assumed to be inline. Thus this proprty MUST contains the string
constant
inline
.
The attachment can be any valid XML. Moreover the attachment data is assumed to be of that type and if it is not, the attachment is set on empty.
The
attachedAt
element indicates when the attachment is added.
The
attachedBy
element indicates who added the attachment. It will be name of user
that invoke the opeartion.
There are four operations to manage attachments:
addAttachment
deleteAttachments
getAttachemntInfos
getAttchments
Example of appriopriate message to create attachment
<soapenv:Header />
<soapenv:Body>
<xsd:addAttachment>
<xsd:identifier>54</xsd:identifier>
<xsd:name>attachment1</xsd:name>
<xsd:accessType>xsd:any</xsd:accessType>
<xsd:attachment><abc><a>test</a></abc></xsd:attachment>
</xsd:addAttachment>
</soapenv:Body>
Properties
attachedBy
and
attachedAt
are set by system.
This operation delete all task attachments that has the same name as specified in request.
Returns attachment information for all attachments associated with the task:
attached name
attached by
attached at
access type
Simple query operations allow to retrieve task data. There are two similary operations and diffirence beetwen then is only in returned data. User can specify a few features that describe Task he is finding:
generic human role
status list
createdOn - it specified date of creating task. I must be use with following operators equals ( "= "), not equals ( "<> "), less than ( "< "), greater than ( "> "), less than or equals ( "<= "), and greater than or equals ( ">= ") see example
where clause - is logically ANDed with the rest condition, it may only reference one Task column with operators as described above.see example
maxTask - If maxTasks is specified, then the number of task abstracts returned for this query will not exceed this limit.
<xsd:genericHumanRole>ACTUALOWNER</xsd:genericHumanRole> <xsd:status>READY</xsd:status> <xsd:status>OBSOLETE</xsd:status> <xsd:createdOnClause><![CDATA[<>02-08-2010 17:16]]></xsd:createdOnClause> <xsd:whereClause><![CDATA[priority<=5]]></xsd:whereClause> <xsd:maxTasks>30</xsd:maxTasks>
Information about tasks or notification should be available in a human-readable way to allow users deadlining with their tasks and notofications via a user inerface. For example, a user queries for his tasks, getting a list of tasks he should work on, displaying a short description of each task. Upon selection of one of the tasks, more complete information about the task is displayed by the user interface.
Definition of presemttiom consist:
name- some kind of task titlepresentation parameters- this element specifies parameters used in two others presentation parameters:subjectanddescription. This attribute is optional and see example for detailssubject- brief task/notification descriptiondescription- long description of the task
Example of the definition od presentation
<htd:presentationElements>
<htd:name xml:lang="en-US"> Approve Claim</htd:name>
<htd:presentationParameters>
<htd:presentationParameter name="firstname" type="xsd:string">
declare namespace cla="http://www.insurance.example.com/claims";
declare namespace htd="http://www.example.org/WS-HT";
xs:string(htd:getInput("ClaimApprovalRequest")/cla:cust/cla:firstname)
</htd:presentationParameter>
<htd:presentationParameter name="lastname" type="xsd:string">
declare namespace cla="http://www.insurance.example.com/claims";
declare namespace htd="http://www.example.org/WS-HT";
xs:string(htd:getInput("ClaimApprovalRequest")/cla:cust/cla:lastname)
</htd:presentationParameter>
<htd:presentationParameter name="euroAmount" type="xsd:double">
declare namespace cla="http://www.insurance.example.com/claims";
declare namespace htd="http://www.example.org/WS-HT";
xs:double(htd:getInput("ClaimApprovalRequest")/cla:amount)
</htd:presentationParameter>
</htd:presentationParameters>
<htd:subject xml:lang="en-US"> Approve the insurance claim for PLN {$euroAmount} on behalf of {$firstname} {$lastname}</htd:subject>
<htd:description xml:lang="en-US" contentType="text/plain"> Approve this claim following corporate guideline #4711.0815/7 for {$firstname} {$lastname}</htd:description>
</htd:presentationElements>
Information about tasks or notification should be available in a human-readable way to allow users deadlining with their tasks and notofications via a user inerface. For example, a user queries for his tasks, getting a list of tasks he should work on, displaying a short description of each task. Upon selection of one of the tasks, more complete information about the task is displayed by the user interface.
Definition of presemttiom consist:
name- some kind of task titlepresentation parameters- this element specifies parameters used in two others presentation parameters:subjectanddescription. This attribute is optional and see example for detailssubject- brief task/notification descriptiondescription- long description of the task
Example of the definition od presentation
<htd:presentationElements>
<htd:name xml:lang="en-US"> Approve Claim</htd:name>
<htd:presentationParameters>
<htd:presentationParameter name="firstname" type="xsd:string">
declare namespace cla="http://www.insurance.example.com/claims";
declare namespace htd="http://www.example.org/WS-HT";
xs:string(htd:getInput("ClaimApprovalRequest")/cla:cust/cla:firstname)
</htd:presentationParameter>
<htd:presentationParameter name="lastname" type="xsd:string">
declare namespace cla="http://www.insurance.example.com/claims";
declare namespace htd="http://www.example.org/WS-HT";
xs:string(htd:getInput("ClaimApprovalRequest")/cla:cust/cla:lastname)
</htd:presentationParameter>
<htd:presentationParameter name="euroAmount" type="xsd:double">
declare namespace cla="http://www.insurance.example.com/claims";
declare namespace htd="http://www.example.org/WS-HT";
xs:double(htd:getInput("ClaimApprovalRequest")/cla:amount)
</htd:presentationParameter>
</htd:presentationParameters>
<htd:subject xml:lang="en-US"> Approve the insurance claim for PLN {$euroAmount} on behalf of {$firstname} {$lastname}</htd:subject>
<htd:description xml:lang="en-US" contentType="text/plain"> Approve this claim following corporate guideline #4711.0815/7 for {$firstname} {$lastname}</htd:description>
</htd:presentationElements>
A number of applications are involved in the life cycle of a task. These comprise:
The task list client, i.e. a client capable of displaying information about the task under consideration
The requesting application, i.e. any partner that has initiated the task
The supporting application, i.e. an application launched by the task list client to support processing of the task.
The task infrastructure provides access to a given task. It is important to understand that what is meant by task list client is the software that presents a UI to one authenticated user, irrespective of whether this UI is rendered by software running on server hardware (such as in a portals environment) or client software (such as a client program running on a users workstation or PC).
This chapter describe all operations that can be use to interaction with task or to manipulate task. If it wass possible, operations related to the same subject were collected in one sections
Operations are executed by end users, i.e. actual or potential owners. The identity of the user is implicitly passed when invoking any of the operations listed in the table below. The participant operations listed below only apply to tasks unless explicitly noted otherwise. The authorization entity indicates people of which roles are authorized to perform the operation. Stakeholders of the task are not mentioned explicitly. They have the same authorization rights as business administrators.
Table 7.1. Participant operations
| Operation name | Desription | Parameters | Authorization |
|---|---|---|---|
|
| Add attachment to a task. |
In
| Actual Owner, Business Administrator |
| getAttachmentInfos details | Get attachemnt information for all attachments associated with the task |
In
| Potetnial Owners, Actual Owner, Business Administrator |
| getAttachments details | Get all attachments of a task with given name |
In
| Potetnial Owners, Actual Owner, Business Administrator |
| deleteAttachments details | Delete attachments with the specified name from the task(if multiple attachemnets with that name exist , all are deleted) |
In
| Potetnial Owners, Actual Owner, Business Administrator |
| addComment details | Add comment to a task |
In
| Potetnial Owners, Actual Owner, Business Administrator |
| getComments details | Get all comments of a task |
In
| Potetnial Owners, Actual Owner, Business Administrator |
| geRendering details | Returns the rendering specified by the type parameter. |
In
| any |
| getRenderingTypes details | Returns the rendering types available for the task. |
In
| name |
| claim | Claim responsibility for a task, i.e. set the task to status Reserved |
In
| Potetnial Owners, Actual Owner, Business Administrator |
| start | Start the execution of the task, i.e. set the task to status InProgress. |
In
| Actual Owner, Potential Owners(only i state Ready) |
| stop | Cancel/stop the processing of the task. The task returns to the Reserved state. |
In
| Actual Owner, Business Administrators |
| release | Release the task, i.e. set the task back to status Ready. |
In
| Actual Owner, Business Administrators |
| suspend | Suspend the task |
in
| Potential Owners(only in state Ready), Actual Owner, Business Administrator |
| suspendUntil | Suspend the task for a given period of time or until a fixed point in time. The caller has to specify either a period of time or a fixed point in time |
in
| Potential Owners(only in state Ready), Actual Owner, Business Administrator |
| resume | Resume a suspended task. |
in
| Potential Owners(only in state Ready), Actual Owner, Business Administrator |
| complete | Execution of the task finished successfully. |
in
| Actual Owner |
| remove | Applies to notification only. Used by notification recipients to remove the notification permanently from their task list client. It will not be returned on any subsequent retrieval operation invoked by the same user |
in
| Notification Recipient |
| fail | ActualOwner completes the execution of the task raising a fault. |
in
| Actual Owner |
| set Priority | Change the priority of the task. The caller has to specify the integer value of the new priority |
in
| Actual Owner, Business Administrator |
| skip | Skip the task. Enable only if task is skipable |
in
| Actual Owner, Business Administrator,Task initiator |
| forward | Forward active task to another person or a set of people |
in
| Actual Owner, Business Administrator, Potential Owners(only in READY state) |
| delegate | Assign the task to one user and set the task to state Reserved. If the recipient was not a potential owner then this person is added to the set of potential owners. |
in
| Actual Owner, Business Administrator |
| getTaskInfo | Applies to both tasks and notifications. Returns info about the task. |
in
| Any |
| getTaskDescription | Applies to both tasks and notifications. Returns the presentation description in the specified mime type. |
in
| any |
| setOutput | Set the data for the part of the task's output message. |
in
| Actual Owner |
| deleteOutput | Deletes the output data of the task. |
in
| Actual Owner |
| setFault | Set the fault data of the task. |
in
| Actual Owner |
| delete Fault | Deletes the fault name and fault data of the task. |
in
| Actual Owner |
| getInput | Get the data for the part of the task's input message. |
in
| Potentail Owners, Actual owner, Business Administrator |
| getOutput | Get the data for the part of the task's output message.e |
in
| Business Administrator, Actual Owner |
| getFault | Get fault data of the task |
in
| sd |
Collection of operations that can be performed only by business administrators. These operations support task management.
Table 7.2. Administrative Operations
| Operation name | Desription | Parameters | Authorization |
|---|---|---|---|
activate | Activates the task. Lets move from state CREATE to READY or RESERVED. Type of transition depends on the number of Potential owners. If there is only one then is set state RESERVED and the Potential owners becomes Actual owner. |
In
| Business Administrator |
| nominate | Nominate organization entity to process the task. When one person is nominated then task status changes to RESERVE and the person becomes Actual Owner. if nominated more persons or group of people then task status changes to REDY. Each nominated organization entity should be added to Potential owners. This operation can be performed when the task is in the state CREATED |
In
| Business Administrator |
| setGenericHumanRole | Sets the organization entity on exactly one Generic Human Role. All other membership to some Generic Human Role are removed |
In
| Business Administrator |
Simple query operations allow to retrieve task data. To see deatails go to filtering
Table 7.3. Simple Query operations
| Operation name | Desription | Parameters | Authorization |
|---|---|---|---|
| getMyTaskAbtracts | Retrieve the task abstracts. This operation is used to obtain the data required to display a task list. |
In
| any |
| getMyTasks | Retrieve the task abstracts. This operation is used to obtain the data required to display a task list. |
In
| any |
Table of Contents
Notification are used to notify a person or a group of people of diffrent business event or actions on the tasks. Inter alia are used in escalation action to notify a user that a task is overdue or a task has not been started yet.
Notifications are simple human interactions that do not block the progress of the caller, that is the caller does not wait for the notification to be completed. The notification appears on the task list of all notification recipients. Notifications may have multiple recipients and business administators. The generic human roles task initiator, task stakeholders, potential owners, actual owner and excluded owners play no role. Notifications do not have ad-hoc attachments, comments or deadlines.
Definition of notifications
<htd:notification name="NCName">
<htd:interface portType="QName" operation="NCName"/>
<htd:priority expressionLanguage="anyURI">
integer-expression
</htd:priority>
<htd:peopleAssignments>
<htd:recipients>
...
</htd:recipients>
<htd:businessAdministrators>
...
</htd:businessAdministrators>
</htd:peopleAssignments>
<htd:presentationElements>
...
</htd:presentationElements>
<htd:renderings>
...
</htd:renderings>
</htd:notification>
Notification properties are a subset of task properties and task features. Functionality of these elements is identical to their counterparts defined for the task. If you want to know their definitions read in chapter Task properties and Task features.
The following attributes and elements are defined for notifications:
Table of Contents
This is response for request getTaskInfo
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getTaskInfoResponse xmlns="http://www.example.org/WS-HT/api/xsd" xmlns:ns2="http://www.example.org/WS-HT" xmlns:ns3="http://www.example.org/WS-HT/api">
<task>
<ns3:id>3477</ns3:id>
<ns3:taskType>TASK</ns3:taskType>
<ns3:name xmlns:ns4="http://www.insurance.example.com/claims">ns4:Task1</ns3:name>
<ns3:status>IN_PROGRESS</ns3:status>
<ns3:priority>0</ns3:priority>
<ns3:taskStakeholders>
<ns2:users>
<ns2:user>user3</ns2:user>
</ns2:users>
</ns3:taskStakeholders>
<ns3:potentialOwners>
<ns2:users>
<ns2:user>user1</ns2:user>
</ns2:users>
</ns3:potentialOwners>
<ns3:businessAdministrators>
<ns2:users>
<ns2:user>user1</ns2:user>
<ns2:user>user2</ns2:user>
</ns2:users>
</ns3:businessAdministrators>
<ns3:actualOwner>user1</ns3:actualOwner>
<ns3:createdOn>2010-08-05T16:15:09.253+02:00</ns3:createdOn>
<ns3:createdBy>soapui</ns3:createdBy>
<ns3:activationTime>2010-08-05T16:15:09.253+02:00</ns3:activationTime>
<ns3:isSkipable>true</ns3:isSkipable>
<ns3:presentationName>Approve Claim</ns3:presentationName>
<ns3:presentationSubject>Approve the insurance claim for PLN 1234 on behalf of EdmundZorn</ns3:presentationSubject>
<ns3:renderingMethodExists>false</ns3:renderingMethodExists>
</task>
</getTaskInfoResponse>
</soap:Body>
</soap:Envelope>