1 of 1 people found this helpful
processes can have wait states such as human tasks and then they are resumed when task is completed. There is no really special things to do there, when process is in wait state it needs to be signaled to move on and the types of signals depends on what wait state it is on. It could be waiting for special event (like message, signal, condition) or on work item completion (like in case of human task). Ksessions are then stored in db so they can be reloaded when required, that is handled by RuntimeManager and RuntimeEngine.
If I build my environment like
RuntimeEnvironment environment = RuntimeEnvironmentBuilder.getDefault()
RuntimeManager manager = RuntimeManagerFactory.Factory.get().newSingletonRuntimeManager(environment);
RuntimeEngine runtime = manager.getRuntimeEngine(EmptyContext.get());
KieSession ksession = runtime.getKieSession();
Assume that there are 2 instances of this process definition. Where can I tell the runtime which of this processInstances should be restored?
If you have a singleton Runtime Manager that means that both process instances are running in the same session. So the runtime manager will know what needs to be restored (because there is just a single session).
Notice that you are using an EmptyContext.get(), which means that for singleton there is no need to provide the runtime manager anything to locate the correct session.
If you use another strategy for example Per Process Instance you will need to provide the business key (or the process instance id) that will let the runtime manager know which session needs to be restored.
OK, if I use the per process instance strategy I have to know the process instance ID to reload a session. Sadly I can't find out how I get all running process instances. How can I get this information?
1 of 1 people found this helpful
What we are doing inside the jbpm console is to use the audit log to list all the active/completed processes. If you are embedding jbpm into your application you maybe want to copy that strategy. Look at this backend service implementation for getting some ideas about how to do that: https://github.com/droolsjbpm/jbpm-console-ng/blob/master/jbpm-console-ng-business-domain/jbpm-console-ng-business-domain-backend/src/main/java/org/jbpm/console/ng/bd/backend/server/DataServiceEntryPointImpl.java
and more importantly this one:
I have created a per process instance session of a process. Then I closed my application.
Afterwards I started my application again and reloaded the session by using singleton strategy (just because I was curious).
I noticed that the original per process instance session was reloaded as singleton session. Should that be possible?
After all those are Runtime Strategies (they take effect on runtime), I wouldn't suggest to mess around with that. but as you mention you can do it.
In JBPM Console you can deploy projects with the three familiar strategies (singleton, per request and per process instance).
What happens if there are two projects deployed. Both use the singleton strategy. Do the processes of both projects share one session or are there two sessions (one session for each project)?
Assume that there are two projects deployed with singleton strategie. Each project contains one process defintion. If there has been created two singleton sessions that would be the same than deploying one project with strategie per process instance which contains two project definitons. In that case every process would run in it own session. Is this correct?
for each line in the deployment list there is a runtime manager.. so your assumption is correct. If you deploy two projects with singleton there are two runtime managers.
If you want to multiple process definitions run into the same session they will need to be in the same project.