Code walkthrough

As you learned, the Worker executes your Workflow and Activity code, so a Workflow Execution cannot progress unless at least one Worker is running. Launching the Worker creates a new process. Since this example is written in Ruby, you can start the Worker by executing the file.

This method first creates a Temporal client.

Next, it creates a new Worker Entity with that client, the name of the Task Queue, and the Workflows and Activities registered with the Worker.

Running the Worker Entity opens a long-lasting connection to the Temporal Service, which it uses to continuously poll for new tasks. Although the Worker is running, the Workflow is not, so the task queue is empty and the Worker has nothing to do.

One way to start the Workflow is with the temporal command-line tool. This example specifies the name of the Worker's task queue, a user-defined Workflow ID, the Workflow Type, and the input data.

An alternative is to start it from code within your own application by using a Temporal client to call the execute_workflow method with your input.

Regardless of how you start the Workflow, the behavior will be the same: the Temporal Service records a new Event into the Event History of this Workflow Execution. WorkflowExecutionStarted is always the first Event.

As I continue with my explanation, pay attention to the Event History shown on the right. Additional events will begin appearing below this one as Workflow Execution progresses. I won't mention all of them, but I highlight them in yellow when they first appear so they're easier to spot.

The Temporal Service adds a Workflow Task to the Task Queue and records another event, WorkflowTaskScheduled, into the Event History. Its name follows a pattern: when a new Task is added to the queue, the name ends with "Scheduled."

Since the Worker Process has capacity to do some processing work, it accepts this new Task. This results in a new Event, one whose name also follows a pattern. When a Worker dequeues a Task, the Service generates an event whose name ends with "Started."

The Worker Process begins the Workflow Task by invoking the execute method from the Workflow Definition. It continues by running code within this method. In the Ruby SDK, Activity options such as start_to_close_timeout are passed in via key word arguments when executing the Activity.

The Workflow code highlighted here declares a variable that will receive the output of our first Activity and then requests execution of that Activity: GreetInSpanish. Since execute_activity waits for the Activity to complete before proceeding, the result of the activity will be stored in greeting and is immediately ready for our use.

A few important things happen as a result of the execute_activity call. The Worker can't make further progress on the Workflow until the Activity Execution concludes, so it notifies the Service that the current Workflow Task is complete. In response, the Service adds a new Event to the history. The Worker also sends a command to the Service requesting it to schedule an Activity Task.

The Temporal Service creates an Activity Task and adds it to the Task Queue, resulting in a new Event.

Since the Worker Process has capacity to perform additional work, it accepts the Activity Task.

The Worker Entity now invokes the method corresponding to the Activity Definition for the GreetInSpanish Activity.

The Worker then runs the code within the method. In this case, the Activity calls the utility method, which in turn issues a request to the microservice.

This request was successful and the service responds by providing a customized greeting in Spanish.

When the Activity method returns, the Worker notifies the Service that the Activity Task is complete, resulting in a new Event.

In response, the Temporal Service queues a new Workflow Task and records another Event.

When the Worker accepts this new Task, the Temporal Service adds a WorkflowTaskStarted Event to the History.

The Worker continues where it left off by executing the next statement in the Workflow Definition.

It is now time to execute the second Activity, so the Worker notifies the Temporal Service that the current Workflow Task is complete and sends a Command to schedule an Activity Task.

The Temporal Service queues an Activity Task for the second Activity and records an ActivityTaskScheduled Event to the history. Let's take a moment to look at a failure scenario. What happens if the Worker crashes; for example, because it ran out of memory?

You can recover from this by restarting the Worker or launching a new Worker on a different machine. In either case, Temporal will automatically recreate the state of the Workflow up to the point of failure, so progress will continue on from there, as if the Worker never crashed at all.

Activities that completed successfully before the crash won't be executed again; instead, Temporal reuses the values returned by their previous executions.

When the Worker accepts the Activity Task. The Temporal Service adds ActivityTaskStarted to the Event History.

The Worker now invokes the method for the second Activity. As before, it then runs the code within the method, which uses the utility method to call a microservice.

But what if that microservice went offline just before the request? In this case, the request would fail, ultimately causing the Activity method to raise an exception.

The default behavior in Temporal is for a failed Activity to be automatically retried, with a short delay, until it succeeds or is canceled. You can customize this behavior with a Retry Policy.

Through a retry, the Worker invokes the Activity method again, which in turn invokes the utility method and calls out to the microservice.

For this example, let's assume that the service outage was an intermittent failure, so the request made during the retry is successful.

Since the service is now back online, it responds to our latest request and provides the requested farewell message.

When the method returns, the Worker notifies the Temporal Service that the Activity Task is complete.

There are still a few lines of the Workflow code that haven't been run yet, so the Temporal Service adds a new Workflow Task to the queue.

When the Worker accepts this new Task, the Temporal Service adds a WorkflowTaskStarted Event to the history. The Worker continues where it left off, executing the remaining statements in the Workflow Definition.

Once this method returns, the Workflow Task is complete.

Since the Workflow method returned, Workflow Execution is now complete, and the Service adds the final event to its history.

The Worker continues polling for new Tasks, but there is no more work related to this Workflow Execution.

The client application, which has been awaiting the result of the Workflow Execution, will now receive that value.

The Service provides the result to the application, which can process it however it wishes.

And now you've seen what happens during a Workflow Execution.