Tuesday, August 28, 2012

Best practices: JBoss Enterprise BRMS—the road to large-scale enterprise solutions

Last week I was in Boston and our Westford offices to meet with various JBoss Integration & BPM Product Managers. Along with these meetings I did two webinar broadcasts with Phil Simpson, the JBoss BRMS Product Marketing Manager.

The recording is available online where we talk about how to discover best practices for constructing both BRMS and BPMS applications that support large numbers of rules and processes operating on big data. We discuss the common use cases with real-world case studies and give you practical tips for scaling out your projects.

Check it out!

GOTO Aarhus: Building highly scalable process and rule apps with JBoss BRMS

I have been invited to talk at GOTO Aarhus in Oct 1-3, so thought I would share my abstract of the talk here which will be taking place on Monday, 1 Oct.

You can find this on lanyrd.com for tracking.

Building highly scalable process and rule-driven applications with JBoss Enterprise BRMS
Your enterprise can become truly intelligent. Get there with Red Hat’s JBoss® Enterprise BRMS—a key part of our vision for the intelligent, integrated enterprise. Its unique combination of open source technologies supports a broad range of decision-management and process-driven applications.

The power of business rules, complex event processing, and business process management is delivered in a single open source distribution and accessible from a common set of authoring tools, JBoss Enterprise BRMS is a robust fusion of:

  *   jBPM5 business process management
  *   Drools business rules
  *   Drools Fusion complex event processing

In this session we will discuss best practices for constructing both BRMS and BPMS applications that support large numbers of processes and rules operating on big data.  We'll illustrate common use cases, provide practical tips and you’ll learn how to confidently scale out your rule applications to meet demanding enterprise needs.

See you there!

Wednesday, August 15, 2012

JBoss BRMS Best Practices - tips for your BPM Process Initialization Layer


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 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.
Figure 2: Getting started.

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.

Chinese translation provided by Christina Lin.

Friday, August 10, 2012

JBoss BRMS 5.3 - Adding on JasperReports for Reporting

Before we start on the how to section of this article I wanted to welcome a new member of our team. We have an intern working with us in the BRMS team that I would like to introduce, Kumar Bijyendra. What better way to introduce him than to present some of his work, so without further delay, here is the guide to get you started adding on JasperReports for JBoss BRMS 5.3.


Introduction


Jasperreports is a free downloadable library that can be used for generating rich reports for Java EE applications. This guide also provides the steps to generate report templates using Jasper iReport designer.

Software requirements

  • JBoss BRMS 5.3 (from customer portal, http://access.redhat.com
  • JasperReports 4.6.0
  • Jasper iReports
  • Maven (for building report server)
  • Ant (for building JasperReports)

Adding on JasperReports

Just follow these steps to get it up and running.
  1. install JBoss BRMS 5.3 standalone.
  2. create the following directories in in BRMS install
    • $JBOSS_HOME/server/default/data/Jasper
    • $JBOSS_HOME/server/default/data/Jasper/Output 
  3. Download (latest) Jasperreports 4.6.0 from the following location
  4. Extract the contents of the downloaded folder in a local directory.
  5. Goto jasperreports-4.6.0-project\jasperreports-4.6.0 directory where the build.xml file resides and do an ant build. This will create the distribution jars at the following location $path_to_jasper\jasperreports-4.6.0-project\jasperreports-4.6.0\dist
    • Jasperreports-applet-4.6.0
    • Jasperreports 4.6.0.jar
    • Jasperreports-fonts-4.6.0
    • Jasperreports-javaflow-4.6.0
  6. Copy the above jars to the following location
    • $JBOSS_HOME\server\default\deploy\gwt-console-server.war\WEB-INF\lib
  7. Get report server code from github repository from the following location
  8. Go to the root directory of the downloaded code and do a maven build: mvn clean install. This will generate the distribution jars; reports-core-1.3.0.jar, report-shared-1.3.0.jar 
  9. Copy the two previous jar folders from the dist directory to the $JBOSS_HOME\server\default\deploy\gwt-console-server.war\WEB-INF\lib 
  10. Delete the existing reports-core-final-1.4.0 and reports-shared-final-1.4.0 in the $JBOSS_HOME\server\default\deploy\gwt-console-server.war\WEB-INF\lib
  11. Download jasper report templates overall_activity.jasper and overall_activity.jrxml from the following link and copy into $JBOSS_HOME/server/default/data/Jasper
  12. Copy the following library jars from $path_to_jasper\jasperreports-4.6.0-project\jasperreports-4.6.0\lib to the following location $JBOSS_HOME\server\default\deploy\gwt-console- server.war\WEB-INF\lib
    • commons-digester-2.1
    • jfreechart-1.0.12
    • jcommon-1.0.15 

Customization and editing .jrxml file

  1. Follow the document JasperReports-Ultimate-Guide-3.0 in docs folder at $path_to_jasper/jasperreports-4.6.0-project\jasperreports-4.6.0\docs
  2. Download and install Jasper iReports designer from the following location
  3. Open the overall_activity.jrxml file in the iReports and edit. Save the .jrxml file and compile by clicking on the preview tab. Copy both the .jrxml (only for future reference) and .jasper file to the $JBOSS_HOME/server/default/data/Jasper 
Enjoy and don't forget to ping Kumar Bijyendra with a big thank you!

Chinese translation available from Christina Lin.