Exception Handling

Exception handling within jBPM is a bit different than what one might imagine. When managing exceptions within jBPM, you are only dealing with those that result from any handler classes that you have created. They are not used for any sort of internal jBPM error that may have been resulted from processing within the engine itself. So, for example, if you are extending functionality with an action or assignment handler, you can trap and manage those errors using the exception handling techniques we will describe.

A source of common misunderstanding about exception handling within jBPM is whether you can use this mechanism to directly alter the flow of the process. The official documentation is rather contradictory on this matter. The upshot is this: While technically you can redirect the[m], this is strongly discouraged. Instead, the proper approach is to instead set a process instance variable, which can then direct subsequent flows by way of a decision node. In addition, you can issue an alert or notification through JMS, email etc., so that someone can perform remedial actions. In chapter 7 of the book, we illustrate how exceptions can be used in tandem with process variables to achieve what is likely the desire affect — notification of the exception to an appropriate party.

While not an advanced feature, per se, we'll next look at how Beanshell scripts can be used in lieu of Java classes for more rapid development.

Beanshell Scripting

Beanshell scripts are supported in most cases where Java handler classes can be used. Thus, they can be used for actions, events, or setting process variables. In addition, Beanshell scripts are used by decision nodes. In this instance, they are a one-line statement that must evaluate to true or false (this is also true for anytime an expression attribute is also allowed).

Regardless of whether you extend jBPM functionality with Beanshell or Java, inevitably you will want the ability to log and monitor the activity that occurs within your process instance. This is whether jBPM audit logging comes into place. We also see in the next chapter how this capability can be used to generate events which can be consumed by an event stream processor, thus providing real-time metrics and monitoring into your jBPM process instances.

Audit Logging

By default, there are a variety of audit logs that are produced as a result of process instance execution. Collectively, these logs will provide you complete insight into every activity that has occurred within a process instance. How can this information be beneficial? For example, you could load it into a data warehouse for reporting and analysis. Or, perhaps monitor the data in real-time for business activity monitoring dashboards, and the like. Like nearly all aspects of jBPM, you can also extend the logging features with your own required capabilities. For example, you may wish to do this if you wanted to dynamically filter the logs for only content you deem relevant. Detailing how this can be accomplished is outside the scope of this excerpt, but is address in chapter 7 of the book.

We will now conclude our discussion of jBPM advanced features by looking into asynchronous continuations, which enables process execution to be asynchronously performed by a server process.

Asynchronous Continuations

You have likely noticed through the exercises thus far that, when you signal the execution of a process instance, it will continue to execute within the thread you are running until it encounters a wait state, such as a state or task node. At that point, you could consider the transaction to be completed. While generally this doesn't cause any problems because most transactions complete within milliseconds, there are times when that may not be the case. Do any scenarios come to mind? How about when you have a node node-type that performs a web service call to a remote system using a traditional request/reply message exchange. In that scenario, the node will block and wait until the reply is received (or it timeouts). This could have highly undesirable consequences for your process if, for example, an immediate response is anticipated (maybe it's a web order being kicked off through the BPM process, and the user is awaiting a response with an order identifier). Fortunately, there is already a built-in approach for managing this scenario directly within jBPM. It is called asynchronous continuations. How this works is best illustrated through a simple example.

Figure 3

In the process shown in Figure 3, let's assume nodes 1, 2, and 3 include Java action handlers which perform some external action. In nodes 1 and 2, those action handlers perform their work synchronously within the same transaction that the process is initiated (this is the default behavior). However, the 3rd node is specified using @async=true. What this means is that the node, and within it any Java action handlers, will be processed by an external command executor. Since node 3 is processed asynchronously, the transaction is completed and placed in a wait state (i.e., persisted) until the join node receives node 3's signal.

The jBPM Enterprise version, which runs within the context of an application server, is, by default, configured to support asynchronous continuations by way of its build-in Job Executor. The Job Executor receives its command message through a JMS queue that is automatically configured when jBPM Enterprise is run. In our example, what this means is that the jBPM Job Executor will asynchronously process node 3. Once completed, node 3's action handler instruction to signal continuance of the execution will be performed. Figure 7.6 shows the process instance just after initiation, where nodes 1 and 2 have been completed and now wait in the join node for the conclusion of node 3.

Figure 4

As Figure 4 illustrates, the asynchronous processing of node 3 occurs in three steps: 1) a JMS message that includes the action handler to be executed is sent to a JMS queue; 2) the jBPM Enterprise Server's command listener is listening for new messages submitted to the queue; and 3) once a message is received it then is sent to the command executor for processing. The command executor will initiate a new transaction from which the action handler is run, and will forward the execution onward. Although not shown, all 3 nodes will then have then completed, the join consummated, and execution moved to the end to complete the process instance.

We have now completed our coverage of some of jBPM advanced features. Others, such as how to create your own node types and integration of jBPM console security, are not covered. The jBPM User Guide does provide some guidance on these matters, and the forum and source code can be indispensable as well. We will now look at a very exciting topic, and that is how to integrate jBPM with SCA and SDO, which was the topic of chapters 3 and 4, and a key cornerstone for creating a SOA environment.