I have posted some articles in the past on migration strategies, taken closer looks at process layers and provided some best practices for jBPM, both touching on very specific parts of your BPM strategies. I wanted to revisit the topic of best practices but then on an Intelligent, Integrated Enterprise level where we talk about getting control over your business processes with JBoss BRMS.
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 thestartProcess 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 finalstartProcess 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.
So far, we have walked through the high level BPM architecture and laid 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.
Process Implementation Layer
This layer focuses on your business process designs, your implementations of custom actions in your processes and extensions to your ways of working with your processes. The adoption of the standard BPMN2 for process design and execution has taken a lot of the troubles out of this layer of your BPM architecture. Process engines are forced to adhere and support the BPMN2 standard which means you are limited in what can do during the designing of your processes.
Knowledge sessions
There is within the JBoss BRMS BPM component one thing of interest for building highly scalable process architectures. This is the concept of a Knowledge Session (KS), specifically a Stateful Knowledge Session (SKS). This is created to hold you process information, both data and an instance of your process specification.
When running rules based applications it is normal procedure to run a single KS (note, not stateful!) with all your rules and data leveraging this single KS. With a SKS and processes, we want to leverage a single SKS per process instance. We can bundle this functionality into a single service to allow for concurrency and to facilitate our process instance life-cycle management. Within this service you can also embed eventual synchronous or asynchronous Business Activity Monitoring (BAM) event producers as desired.
This article briefly walks through the high level BPM architecture and lays out the various layers of interaction. The implementation layer is examined to provide some insights into best practices within this layer. The main focus is the SKS where we suggest how to not only use, but manage process instance life-cycles within a single service. On top of this it is suggested that this is a good entry point to offload your BAM events. There is still more to take a look at in future articles, in the Process Interaction Layer, in the Process Repository, in the Tooling and in the reporting & BAM layers.
Process Interaction Layer
There is much to be gained by a good strategy for accessing business logic, back-end systems, back-office systems, user interfaces, other applications, third-party services or whatever your business processes need to use to get their jobs done. Many enterprises are isolating these interactions with a service layer within a Service Oriented Architecture (SOA) which provides for flexibility and scales nicely across all the various workloads that may be encountered. Taking a look at the BPM layer here we want to mention just a few of these backend systems as an example of how to optimize your process projects in your enterprise.
Human tasks
The JBoss BRMS BPM architecture includes a separate Human Task (HT) server that runs as a service that implements the WS-HT specification. Being pluggable there is nothing to prevent you from hosting another server in your enterprise by exposing the WS-HT task life-cycle in a service. This should then use a synchronous invocation model which vastly simplifies the standard product implementation that leverages a HornetQ messaging system by default.
Reporting
A second service that you can implement to provide great reporting scalability we call a Business Activity Monitoring (BAM) service. This service you would use to centralize the BAM events and use it to push these events to JMS queues which are both reliable and fast. A separate machine can then be used to host these JMS BAM queues, processing the messages without putting load on the BPM engine itself, write to a separate BAM database, optimise with batch writing and any clients that consume the BAM information will again not be putting any load on the BPM engine itself.
Conclusion
This article briefly walks through the high level BPM architecture and lays out the various layers of interaction. The interaction layer is examined to provide some insights into best practices within this layer. There are several services that you can create to centralize your activities around human task and reporting. By centralising your human task interaction you can provide a standard and scalable solution to your enterprise. With the BAM service you are able to off load the work to a separate entity in your architecture, guaranteeing both delivery of these events and consistent performance with regards to reporting activities from your processes. There is still more to take a look at in future articles, in the Process Interaction Layer, in the Process Repository, in the Tooling and in the reporting & BAM layers.
Chinese translation provided by Christina Lin.
Reference: JBoss BRMS Best Practices – tips for your BPM Process Initialization Layer , JBoss BRMS Best Practices – tips for your BPM Process Implementation Layer , JBoss BRMS Best Practices – tips for your BPM Process Interaction Layer from our JCG partner Eric D. Schabell at the Thoughts on Middleware, Linux, software, cycling and other news… blog.
