Hi @Larry , I’d like to offer some guidance:
First, what you are trying to do, adding a variable with a specific scope via the Zeebe client, depends, with the Spring Zeebe Client, it is not yet implemented, could be that I have not seen any example so far. I normally use the Spring Zeebe Client, and an instruction like this:
@ZeebeWorker(type = "write-variables"):
public void writeVariables(final JobClient client, final ActivatedJob job) {
...
Map<String, Object> map = new HashMap<>();
map.put("Message", "Hello World");
client.newCompleteCommand(job.getKey()).variables(map).send(); //This is writing variables to the process
...
}
results in setting the variables in the process scope. The documentation of the command I use, do not mention anything about the scope, see JobClient - zeebe-client-java 8.3.0-alpha1 javadoc
If you use the spring zeebe, then you will need here a workaround :
- Make the subprocess a call activity, the call activity when invoked will have its own scope. You will only need to control the input and output mapping.
You could try without the Spring Zeebe, and use the raw Zeebe client, with it you would use something like this:
Map<String, Object> variablesMap = new HashMap<>();
map.put("text", "Some text");
ZeebeClientBuilder clientBuilder = ZeebeClient.newClientBuilder().gatewayAddress("some address");
ZeebeClient zeebeClient = clientBuilder.build();
zeebeClient.newSetVariablesCommand(1L).variables(variablesMap).local(true).send();
Here you are using this Command SetVariablesCommandImpl - zeebe-client-java 8.3.0-alpha1 javadoc, which has a local method to tell the process if a variable is local. I have not tested this extensively, but it could be what you need. Just remember, this is possible with the raw Zeebe client, not with the Spring Zeebe client. The Spring Zeebe client is just a wrapper around the Zeebe client.
Second, regarding the part “I need to use the Zeebe Client to create variables because I have middleware that checks the variable size before returning it to Camunda.” . I would like more context here, because as it is, sounds like a little misunderstanding of the architecture.
Let me explain, the Zeebe Client is ultimately responsible for sending commands to the brokers,so there is nothing in between the Zeebe Client and the Broker, unless you intercept the request, do something with the intercepted request, and then forward it again to the broker, for which you will need again the client.
I actually think your middleware uses the Zeebe client, and the situation is reduced to the first point.