Proper way of passing variables between External Tasks

I am attempting go create a workflow of two simple External Tasks, Task 1 and Task 2. I would like to receive variables from the /start request, then make simple modifications in the worker for task 1, and send those variables in to task 2 as input. I have been unable to find anything demonstrating how this can be done. Can anyone help provide guidance on this? In other orchestration engines, the passing of variables is pretty standard and simplistic, so I’m sure I’m doing something incorrect here.

Follow up question: I notice that when I’m parsing out the variables, I see some odd behavior. The input variables configured on the task are always present, however the variables sent in the JSON request to start the workflow are only present on the first attempt by the worker to process the task. If the task fails, any subsequent attempts do not contain the variables sent in the JSON payload. Is this expected behavior?

There are plenty of examples available at Camunda Consulting · GitHub. Feel free to refer and try it out based on your requirement.

Hi @bdburci,

you have to complete task 1 returning new process variables in the complete command.

Then you will get them in task 2.

Input- and output mapping can be used if you want to change the variable name for the worker (input mapping) or the remaining activities (output mapping). Process Variables |

Hope this helps, Ingo

Thank you for the replies, @Ingo_Richtsmeier and @cpbpm. That makes sense, and I will look at these links you sent over.

Did you have any information on variables sent in via the JSON payload to start the execution? I’m still seeing variables sent in the JSON payload as not persisting if an execution is retried. Is this intended behavior?

This is common issue with C7 due to the execution pattern (complete all tasks until a DB transaction, if any steps fail in this then rollback to last DB transaction).

The workaround (which makes the whole processes async) is to put Async After on your Start element. This forces a write of the variables to the DB immediately on start.

Thank you @GotnOGuts, really helpful explanation. Since you mentioned that this is a common issue in C7, am I to infer that this issue has been resolved in C8?

I haven’t got an opportunity to test it out with C8 yet.
But, the whole “Start a process instance” changes in C8 (along with the execution model), so maybe with a bit of luck it will be different.

Hi @bdburci and @GotnOGuts,

Yes, Camunda 8 handles things differently. There is no RDBS, there are no classical transactions. Hence, there is no problem with rolling back multiple tasks or even further than the start event. Instead, we have at-least-once semantics: A service task may be invoked multiple times and need to be idempotent.