This article expands on the previous jBPM excerpt to explore some of the advanced capabilities found in jBPM. Since it is just an excerpt, summary-level information is only provided, but it should give you a good flavor of the advanced features the product offers. Unlike the book, detailed code samples, descriptions, and annotations are not provided.

The final chapter on jBPM covers two mains topics: enterprise functionality and integration with Apache Tuscany's Service Component Architecture (SCA) and Service Data Objects (SDO). The enterprise features of jBPM we'll discuss are particularly relevant when building very complex business processes that have enterprise-ready exception handling and logging. The ability to decompose complex business processes into subprocesses is particularly relevant to SOA, as it enables you to construct higher-level composite services that can be reused by multiple processes. The integration with Apache Tuscany (SCA/SDO) discusses an approach for service-enabling jBPM, thus making it a first class citizen in your SOA environment.

Enterprise jBPM Features

The enterprise features of jBPM that are the focus of this section are beneficial when you begin developing complex business processes. In particularly, it is useful to be able to break down, or group, complex processes into more manageable pieces. We will discuss two means of accomplishing this within jBPM: superstates and subprocesses. Later, we will describe solutions for how to manage exceptions that may occur as a result of any custom code you developed as part of the process.

While not an "advanced" feature per se, our focus will turn to describing how you can use in-line code in the form of Beanshell scripts and monitor a given process instance through the extensive logging features that are provided. Lastly, we look into a concept called asynchronous continuations, which enable you to distribute processing to the jBPM server in which jBPM enterprise is running. Let's begin by looking at jBPM superstates.

Superstates

Superstates in jBPM are simply a grouping of nodes. They are useful, for example, when you want to logically associate together a group of nodes. This might be done to delineate phases of a process or to group by organizational responsibilities. For example, an employee termination process is typically cross-departmental, with various responsibilities falling within several organizations.

Figure 1

In one instance, superstates were used to group the nodes between HR, Finance and Security. Within the jBPM Graphical Process Designer (GPD), when you deposit a superstate node into the jBPM working area/canvas, a bordered region is created where you can then add nodes and transitions. As you can see, these border areas can be resized, and will sprout scrollbars where necessary. You can also associate timers to the superstate (this does require the enterprise version of jBPM, in other words, the app server addition). In the scenario shown in Figure 1, you could, for instance, notify a manager of the HR org that their team's work has not been completed in a timely fashion. Thus, using events and timers, there is benefit beyond the obvious achieved by providing visual hierarchy and grouping. Related in concept are subprocesses, which are intended to provide greater process composition flexibility.

Subprocesses

Subprocesses provide a means to create decomposed processes. In other words, you can define a master process which, in turn, calls subprocesses. The subprocess can be considered as though it is simply another node in the process. When the subprocess is complete, execution will continue in the calling process. This ability enables you to create more complex processes without overly complicating the visual layout. Additional benefits include the ability to create reusable process modules that can be incorporated by other process definitions. In chapter 1 we discussed that an important aspect of SOA is the ability to create composite services. Using subprocesses, you can achieve this by creating reusable processes. These can be run stand-alone, or as subprocess to a larger orchestration.

In Figure 1, we illustrated a modestly complex business process used for employee termination. In that case, superstates were used to provide some logical structure to the diagram. Since the security-related nodes were the most involved, let's instead break that out into a separate subprocess.

Figure 2

In Figure 2, the node named security represents the new subprocess (identified within the node icon as <<Process State>>). When this node is encountered, a new process instance for the security process is instantiated.

We have now covered two approaches for helping you organize and/or decompose complex business processes — essential tools for building enterprise orchestrations. Another important aspect of enterprise solutions is effective exception handling.