cancel
Showing results for 
Search instead for 
Did you mean: 

Ended process?

oconnor0
Champ in-the-making
Champ in-the-making
I'm learning Activiti & had a question about determining whether or not a process has ended.

I have a unit tests that runs thru the tasks in a process. It then calls ProcessInstance.isEnded() which returns false seeming to indicate that the process instance has not completed.

But if I perform a historical process instance query, that process has an end time.

Is this expected behavior? It seems confusing.
6 REPLIES 6

ronald_van_kuij
Champ on-the-rise
Champ on-the-rise
I you reload, or try to reload, the processinstance from the database before doing the last isEnded() you'll see that that it is not there anymore.

Yes, this is kind of confusing, but there is no guarantee that the process is ended in the same thread, so the behaviour you see is 'nomal' but indeed kind of illogical in a sense

oconnor0
Champ in-the-making
Champ in-the-making
I you reload, or try to reload, the processinstance from the database before doing the last isEnded() you'll see that that it is not there anymore.

Yes, this is kind of confusing, but there is no guarantee that the process is ended in the same thread, so the behaviour you see is 'nomal' but indeed kind of illogical in a sense

To make sure I understand:

If I attempt to load the completed process instance via RuntimeService.createProcessInstanceQuery(), I will be unable to find it because it's been removed from the current process instances & into historical (assuming historical is turned on)?

The absence of that process instance is an indication that it has completed.

Is an historical query the only way via the API to determine how that process instance completed?

Under what conditions does isEnded() return the correct answer?

gokceng1
Champ in-the-making
Champ in-the-making
I you reload, or try to reload, the processinstance from the database before doing the last isEnded() you'll see that that it is not there anymore.

Yes, this is kind of confusing, but there is no guarantee that the process is ended in the same thread, so the behaviour you see is 'nomal' but indeed kind of illogical in a sense

To make sure I understand:

If I attempt to load the completed process instance via RuntimeService.createProcessInstanceQuery(), I will be unable to find it because it's been removed from the current process instances & into historical (assuming historical is turned on)?

The absence of that process instance is an indication that it has completed.

Is an historical query the only way via the API to determine how that process instance completed?

Under what conditions does isEnded() return the correct answer?

I find this situation absolutely confusing too.
Absence shows ending but not vice-versa, a process might be ended but may not be removed from runtime table. Also historical query's unfinished/finished methods shows this behavior. You can use native queries for end time nullity to be sure.

frederikherema1
Star Contributor
Star Contributor
The  ProcessInstance.isEnded() only works if the API-call you just did actually ended the workflow (eg. startWorklfow of a workflow with NO wait-states in it and NO async behavior). Please remember that the object you get back from our API is detached and is only a representation of the workflow at the time you did the actual call. Any later mutations to the process by other API-calls or internal job-threads are not reflected on the detached ProcesInstance entity.

As ronald says, if you want to make sure a process is finished NOW, use the runtimeService.query(..) to see if it returns a process-instance.

ronald_van_kuij
Champ on-the-rise
Champ on-the-rise
Maybe a runtimeService.isEnded(procId) as a convenience method?

frederikherema1
Star Contributor
Star Contributor
That's an option Ronald, however, without history enabled we cannot be 100% sure a process is ended or has never existed in the first place. So returning true based on the existence (or absence) of a runtime-process instance is not a safe bet. We also cannot rely on the history being on, so I guess this is a judgement-call that needs to be done by the user of the API.