1 Reply Latest reply on Aug 4, 2014 3:21 AM by Maciej Swiderski

    Can process definitions be persisted with only the jBPM engine?

    John McCarthy Newbie

      Hi everyone.  This is my first post, so let me say thank you to you all for your efforts on jBPM (& drools) as well as the community support.


      I'm investigating using the jBPM engine in isolation without the workbench.  I've got the engine up and running thanks also in part to the spring support coming in jBPM 6.1.


      I'm looking into persistence right now.  I know process instances are persisted, but can process definition also be persisted through just the jBPM engine?  It looks like this is supported, but I'm struggling to figure out how to configure this.  From the user guide (Section 8.1 Process Instance State),

      Also, the process definitions themselves, and the history information (logs of current and previous process states already) can also be persisted.

      The rest of the chapter discusses process instance and history information persistence but not process definitions.

      I've seen a number of different posts including how to deploy processes in jBPM 6? which discusses how the workbench now uses maven to manage process definitions and Clustering in jBPM v6 which discusses using git for asset management including process definitions.  There's also How to store process definition to the database in jBPM5? which is similar to what I'm interested in for jBPM 6.  In that discussion, a DMS such as Alfresco was mentioned.

      Currently, I'm using the RuntimeEnvironmentFactoryBean to load a bpmn file at startup.  I'd like to have something more dynamic where processes can be added and removed at runtime, backed by some form of persistence or asset management.  I recognize this isn't the typical jBPM operating model.

      Any feedback would be appreciated.



        • 1. Re: Can process definitions be persisted with only the jBPM engine?
          Maciej Swiderski Master

          jBPM 6 recommends use of maven jars as the components that contain knowledge assets (process definitions, rules, etc) and makes sure it can properly manage it from versioning and isolation point of view. If you don't need such capabilities you can make use of your own way of working with assets and add/remove them on your own. RuntimeEnvironment allows to give KieBase prebuild and by that disable auto build of the kbase so you can load your assets from whatever location add them to kbase and then use that kbase to bootstrap RuntimeEnvironment