camunda
I can set variables when failing a job
Zeebe is amazing!!!
I want to migrate my previous java Camunda 7 External Task code to Zeebe Job Worker. I'm missing the absolute "must" .variables(...) function in .newFailCommand and newThrowErrorCommand. I was able in Camunda 7 External Task to add (local/global) variables with handleFailure and handleBpmnError functions.
Describe the solution you'd like I can set variables when sending a fail job command.
client.newFailCommand(...).variables(...)
It should set the variables, similarly to the complete job command.
client.newCompleteCommand(...).variables(...)
The given variable should be set as local variables in the scope of the related task. As a result, the next activated job could access the variables.
If the command would set the variables globally then it would need to apply the output mappings of the related task. Applying output mappings could raise an incident and would make the job not activatable anymore.
Hey thanks for trying Zeebe and reaching out @waldimiro !
I think the part of client.newThrowErrorCommand is a duplicate of https://github.com/camunda/zeebe/issues/4337 or https://github.com/camunda/zeebe/issues/4080
Could you please add your comments there and describe your use case please? :)
Regarding adding payload to client.newFailCommand could you define your use case here? What would this look like? And what would you expect at the process execution?
Greets Chris
Hi @Zelldon, I don't have a specific case. It is very important to propagate variables not only on task completition but in failure and throw cases too.
As workaround I'm using zeebeClient.newSetVariablesCommand() in Job Worker... is that correct?
I'm using quarkiverse zeebe.
@ZeebeWorker(type = "test8")
public class Test8Zeebe implements JobHandler {
@Inject
protected ZeebeClient zeebeClient = null;
@Override
public void handle(JobClient client, ActivatedJob job) throws Exception {
try {
client.newCompleteCommand(job.getKey()).variables(Map.of("key1", "value1")).send().join();
}
catch(Exception e) {
// Is that the way to add arbitrary variables to process/task?
this.zeebeClient.newSetVariablesCommand(job.getElementInstanceKey()).variables(Map.of("key2", "value2")).local(true).send().join();
// ... why not add the possibility to add variables in newFailCommand (and newThrowErrorCommand)?
client.newFailCommand(job).retries(0 /* No retries */).errorMessage("This is a fail exception").send().join();
//client.newThrowErrorCommand(job).errorCode("object-not-found").errorMessage("This is a throw exception").send().join();
}
}
}
Hi @Zelldon, I don't have a specific case. It is very important to propagate variables not only on task completition but in failure and throw cases too.
For error thrown I get that, but not for job failure, since you want to retry it. Or is it to persist the intermediate state? :thinking: I think it would be good if you could reason about it a bit better, otherwise, I think the chances are quite low that this will be implemented.
As workaround I'm using zeebeClient.newSetVariablesCommand() in Job Worker... is that correct?
It depends of course what you want to achieve, since I don't know your use case it is hard to tell. If you want to update the intermediate state sounds like a solution yes.
Hi @Zelldon, thanks. About the failure case. Imagine that each time that a job worker is invoked, the glue code starts a task on a system. The system task has a taskId. The system task is "retryable" (thanks the taskId). In case of failure, where can I store the taskId so that by the next retry will "retryed" the correct system task associated with the Camunda process instance? With Camunda 7 was easy to store the taskId in the handleFailure variables. Perhaps you can give me more ideas...
@Zelldon, sorry... another case about the failure case can be: for each retry I want to store the date and based on them, react the next retry... how you see there are not a specific case but give the possibility to store intermediate variables is very important (or... the solution can be through the zeebeClient.newSetVariablesCommand()... but I don't find so elegant - my opinion).
@Zelldon excuse me... I realized that I am trying to convince you that the previous version was very good (Camunda 7 External Worker) :) I ask me why in Camunda 8 the Zeebe Job worker was not implemented based on the previous know how...
@waldimiro thank you for your input :+1: I think it is clear that there are use cases for the variables.
To sum it up, this issue is about supporting the set of variables in the job fail command. The throw error command is covered by #4337/#4080.
A workaround is available: set the variables separately using a set-variables command within the job worker.
why in Camunda 8 the Zeebe Job worker was not implemented based on the previous know how
Zeebe/Camunda Platform 8 is a completely new implementation. But it is still young and doesn't contain all features from Camunda Platform 7. We will add more features eventually. Since we have limited resources, we try to prioritize the work, also based on the user input. We ask for use cases to understand the need and the usage of the feature, and to prioritize it.
@saig0 @Zelldon Thanks! I appreciate a lot your effort!! Again... Zeebe is amazing!!!
Hi, @saig0, I'd love to task this, both for newFailCommand and newThrowErrorCommand ?
@skayliu go for it. :rocket: Only for the job fail command.
The throw error command is covered by the other issues #4337/#4080.
The given variable should be set as local variables in the scope of the related task. As a result, the next activated job could access the variables.
If the command would set the variables globally then it would need to apply the output mappings of the related task. Applying output mappings could raise an incident and would make the job not activatable anymore.
@skayliu does this answer your question?
@saig0, According to this, UpdateVariableDocumentProcessor#L61, the VariableDocumentRecord has a updateSemanticsProperty, If the newFailcommand would set the variables globally then the JobRecord need updateSemanticsProperty too, It's this ok?
I suggest that the job fail command sets the variables only locally. No option to set global variables.
The reason is variable propagation. Similar to the job complete command, we don't set the variable globally but we propagate the variables from the related task to the upper scopes. If the task has an output mapping then the mapping is applied. If the output mappings can't be applied then we would need to create an incident.
This would be more complex. So, I prefer to set the variables only locally in the scope of the task.
This would be more complex. So, I prefer to set the variables only locally in the scope of the task.
Yes, I'm think so to be locally