Developing BPM console plugins

I committed a first draft of a plugin mechanism that allows composition of BPM console features more easily. Initially we'd been looking for a convenient way to deal with the differences in jbpm3 and jbpm4, but now it has proven to be good solution for console mash-ups in general. For instance future integration or composition with Guvnor.

The idea is simple: While providing common elements like authentication, configuration and look and feel, the console needs to be assembled out of common and proprietary features. Not everything we build into it, works across BPM runtimes even though it's our foremost goal.

Fortunately GWT already ships with an extension mechanism called "Deferred Binding". It allows you to replace or generate components at build time. Build time in our case means maven, and the easiest way to customize a maven build is by providing different sets of dependencies. Unlike the regular GWT compilation which is restricted to a subset of the JDK, the deferred binding has access to the full API, including classloading. It actually happens before the GWT compiler kicks in.

Great. That means our plugin loader can build upon the availability of plugins in the classloading scope.
Maven already provides the dependency management, then we are set.

Let's look at an example. Trunk contains a plugin-example that should get you going. Take a look at the pom.xml dependencies first. Any plugin has a dependency on the console plugin API:

<dependency>
     <groupId>org.jbpm.jbpm3</groupId>
     <artifactId>gwt-console-plugin</artifactId>
     <version>1.0.0-SNAPSHOT</version>
</dependency>

It ships with a few concepts that we need to clarify before we can move on. The console acts as a Workspace. A Workspace contains Editors, which are composed of different Views. Developing a plugin actually means implementing an Editor and providing a workspace configuration (workspace.cfg).

When building the console, the deferred binding generates and links the code that is required to associate all Editors in a workspace configuration with the console framework. Sounds terrible, but a plugin developer only needs to know a few interfaces and create a workspace configuration.

public abstract class Editor extends Panel
{
 protected ApplicationContext appContext;

 public abstract String getEditorId();
 public abstract String getTitle();
 public abstract String getIconCSS();
 public abstract MenuSection provideMenuSection();
 
 [...]
}

An Editor is your plugin root implementation. It needs to be uniquely identified (editorId) and contribute to the main menu (MenuSection). It can contain one or more views:

public abstract class View extends Panel
{
  protected ApplicationContext appContext;

  public abstract String getViewId();
  public abstract String getIconCSS();
}

The editor and it's views share an ApplicationContext that gives you access to common things like authentication, configuration, logging, etc.

public interface ApplicationContext
{
  [...]
  void displayMessage(String message, boolean isError);
  Authentication getAuthentication();
}

Besides that, you can leverage anything GWT provides for implementing your plugin.
I think you get the idea. Take a look at the plugin example (Google Maps integration), especially the editor implementation.
In order to enable this workspace configuration you need to build with "mvn -Pplugin-example" switch.

Discussion
Please join us in the overlord forum for further discussions.

Typing a BPM system

While working on the GWT console I came across two requirements that I couldn’t realize easily within the console: process variables inspection and task management forms. Both solutions should allow modification of data associated with a process through web based forms.

In order to build such a form and to process the data submitted through it you’d need some kind of data type description associated with the process definition. Even if you don’t intend to build those forms at runtime, but instead chose a design time approach you would still be left with the question of validation.

But not only that. The tooling that helps you build the task forms at design time would need some data type description as well. How would know what types to chose for UI elements and the keys to access it?

This leads to an additional requirement: Once you got the data type description and you successfully modeled your form, how do access the data at runtime? Somehow the process data needs to extracted and displayed through the forms.

One thing you may realize at this point is that a simple example like the task management forms already require type information across BPM components. It start’s with the tooling, is used to extract data at runtime and finally describes how the forms should be rendered.

One thing that jumps to my mind XML and XSD. Ok, I admit that I have been working on the JBoss web service stack, but other problem domains chose such a solution as well. Just think of heterogenous (i.e. ESB) or event based systems (i.e. CEP). And they do so for good reasons:

• You get a data type model that supports structured and simple types
  
• It can be validated through XSD
  
• Access to the data can either be done programatically or through XPath
  
• Data can be represented in Java or XML
  

If you add XForms to the picture we are one step closer to solving my initial task management problem: Describe your data types through XSD, extract it by using XPath and display it through XForms.

But there’s more to it: Decoupled producer and consumers in SOA, in which BPM plays in important role, would greatly benefit from such a type system as well. Any invocation between a process and a service could then be constrained to the type information at hand.

GWT console Beta2

Some things changed in Beta2 others did improve and I’d like to give you a quick update on what happened the last two month.

TokenEditor

Something you may already know from the JSF console and what is commonly used during development is the possibility to signal tokens directly from the console. We’ve added that feature to the GWT console under the section “Development tools”. You’ll notice those by the little wrench icon in the upper corner. These tools will be available to a particular role only, once we add authorization to the editors.



Report server integration

Beta2 drops the gchart, the client side Javascript charting library and instead switched to BIRT. There have been several reasons leading to this decision.
On the one hand we’ve realized that biggest challenge with reporting is not rendering itself (which gchart could have provided) but the tooling that needs to go along with it.



We’ve realized that it’s close to impossible to come up with the one and only BPM report that pleases everyone. Most reporting and dashboard applications are actually quiet the opposite: Highly customized towards particular users and their problem domain. This is the approach we are taking with BIRT as well. The jBPM console ships with stock reports, that can be extended or even be replaced.

If you are interested in jBPM reporting a good starting point would be the report server project introduction.



Task management

We’ve also added the first task management functionality which currently does focus on task assignments.



The current release allows you to claim tasks, complete them by signaling or reassign tasks to a particular user or group. Future console version will embed task forms for human interaction, but this area in particular requires further discussion.

Stay tuned...