Tuesday, November 3, 2009

BPM Console 1.2 released

Release Notes - BPM Console - Version BPM Console 1.2


  • [BPMC-15] - Principal not correctly resolved

  • [BPMC-20] - Parse error on process instance with two active nodes

  • [BPMC-25] - XMLProxy chokes upon cookie initialization

  • [BPMC-24] - 'rootToken' is optional in the ProcessInstanceRef

Feature Request

  • [BPMC-14] - Add support for custom reports

  • [BPMC-17] - Add paging to processdefinitions, processinstances, tasks, ... views

  • [BPMC-21] - CSS for task forms

  • [BPMC-22] - Auto-resize task form windows

  • [BPMC-26] - Provide preferences panel

  • [BPMC-27] - Initialize report server when server module is loaded

Wednesday, October 7, 2009

Drools 5.1 M1 ships the BPM console

Drools 5.1 M1 includes the recent BPM console. Take a look, give it a ride: http://blog.athico.com/2009/10/drools-51-m1-release-notes.html

Thursday, September 10, 2009

Activity Monitoring, Part 1: A twitter example

SAM has been around for quiet some time, but still didn’t get much traction. On the one hand I was involved with other projects and on the other SAM did lack good examples that reveal the underlying concepts and put them into context.
In the past few days I’ve put together an activity monitoring demo that will be used to explain the core concepts and give you an idea how SAM can be used to monitor activities of a particular domain.

Event streams

First of all, a good example needs constant event feeds. I was thinking about monitoring TCP packages on my box, but then came up with much more comprehensive example: Twitter feeds. Twitter has such a high volume of messages that it’s easy to derive event streams from it. In order for correlation to make sense we need events that share some kind of context. Using the twitter search API we can query messages that contain particular keywords, which is just enough contextual information for this example to make sense. Because I was tired of the king of pop, I decided on another high volume discussion, in this case iran.

You may ask: “Why event streams to begin with?” Because SAM is intended to monitor activities in a system close to real time. System activity is expressed a number of events that happen in no particular order but constantly over time. Event’s don’t even need to share the same properties, even though in our example they do.
And last but not least: It’s no fun to monitor a system without activity. You’d just get blank graphs and empty tables, which is hard to explain to the audience.


Events come in all kinds of flavors. Most likely events share common properties if they derive from the same domain, i.e the twitter message cloud. When instrumenting a target domain you create event representations and push them to SAM using a specific stream input. A stream input is bound to a transport layer (i.e. JMS) and has a set of processing rules associated with it. These rules are used to monitor and act upon event streams if certain conditions kick in:

