I am basically looking to generate UUID while an element is being activated (i.e. input parameter, something like “=uuid() : requestId”). is there a way to generate UUID (without having to use a service task)?
Thanks,
Sateesh
Hi @mrsateeshp,
Thank you for raising this up.
Currently, there is no way to generate a UUID without a job worker.
Please share more details about your use case.
Why do you need a UUID?
Where do you want to use it?
Did you think about an alternative solution/model?
Best regards,
Philipp
we are basically trying to externalize task execution(because we have our own), so my workflow simply sends a request to a queue and waits for the response (UUID being the CorrelationId). I would ideally want the workflow to generate/control that UUID if possible.
Thank you for sharing.
Generating a UUID can be tricky. But it could be an option to expose the key of the workflow instance and/or the key of the element instance to expressions. The keys are unique in the Zeebe cluster.
What do you think?
Thanks Philipp, I think they come handy generally in many different use cases and would help as alternative for UUID to some extent (i.e. as long as there is only one instances of zeebe cluster per environment).
along with workflow instance key, workflow key & process Id would be good to have.
Regards,
Sateesh
This is basically a synchronous wait. So you could put the UUID into the variable payload when you create the process instance, then correlation is message name + UUID using standard message correlation.
You don’t need to scope it down to the element, because the message name and the UUID in the payload are sufficient to uniquely identify it in the process model.
If you wanted to generalise it, you could put the message name as a header in your “send to external executor” task instance. Then your “send to external executor” job worker takes the header and merges it with the payload. When the external task execution completes, then the return message has the name from the header and the UUID from the variable payload.
Even if you mapped a UUID into the payload via a FEEL expression in an input mapping, I think you would have to put both the send task and the receive message task into a subprocess and do the input mapping on the subprocess, no?
So your model complexity would be equivalent either way - you’d have to either put these async/await patterns in subprocesses with an input mapping, or put the return message name in the header of the send task, and have your queue worker add it to the external service payload.
The benefit of the task header approach is that you can do that now.
This externalised async queue with synchronous wait in the model is discussed in this post: How do I structure a system with Zeebe and RabbitMQ?
this works only if there is only one service task in a workflow, and also this does not handle “retry” of “send request”.
subprocess is not mandatory, i could expose the generated UUID as output variable to merge it into the workflow payload which will then be used in the “wait task”.
1 Like
this works only if there is only one service task in a workflow, and also this does not handle “retry” of “send request”.
Would this not work with multiple service tasks if you follow them with a message catch and make the message name unique, and put the message name as a header on the send service task?
I’m not sure how it doesn’t handle retries?
subprocess is not mandatory, i could expose the generated UUID as output variable to merge it into the workflow payload which will then be used in the “wait task”.
Right, that reduces the complexity somewhat.
The combination of a unique-per-process payload variable and a unique-per-service-task message name in the service task header would be a UUID, no?
If you have a UUID in the process variables, you can generate a UUID for each service task by combining that with the unique ID in the service task header, and message correlation allows you to target the specific message catch event with the response.
Unless I’m missing something?
Like this:
The combination of message name and payloadUUID is unique per instance. It is derived by combining the UUID of the message name, passed via the service task header, and the UUID of the process, which is sent in via the variables when the process starts.
That uniquely identifies an element in the process model for an external system.
Hi Josh, appreciate your inputs & suggestions. please find my thoughts below.
- regarding “retries”, what i meant is, for any reason the same “Send Request” task is executed, it would be ideal not to use the previous request id. I suppose we could make it unique by adding timestamp.
- the proposed solution is valid, 2 concerns:
- it involves too many steps, more places to make mistakes. we have at least 10s of workflows (if not 100s), repeating these steps across the estate seems a lot to ask from developers.
- dependency on workflow-instance-creator(or parent workflow) to supply UUID as input argument for the child workflow does not seem like good encapsulation(UUID is more like a technical, not a business data to pass from one workflow to other). Also most of our orchestration is event driven, message producer does not need to know how the consumer is going to process it. Hence we ideally want the element to generate UUID on its own where required.
Regards,
Sateesh
1 Like