BPEL: scripting and human tasks

In the last column in this series, we looked at the general concept of business process management with respect to SOA (Service Oriented Architecture) based systems. In particular, we reviewed BPEL (the Business Process Execution Language) and what it offers and at some of the extensions for BPEL.

In this second column, we’ll look in more detail at BPEL itself; and at what BPEL looks like. We will then explore the BPEL4People extension to BPEL. In the third column in this series we will look at the BPELJ extension and conclude by examining Compensation (which is a little like an undo facility for BPEL).

BPEL

In the last column, we said that BPEL was an aimed at programming in the large. That is, it is aimed at very high-level process orchestration/control rather than at low-level function implementation. Thus, it differs from a language such as Java (a language oriented towards programming in the small) in that it does not try to be a general-purpose language in which it is possible to write a variety of software solutions. Instead it focuses on one type of software solution, that of co-ordination of services.

This effectively means that rather than being a large language such as PL/I or a language that allows additional libraries to be added (such as the Java language), BPEL is a relatively small, fixed language oriented around the invocation of services, and the flow of control between services. BPEL’s features therefore fit around this: the creation of flows; sequences; while operations; if-then-else constructs; loops; variables; the ability to receive requests; send responses (to the invoker of the process); invoke services; and assign values to variables. It also supports both synchronous and asynchronous interactions.

From the above list of facilities supported by BPEL you might think, “yes this looks like a small programming language” and, in essence, you’d be correct. However, two features mark BPEL out as being somewhat different to most other programming languages, the first is that it is essentially web-services-based (in all its operations) and the second is that is a purely XML-based language. Whilst the first is an implementation choice for writing BPEL scripts, the second is a bigger issue for me.

To expand on this for a moment, I do not find that XML is the ideal structure within which to write software (hey, C, C++, Java, Pascal are all examples of well established and successful ways of providing suitable programming languages and none of these look like XML). As an example, the following illustrates how a value is assigned to a variable within BPEL:

<bpel:copy>
<bpel:from>
     <bpel:literal>yes</bpel:literal>
  </bpel:from>
  <bpel:to part="accept" variable="approval"/>
</bpel:copy>

The equivalent of doing this in a language such as Java might be:

approval.accept = “yes”;

Which do you find the more intuitive and easier to read? I know which one gets my vote!

BPEL GUI Tools

Given the discussion in the previous section, what does a BPEL program look like? Well, structurally, it looks much like any other program you might have encountered. It contains:

• imports for elements outside of the script
• variable declarations
• error handlers
• a logic definitions section (the body or in BPEL terms the flow) containing:
  • invocations of services
  • flow of control statements
  • variable assignments

And, yes, if you try to read a BPEL script it can become difficult due to the nature of XML and BPEL. However, most people will define a BPEL script using a graphical BPEL editor. Examples of such tools (there are numerous ones available) include the WebSphere Integration Developer, the ActiveBPEL Designer and the embryonic Eclipse BPEL Designer project. The screen dump in Figure 1 is taken from the ActiveBPEL Designer tool and illustrates the BPEL script for the common loan approval example:

Figure 1 describes a BPEL flow that could be defined as:

“If the loan is for less then 10,000 the loan assessor can determine if it is low risk or not. If it is low risk then it will be approved. If the loan is for more then 10,000 or the assessor considers it high risk then the loan is passed to the loan approver for assessment. If they consider the loan to be low risk it is accepted.”

Note that a 30 day evaluation license for ActiveBPEL Designer can be obtained form its supplier, Active Endpoints, here.

The equivalent Java for the logic presented in Figure 1might be:

public class Processor {
    public String assessLoanRequest(Request request) {
        Approval approval = new Approval();
        Risk risk = new Risk(); 
        if (request.amount < 10000) {
            risk.level = loanAssessor(request);
            if (risk.level == “low”) {
                approval.accept=”yes”;
                return approval; 
             }
        } 
        // Otherwise – unless we have returned
        risk.level = loanApprover(request);
        if (risk.level == “low”) {
            approval.accept=”yes”;
            return approval; 
        }
    }
}

Although this is not particularly elegant Java (I have tried to keep it in line with the BPEL graph) it illustrates the idea.

We can dissect parts of the BPEL script created by the tool in figure 1 to see what it looks like. First off, the BPEL script imports the WSDL definitions that will be used for the data types exchanged between the services as well as for the services themselves. Next, the partners links used to define the services with which the BPEL script will interact are defined. The following snippet illustrates how the partner link for the loan assessor might be defined. It is defined here so that it can be referred to later on in the script.

<bpel:partnerLinks>
   <bpel:partnerLink name="assessor" partnerLinkType="lns:riskAssessmentLT" partnerRole="assessor"/>
</bpel:partnerLinks>

Next come the variable declarations. These are exactly what they claim to be: variables that can be used through out the remainder of the BPEL script. The following code snippet defines three variables request, approval and risk.

<bpel:variables>
   <bpel:variable messageType="lns:creditInformationMessage" name="request"/>
   <bpel:variable messageType="lns:approvalMessage" name="approval"/>
   <bpel:variable messageType="lns:riskAssessmentMessage" name="risk"/>
   </bpel:variables>

Their types are defined by the message type; and relate to data types defined externally to the BPEL script.

The main body of the BPEL script is defined between two flow elements (<bpel:flow> and </bpel:flow>). Within this section, we define the invocations of the services, the receipt of the original request and the generation of a response back to the client of the script. As an example, consider the following code snippet:

