Currently I am trying to access the UUID of a variable instance during runtime.
My bpmn currently contains a sub-process which iterates over an array of “event” objects. The sub-process contains a service task flowing to a user task (user task is just for troubleshooting, will be removed once this is working correctly). For each event I would like to be able to access the variable instance UUID within the sub-process.
I am attempting to use the Delegate Execution in the Service task to achieve this. However, there doesn’t appear to be a way to get to the variable instance UUID directly with the Delegate Execution, which would be ideal.
Is there any way to get the variable instance UUID at runtime inside of my sub-process?
I think that is not easily possible via API. You can make a variable instance query (via delegateExecution.getProcessEngineServices().getRuntimeService().createVariableInstanceQuery()). However, this query will only ever work if the variable is not created in the context of the same process engine command (for the reasons, see this post).
For an internal API workaround, you could do
CoreVariableInstance variableInstance = ((ExecutionEntity) delegateExecution).getVariableInstance("someName")`;
String id = ((VariableInstanceEntity) variableInstance).getId();
As always with internal API, be aware that these methods/classes may change in future Camunda versions.
In my process I am writing results and a subset of data from the event to a DB. However, I thought it would be useful to tie that back to the history which camunda already has in it’s DB. So I wanted to use variable instance UUID to tie the two together.
I imagine there may be a better way to do this but this was the best I could come up with.
@ac13, based on your first post could you just do:
Your “events” are grouped into a “collection”. You pass the collection into a Multi-instance Sub-Process, so that each event gets its own sub-process instance to parse the event and pass it into the DB. In the DB you could store the sub-process instance id and the parent instance ID?
I ask because your original post reminds me of this type of scenario:
Yea I actually tried to use the variable instance query you mentioned however it was not returning the results I expected. The first time I started the process it would return nothing, the second time it would return all the variables from the 1st process that was still running in the user task. After reading the post you linked I think I have a little better understanding of why it didn’t work like I thought it would.
The workaround seems to return what I’m looking for. For the time being I’ll implement that until I can take more time to learn a little more and hopefully implement a solution that isn’t dependent on internal API.
@StephenOTT, It seems that you are correct and I could get both the sub-process instance id and the parent instance ID from the execution during the multi-instance sub-process.
However, I don’t see an easy path to the variable instance with these two ID’s.
My end goal is to be able to call the camunda rest api, specifically, GET /history/variable-instance/{id}
I’ll have to look into your suggestion and see if there’s a Rest call I can make with those ID’s that will get me similar results. Thanks for the help.
Why do you need the specific variable instance ID if each “processing” of the “events” are handled by individual sub-processes? It sounds like the variable instance id would be redundant information?
If you are doing all of your processing against a single variable in a single process, and the variable value kept changing (for example as you looped through each event in a script), then could totally see the use case for pulling the history for the variable as you would want to know what was the data in the variable at the time of processing. But in the Multi-Instance scenario, you would/could have process instances as that identifier. Each “event” would have its own Sub-Process instance and so (depending on what you are doing with your “Events”), the variable would likely only have a single instance/history (the initial creation when the sub-process instance is generated). So it sounds like having the instance history would be redundant for you use case?
I have been working on a “default” list of process characteristics to store in third-party DB when sending data from camunda to another system. So especially interested in your use case as I would start adding Variable instance IDs if there is a good reason/if it was useful for future queries.
@StephenOTT After looking into your suggestions it doesn’t appear that I really need the variable instance UUID since I am actually able to access the variable’s history with just the Sub Process UUID (activity instance UUID of the subprocess) and knowing the name of the variable. Thanks for all the help.