CloudFlow:Task steps

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 until 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 the system 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 the system receives a callback request or timeout notification of the task.
• Optional:timeoutSeconds: the timeout period of the 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: the group of retry policies. Each retry policy has the following attributes:
  • errors: the one or more errors. For more information, see Error definitions.
  • intervalSeconds: the initial interval between retries. The maximum value is 86,400 seconds. Default value: 1 second.
  • maxIntervalSeconds: the maximum time interval for retries. 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: the group of catch policies. Each catch policy has the following attributes:
  • errors: the 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.

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           

    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.
  • 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 still 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\"}}",