Introduction
To start with we need to take a closer look at the landscape and then peel back the layers like an onion for a closer look at how we can provide BPM projects that scale well. Figure 1 shows that there are several component layers where we will want to focus our attention:
- Process Initialization Layer
- Process Implementation Layer
- Process Repository
- Tooling for business users & developers
- Console, reporting & BAM dashboards
- Process Interaction Layer
 | |
|
The process initialization layer will be covered in this article, where I present some best practices around you, your customer and how processes are started.
The process implementation layer is where the processes are being maintained, with help from the process repository, tooling, business users and developers that design them. Here you will also find the various implementation details, such as domain specific extensions to cover specific node types within our projects. Best practices in this layer will be covered at a later time.
The console, reporting and BAM dashboard components are the extended tooling used in projects to provide business value or information that can be used to influence business decisions. Best practices in this area will be covered at a later time.
Finally, the process interaction layer is where you processes will connect to all manner of legacy systems, back office systems, service layers, rules systems even third party systems and services. Best practices in this area will be covered in a later article.
 | |
|
Process Initialization Layer
Taking a look at how to initialize your processes, I want to provide you with some of the best practices I have seen used by larger enterprises over the years.
There seems to be a main theme of gathering the customer, user or system data that is needed to start your process, then just injecting it by the startProcess call. This can be embedded in your application via the BRMS jBPM API call, make use of the RESTful service or via a standard java web service call. No matter how you gather the data to initialize your process instances, you might want to think about how you would want to scale out your initialization setup from the beginning. Often the initial projects are setup without much thought as to the future, so certain issues have not been taken into consideration.
Customers
The customer defined here can be a person, a system or some user that provides for the initial process starting data. In figure 2 we provide a high level look at how our customers provide process data that we then package up into a request to be dropped into one of the process queues. From the queues we can then prioritize and let different mechanisms fetch these process requests and start a process instance with the provided request data. We show here EJB’s, MDB’s and clouds that represent any manner of scheduling that might be used to empty the process queues.
Queues
These queues can be as simple as database tables or as refined as message queues. They can be setup any way your project desires, such as Last-In-First-Out (LIFO) or First-In-First-Out (FIFO). The benefits of using message queues is that you can prioritize these from your polling mechanism.
The reason for this setup is two fold. First, you have ensured that by not directly starting the process instance from the customer interface that you have persisted the customer request. It will never be lost in route to the process engine. Second, you have the ability to prioritize future processes that might not be able to meet project requirements like a new process request that has to start in 10 seconds after submission by the customer. If it gets put at the bottom of a queue that takes an hour to get to processing it, you have a problem. By prioritizing your queues you can adjust your polling mechanism to check the proper queues in the proper order each time.
Java / Cloud
The java icons in figure 2 are representing any JEE mechanism you might want to use to deal with the process queues. It can be EJB’s, MDB’s, a scheduler you write yourself or whatever you want to come up with to pick up process requests.
The cloud icons are meant to represent services that can be used by your software to actually call the final startProcess method to initialize the process instance being requested and pass it initial data. It is important to centralize this interaction with the jBPM API into a single service thereby ensuring minimal work if the API should change, for possible version migrations in the future and should you wish to expand it in future projects to extend the service interaction with jBPM.
Conclusion
This article briefly walks through the high level BPM architecture and lays out the various layers of interaction. The first layer of interaction in larger enterprise BPM architectures, the initialization layer is examined to provide some insights into best practices within this layer. It is not a discussion that attempts to push implementation details, but takes a step back and introduces some of the basic elements that are repeatedly encountered in large BPM architectures. It covers the initial customer submission of a processing request, the queueing of process requests and the processing of these queues in a consistent and scalable manner. There is still more to take a look at in future articles, in the Process Implementation Layer, the Process Interaction Layer, in the Process Repository, in the Tooling and in the reporting & BAM layers.
Reference: JBoss BRMS Best Practices – tips for your BPM Process Initialization Layer from our JCG partner Eric D. Schabell at the Thoughts on Middleware, Linux, software, cycling and other news… blog.
