This topic describes task steps and examples.

Attributes

A task step defines the function invocation information of Function Compute. When a task step is executed, the corresponding function is invoked.

A task step contains the following attributes:

  • type: The step type. The value task indicates that the step is a task step.
  • name: the name of the step.
  • resourceArn: the resource identifier, which can be a function, MNS queue, or Serverless workflow flow. Example: acs:fc:cn-shanghai:18807708****3420:services/fnf_test/functions/hello. For more information, see Service Integration.
  • Optional:pattern: the execution mode of an integration service. Different integration services support different execution modes. Default value: requestResponse. Valid values:
    • requestResponse: The system waits till the task execution ends after a task is submitted and then continues the step.
    • sync: The system waits until the task execution ends after a task is asynchronously submitted, and then continues the step after it receives the task execution result.
    • waitForCallback: The system suspends the step after a task is asynchronously submitted (such as invoking a function), and waits until it receives a callback request or timeout notification of the task.
  • Optional:timeoutSeconds: the timeout period of a task. If the task execution duration exceeds the specified timeout period, the task step times out.
  • Optional:end: Specifies whether to proceed with the subsequent steps after the current step ends.
  • Optional:inputMappings: the input mappings. The input of the task step will be used as the event of a function invocation. For more information, see InvokeFunction.
  • Optional:outputMappings: the output mappings. $local is the result of a function invocation and must be in JSON format.
    Note If no output mappings are specified, $local is used as the output of this step by default.
  • Optional:errorMappings: the error mappings. This attribute parameter is valid only when an error occurs during step execution and the catch parameter is specified. You can use the $local.cause and $local.error values to map error information to the output and pass it to the next step.
    Note The $local.error and $local.code values are reserved for the system. The source field in errorMappings must be set to these two values. For more information, see Examples. In addition, the errorMappings parameter is optional. If it is not specified, error information cannot be obtained in the next step after an error occurs.
  • retry: Specifies a group of retry policies. Each retry policy has the following attributes:
    • errors: Specifies one or more errors. For more information, see Error definitions.
    • intervalSeconds: the initial interval between retry attempts. The maximum value is 86,400 seconds. Default value: 1 second.
    • maxIntervalSeconds: The maximum time interval for retry attempts. Both the maximum value and default value are 86,400 seconds.
    • maxAttempts: the maximum number of retries. Default value: 3.
    • multiplier: the value by which a retry interval is multiplied to make the next retry interval. Default value: 2.
  • catch: Specifies a group of catch policies. Each catch policy has the following attributes:
    • errors: Specifies one or more errors. For more information, see the following table.
    • goto: the name of the destination step.
      Note The destination step must be a step parallel to the current task step.
Table 1. Error definitions
Function execution status HTTP status code of a Function Compute response Function Compute response Serverless workflow step failure (for retry and catch) Retry
Not executed 429 ResourceExhausted FC.ResourceExhausted Yes
Not executed 4xx but not 429 ServiceNotFound, FunctionNotFound, or InvalidArgument FC.ServiceNotFound, FC.FunctionNotFound, or FC.InvalidArgument No
Uncertain 500 InternalServerError FC.InternalServerError Yes
Not executed 503 ResourceThrottled FC.ResourceThrottled Yes
Execution successful, with an error code returned 200 A custom error, including errorType errorType Determined based on business
Execution failed, with an error code returned 200 No errorType FC.Unknown Yes
Execution successful, with a non-JSON object returned 200 No errorType FC.InvalidOutput No

Examples

  • Simple task steps

    The following sample flow contains a task step.

    • If the input is {"name": "function flow"}, the output is {"hello": "function flow"}.
    • If no input is specified for the flow or the flow input does not contain the name key, the task step execution fails, which causes a flow failure.
    • Define the flow.
      version: v1
      type: flow
      steps:
        - type: task
          name: hello
          resourceArn: acs:fc:{region}:{accountID}:services/fnf_test/functions/hello           
      The parameters of resourceArn:
      • {region}: Replace it with the actual region, such as cn-shanghai.
      • {accountID}: Replace it with your account ID. You can view the account ID by clicking the profile picture on the Flows page of the Serverless Workflow console, as shown in the following figure. create_flow_step1
    • Define the function.
      import json
      
      class MyError(Exception):
        pass
      
      def handle(event, context):
        evt = json.loads(event)
        if "name" in evt:
          return {
            "hello": evt["name"]
          }
        else:
          raise MyError("My unhandled exception")          
  • Retry

    The following example shows how to retry a task upon MyError. If no input is specified for the flow or the flow input does not contain the name key, Serverless workflow fails to retry tasks multiple times based on retry policies.

    • It waits 3 seconds after the first error occurs, and then invokes the function again.
    • It waits 6 seconds (intervalSeconds x multiplier) after the second error occurs, and then invokes the function again.
    • It waits 12 seconds (intervalSeconds x multiplier x multiplier) after the third error occurs, and then invokes the function again.
    • If an error occurs after three retries, the number of retries exceeds maxAttempts. Therefore, the task step fails and the flow fails.
    version: v1
    type: flow
    steps:
      - type: task
        name: hello
        resourceArn: acs:fc:{region}:{accountID}:services/fnf_test/functions/hello
        retry:
          - errors:
            - MyError
            intervalSeconds: 3
            maxAttempts: 3
            multiplier: 2            
  • Catch errors

    The following example shows how to catch MyError and then go to the final step. The error is caught, so the flow is successful.

    version: v1
    type: flow
    steps:
      - type: task
        name: hello
        resourceArn: acs:fc:{region}:{accountID}:services/fnf_test/functions/hello
        catch:
          - errors:
            - MyError
            goto: final
      - type: pass
        name: pass1
      - type: pass
        name: final           
  • Catch errors with error mappings specified

    The following example shows how to catch MyError and then go to the final step. Error information can be obtained and processed in the final step because error mappings are specified. The flow is successful. You can also specify in the errorMappings to map the inputs and constants of this step to the outputs.

    version: v1
    type: flow
    steps:
      - type: task
        name: hello
        resourceArn: acs:fc:{region}:{accountID}:services/fnf_test/functions/hello
        errorMappings:
          - target: errMsg
            source: $local.cause # This value is reserved for the system and can be used directly when an error occurs in this step.
          - target: errCode
            source: $local.error # This value is reserved for the system and can be used directly when an error occurs in this step.
        catch:
          - errors:
            - MyError
            goto: final
      - type: pass
        name: pass1
      - type: pass
        name: final  

    In the event of the final step, you can see the following content in EventDetail:

    "EventDetail": "{\"input\":{},\"local\":{\"errorCode\":\"MyError\",\"errorMsg\":\"some message\"}}",