Workflows are not necessarily instantaneous, and executions can span over a long period of time. Some steps may potentially launch asynchronous operations, which might take seconds or minutes to finish, but you are not notified when the process is over. So when you want for something to finish, for example before polling again to check the status of the async operation, you can introduce a sleep operation in your workflows.

Google Cloud Workflows offers a few built-in environment variables that are accessible from your workflow executions.

There are currently 5 environment variables that are defined:

• GOOGLE_CLOUD_PROJECT_NUMBER: The workflow project’s number.
• GOOGLE_CLOUD_PROJECT_ID: The workflow project’s identifier.
• GOOGLE_CLOUD_LOCATION: The workflow’s location.
• GOOGLE_CLOUD_WORKFLOW_ID: The workflow’s identifier.
• GOOGLE_CLOUD_WORKFLOW_REVISION_ID: The workflow’s revision identifier.

Let’s see how to access them from our workflow definition:

So far, in this series on Cloud Workflows, we’ve only used the Google Cloud Console UI to manage our workflow definitions, and their executions. But it’s also possible to deploy new definitions and update existing ones from the command-line, using the GCloud SDK. Let’s see how to do that!

If you don’t already have an existing service account, you should create one following these instructions. I’m going to use the workflow-sa service account I created for the purpose of this demonstration.

Time to do something pretty handy: calling an HTTP endpoint, from your Google Cloud Workflows definitions. Whether calling GCP specific APIs such as the ML APIs, REST APIs of other products like Cloud Firestore, or when calling your own services, third-party, external APIs, this capability lets you plug your business processes to the external world!

Let’s see calling HTTP endpoints in action in the following video, before diving into the details below:

All the workflow definitions we’ve seen so far, in this series, were self-contained. They were not parameterized. But we often need our business processes to take arguments (the ID of an order, the details of the order, etc.), so that we can treat those input values and do something about them. That’s where workflow input parameters become useful!

Let’s start with a simple greeting message that we want to customize with a firstname and lastname. We’d like our workflow to look something like this:

So far, in this series of articles on Cloud Workflows, we have used simple data types, like strings, numbers and boolean values. However, it’s possible to use more complex data structures, like arrays and dictionaries. In this new episode, we’re going to use those new structures.

Arrays can be defined inline (like anArray) or spanning over several lines (like anotherArray):

- assignment:
    assign:
        - anArray:  ["a",  "b",  "c"]
        - anotherArray:
            -  one
            -  two
- output:
    return:  ${anArray[0] + anotherArray[1]}

The output step will return the string "atwo".

So far, in our Cloud Workflows series, we have seen some of the YAML syntax for defining workflows. However, steps are defined after each other, as a series of step definitions, but in spite of the jump instructions, the conditionals, you don’t really see visually what is going to be the next potential step in a workflow execution.

Fortunately, a new UI enhancement has landed in the Google Cloud Console: the ability to visualize a workflow definition with a graph, when you’re editing the definition. Furthermore, the graph is updated in quasi real-time as you make updates to the definition.

In the previous articles about Google Cloud Workflows, we talked about how to assign variables, create expressions, and also how to jump from a step to another. It’s time to combine both aspects to understand how we can do conditional jumps, thanks to the switch instruction.

Let’s start with a first step defining a variable, whose value we’ll use in our switch condition:

- assignement:
    assign:
        - number:  42

Then we’re going to create our second step that will use a switch instruction, with an expression:

Now that we have multiple steps in our workflow definition, let’s see how we can pass data around, from a step to another.

In a step, you can assign values to variables. Those values can be ints, doubles, strings, or booleans (and also null). Use the assign keyword as follows:

- assignments:
    assign:
        - two:  2
        - pi:  3.14
        - message:  "Hello"
        - bool:  True

Those variables are available in the whole scope of the workflow, and can be accessed in other steps. So let’s see how we can do something with those variables. Let’s add a second step to our workflow definition:

Let’s continue our discovery of Goole Cloud Workflows!

Yesterday, we discovered the UI of Workflows. We created our first workflow. We started with a single step, returning a greeting message:

- sayHello:
    return: Hello from Cloud Workflows!

A workflow definition is made of steps. But not just one! You can create several steps. In YAML, the structure of your workflow will be something like:

- stepOne:
    # do something
- stepTwo:
    # do something else
- sayHello:
    return: Hello from Cloud Workflows!

By default, steps are executed in the order they appear, from top to bottom. The execution will finish when either you return a value, or you reach the final step. If there’s no return statement, a null value is returned as result of the workflow execution.