Worklist Overview

This post is the first in a series on building a custom worklist application for BPM/SOA Suite 11g.

In this post, we will introduce the application and outline the basic architecture.

For our ‘version 1.0’ worklist sample, we decided to implement a basic set of functionality including listing and filtering tasks, actioning tasks, adding comments, and integration with WebLogic Server for security.

The purpose of this sample is to give a fully worked example of building a custom worklist application from scratch.

Let’s take a quick tour of the worklist.  Our login screen will look as follows:

Once a user logs in, they will be able to view the task list, as shown below.  Note that they can filter by the assignee and the status.  They can also click on the Task Number link to view details of an individual task.

On the task detail screen, they are able to see the payload and comments, add comments, and action the task.  The example includes both the ‘custom actions’ defined in the Human Task definition, and the ‘system actions’ that are available for all tasks.

Users are also able to view a list of the tasks that they are able to initiate, and can initiate a task, which will display the task form for the user to enter the necessary information.

We wanted to use a common web framework and development environment to create the sample.  We decided on Spring Web MVC, not because we necessarily think it is the best framework, but because we think it is commonly used and well understood.  As it implements the MVC pattern that many common frameworks use, we hope that the example will still be useful even if you prefer to use a different web framework.

Spring Web MVC uses a ‘Dispatcher Servlet’ as its ‘front controller,’ as shown in the diagram below, which is taken from the Spring Framework Reference.  This dispatcher delegates the request to a controller that we provide.  The controller populates the model and then passes it to the view.  The view is responsible for rendering the user interface.

We built the example to run on WebLogic Server.  The build was managed using Maven.

We register each of our controllers in the Spring configuration file, along with the mappings from URLs to the appropriate controller.  This file also contains properties that determine which view to use when the controller was successful or failed.

In our example, all of the URLs are protected, with the exception of the home page.  We have use the WebLogic deployment descriptor to define the security rules.  At no time does our application collect or store credentials.  This is all done by the WebLogic Server security infrastructure on our behalf.  The application is written to support multiple concurrent users and to support deployment into a clustered environment.

Logging has been included in the application so that you can follow through the execution while you are exploring the application.  All logging is done through a central utility class, so that it can be easily removed.  The logging is all printed to the System.out of the WebLogic Server, i.e. on to its console and into its log file.  We found this useful during development because you can essentially watch what is happening in real time.

In the next post in the series, we set up our development environment so that we can start the project.