Investigating the web console interface

The jBPM web console is where our users will do their tasks, monitor the process, and administer the running of the live process. The web console is developed and maintained by the jBPM project team as an example of a web front-end to the jBPM process engine. The intention is that the example web console can serve as the starting point for jBPM users' own implementations of jBPM: it can be developed and tailored to our exact needs. Of course, if you do make improvements and develop the code base, you should submit your changes back to the jBPM community to help make the project even better.
At the time of writing, the web console is under very active development for the
3.2 release of jBPM, and hence the version that you actually end up using may well differ slightly from that presented in these pages. No matter, the concepts will remain the same and it will only be aesthetic differences, if there are any.
Let's have a look at the web console. With the application server running, fire up
your browser and go to http://localhost:8080/jbpm-console/ where you will
be presented with the console login page:

In the middle of the screen, there is a hard-coded table featuring the usernames that are used with the default jBPM example process. We can ignore these and use one of our own logins that we put into the database, previously. Log in with the username and password of "powellb" and "powellb", to log in as our Talent scout. Once we're logged in, we can see the various portions of the web console that we can interact with, some of which are targeted at end users, some at managers, and some at administrators:

Of course, in a live environment we'd probably want to change this a bit so that end users don't get to see the managerial or administration sections, but we won't worry about that for now. Let's explore the various parts of the console. To make our exploration meaningful, let's create an instance of our process. Click Processes, then Start process next to the latest version of the "Produce music products" process:

This starts a new instance of the process and takes us to the first task form. If you now click Process Instances, you will see a list of all instances of the process that are currently in course on this server. If you click View you can see all the details of that process instance:

From here, we can inspect the process definition diagram and code, as well as see some history of what has happened to this instance of the process while it has been running.

End users

End users will naturally be the heaviest users of the process's user interface, and there are two elements of the web console, in particular, that are expressly designed for them: tasks lists and task forms. The ordinary user should live and breathe in their task list as it represents the queue of work that they have to complete to fulfil their part of the process.
The web console actually contains two task lists, one for the user, but also one for the group. The user's task list presents a list of all the tasks that are currently assigned to the user that is logged in. For example, if we click User Task List in the menu we can see that we currently have one task assigned to us:

This makes sense as we are currently logged in as a Talent scout, and we have just started an instance of the process where the first task node, "Hold auditions", is assigned to the Talent scout swimlane. If you were to log out and log in as a different user, you would see that their task list is currently empty, as they haven't had anything assigned to them yet.
You will also notice as you play around with the web console that tasks exist in either the user task list or the group task list, but not both. This is to make sure that you don't get multiple users working on the same group task: the idea is that the user "takes" a task off the group stack and adds it to their own to work on it. The group task list is intended for situations where you have a pool of users, any one of whom could take the task, removing it from the group task list and bringing it into their personal user task list.

If we go back to the user task list, and click View, next to the task we have assigned to us in our list, we are presented with the screens we need to be able to complete this task. This is the task form we generated previously, and we can now see how those XHTML elements are rendered in our browser:

We can see that the web console has indeed picked up the "mapped names" of our process variables, using "Audition date" and "Audition location" as the labels in the input form. We can also see that the task form has three action buttons that the user can click: Save, Cancel, and Save and Close. The Save and Cancel buttons will be present on every task form page, although we will find that later in the process the Save and Close button will be called different things. This is because this button is the transitionButton element we saw earlier that will pick up the transition name, if one is specified. If there isn't a name specified for the transition, the button is simply labeled End Task by default. The Save button allows the user to fill out the task form and save its contents without submitting it and moving to the next node of the process. This is particularly useful in more complex forms where the user may not know exactly what they need to enter straight off. Similarly, the Cancel button allows the user to discard any input that they have made and go back to their task list without moving on in the process.

One of the best features of the web console, one which really highlights the benefits of business process management, is shown in the Diagram tab of the task form:

