Hi all,
I am trying to use the engine with the history level set to none, and I am having trouble a) making sure that the process completed normally and b) retrieving the final value of a process variable from the process instance. The code I use looks like this:
ProcessInstance instance = _processEngine.getRuntimeService().startProcessInstanceByKey(...);
if (instance.isEnded()) {
// how do I check for normal termination, i.e. reaching an end event, as opposed to a
// canceled process for example?
return ((ExecutionEntity)instance).getVariableInstance(variableName).getValue();
}
… and I would like to avoid the downcast to ExecutionEntity: is there a way to navigate to the instance’s execution without going through queries (which don’t return anything because history level is NONE)?
Thanks!
Franck
Hi Franck,
public void testStartEndProcess() {
ProcessInstance processInstance = runtimeService.startProcessInstanceByKey("StartEndProcess");
assertThat(processInstance.isEnded(), is(true));
assertThat(((ExecutionEntity) processInstance).getExecutions().get(0).getActivityId(), is("theEnd"));
}
Works fine. You want to avoid downcast. You are right, queries are empty because of history level NONE.
One possibility could be to add a listener to the end event which will write variable value and process end state to the structure which is accessible form outside of the process scope (in memory or in the DB). That’s one possibility. I am not saying the best one.
Martin
Thanks Martin, I like the listener idea, I will experiment with that.
Regarding the
((ExecutionEntity) processInstance).getExecutions().get(0).getActivityId(), is(“theEnd”)
suggestion, I see two issues with it:
- is it guaranteed that getExecutions().get(0) will always return the execution in which the end event was reached?
- I don’t know the activityId of the end event (or end events since there could be several), I would need to scan the process beforehand to find that out…
Franck
No it depends on the process instance state and definition
yes, but Ids are specified in the definition.
Martin
Right… so overall the listener approach seems much simpler and more reliable
Thanks!
Franck
May be small improvement could be to add the listener automatically to the end activity during process parsing. In that case you can be sure that nobody will forget it.
https://www.flowable.org/docs/userguide/index.html#advanced_parseHandlers