rule "all iran tweets"
$tweets: List() from accumulate(
$t : Tweet(id>0) over window:time(15s) from entry-point "iran tweets",
collectList( $t )
SAM.getListener("iran results").update($tweets);


In this example a simple rule is associated with the event stream input “iran tweets” that collects messages over a 15sec time window and pushes them to a stream output “iran results”.

While stream inputs collect events, stream outputs are used to forward events,
i.e. for notifying SLA watchdogs. The number of processing steps between input and output is not limited. You may use rules that trigger other rules. I.e. first filter certain events and then correlate them:

But for the sake of simplicity we simply collect events over time and push them to the monitoring UI. We could add more complex processing rules, but that would extend the scope of this blog post and will be explained in Part 2 of this series. But for those of you who cannot wait, I suggest to take a look at Drools Fusion, the CEP engine that drives the complex correlation capabilities within SAM.


The whole purpose of SAM is monitoring and management of a system in place. SAM has a close relation to BPM console, as it will be used to realize the BAM capabilities (Business Activity Monitoring) for JBoss BPM projects. For this reason I’ve chosen to implement the monitoring UI right atop of the BPM console framework. The user interface you see in the next sections is actually an editor component that can be plugged into the BPM console.

But before we dive into the details, we need explain how SAM interfaces with a monitoring console.

The monitoring UI and SAM are decoupled through the use of current value tables (CVT). A CVT holds the correlation results at a particular point in time. Any processing result that is forwarded to an event stream output will update a specific CVT that is associated that output. The monitoring UI doesn’t access the stream output directly, but instead reads the data from a CVT:

So, whats happening in our twitter example? Every 15 sec we collect the events from our stream input and simply forward to a stream output, that in our case is writing to a current value table. The monitoring UI runs in a another thread and uses a different update interval. It assembles a graphical representation and displays it to the user. In this case a line chart that depicts that number of messages at given point in time:

Et voila! We’ve reached our first milestone: Monitoring twitter participation on a certain topic close to real-time.


As the name suggests, a current value table only holds most recent data. In our example it means the last sample point on the x-axis of the chart above. Here’s the corresponding value table:

In this case four people have been tweeting about “iran” at that given point. But what if we want to go back in time? I.e. inspecting a previous peak or any other kind of derivation? Fortunately our CVT implementation doesn’t simply purge all records when an update occurs, but instead “swaps” all data to a Handler that will maintain a CVT’s history. It stores all snapshots so they can be retrieved later on.

Second milestone: We are not restricted to the most recent data, but can also go back in time and compare current and past event streams by simply navigating through the chart:

Drill down

That leaves us with one remaining question. The event properties available are pretty limited. Why is that? And how can we get to the details?

In order to answer these questions we need to step back a little. SAM tries to provide event stream analysis close to real time. That means we aim for minimum footprint whenever possible. Event representations travel back and forth through the whole monitoring infrastructure, beginning with the target domain being monitoring, then entering the event processor itself and finally being represented visually in a monitoring UI. It’s important to restrict the payload without sacrificing the analysis possibilities. The solution is simple: SAM works with references to both the target domain and the event entity. Basically everything that is required are an event context (i.e. twitter user name), a timestamp and a reference id (i.e. message id). Other properties that go beyond that depend on the correlation rules you want to apply. The challenge when creating a monitoring solution is finding the right balance between target domain instrumentation (initial event representation) and correlation capabilities.

If we stick to our example, both message ID and username are sufficient to drill down later on. We can always go back to twitter and retrieve the message contents for a particular message ID. It leverages one of the fundamental ideas behind SAM CVT implementation: On-demand content retrieval:

Putting it all together

Let us quickly recapture what has been explained here.
We capture events of a target domain and push them to SAM through event stream inputs. Each input is associated with a set of processing rules that monitor the event stream and kick in on certain conditions. When rules kick in we can forward events to stream outputs or further feed them into the processor.

One of the use cases for stream outputs are monitoring tools that display the information to a user. Users watch for exceptional situations and need to know what’s causing them. This also implies access to events that did happn in the past.

Thorough analysis requires you to drill down to the event details and the source of information. Which is not necessary for all events, but only those of interest hence the need for on-demand content retrieval.

Comments? Thoughts? Please let us know at the Overlord forums.

In the meantime enjoy the screencast of the twitter monitoring demo in action.

Friday, September 4, 2009

Monday, August 31, 2009

BPM Console 1.1.2 released

BPM Conosle 1.1.2 carries minor enhancements, probably the most notable change is the switch from HTTP Basic Auth to form based authentication and session management (BPMC-12). Here's the complete changelog:

Release Notes - BPM Console - Version BPM Console 1.1

  • [BPMC-7] - url is wrong in the resources page for jbpm profile
  • [BPMC-1] - Make tasks the default editor
  • [BPMC-2] - Move settings to the bottom
  • [BPMC-3] - Split rendering directives and process variables in form processor
  • [BPMC-5] - Tomcat Lite doesn't pickup profile changes
  • [BPMC-9] - Form processing requires access to principal doing the call
  • [BPMC-10] - Pick JAAS domain for server module from build profile
  • [BPMC-8] - Set the correct log for RESTEasy in JBoss As.
  • [BPMC-12] - Switch to form based authentication and session management
  • [BPMC-13] - Remove TX demarcation inPluginMgr

Monday, August 24, 2009

BPM Console screencasts

Several new screencast have popped up recently that show the BPM console in Action.

- Joram shows how to customize the reporting.
- Kris did an excellent overview of the console as a whole, including task forms.

Thursday, July 23, 2009

Alex McGuire on Using Scala in a Large-Scale Project

Alex McGuire, a developer with √Člectricit√© de France, describes how his team has been gradually migrating to Scala in a 300,000-line mission-critical production application. More ...

Tuesday, July 7, 2009

James Strachan on Scala

If you are interested in Scala, then I'd recommend James blogpost on Scala. He did collect a lot of resources to whet your appetite.

Tuesday, June 30, 2009

Integrating App Engine with EC2

A usual morning: Grab a coffee, check your emails and browse the latest rss feed updates. This time stumbled across an interesting session, given at google i/o: "App Engine Nitty-Gritty: Scalability, Fault Tolerance, and Integrating Amazon EC2"

Thursday, June 25, 2009

Client-side data storage: JavaScript database support

I remember the days when Javascript was considered a severe security vulnerability. Now we get client side javascript database support. Safari already implements it. Wicked!

Drools Flow adopts BPM Console

Kris Verlaenen, the Drools Flow lead, has successfully adopted the BPM Console for Drools.
This means you can now manage Drools Flow processes the same way you do in jBPM4.

That's great news. It shows that the initial design, decoupling the console from the engine has proven to be successful.


Monday, May 18, 2009

"Clothes make a man": Moving to gwt-mosaic 0.1.10

Since jBPM 4.0.0.CR1

Today I've tested the new mosaic styles on the BPM console.
Thanks to George for back porting the
Aegean theme and the layout manager improvements to the mosaic build for GWT 1.5.3:

Thursday, May 14, 2009

BPM Console, Task UI Demo

I've created a quick demo of the new Task UI feature, embedded in the console. Enjoy!

BPM Console, Task UI Demo from Heiko Braun on Vimeo.

(Best viewed full screen with scaling turned off)

Questions? Leave a comment in the forum.

Thursday, April 23, 2009

BPM console: springtime cleaning

Since 4.0.0.Beta2

The BPM console is approaching Beta3 and it was about time to tidy up. We'd been running on gwt-ext from the beginning, because it was easy to get started with the project. But due to some license changes in the gwt-ext project, we'd been forced to abandon that approach and chose gwt-mosaic as it's successor. Mosaic works like charm and will eventually evolve as the default library for any JBoss GWT console.

Plugin-API and workspace composition
We are still looking into unification that allows composition of management interfaces across JBoss project within a single console. The BPM console already follows that approach, which has been explained in a previous blog post. Besides some minor refactorings in the plugin-api, the concept did basically remain the same: A workspace is assembled at build-time. Editors (workspace plugins) are retrieved from the classpath (maven dependencies) and configured through a workspace configuration:



# not yet implemented in jBPM4

Proper MVC design
If you got the chance to look into the previous codebase, you'd probably realized that the model and view components have been tightly intermingled. It was a result of the early UI prototypes that simply survived across releases. But with migration to mosaic, we decided to clean it up was well. The current implementation uses mvc4g, a GWT ready implementation of the HMVC pattern. As a result the plugin-api does leverage that pattern by default:

If you now look at the sources, you'll find a clean and easy to understand separation of editors, actions and views:

Improved error handling
One of the major complaints we received about previous console versions, was the fact that, sometimes it got stuck without any indication of what has been going wrong. With the latest refactorings, any HTTP request handling has been delegated to the core GWT RequestBuilder classes. This gives us more fine grained control, including request timeouts and http status codes as well as standardized error reporting.

New look and feel
Mosaic is more close to the actual GWT sources and hence less fancy. But the actual Widgets are less error prone and do render faster then gwt-ext:

Stay tuned. Now that we got the codebase in good shape for this summer, we'll proceed with functional enhancements: Task forms and reporting.

Join the discussion in the console dev forum.

Tuesday, March 31, 2009

JBoss at Google Summer of Code

JBoss is mentoring projects at this year Google Summer of Code again. If you interested in working on jBPM or JBoss projects in general then please checkout the list of available projects.

jBPM offers a list of projects that will be mentored by Tom and me. If you are interested in one of those get in touch with us.

Monday, March 30, 2009

jBPM Task Management: A look at the participation model

Since 4.0.0.Beta1

The revisited task management model in jBPM introduces a new concept: task participation. The participation model describes identities (user or groups) and the type of involvement in the actual completion of task:

Example 1: User and business administrator participation
A common use case where this model fit's quiet nicely is the distinction between a user that actually performs the task and a business administrator monitoring progress. Depending on the participation type some principals will actually do the work, while others make sure tasks are executed within given constraints (i.e. priority, duedate, etc).

Example 2: Task stakeholders with different participation types
Another example could be stakeholders monitoring the actual outcome of task, or delegation between different participants that co-operate on a task. In this case a "initiator" of task, a "candidate" performing the work and the "final recepient" might be different participation types.

The TaskService API already reflects those changes:

* retrieves a list of tasks for a user
* and a particular {@link org.jbpm.task.Participation} type
* @see org.jbpm.TaskQuery
List findTasksByParticipation(String participation, UserRef user);

* retrieves a list of tasks for a group
* and a particular {@link org.jbpm.task.Participation} type
* @see org.jbpm.TaskQuery
List findTasksByParticipation(String participation, GroupRef... groups);

Currently we ship some default participation types, out of which only type 'candidate' is supported, but you can expect this to be extended in the near future.


String CANDIDATE = "candidate";

IdentityRef getIdentityRef();

/** see constants for default participations */
String getType();

Stay tuned.

Friday, March 20, 2009

Task management extensions: Human interaction management

a) Application: Some process being executed that hits a task activity

b) Task Mgr: The current jBPM4 base model for managing tasks. It includes assignments, variables, etc.

c) Notification Mgr: Decouples the notification features. I.e. email, ical,etc. The idea is borrowed from the latest code contribution.
How and if the task management does notifications will be pluggable. We will probably provide a smtp notification mechanism as the default.

d) Form Mgr: Interfacing the outside world. Formost use would be HTML forms of some kind, but can be a WS interface as well. The Form Mgr relies on the variables and resources associated with a process.

Tuesday, March 10, 2009

RFC: Process deployment use cases

This is a request for comments.
Since 4.0.0.Beta1

  • What deployment use cases do we want to cover?
  • What constraints should apply for each use case?

The matrix below shows the constraints for the deployment policies that are currently implemented:


There is currently four properties that are taken into consideration when processes get deployed:
the process name and version (part of jpdl.xml), the artifact name (i.e OrderProcess.par) and the artifact timestamp.
Process name, version and artifact name are the main properties that distinguish process deplyoments, the timestamp basically just acts as a fallback when no version is given and leads a version auto-increment.

Possible combinations of those properties lead to matrix above.

Work on the jBPM4 deployer started