Agile Zone is brought to you in partnership with:

Eric D. Schabell has been working within software development since 1998 for many different organizations such as IBM, Radboud University Nijmegen, SNS Bank and smaller software companies. He has been involved in different roles within Open Source projects such as Sourcemage Linux, eGroupWare, DocConversion, cmlFramework and is still helping out in the JBoss jBPM project focusing as lead on the jBPM Migration project. Since 2009 he has been actively evangelising JBoss products and is a huge fan of OpenShift (PaaS). He is employed as JBoss Technology Evangelist for Red Hat, is a guest lecturer at the Radboud University Nijmegen and enjoys writing on various topics. Eric D. is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. You can read more from them at their website. View Full User Profile

JBoss BRMS Best Practices - Tips for your BPM Process Implementation Layer

12.07.2012
| 4360 views |
  • submit to reddit

 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

Figure 1: Enterprise BPM landscape.
The process initialization layer was covered in part I of this series, where I presented some best practices around you, your customer and how processes are started.

The process implementation layer which will be covered here 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.
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 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.


Conclusion
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.
Published at DZone with permission of Eric D. Schabell, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)