- 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
- BPM Console Reference 1.0.0.GA
- Report server (BIRT integration)
- Report customization
- Console screencast
The client side uses GWT and additionally relies on GWT-Mosaic. There is an intermediary facade build on RESTeasy (JSR311) which uses Json encoding. The console server itself is decoupled from concrete jBPM implementations through an integration layer,
which needs to be implemented by managed runtimes. The following picture shows a high level overview:
The client 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 to move away from GWT-Ext due to a change in their license model, but for now it enables us to get things done quickly. The client application shares a domain model (DTO) with the REST facade and json encoded data for the backend integration.
The server is build on RESTeasy, a JSR 311 implementation. It allows for rapid publishing of REST resources and has out of the box support for "application/json" and "text/xml" marshalling. Support for specific content types can easily be extended, which can become important when extending the BI/BAM capabilities (think PDF or Image generation). REST was 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)
The integration layer decouples the console server from the managed BPM runtime. Both the GWT application and the intermediary layer share a domain model which needs to be adopted by concrete BPM implementations. Differences between jBPM3 and jBPM4 will be tackled at this level.
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
The server and war modules create distinct web applications which can be deployed separately. This allows you to deploy the REST facade on a running 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 resources like 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 your OS. 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)
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
The gwt console ships as optional installation component with the jBPM installer (beginning 3.3.0.GA). Since it has a dependency on the jBPM runtime it will follow the same release cycle, which every 8 weeks. Details on the jBPM roadmap can be found here .
Ask for help at irc.codehaus.org#jbpm