How to add extended attributes to Zeebe
Can you please explain what you mean by adding extended attributes? Also, what do you want to achieve?
We try to stay as close as possible to the BPMN spec, to keep process definitions interoperable with other engines. To make Zeebe function in the way we think is best, we’ve had to add some extensionElements (e.g.
zeebe:taskDefinition), which we place in the
AFAIK you can add custom extensionElements from other namespaces, but I don’t really see any need for adding custom extensionElements in the
zeebe namespace. Perhaps you have good reasons for it. Can you explain why you would want to do that?
because I want to get the attribute value where I implement io.zeebe.client.api.worker.JobHandler
You can use task headers for this. These are available in the
io.camunda.zeebe.client.api.worker.JobHandler in the
getCustomHeaders() (returns a
I’ve already answered this here: How to record job handle logs - #4 by korthout
This is only the attribute of the service task. I hope that the extended attribute of the whole process, such as bpmnprocessid, can be obtained directly
You can obtain this directly for each ActivatedJob with ActivatedJob#getBpmnProcessId()
What I mean is that I can add a process definition attribute, which can be obtained as easily as bpmnprocessid
Well, that’s a predefined interface method right? Custom values could never be as easy as that. However, we do offer 2 ways to retrieve custom values in your worker: task headers and process variables. Task headers are specific to the task, but you’d rather want a more globally defined value. In that case, process variables seem like a good fit.
Simply create an output mapping on the root-level none start event that sets the variable and consume the variable in the job worker(s) using one of the getVariable methods on ActivatedJob.
Does that help?
I just want to add extented atribute and get process extented define atribute where I implement io.zeebe.client.api.worker.JobHandler,Sometimes the extented atribute value will be very large, I don’t want to set by header or vars，and the atribute not only belong to a header
Sometimes the extented atribute value will be very large
Please note that Zeebe is build to orchestrate workflows, not to store data. Large data will significantly slow down Zeebe. If you have large data, please store it in a suitable data store and use a reference to this data in Zeebe.
I just want to add extented atribute and get process extented define atribute
I’m sorry, but personally I don’t think is a good idea. The reason I don’t think this is a good idea is that zeebe already provides 2 ways to provide data to a job worker: task headers and process variables. If you need process-level scoped data, then output mappings already allow you to define this data at that level and the job worker can easily access it from the job.
However, if you think this is a necessary feature, please feel free to open a feature request on github. Perhaps my team feels different than I do.
I don’t want to set by header or vars
Perhaps you can explain why variables are not suitable to your case
In other words, I want to get some custom attribute values of the specific process definition according to the workflowkey. I need to use this custom attribute value at the beginning or end of the process. In short, this attribute does not belong to a process instance variable or a node taskheader, it belongs to a version of the process definition
Custom Header on a task. You could make your first task in the process a worker that writes the custom header value into the variable payload, to ensure that it is available all the way through the process.
Thanks for your help
Thank you for helping me
Of course, this can solve this problem, but this solution is very strange, because this configuration is relative to the process definition, not the submitted process instance. It’s strange to put the global configuration of the process definition on the first node
It looks like you can use the Input/Output mapping on the Start event. In that case, you use FEEL expressions to assign literal constants to variables in the payload.
yes ，This should be a better solution。