Hi All,
We have used flowable in our application but our cucumber test are getting failed.
We came to know that we are getting null response at below line:
ProcessInstance XXXXXXXXX = runtimeService.XXXXXXXXXXXQuery()
.superProcessInstanceId(XXXXXXXXXX)
.singleResult()
Can anyone please suggest the solution to it?
Can you please share more of your code? This lines create query, set’s one query parameter and executes that query. If there is no ProcessInstance with the given parameters (superProcessInstanceId) a null response is expected behavior. To create process instances please use the
ProcessInstance processInstance = runtimeService.createProcessInstanceBuilder()
.processDefinitionKey(“someProcessDefinitionKey”)
.start();
Greetings
Christopher
The code looks like this:
@Nullable
public Task method(String var) {
ProcessInstanceQuery var1=runtimeService.method1();
var2=processInstanceQuery.superProcessInstanceId(var);
ProcessInstance var3=processInstanceQuery.singleResult();
if (nonNull(var3)) {
String var4 = var3.getId();
ProcessInstance var5 =
runtimeService.createProcessInstanceQuery()
.superProcessInstanceId(
var3).singleResult();
String var6 = Optional.ofNullable(var5)
.map(ProcessInstance::getProcessInstanceId)
.orElse(var4);
return taskQueryExecutor.getMethod(var6);
}
Hey, so you try to load an existing process instance based on the superProcessInstanceId.
If there is no such process instance it will return null. I need a bit more context 
. How are these processes created,etc.
Greetings
Christopher
It got created as below:
Map<String, Object> var = new HashMap<>();
var
.put(ProcessVariables.TopLevel.INIT_DATA, objectMapper.writeValueAsString(var1));
processInstanceVariables.put(ProcessVariables.TopLevel.XXXXXX, var1.getXXXXXX());
var.put(ProcessVariables.TopLevel.YYYYY, var1.getYYYYY());
String var1 = runtimeService
.startProcessInstanceByKey(ProcessType.ZZZZ.code(), var)
.getProcessInstanceId();
Hey @WelschChristopher, I need to add a few comments on the above description.
There was a framework upgrade from Activiti in version 5.2.2, into the Flowable version 6.7.2. Our system has a main process definition which consists of a few minor sub processes.
The problem which we face now is that previously, in Activiti 5.2.2, when we used such API call:
runtimeService
.createProcessInstanceQuery()
.superProcessInstanceId(firstLevelCallActivityProcessInstanceId)
.singleResult();
we were getting a process instance object, while now, after the upgrade, that query is returning a null value, causing later on problems with collecting tasks out of that processes. There were not changes on the processes definition after the upgrade.
I’ve verified how that processes are getting loaded and this is working in the same way as it was in Activiti 5.2.2., the only difference which I’ve noticed is that now processId is represented by an UUID, while earlier it was just a standard int number, not sure if that might be any source of the problem though.
Is there any way in which I could verify while the processes definition is loaded and they seems to be missing a pointer for a main(super) process instance?
Hey @WelschChristopher could you please help us in giving some solution to the issue?
Hey @michalmytnik,
this shoul work after the migration from 5. to 6 .
Greetings
Hello @WelschChristopher, thanks for the reply.
So I’ve debug that more, and this is looking really strange. We didn’t change any processes definition, but after the upgrade debug shows that after we start our main process by that line of code:
runtimeService
.startProcessInstanceByKey(ProcessType.ZZZZ.code(), var)
.getProcessInstanceId();
it loads correctly the main process definition, enter the first Java Delegate, execute that, and immediately skip out of the process (breakpoint in debug on the second Java Delegate is never invoked) and goes into another line of code instead, which is adding an EventListener.
When I run that in debug based on Activiti 5.2.2, this is also loading the main process, starting that, but instead of executing only the first delegate and jumping out, immediately executes also second delegate, and entering the third step in business process, which is in another subprocess, creating there a user task, and finally executes the Event Listener addtion.
I don’t know if we need to change anything in our bpmn files definition after upgrading from Activiti 5.2.2. for Flowable 6.7.2, I actually have tried to replace all the namespaces from “activiti” to “flowable”, but it doesn’t solve the problem.
In addition, when I ask in debug runtimeService about active processes list, after the upgrade for Flowable it shows only 1 active process which is our main process. While query for the same in Activiti 5.2.2 it shows 3 active processes, one is the main process, second is the first subprocess , and third is the first user task inside that subprocess.
That looks like there is some problem in the execution of chain of the process definition steps, but it’s hard to determine what is causing that. There are not exceptions while loading BPMN files, not any other which could advise on that.
Hey @michalmytnik,
the problem you describe does not ring a bell. If there is some commonly issues with the migration, it would occure quite often. Especially considering the time since first flowable 6 release. Can you share your model/parts of the model, or even better a reproducable unit test?
Greetings
Christopher
Hello @WelschChristopher , thanks for the reply.
After a long investigation and debugging I found what was the root cause of the problem. Our process contains some async Delegates Invokations, which were working 100% fine on Activiti 5.2.2, tests has been written with assumption that even if the Delegate is marked as async task it would be extecuted immediately when the process is started. After changes introduced in Flowable it doesn’t work in that way, so was never able to “catch” a breakpoint in the second (async) Delegate just after the process started, it was processing remaining code, and tests immediately got red.
I’ve changed the process definition a bit, removed async flag from Delegates and seems to be promising now.
Thank you for your support, appreciate that.
That point is quite odd: when a task is marked as async it will never be executed immediately. It’s very odd this worked all the time correctly, as theoretically this shouldn’t have been the case.
That was shock for me too, but literally, debugging proofs that an async Delegate Task has been always completed in Activiti, before the next line of code ( after process start ) has been invoked. After switch to Flowable it started to be a real async and then I’ve got all the test failing. Not sure where/how to check the real difference here. When i remove an async flag now it works as before.