Output variable on an end event is not exported

Camunda Platform 8 Topics Camunda Platform 8 Workflow Execution
#1

I set an output variable on an end event to indicate the business status of the workflow completion.
The purpose is to capture this in the exporter and mark the flow as SUCCESS/FAILED.
This variable is not being exported (not seen by Kafka exported or Simple Monitor)
Zeebe version 0.25

E.g., the variable workflowStatus is assigned with the value “FAILED”:

<bpmn:endEvent id="Event_0ukr5ax" name="End Failure">
      <bpmn:extensionElements>
        <zeebe:ioMapping>
          <zeebe:output source="= &#34;FAILED&#34;" target="workflowStatus" />
        </zeebe:ioMapping>
      </bpmn:extensionElements>
      <bpmn:incoming>Flow_1nq1k0j</bpmn:incoming>
    </bpmn:endEvent>

Is there any other way to set a variable on a particular path without a service task?

1 Like
#2

I’ve done this in the past by putting a dictionary into the variable payload on creation, and mapping the dictionary into a variable. So:

createProcessInstance(
   'some-process-model-id', {
      resultDict: ['SUCCESS', 'FAILURE']
})

And then map resultDict[0] to the result variable on some subprocess for SUCCESS, and resultDict[1] for FAILURE.

Something like that. Not sure if it will work in your case.

#3

Hi,

Thanks for the quick response.
This suggestion seems to be unrelated to what I need.
I do not have sub-processes - just want the workflow to set a variable indicating the overall workflow completion status.
Then I check this variable in my exporter to know if the workflow operation was successful or not.

It seems like variables on an end event are not being exported.

Can it be that output variables on en end event are only applicable from within a sub-process?

#4

Hey @yoavsal

I think the issue is that output mappings are not evaluated for end events. Only specific elements support output mappings

In the docs it says:

Output mappings can be used to customize how job/message variables are merged into the workflow instance. They can be defined on service tasks, receive tasks, message catch events and subprocesses.
https://docs.camunda.io/docs/product-manuals/concepts/variables#output-mappings

This would also be a philosophical question where do you map/set the variables when the process instance has ended?

Maybe we can go a step back and think about what you’re trying to achieve? Why isn’t it enought to receive the event occurred of the specific end event ?

Greets
Chris

#5

Hi,

Thanks for this clarification.
So, you suggest that the end event’s ‘ElementId’ will be the indication for workflow completion status?
This can work but, still, we want to be able to set several variables describing the end status.

We could use an ‘outcome’ service task that will publish an event with these variables or just set them as variables to be handled by the exporter but adding an extra service task node to each workflow, just for setting variables seems like a waste of resources (a worker will have to handle it), and setting the variables on some element just before the end is not always possible.

I think this is somewhat related to Zeebe Workflows Inside a REST Request/Response - Camunda but in our case, we do not want the caller to ‘wait’ for the result, we are publishing the result from the exporter.

We are looking for a clean way to set the ‘outcome variables’ in the workflow so we can process and publish them in the exporter.

Any suggestion?

#6

My current customer also ran into this problem. Their use case is filtering out order items that are out of stock. So their tried to set an outcome variable at the end of a Multi-Instance Sub-Process. The variable was to be collected into the output collection to allow filtering out items using a FEEL filter expression before iterating over the list again to ship the available items. So this might be worth a feature request.

2 Likes
#7

hi, we bumped into this exact issue today. Any status update on this please ?

#8

Hi,

For what it’s worth, our solution was adding a Timer Event with a zero delay (PT0S) right before the End Event and setting the desired outcome variable using this object.

This at least gave us a standard convention for creating workflow return value

Yoav

1 Like
#9

Nice hack!