<bpel:invoke inputVariable="request" name="InvokeLoanApprover" 
operation="approve" outputVariable="approval" partnerLink="approver" 
portType="lns:loanApprovalPT">
   <bpel:targets>
      <bpel:target linkName="receive-to-approve"/>
      <bpel:target linkName="assess-to-approve"/>
   </bpel:targets>
   <bpel:sources>
      <bpel:source linkName="L2">
         <bpel:transitionCondition>
             $risk.level="low"
         </bpel:transitionCondition>
       </bpel:source>
      <bpel:source linkName="L3">
         <bpel:transitionCondition>
              $risk.level!="low"
         </bpel:transitionCondition>
       </bpel:source>
    </bpel:sources>
</bpel:invoke>

This code snippet essentially says execute the approver service (defined earlier via the partner link). The parameter passed into this is the request and the result is stored in the approval variable. There are two ways to get to this point, one is via the receive-to-approve link and one is via the assess-to-approve link. In terms of flow-of-control, the result of the service being called depends on the value of the level part of the risk object. If it is “low” then link L2 is followed; and if the value is not “low” then link L3 is followed.

Which takes us to the last part of the BPEL script we will look at here, links. The following code snippet shows some of the links for this BPEL script:

<bpel:links>
   <bpel:link name="receive-to-assess"/>
   <bpel:link name="assess-to-approve"/>
   <bpel:link name="L2"/>
   <bpel:link name="L3"/>
    …
</bpel:links>

These links will be used later in the script, to define the flow between the services.

BPEL4People

One of the things you may have noted from the above example is that there appear to be two ways in which the loan can get approved, one is by the LoanAssessor and the other is via the LoanApprover. At this point you might well as “Why are there two services doing the same thing?”

The answer is that my aim in this example is to suggest that any loan below 10,000 might be assessed for risk automatically. Thus, if this loan assessor service indicates that the loan is of a low risk; then the loan is approved automatically. However, if the loan is for more than 10,000, or is considered a medium to high risk, then a human assessor should assess the loan.

However, is that what the above example illustrates? Not really; as in this example it appears that both the loan assessor and the loan approver are in fact software services. This is not a new issue, as most business processes incorporate some element of human involvement. Indeed, in the WebSphere BPEL toolset IBM has introduced the concept of a Human Task to represent the type of work that a human might do within a business process. However, this is a proprietary approach and is not in keeping with BPEL in general, so the BPEL4People standard has emerged.

This standard was originally proposed by IBM and SAP; and is intended to allow the integration of “people processes” with BPEL. The aim is to standardize the representation of the activities that people carry out within a business process. This will allow these processes to be represented explicitly as part of the definition of the overall business process. Thus, business flows can be dependent on actions performed by humans and on information provided by human tasks. However, it should be noted that the original BPEL4People white paper is exactly that - it is a proposal and not a specification. It thus provides a description of a workflow model for human tasks and what a BPEL4People implementation will need to provide. It does not provide a detailed description of how BPEL4People should look (although this is currently in development – see the document here, which was published only in June 2007).

Both the white paper and the embryonic specification describe the ways in which people interact and are involved in more complex business processes. This may involve escalation, with the same task performed by multiple people (for validation purposes) etc. Much of the BPEL4People extension relies on the introduction of a new activity type, the proposed People activity type. The activity is implemented by a task performed by a human and the interface to this new task type is specified in the BPEL script - but would (probably) not have a full WSDL specification.

At run time, the activity sends data to the task input and receives data from the task output. The following example is taken from the BPEL4People specification and illustrates how a human task for electing an employee of the month, might be represented:

<extensionActivity>
    <b4p:peopleActivity name="electEmployeeOfTheMonth"
inputVariable="candidates" outputVariable="vote">
<htd:task name="votingTask">
<htd:interface operation="vote"
portType="el:votingPT"/>
<htd:peopleAssignments>
<htd:potentialOwners>
<htd:from>$voters/users/user[i]</htd:from>
</htd:potentialOwners>
</htd:peopleAssignments>
<htd:presentationElements/>
</htd:task>
…
    </b4p:peopleActivity>
</extensionActivity>

The BPEL4People peopleActivity has a name, and specifies any inputs and outputs form the task. The task itself is called votingTask and specifies what the interfaceof the task is. How the task is implemented is beyond the scope of BPEL – it could be a web page is activated or it could be that a message is sent via email to all those eligible to vote etc. The list of voters is defined by the information obtained from the from element.

BPEL and BPEL4People?

So what does this give us over just representing long running, asynchronous activities with standard BPEL? Well primarily, it makes human processes first class entities within the BPEL script. The benefit of this is that BPEL4People explicitly represents Human Tasks making the role of the human in the process more obvious.

However, against this is the fact that at its core, BPEL is a Service Orchestration/Co-ordination language. It is not a work order management system; it is not a task management system; it is not even a workflow system per se. So, does the introduction of BPEL4People really achieve very much?

I suspect that answer here is, “not a great deal”; with the notable exception of allowing business modellers to think explicitly about the role humans and the tasks performed by humans and thus the role such tasks play within the overall orchestration process.

Resources

BPEL Specifications.

BPEL4People White Paper.

WS-BPEL Extension for People.

BPEL Source Links.

Eclipse BPEL Project.

ActiveBPEL Designer.

WebSphere Integration Developer.