Obtaining process instance variables as soon as process instance completes

We have some process definitions that do not have any user tasks. These processes are executed using the REST API (https://docs.camunda.org/manual/7.3/api-references/rest/#process-definition-start-process-instance). I wonder in what situations the ended flag can be false. Is it only in the case if a process instance requires user input? If it is not guaranteed to be true all the time for process instances that have no user tasks, what would be the best way to obtain process instance variables as soon as the process instance finishes.

Hi mmiliauskas,

You can attach an ExecutionListener to the end of a process instance to get the output at the proper time
See below link
https://docs.camunda.org/manual/7.5/user-guide/process-engine/delegation-code/#execution-listener

1 Like

I suspect that if your process uses an asynchronous continuation, your start process call will return when the asyc continuation is reached. In this case, the ended flag should be false. You could consider a user task as implicit async continuation, but you can also declare a task as an explicit async continuation.

Ive considered your requirement. If your use case is you want to implement a function as a process;
Ensure there are no async continuations.
On process completion, store the process variable as thread local variable.
Use a wrapper component to call the start process, when control returns, extract the thread locals and re-package as a function call response…

regards

Rob

1 Like

Starting with 7.6.0-alpha2, there is an API method for this use case, see http://stage.docs.camunda.org/manual/latest/user-guide/process-engine/process-engine-concepts/#variables-in-return

Cheers,
Thorben

2 Likes

@Webcyberrob You mean ThreadLocal Java Class, Right?
or some thing else?

Hi,
actually I was being a little non-specific. Your choices are something like;
In the process model write values out to a well known location eg file store, then retrieve them in your wrapper component.
You could use native operating system thread local storage.
You could potentially use java ThreadLocal…

regards

Rob