2 Replies Latest reply on Aug 29, 2014 10:50 AM by Kris Verlaenen

    What runtime manager strategy to use for user submitted workflows?

    Nitish Sharma Newbie


      We are working on an application in which a user can design his own workflow (in a web-ui) and then submit it for execution. We have chosen jBPM as our execution and workflow manager engine. The user submitted workflow will be translated to a jBPM (bpmn2) workflow. Since this is a multi-user application, supporting concurrent workflows execution is a primary requirement. To facilitate that we are building jBPM on top of storm, where, for instance, each submitted workflow will execute in a separate bolt.

      Now the question is what kind of strategy to use for runtime manager - singleton, per request, or per process. Singleton seems to be the most suitable one; all the bolts sharing same runtime engine. But we couldn't figure out from the documentation how to dynamically add processes to a singleton runtime environment. Creating a new runtime environment for every workflow submitted doesnt seem to be right.

      Any suggestions are highly appreciated.



        • 1. Re: What runtime manager strategy to use for user submitted workflows?
          Nitish Sharma Newbie

          Okay, going through the docs again we figured out that it makes sense to user per process instance that instructs runtime manager to maintain a strict relationship between kie session and process instance. Although after looking at couple of more examples and code snippets we are confused on what is the correct approach to get a KieSession instance. So far we have seen two approaches:



          # Get a new KieBase and KieSession for every workflow submitted.
          KieHelper kieHelper = new KieHelper();
          KieBase kieBase = kieHelper
          KieSession ksessionFromBase = kbase.newKieSession();



          # using same manager instance for all workflows; get a new session
          manager = (RuntimeManager) applicationContext.getBean("runtimeManager"); # per process instance runtime manager
          RuntimeEngine engine = manager.getRuntimeEngine(ProcessInstanceIdContext.get());
          KieSession ksessionFromEngine = engine.getKieSession();


          In first approach, we need to create new kiebase and kiesession for every workflow submitted. Also this approach doesnt use runtime environment or runtime manager or runtime engine. In second approach, we create a per-process-runtime-manager and get a new session out of it for every workflow submitted. But with this approach we dont know how to add a process definition dynamically.

          In conclusion, the first approach seems to do the trick but we dont even know if thats correct approach or not. Moreover, the documentation leans towards the usage of runtime manager and we dont really know the advantage/disadvantage of not going through that route and above that the issue of adding a process definition.

          Any clarifications would be highly appreciated.



          • 2. Re: What runtime manager strategy to use for user submitted workflows?
            Kris Verlaenen Master

            The runtime manager allows you to more easily create a session, preconfigured with a task service and listeners, etc.  This is recommended, and underneath is kinda using the same approach as your first example (but it does do a lot more for you out-of-the-box).


            Regarding changing processes, you should consider using a different runtime manager per project or even per version of the project you would like to deploy.  For example, say you have a process and would like to start using that, so you create version 1.0 of your project and instantiate a runtimeManager for that.  If you later would like to push changes to the process, you could create v1.1 of your project and create a new runtime manager for that.  If you are not planning to use v1.0 you can dispose the old runtime manager.  If you don't manage different versions of your project like that, you would otherwise get into problems with migrating existing process instances, as they might still need your old processes.