Workflows for orchestration in GCP - Step-by-Step Execution

Process Flow - Workflows for orchestration

Start Workflow

↓

Execute Step 1

↓

Check Step 1 Result

↓

Execute Step 2

↓

Check Step 2 Result

↓

Execute Step 3

↓

End Workflow

The workflow starts, executes steps in order, checks results, and handles errors before ending.

Execution Sample

GCP

start:
  call: http.get
  args:
    url: https://example.com/api
  result: response

next:
  switch:
    - condition: ${response.status_code == 200}
      next: success
    - condition: ${true}
      next: failure

This workflow calls an API, checks the response status, and branches based on success or failure.

Process Table

Step	Action	Input/Condition	Result	Next Step
1	Start Workflow	None	Workflow started	Execute Step 1
2	Execute Step 1	Call API https://example.com/api	Response status 200	Check Step 1 Result
3	Check Step 1 Result	response.status_code == 200	True	Execute Step 2
4	Execute Step 2	Process data from API	Data processed successfully	Check Step 2 Result
5	Check Step 2 Result	Processing success	True	Execute Step 3
6	Execute Step 3	Finalize workflow	Workflow finalized	End Workflow
7	End Workflow	None	Workflow completed successfully	None

💡 Workflow ends after all steps succeed without errors.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
response.status_code	undefined	200	200	200	200
data.processed	false	false	true	true	true
workflow.state	started	step1_done	step2_done	step3_done	completed

Key Moments - 3 Insights

Why does the workflow check the response status after calling the API?

Because the workflow needs to decide the next step based on success or failure, as shown in execution_table row 3.

What happens if the response status is not 200?

The workflow would follow the failure branch to handle errors, but in this trace, it proceeds because the status is 200 (row 3).

How does the workflow know when to end?

It ends after the last step completes successfully, as shown in execution_table row 7.

Visual Quiz - 3 Questions

Look at the execution table, what is the response status after Step 1?

A 404

B 500

C 200

D undefined

💡 Hint

Check the 'Result' column in row 2 of the execution_table.

At which step does the workflow decide to proceed to Step 2?

A Step 1

B Step 3

C Step 5

D Step 4

💡 Hint

Look at the 'Next Step' column in row 3 of the execution_table.

If the API response status was 500, what would happen in the workflow?

A Handle Error after Step 1

B Proceed to Execute Step 2

C Skip Step 2 and Step 3

D End Workflow immediately

💡 Hint

Refer to the concept_flow where failure after Step 1 leads to error handling.

Concept Snapshot

Workflows run steps in order, checking results after each.
They branch on success or failure to handle errors.
Each step can call services or process data.
The workflow ends when all steps succeed or an error is handled.
Use conditions to control flow and ensure reliability.

Full Transcript

This visual execution shows how a Google Cloud Workflow runs steps one by one. It starts by calling an API, then checks if the response was successful. If yes, it processes data and finalizes the workflow. If any step fails, it handles errors accordingly. Variables like response status and workflow state update after each step. The workflow ends only after all steps succeed or an error is handled. This helps automate tasks reliably by controlling the flow based on results.

Practice

1. What is the main purpose of Google Cloud Workflows?

easy

A. To store large amounts of data securely

B. To automate and coordinate multiple cloud services in a sequence

C. To create virtual machines for computing

D. To monitor network traffic in real-time

Solution

1. Step 1: Understand the role of Workflows

   Workflows are designed to automate tasks by connecting different cloud services step-by-step.

2. Step 2: Compare options with this role

   Options B, C, and D describe storage, computing, and monitoring, which are not the main purpose of Workflows.

3. Final Answer:

   To automate and coordinate multiple cloud services in a sequence -> Option B

4. Quick Check:

   Workflows automate cloud tasks = A [OK]

Hint: Workflows connect services step-by-step to automate tasks [OK]

Common Mistakes:

• Confusing Workflows with storage or compute services
• Thinking Workflows monitor network traffic
• Assuming Workflows create virtual machines

2. Which of the following is the correct way to start a step in a Google Cloud Workflow YAML?

easy

A. steps:

B. start:

C. main:

D. execute:

Solution

1. Step 1: Recall the YAML structure for Workflows

   The main entry point for a workflow is defined under the main: key.

2. Step 2: Check other options

   Options like steps:, start:, and execute: are not valid top-level keys for starting a workflow.

3. Final Answer:

   main: -> Option C

4. Quick Check:

   Workflow starts with main: in YAML [OK]

Hint: Workflows start with main: block in YAML [OK]

Common Mistakes:

• Using steps: instead of main:
• Confusing start: as the entry point
• Trying execute: which is invalid

3. Given this snippet of a workflow YAML:

main:
  steps:
  - call: http.get
    args:
      url: "https://example.com/api"
  - return: ${steps[0].body.status}

What will the workflow return if the HTTP GET response body is {"status": "success"}?

medium

A. "success"

B. {"status": "success"}

C. An error because of wrong syntax

D. null

Solution

1. Step 1: Understand the call and return steps

   The first step calls an HTTP GET and stores the response in steps[0]. The second step returns the status field from the response body.

2. Step 2: Extract the status value from the response

   The response body is {"status": "success"}, so steps[0].body.status is "success".

3. Final Answer:

   "success" -> Option A

4. Quick Check:

   Return status field from HTTP response = "success" [OK]

Hint: Return uses ${steps[index].body.field} to get JSON values [OK]

Common Mistakes:

• Returning the whole body instead of the status field
• Syntax errors in accessing steps array
• Assuming null if not parsed correctly

4. Identify the error in this workflow snippet:

main:
  steps:
  - call: http.get
    args:
      url: "https://example.com/api"
  - return: steps[0].body.status

medium

A. Missing quotes around the URL

B. Incorrect indentation of steps

C. http.get is not a valid call

D. Missing ${} around the expression in return

Solution

1. Step 1: Check expression syntax in return

   In Workflows YAML, expressions must be wrapped in ${} to be evaluated.

2. Step 2: Verify other parts

   Indentation is correct, http.get is valid, and URL is quoted properly.

3. Final Answer:

   Missing ${} around the expression in return -> Option D

4. Quick Check:

   Expressions need ${} to evaluate in return [OK]

Hint: Wrap expressions in ${} to evaluate in workflow YAML [OK]

Common Mistakes:

• Forgetting ${} around expressions
• Misaligning YAML indentation
• Assuming http.get is invalid
• Not quoting URLs

5. You want to create a workflow that calls two APIs in sequence, but only calls the second API if the first returns status "ok". Which workflow feature helps you implement this conditional logic?

hard

A. Using switch or if steps to check the first API's response

B. Using parallel steps to call both APIs at the same time

C. Using retry to repeat the first API call until status is ok

D. Using return to stop the workflow after the first call

Solution

1. Step 1: Understand conditional execution in workflows

   Workflows support switch or if steps to decide which steps run based on conditions.

2. Step 2: Match the requirement

   To call the second API only if the first returns "ok", use if or switch to check the first response before proceeding.

3. Final Answer:

   Using switch or if steps to check the first API's response -> Option A

4. Quick Check:

   Conditional steps use if/switch to control flow [OK]

Hint: Use if or switch to run steps conditionally in workflows [OK]

Common Mistakes:

• Using parallel steps which run both APIs simultaneously
• Using retry which repeats calls but doesn't conditionally run next
• Using return which ends workflow early