1 Reply Latest reply on Apr 15, 2012 5:43 PM by xmithj

    Runtime engine: JBPM Console or Drools Server?

    jmwest532

      With all the videos around that show the nice integration of the JBPM Console with Guvnor, and its whole set of features, one would have thought that  JBPM Console is the ubiquitous remote runtime engine for rules and business process. We have found that out the box the JBPM Console among other limitations, doesn’t use or leverage Spring, Camel, etc.

      One would have expected JBPM Console to be built on top of Drools Server (which is Spring and Camel ready), and Drools Server to be a production ready runtime engine. But it turns out JBPM Console in an old project not related to Drools Server and out of the box the Drools Server doesn’t seem to deal with business process persistence, dynamic creation of statefull  ksession per request/user, etc.

      Having dynamic creation of statefull ksession per request (i.e. per business process instance) is a must when you are using business processes that include Rule Tasks components since facts related to a particular request must be persisted to be used later in a long running business process. However, we have found JBPM Console uses and reuses the same SessionInfo record for different process instance, and Drools Server’s documentation only talks about statically defined ksessions inside the Spring configuration file.

      Is there a production ready runtime engine able to run long running/persistent business processes that include Rules Tasks components (these also require rules-facts persistence)?

        • 1. Re: Runtime engine: JBPM Console or Drools Server?
          xmithj

          Hi J W,

           

          I don’t think these applications are intended to be the ubiquitous jbpm/drool runtime engine, at least not at the current time. I believe their purpose is to show case what is possible to achieve with the framework.

           

          As you said, when you have business process with Rules Tasks you need to be able to create a knowledge session per request. These ksession will persist/serialized the rule-facts to be evaluated inside the Rules Tasks components. So don’t create static ksessions in your configuration file. I would suggest you create your own war file that exposes your services and per invocation you dynamically create a ksession (using the framework api). The out of the box persistence mechanism should take care of the rest.