Thursday, January 15, 2009

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.

8 comments:

Thomas said...
This comment has been removed by the author.
Thomas said...

This is excellent news and good work.

Are there any plans to extend the notion of plugins to the server module? For example, if I write a plugin for Process Management or Task Management I would also want to extend the server side REST facade.

Taking this idea even further, as the number of available plugins grows there might be an overlap of conceptually common data. For example the list of active Process Instances might be of interest to more than just one plugin.

Instead of every plugin defining its own propriatary REST facade for Process Instance data, there might be a need for data access that is "native" to the gwt-console. This would result in a standard interface that is available to every server side plugin.

Some of this we have in the BPM Integration Layer, which already deal with the notion of

* ProcessEngine
* ProcessDefinition
* ProcessInstance
* Message
* Signal

Note, that I've taken the notion of Token out of this list, which seems to be proprietary to jBPM

Unknown said...

This is ideed a nice idea and a good example. Google Maps seems to have replaced 'HelloWorld';-)

Regarding the Token, are you sure Thomas?

From Notations and workflow patterns [bpmn.org]

The
behavior of this pattern can be described by the use of a conceptual “Token” that travels down a Se-
quence Flow from the source object to the target object—as shown by the directionality of the arrows.


And the 'token' is referred to in lots of other documents as well, including ones on e.g. the workflowpatterns site.

Thomas said...

Ronald,

I don't question the concept of Token in general an I would fully agree with your quote above. BPMN also talks about the notion of Token.

BTW, this is also why I advice to keep the concepts of Token and ProcessInstance separate and not combine them in something called Execution. This would indeed be conceptually incorrect.

However, it is proprietary to jBPM that a client of the ProcessEngine (i.e. the GWT-Console) is responsible of moving the Token from one node to the next.

Instead I advocate that the ProcessEngine controls the movement of all Tokens and exchanges data with the client via Signals, Messages and callbacks that may receive the Token.

In that way the GWT-Console could query the state of all (suspended) Tokens associated with a ProcessInstance and send directed Messages if needed.

Heiko Braun said...

Ronald, Thomas, please see my replies in the overlord forum

markinsonmarshal said...

I had collected information about BPM for the presentation in our college.....Since then I'm very curious to know more and more about it. Whenever I get a chance I surf net for getting more information about BPM.Coming to this post.I found the code and information provided here is very informative.
It was a great pleasure visiting here.Shall surely come here later to get more of new updates.
BPM

Unknown said...
This comment has been removed by the author.
Unknown said...

The idea behind this blog post Developing BPM console plugins is outstanding,

psychology dissertation layout