We're currently investigating to use BPM as a workflow/state machine for process orchestration in a very high volume clustered environment. Orchestration component is Spring application which sends and receives events from other component over MQ/REST and basically events decides process state transition.
Here are some basic requirements for the Orchestration component we have and so far my observations with jBPM5 -
1. Clustering and Server deployment - Multiple instances of orchestration component are deployed to the cluster, hence the process state is maintained across cluster and server instances can drop and join the cluster any time.
Observation: If I use drools-spring to boot-strap my jBPM5 engine then I got 2 options - a) create new session or b) load existing session. But to load existing session I need to specify session id. In other words, I would need to write custom code upfront to decide whether I want to create new session or load existing one based on some thing, and this code needs to be cluster-safe as multiple instances starting up at the same time.
So do you agree we cant use any out-of-the box solution here and one have to write custom boot-strap code?
2. Dashboard support - We have our own platform-wide Dashboard and we want to add process state information to it, ideally using REST interface provided by jBPM. So we're not using any of jBPM console apps provided out-of-the-box.
Observation: currently jBPM console functionality is consists of JBoss BPM modules(ex. org.jboss.bpm:gwt-console-server etc) hooked in with jBPM integration services as provided in jbpm-gwt-xxx modules. we cant use it out-of-the box because -
1/ some of the jbpm-gwt-xxx modules have got persistence.xml with hard-wired H2 database details
2/ they are tightly coupled with Human-task and Guvonor, however in our case we are bundling all our processes as part of the application and not using any WS-HT either. In other words state transition of our process is driven by the events.
So as I understand we would need to build our version of "org.jboss.bpm:gwt-console-server" bundled with custom services to expose REST api to be used by dashboard. Would Knowledge api be used to extract current state from the database or am I missing something here?
3. Persistence - As I understand there are 2 forms of it - runtime state and auditing. Auditing is mainly pluggable using various listeners, and there are some out-of the box audit loggers available. For Runtime state, which is core part of jBPM5, I only see 3 entities -
<class>org.jbpm.persistence.processinstance.ProcessInstanceInfo</class>
<class>org.drools.persistence.info.SessionInfo</class>
<class>org.drools.persistence.info.WorkItemInfo</class>
Observation: Runtime state is stored in binary form and there is no relationship between tables, so merely looking at tables not able to say which process part of which session. So one has to use knowledgeSession to extract the information.
I see loads of potential in jBPM5 and believe it could be used in our case. I would really appreciate any directions here to understand how it can solve our requirements as pointed out above?