As you can see, this screen shows the user how their current task fits into the context of the process as a whole, by highlighting the current node in the process diagram. This is incredibly powerful from an end user's point of view as they can easily see how they are one cog in a bigger machine, and how the quality and timeliness of their work affects the work of others.
If we go back to the task form, enter some example data into the form and click End Task, the process variables we have entered are saved to the jBPM database, the task
is marked as completed and the process execution moves on to the next node in the process definition. As the next task node is also assigned to our Talent scout, we can go back into the task list and pick up the next task:

Managers

The managerial part of the web console is probably the least developed part of the system at the moment. It is anticipated that managers will be able to use the web console to deploy new processes, monitor operation of the process, correct end users' process variable mistakes, cancel processes if need be, and monitor process timers. However, this functionality hasn't been fully developed at the time of writing: perhaps it will have been by the time you come to read this book. Nevertheless, never fear, as some of this functionality overlaps with the Business Activity Monitoring functionality that we will build in a later chapter.

If you log out of the web console and log back in with the username "manager" and password "manager", you can see that there is one more menu option available to our managers, "Deploy process":

This is actually an alternative way for us to deploy our processes, rather than using the deployment functionality in the Designer. Personally, I find it easier to use the Designer's deployer, but you might want to experiment with this one.

Of course, managers can also go into any of the task forms through the Process instances menu and use the re-assignment functionality to re-distribute the workload around their team:

Adapt the web console

The web console functions perfectly well as it is, although there are obviously a few things we'd like to do to make it our own. In later chapters, we'll make some further adaptations to the web console, but for now we'll content ourselves with adding some "help" text to the task form pages to give our proof-of-concept testers a few pointers as to how they should use the system. We are simply going to include a bit of text on each task form telling the users what is expected of them. We can do this with some very straightforward HTML. Go back into the Designer and double-click the hold-auditions.<br /><br /> Add in the date and location of the next audition. Please enter the date in the format DD-MM-YYYY.xhtml task form in the Package Explorer. Scroll down to the end of the code and add the following lines of HTML and text on a new line between the dataform and uicomponentclosing tags:

<br /><br /> When you've finished click Save to save your changes for later, or click End Task to submit and move on. You can click Cancel if you don't want to save your changes and are not ready to submit.
<br /><br /> Hopefully, this code isn't too earth shattering for you. If we now re-deploy the process definition to the server, start a new instance of this latest version of the process and have a look at the Hold auditions task form, we can see that our help text shows up on the screen to help our users understand what they need to do:

You can do this for every task form where you believe it would be worthwhile to give the end user a bit of a helping hand. Remember, however, that if for some reason you have to re-generate the task form your help text will be lost.

Sign off for the proof of concept

All that remains now is to demonstrate the proof-of-concept web console to the sponsor and the proof-of-concept testers, and to ask them to sign it off as ready for testing. At this stage, it is very worthwhile setting some expectations and making it clear to these people that they are not signing off the system as being production-ready, merely that the bare functionality is in place to have a meaningful proof-of-concept test.We also need to ask our proof-of-concept users to start gathering together the data they will need to put the system through its paces. They should look at historical records of the process to pull together this information: although, sometimes there will be no option but to fake it as the data may not have been recorded. As long as the data is sensible and realistic, there is no problem with this approach. The important thing is that the process definition and the user interface can be tested under semi-realistic conditions by the testers going through the process in "fast forward" with pre-determined data.

Summary :
In this chapter, we have built the user interface that our proof-of-concept testers will use to interact with the process definition, which we built in the previous chapter. At this stage, we are not worrying about making the web console look pretty or in adapting it for our specific requirements: we are just going to make do with what is available out of the box. After all, the basic functionality of the jBPM web console is actually quite advanced and really provides more than enough for us to get started. In later chapters, we'll tinker here and there with it and we'll work at making the system more production-ready. But for now, we have our proof-of-concept system ready to go, and in the next chapter we'll see if we can indeed prove that concept. We have covered:
• Building task forms
• Setting up users and groups
• Deploying the process
• The elements of the user interface
• Adding help text to the task forms
• Obtaining sign-off that the UI is ready to run the proof of concept
Our final deliverable from this phase has been the web console that has been signed off as fit for the purposes of running our proof of concept test.

Your Name / Email Address
Comment
Spam Protection - Please enter the code in the image -

Listen to code