-
1. Re: What runtime manager strategy to use for user submitted workflows?
ndsharma Aug 14, 2014 5:22 AM (in response to ndsharma)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 .addResource(ResourceFactory.newClassPathResource("MyProcess.bpmn")) .build(); 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.
Cheers
-
2. Re: What runtime manager strategy to use for user submitted workflows?
krisverlaenen Aug 29, 2014 10:50 AM (in response to ndsharma)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.