BPM Console

Project information

• Source repository: https://svn.jboss.org/repos/soag/bpm-console/trunk
  Anonymous access: http://anonsvn.jboss.org/repos/soag/bpm-console/trunk
• Forum: jBPM Developer Forum , JBoss GWT Developer
• Issue tracking: https://jira.jboss.org/browse/BPMC
• Blog: http://relative-order.blogspot.com/
• IRC: irc.codehaus.org#jbpm
• ohlog.net: https://www.ohloh.net/projects/jbpm-gwt

Related topics

• BPM Console Reference 1.0.0.GA
• Report server (BIRT integration)
• Report customization
• Console screencast

Overview

Theclient side uses GWT and additionally relies on GWT-Mosaic. There is anintermediary facade build on RESTeasy (JSR311) which uses Jsonencoding. The console server itself is decoupled from concrete jBPMimplementations through an integration layer,

which needs to be implemented by managed runtimes. The following picture shows a high level overview:

GWT Application

Theclient side use GWT 1.5 and currently relies on the GWT-Ext extensions.Recent discussions show that it's quiet likely that we are going tomove away from GWT-Ext due to a change in their license model, but fornow it enables us to get things done quickly. The client applicationshares a domain model (DTO) with the REST facade and json encoded datafor the backend integration.

Console Server

The server isbuild on RESTeasy, a JSR 311 implementation. It allows for rapidpublishing of REST resources and has out of the box support for"application/json" and "text/xml" marshalling. Support for specificcontent types can easily be extended, which can become important whenextending the BI/BAM capabilities (think PDF or Image generation). RESTwas chosen over GTW RPC for several reasons:

• Decoupling of client and server (See "Testing the GWT console")
• Extendable content types
• Support for non  GWT clients, i.e. the eclipse tooling
• Simplified development model (i.e curl)

Integration Layer

Theintegration layer decouples the console server from the managed BPMruntime. Both the GWT application and the intermediary layer share adomain model which needs to be adopted by concrete BPM implementations.Differences between jBPM3 and jBPM4 will be tackled at this level.

Project structure

If you take a look at the maven build structure, you'll find  the modules: RPC,Server and WAR.

• RPC: Shared domain model between the GWT app and the console server
• Server: The REST facade plus integration layer
• WAR: The GWT application itself and test suite

Theserver and war modules create distinct web applications which can bedeployed separately. This allows you to deploy the REST facade on  arunning JBoss AS instance, while still developing in GWT hosted mode.The test suite  does rely on this mechanism as well. It's necessary,because the DAOFactory implementation usually require server resourceslike EJB's, Datasources, etc.

 

NOTE: The server module needs to be deployed on a running jboss instance, along with jbpm. The easiest way is using the installer as described here: http://www.jboss.org/community/docs/DOC-12863

 

Build and test the console

The console is build within the WAR module. It relies on the maven-gwt plugin,which automatically downloads and install a GWT bundle specific to yourOS. Detailed information goals, setup and examples can be found here .

Follow these 3 steps to get started:

1. Build the whole package:

cd gwt-console/trunk
mvn install

2. Make sure the gwt-console-server.war is installed along with jBPM (or any other process engine)

• Building jBPM4 from source

3. Launch/debug the GWT app itself

cd gui/war

# compile and launch in hosted mode, requires the REST facade to be deployed
mvn gwt-maven:gwt

# hook up a debugger
mvn gwt-maven:debug

Roadmap and Releases

Thegwt console ships as optional installation component with the jBPMinstaller (beginning 3.3.0.GA). Since it has a dependency on the jBPMruntime it will follow the same release cycle, which every 8 weeks.Details on the jBPM roadmap can be found here .

Problems?