Section on initializing the work is not clear to me

[grossdan]

After describing how to turn the greeting function into a workflow the next section is not clear to me.

it describes code to initialize a client, a worker that gets a client as argument, and registration of a workflow – there is also mention of queue …

Those concepts are still disconnected in my mind – no effort has been made yet to show a conceptual diagram that links these – so how these relate and who they are used to execute workflows is unclear.

Here is what i think may be the case:

1. control must be inverted – i.e. the temporal server must workflows and tasks.
2. workers seem to be the processes that receive (or poll) execution requests
3. workers use clients to communicate with the temporal server
4. a client is passed to the workers.
5. the greeting function is a workflow – which is a bit unclear – its one task “atomic” task – why is it used to illustrate a workflow.

I would have declared at workflow and two steps to have something mininal to explain

all clarifications are much appreciated.

Dan

[tomwheeler]

HI Dan,

Thanks for your message. I created the Temporal 101 with Go course.

My approach to designing it was to avoid overwhelming someone learning Temporal by introducing too much at once. Instead, I aim to briefly introduce the main characters (Workflows, Workers, Temporal Server, Task Queue, Temporal Client, and so on) and briefly explain their role. As the course progresses, I begin to show how those things interact with one another. This culminates with a code walkthrough near the end that illustrates what’s happening behind the scenes for a Workflow Execution that you run during a later exercise.

I encourage you to stick with the course. When you complete it, I think you’ll have a pretty solid understanding of how these pieces work together. In the meantime, here is a quick summary:

• The Workflow Definition is the function that specifies your business logic. That’s the greeting function you reference from the training course, although in a real-world example, a Workflow Definition might specify how to process an online order, provision cloud infrastructure, onboard a new employee, manage customer subscriptions, or something more substantial.
• You use a Temporal Client to communicate with the Temporal Server; for example, to request Workflow Execution. That Temporal Client might be the one built into the temporal command-line tool, the one within the Temporal Web UI, or inside a custom application you’ve created.
• The Temporal Server tracks and manages the Workflow Execution, although it does not execute the Workflow Definition itself. Instead, it manages Task Queues and adds Tasks to them that detail which functions to run. It also manages a log (called an Event History) that documents what has already taken place during a given Workflow Execution.
• The Worker is what actually executes your Workflow Definition. It uses a Temporal Client to poll the Task Queue on the Temporal Server. When the Worker finds a relevant Task (i.e., one that matches what was specified during Worker registration), it will run the function with the input data specified in that Task. Afterwards, the Worker reports the result back to the Temporal Server, which appends the details to the Event History for that Workflow Execution.

Hope that’s helpful and thanks again for your interest in the course,

–Tom Wheeler

[grossdan]

Hi Tom,

Thank you.

I guess my style of learning is top down – i like to see the big picture first and then learn about the details.

I am also a visual learner – so I like to see an architecture diagram, and in this case, likely also an interaction diagram – to help me see how things fit together.

I will continue to review and perhaps try to draw this out …

Edit:

Also, I think it would be very useful to show a “before” and “after” …

How is a temporal workflow coded without temporal and how after – this highlights in a good way to developers how exactly temporal works to assist.

re: My approach to designing it was to avoid overwhelming someone learning Temporal by introducing too much at once.

I think you can trust experienced developer to know how to deal with larger information chunks – it would help me to see a bigger picture quicker.
Dan

[grossdan]

Let me review what you wrote in detail and make comments, ask clarification questions:

Context:

A workflow is a collection of actions performed by persons and/or automated functions, that are orchestrated, in a step by step way, flowchart like, tied together through some (conditional) business logic – there are sequential and parallel paths, loops, as well as conditional branches.

From a technical point of view, a workflow is code that invokes UIs that present work steps to persons and invokes code that automated actions. There is also information passing around invocations.

The information passed around is typically minimal – such as a case id, since workflows are most typically supported by a backend database which holds all relevant information.

re: The Workflow Definition is the function that specifies your business logic.

So, given the above I would expect a workflow function to describe step-by-step action invocations tied together through some business logic.

The workflow code is defined in a workflow application - and this application is not physically transferred to the temporal server but runs on its own application server.

So i expect the workflow application to communicate workflow “intents” with the temporal server through the API.

The temporal server is then responsible for invoking actions according to the workflow logic.

This also means that there must be a “dialog” between a workflow application and the termporal server as so:

The workflow application tells the temporal server to invoke an action.

The temporal server invokes the action and receives a response

The temporal server provides the response to the workflow application.

The workflow application then determines what to do next, based on business logic.

---

To make the following possible, there is a need to register Actions with the temporal server. The actions identifiers are based on the action declarations included in the workflow application. The identifiers are also used by the temporal server to invoke the right action.

Actions could be invoked directly by the temporal server or indirectly via work queues, which is a better approach in asynchronous work environments.

A work queue is basically an inbox – an action checks the inbox to see if work needs to be done.

Its possible that an inbox could queue action requests from more than one executing workflow instance.

Finally, actions receive at a minimum a case id with which they can determine a current state of a case is and then do their action.

–

To ensure resilient execution the temporal server also ensures that action orchestration is resilient to failure, and if a failure occurs in one action it is communicated to the workflow application – who is called upon handing the failure business logic.

Maybe something like this:

[tomwheeler]

You pretty much have it. I want to comment on one thing that you wrote:

From a technical point of view, a workflow is code that invokes UIs that present work steps to persons and invokes code that automated actions. There is also information passing around invocations.

A Workflow does not necessarily involve any sort of UI. Workflows are typically part of a system’s backend processing. The Workflow Execution begins with a request from a Temporal Client, such as the one built into the temporal CLI or one you’ve built into your application (for example, calling the client.ExecuteWorkflow function provided by the Temporal SDK when someone clicks a button in the UI you’ve created). You can then use the Temporal Client to interact with the Workflow while it’s running (for example, sending a request to cancel it) or retrieve its result once it completes.

Here’s a screenshot based on the “Workflow Execution: Code Walkthrough” video near the end of the course. I’ve combined elements from a couple of frames in that video and annotated the image with a few numbers to illustrate the sequence in a static image.

1. A Temporal Client (for example, inside some UI you’ve built) sends a Workflow Execution request to the Temporal Service (labeled here as Temporal Cluster). This results in a new Workflow Task being added to the Task Queue (not shown)
2. The Worker continuously polls the Task Queue on the Temporal Service, looking for work to perform.
3. When the Worker finds the Workflow Task added in step 1, it accepts that Task, which details which Workflow Definition to run and what data to use as input to that function.
4. The Worker then locates the Workflow Definition (based on it having previously been registered with that Worker) and then runs the function as specified in the Task.

Variations of this sequence continue until the Workflow Execution is complete, at which point the Temporal Client from step 1 can retrieve the result returned by the Workflow Definition.