9 min read

Introduction

BPEL4People has been developed to provide extensive support for human interactions in BPEL processes and to standardize the human interactions. Originally, the BPEL4People specification was defined by IBM and SAP. Other companies, such as Oracle, Active Endpoints, and Adobe have also joined. Today, this specification has being advanced within the OASIS BPEL4People Technical Committee. The BPEL4People specification contains two parts:

  • BPEL4People version 1.0, which introduces BPEL extensions to address human interactions in BPEL
  • Web Services Human Task (WS-HumanTask) version 1.0 introduces the definition of human tasks

BPEL4People is defined in a way that it is layered on top of the BPEL language. We will now have a brief look at the WS-HumanTask and then at the BPEL4People.

Brief look at WS-HumanTask

The WS-HumanTask specification introduces Human Tasks to BPEL. Human Tasks are services, implemented by humans. 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. This is very similar to human tasks in WebSphere, with two main differences—WS-HumanTask standardizes tasks among different vendors, and WS-HumanTask introduces new activities for specifying the properties of human tasks. In WebSphere, we had to use the Integration Developer GUI instead.

WS-HumanTask makes a distinction between Human Tasks and notifications. Notifications are a special type of Human Task that allows the sending of information about noteworthy business events to users. Notifications are always delivered one-way. There is no response from notifications expected.

Overall structure

The overall structure of the human interactions definition is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<htd:humanInteractions
  
  
  
  targetNamespace="anyURI"
  expressionLanguage="anyURI"?
  queryLanguage="anyURI"?>
 <htd:extensions>?
   <htd:extension namespace="anyURI" mustUnderstand="yes|no"/>+
 </htd:extensions>
 <htd:import namespace="anyURI"?
   location="anyURI"?
   importType="anyURI" />*
 <htd:logicalPeopleGroups>?
   <htd:logicalPeopleGroup name="NCName" reference="QName"?>+
       <htd:parameter name="NCName" type="QName" />*
 </htd:logicalPeopleGroup>
</htd:logicalPeopleGroups>

<htd:tasks>?
    <htd:task name="NCName">+
       ...
   </htd:task>
 </htd:tasks>

<htd:notifications>?
  <htd:notification name="NCName">+
     ...
  </htd:notification>
 </htd:notifications>
</htd:humanInteractions>

Human Tasks

The most important is the definition of the Human Task. The definition includes the following:

  • Interface
  • Priority
  • People assignments
  • Delegation
  • Presentation elements
  • Outcome
  • Search priorities
  • Renderings
  • Deadlines (start and competition deadlines)

The WS-HumanTask specification foresees the following syntax to define a human task:

<htd:task name="NCName">
  <htd:interface portType="QName"
    operation="NCName"
    responsePortType="QName"?
    responseOperation="NCName"?/>
  <htd:priority expressionLanguage="anyURI"?>?
    integer-expression
  </htd:priority>
  <htd:peopleAssignments>
     ...
  </htd:peopleAssignments>
  <htd:delegation potentialDelegatees=
    "anybody|nobody|potentialOwners|other"/>?
     <htd:from>?
         ...
     </htd:from>
    </htd:delegation>
    <htd:presentationElements>
       ...
    </htd:presentationElements>
    <htd:outcome part="NCName" queryLanguage="anyURI">?
      queryContent
    </htd:outcome>
    <htd:searchBy expressionLanguage="anyURI"?>?
       expression
    </htd:searchBy>
    <htd:renderings>?
    <htd:rendering type="QName">+
       ...
    </htd:rendering>
    </htd:renderings>
    <htd:deadlines>?
       <htd:startDeadline>*
          ...
    </htd:startDeadline>
    <htd:completionDeadline>*
        ...
    </htd:completionDeadline>
   </htd:deadlines>
 </htd:task>

Escalations

Within the deadlines, escalations can be defined. An example of defining an escalation is shown as follows:

<htd:escalation name="highPrio">
  <htd:condition>
    <![CDATA[
      (htd:getInput("OrderRequest")/amount < 1000
      && htd:getInput("OrderRequest")/prio <= 10) ]]>
    </htd:condition>

    <htd:notification name="ClaimApprovalOverdue">
      <htd:interface portType="tns:ClaimsHandlingPT"
        operation="escalate" />
      <htd:peopleAssignments>
          <htd:recipients>
        <htd:from logicalPeopleGroup="Manager">
          <htd:argument name="region">
             htd:getInput("OrderRequest")/region
          </htd:argument>
         </htd:from>
        </htd:recipients>
       </htd:peopleAssignments> 
       <htd:presentationElements>
           <htd:name>
               Order approval overdue.
           </htd:name>
          </htd:presentationElements>
         </htd:notification>
        </htd:escalation>

In a similar way, a reassignment could be done.

Notifications

Notifications are defined with the following:

  • Interface
  • Priority
  • People assignments
  • Presentation elements
  • Renderings

An example is shown as follows:

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

Programming interface

The WS-HumanTask specification also defines the API for applications that are involved with the life cycle of a human task or a notification. It provides several types of operations, including:

  • Participant operations, such as operation for claiming tasks, starting, stopping, suspending tasks, completing tasks, setting priority, delegating, and so on
  • Simple query operations, such as getMyTasks and getMyTaskAbstracts
  • Advanced query operation, which provides several possibilities for retrieving the tasks
  • Administrative operations for nominating and activating tasks, and setting generic human roles

The specification also defined XPath extension functions to retrieve Human Task properties.

Now that we are familiar with WS-HumanTask, let us have a brief look at the BPEL4People specification.

