How to handle the next task

Greetings. I’ve downloaded the go example from and I’ve reproduced the example as demonstrated. The workflow stops after completing the first task. What does it look like in the go client for the token to move on to the next task? Do you have a go client example of the token advancing through the sequence of tasks and of handling the exclusive gateway and of reaching the end? Thank you.

Hi @kwalker17,you need to assign distinct task-types to each of the tasks, then implement workers that handle those task types.

So, for example, set the task-type of the Fetch Items to fetch-items, then instantiate a worker for it in your code base. You would add a line after:

jobWorker := client.NewJobWorker().JobType("payment-service").Handler(handleJob).Open()

that has:

fetchItemsWorker := client.NewJobWorker().JobType("fetch-items").Handler(handleFetchItems).Open()

And implement handleFetchItems. The simplest implementation would be:

func handleFetchItems(client worker.JobClient, job entities.Job) {
     jobKey := job.GetKey()
     log.Println("Fetching items for", jobKey)
     // Business logic goes here
    request, err := client.NewCompleteJobCommand().JobKey(jobKey).VariablesFromMap(variables)
     if err != nil {
         // failed to set the updated variables
         failJob(client, job)

Now, when you run your program it will create two workers that service the first two tasks. You will see the token advance in the broker state as your new worker pulls tasks of the fetch-items type and processes them.

Then do the same thing for the third task, Ship Parcel - assigning a task-type, implementing a handler, and instantiating a worker.

In an actual system you might make these completely separate programs running on their own nodes, to allow different parts of your system to be scaled at different rates, or you may not - and I don’t recommend it initially while you are getting your head around how Zeebe works.

Once you’ve done the same thing again to implement the third task type for Ship Parcel, your workflow instances will go all the way through the workflow.

There is no exclusive gateway in the example workflow in that section of the docs. But if you modify the workflow to add one, like this:, then you just need to implement workers for any additional tasks that you add.

Hope this helps,

Hello @jwulf and thank you so much for the guidance on how to proceed. Your instruction was perfect. I have the happy scenario working. Next I’ll sort out how to use a gateway.

Is there any API documentation, i.e., something that provides an overview of the commands?

If I were to make a separate program for each task to run on separate nodes, what would the program look like? Would we deploy the workflow in each program? Or is there a command that looks for an already deployed workflow?

All the best,

1 Like

For API documentation for the Go client, the best source is your IDE intellisense and the source code (for example:

For workflow deployment, in the JavaScript library I have written a convenience method for this, to check if a workflow is deployed already. (See:

At the moment, the gRPC method that it relies on has been removed, so as it stands at the moment, this will stop working in the next release 0.18.

Please vote on this issue with a +1:

If this is implemented, you can just deploy the workflow in all your task worker programs, and it will only deploy if it is not already deployed.

That is the easiest way to get started - deploying in each program - but, as it stands at the moment, it will deploy a new version of the workflow each time. That is not a big deal for development and experimentation.

Does this make sense?

1 Like