'Business Process Management with JBoss jBPM'

It's all very well having a beautiful process definition, but this is "business process management", not "business process definition". Having a process definition that accurately reflects the way the business works is only half the story. In this chapter, we'll add the majority of the remaining half. The final icing on the cake will be added in the last few chapters.

In this chapter, we are going to build the end user part of our BPM system. We will put together the user interface, which our proof-of-concept testers will use to interact with the process definition that we created in the previous chapter. By the end of the chapter, we will have obtained sign-off from our sponsors and the proof-of-concept testers indicating that they are happy that this user interface is ready to test. In the next chapter, we'll run our testing to prove that our BPM concept system will indeed meet Bland Records' requirements and should be further developed.

In this chapter, we will look at the following:
• Building web forms for the tasks we defined
• Setting up our proof-of-concept users in the system
• Deploying the process
• The default jBPM web console interface
• Adding some help text to the web console interface
• Obtaining sign-off that the web console is ready to run the proof of concept

Build the prototype

With the process engine of our BPM system now in place, it's time to turn our attention to the user interface that our users will interact with, as they execute the process. We will make this available over the internet as a series of web screens that the user can use like a regular website: the jBPM project refers to this as the "web console". For the time being, we will build the web console on our local machine, where we'll be able to play around with it until we are happy.In the next chapter, we'll see how we can deploy it on a server, so our proof-of-concept users can test the system properly.
The web console is a combination of task lists, which represent the queue of work that a user or a group of users has to do, and task forms, which are the screens where the user can actually complete the tasks that have been assigned to them. As we'll see later in the chapter, the jBPM web console also comes with some other handy utilities out of the box, although most of these are more useful for management and administrators than end users.

Develop the prototype user interface
The first step is to build what jBPM terms the "task forms". These are the screens where the user will do the work assigned to them, making an update to a process variable or confirming they have done a piece of offline work, for example:

We need to generate one of these task forms for every task node in our process. This is quite a simple thing to do but, as there isn't a "generate all task forms" button, it is rather time consuming. Still, it does give us the opportunity to ensure each task form is correctly put together. The task forms use XHTML JavaServer Faces tags. JavaServer Faces (JSF) is a Java-based web application framework that simplifies the development of user interfaces for Java applications. For those who know some HTML, the syntax for the Faces tags is not a million miles away. For our purposes, we won't need to worry too much about the Faces elements, as we will limit our interaction with them to a few simple amendments and additions. Nevertheless, for those who are interested, there is a good tutorial on JavaServer Faces here: http://www.exadel.com/tutorial/jsf/jsftutorial-kickstart.html
Anyway, on with our work. Start up the process Designer if you haven't already got it open. Highlight the first task node in the process diagram, which is of course our start node, "Hold auditions". In the Outline view, expand the tree until you find the "Hold auditions" task (note you need the task element within the node, not the node itself). Right-click and select Properties. In the left-hand menu, navigate to the Advanced screen. On here, you will see a Generate Form... button; click it:

Once you've clicked to create the task form, the Designer will ask you to confirm the variables that you've already defined in the process definition and which should be collected on this task form. In our case, these are audDate and audLocation for the "Hold auditions" task node:

As mentioned in the previous chapter, it will be the mapped names of "Audition date" and "Audition location" that will actually be used in the web console, making for a more user-friendly experience.
You will notice at the bottom of this dialog window that the Designer
automatically gives the task form file a name of task node name.xhtml, with .xhtml being the filename extension used for XHTML JavaServer Faces files. We should leave these settings as they are: the only time we'd need to change the filename is if we have two nodes called the same thing. Click OK, then OK again, to close the task node properties window and you will see in the Package Explorer window that the new task form file has been added to our project, along with an XML file called forms.xml:

Double-click the Hold-auditions.xhtml file, so we can have a look at what's been created for us. Something like the following code should open up in the main editor window:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
<!-- the DOCTYPE means we are required to use html for a root element -->
<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:c="http://java.sun.com/jstl/core"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:tf="http://jbpm.org/jsf/tf"
    xmlns:jbpm="http://jbpm.org/jsf">
          <ui:component>
                <jbpm:dataform>
<f:facet name="header">
        <h:outputText value="#{taskName}"/>
</f:facet>
<!-- TASKFORM ROWS -->
<jbpm:datacell>
<f:facet name="header">
      <h:outputText value="Audition date"/>
</f:facet>
<h:inputText value="#{var['audDate']}" />
</jbpm:datacell>
<jbpm:datacell>
<f:facet name="header">
       <h:outputText value="Audition location"/>
</f:facet>
         <h:inputText value="#{var['audLocation']}" />
</jbpm:datacell>
<jbpm:datacell>
<f:facet name="header">
        <h:outputText value="Actions"/>
</f:facet>
<!-- TASKFORM BUTTONS -->
<tf:saveButton value="Save"/>
    <tf:cancelButton value="Cancel"/>
       <tf:transitionButton value="Save and Close"/>
       </jbpm:datacell>
   </jbpm:dataform>
 </ui:component>
</html>

As you can see, this code really isn't massively different from HTML: it is certainly pretty understandable to the uninitiated. Still, we don't actually have to worry about its content in any respect: we can quite happily leave it completely alone. Nevertheless, a bit later in this chapter, we will make a couple of edits to it, just to tailor it to our needs somewhat. While we're here, we may as well have a quick look at the forms.xml file: double-click it to inspect it in the main editor window. The content in the Source view will be something like this:

<?xml version="1.0" encoding="UTF-8"?>
<forms>
<form task="Hold auditions" form="Hold-auditions.xhtml"/>
</forms>

As you can see, this file is extremely simple and all it does is list out all the task forms that will be needed by the web console to execute the process definition. We will not need to edit this file at all.

Now comes the laborious bit: we must go into every task node that we have defined and repeat the above task form creation process. There should be no need to change any of the variables or file names, just accept the defaults that the Designer gives you. Obviously, you don't create any task forms for fork or join nodes, only for task nodes. When we've finished, we should have a long list of XHTML task form files in our Package Explorer:

If you look at the XHTML code for a node where we have specified a name for a transition from the node, there will be a task form button tag included that will be called the same name as the transition. For example, in our Contract-supportingmusicians. xhtml task form, we have the following buttons specified:

<!-- TASKFORM BUTTONS -->
<tf:saveButton value="Save"/>
<tf:cancelButton value="Cancel"/>
<tf:transitionButton transition="Done" value="Done"/>

The transitionButton is given a value of "Done", the same name as the transition we specified, and will result in a button labeled "Done" showing up in the web console for our users to click. So even though the user won't actually input any process variables on this screen, they will move the process on by clicking the appropriately-labeled "Done" button to confirm they have done the task offline and the process can resume. Of course, this gets even more useful where we have specified two transitions and the task form will therefore include two buttons for the user to choose from. For example, the user will be able to choose between an "Incorrect" and a "Correct" button on the "Review credits and cover artwork" task form, because the Designer has automatically recognized that there are two leaving transitions and created the necessary buttons with the following code:

<!-- TASKFORM BUTTONS -->
<tf:saveButton value="Save"/>
<tf:cancelButton value="Cancel"/>
<tf:transitionButton transition="Incorrect" value="Incorrect"/>
<tf:transitionButton transition="Correct" value="Correct"/>

This is very clever stuff and goes to prove just how much jBPM is doing for us without us having to get our hands dirty with code.