Brief look at BPEL4People

BPEL4People is a BPEL extension, which adds several activities to the BPEL language. The most important extensions introduced in BPEL4People are people activities and people links. People activities are used to define human interactions. For each people activity, the BPEL server must create work items and distribute them to users eligible to execute them. People activities can have input and output variables and can specify deadlines. This is very similar to what we have seen in the WebSphere support for human tasks.

To specify the implementation of people activities, BPEL4People introduces tasks. Tasks specify actions that users must perform. Tasks can have descriptions, priorities, deadlines, and other properties. Tasks can be represented in-line, or using WS-HumanTask.

To associate people activities and the related tasks with users or groups of users, BPEL4People introduces people links. They associate users with one or more people activities. People links are usually associated with generic human roles, such as process initiator, process stakeholders, owners, and administrators.

Overall structure

The overall structure of BPEL4People extensions is as follows:

<bpel:process ...
  
  >
  ...
  <bpel:extensions>
    <bpel:extension namespace="http://www.example.org/BPEL4People"
      mustUnderstand="yes"/>
    <bpel:extension namespace="http://www.example.org/WS-HT"
      mustUnderstand="yes"/>
   </bpel:extensions>
   <bpel:import importType="http://www.example.org/WS-HT" …/>

   <b4p:humanInteractions>?
     <htd:logicalPeopleGroups>?
         <htd:logicalPeopleGroup name="NCName">+
            ...
        </htd:logicalPeopleGroup>
     </htd:logicalPeopleGroups>
     <htd:tasks>?
        <htd:task name="NCName">+
           ...
        </htd:task>
       </htd:tasks>
       <htd:notifications>?
          <htd:notification name="NCName">+
             ...
          </htd:notification>
        </htd:notifications> 
      </b4p:humanInteractions>
    
    <b4p:peopleAssignments>
       ...
</b4p:peopleAssignments>
    ...
<bpel:extensionActivity>
  <b4p:peopleActivity name="NCName" ...>
     ...
  </b4p:peopleActivity>
 </bpel:extensionActivity>
      ...
</bpel:process>

Let us have a look at the new elements:

  • The element <b4p:humanInteractions><b4p:/humanInteractions> contains declarations of elements from the WS-HumanTask namespace, such as <htd_logicalpeoplegroups></htd_logicalpeoplegroups>, <htd_tasks></htd_tasks>, and <htd_notifications></htd_notifications>. The element <htd_logicalpeoplegroup></htd_logicalpeoplegroup> specifies a logical people group used in an inline human task or a people activity. The <htd_task></htd_task> element is used to provide the definition of an inline human task. The <htd_notification></htd_notification> element is used to provide the definition of an inline notification.
  • The element <b4p_peopleassignments></b4p_peopleassignments> is used to assign people to process-related generic human roles.
  • The new activity <b4p_peopleactivity></b4p_peopleactivity> is used to model human interactions within BPEL processes.

People assignments

BPEL4People defines generic human roles. These roles define what a person or a group of people can do with the process instance. The specification defines three process-related generic human roles:

  • Process initiator: Person that triggered the process instance
  • Process stakeholders: People who can influence the progress of a process instance, for example, by adding ad-hoc attachments, forwarding a task, or simply observing the progress of the process instance
  • Business administrators: People allowed to perform administrative actions on the business process instances

The syntax of people assignments looks like this:

<b4p:peopleAssignments>
  <b4p:processInitiator>?
    <htd:from ...>
       ...
    </htd:from>
  </b4p:processInitiator>
  <b4p:processStakeholders>?
    <htd:from ...>
       ...
    </htd:from>
   </b4p:processStakeholders>
   <b4p:businessAdministrators>?
     <htd:from ...>  
         ...
     </htd:from>
    </b4p:businessAdministrators>
       </b4p:peopleAssignments>

People activities

People activities are used to integrate human interactions within BPEL processes. A people activity can be integrated with an inline Human Task or with a standalone Human Task. An inline task can be defined as part of a people activity. A standalone Human Task is defined separately and can be used several times. To specify Human Tasks, we use the WS-HumanTask specification.

The overall syntax is as follows:

<b4p:peopleActivity name="NCName"
  inputVariable="NCName"?
  outputVariable="NCName"?
  isSkipable="xsd:boolean"?
  standard-attributes>
  standard-elements
    ( <htd:task>...</htd:task>
    | <b4p:localTask>...</b4p:localTask>
    | <b4p:remoteTask>...</b4p:remoteTask>
    | <htd:notification>...</htd:notification>
    | <b4p:localNotification>...</b4p:localNotification>
    | <b4p:remoteNotification>...</b4p:remoteNotification>
    )
  <b4p:scheduledActions>?
     ...
  </b4p:scheduledActions>
  <bpel:toParts>?
    <bpel:toPart part="NCName" fromVariable="BPELVariableName"/>+
  </bpel:toParts>
  <bpel:fromPart part="NCName" toVariable="BPELVariableName"/>+
  <bpel:fromPart>?

  </bpel:fromParts>
  <b4p:attachmentPropagation fromProcess="all|none"
    toProcess="all|newOnly|none"/>?
 </b4p:peopleActivity>

Summary

In this article, we have covered the BPEL4People and WS-HumanTask specifications. These specifications have standardized the approach to BPEL human interactions and made it portable through different SOA process servers. We have overviewed both specifications and have seen that there are no major conceptual differences between the current Oracle support and the approach taken in specifications. At the time of writing, it has not been clear how much support these specifications will get from SOA platform vendors.

Further resources on this subject:

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here