Integrate with Serverless Workflow

Scenarios

Use Serverless Workflow integration when you need to:

• Break down a large flow into smaller flows.
• Reuse common steps across multiple flows.
• Overcome single-flow limits, such as the maximum event count (5,000 by default) and maximum run time (1 year).
• Handle faults in control steps — for example, run a parallel step as a child flow and handle its faults in the parent flow.

Integration modes

Serverless Workflow integration supports three modes: request/response (requestResponse), synchronous (sync), and wait-for-callback (waitForCallback).

• Request/response (requestResponse) mode
  The parent flow proceeds to the next step immediately after starting the child flow.

  version: v1
  type: flow
  steps:
    - type: task
      name: fnfInvoke
      resourceArn: acs:fnf:::flow/subflow_demo_child
      pattern: requestResponse # Optional. This is the default mode.
      inputMappings: # If inputMappings is not specified, the parameters of the parent flow are used as the input for the child flow based on the default mapping rule.
        - target: childName # Used to set the execution name of the child flow in the service.
          source: $input.childName
      serviceParams:  # The service parameters for Serverless Workflow integration. This parameter is optional. If this parameter is omitted, a random string is used as the execution name, and the parameters that correspond to InputMappings are used as the input for the child flow.
        Input: $  # Use the mapped input as the input parameter to start the child flow.
        ExecutionName: $.childName # If you use a variable in serviceParams, make sure the variable exists in inputMappings.

• Synchronous (sync) mode

  The parent flow starts the child flow and waits for it to complete before proceeding.

  version: v1
  type: flow
  steps:
    - type: parallel
      name: parallelTask
      branches:
        - steps:
          # This step shows how to integrate with Serverless Workflow in sync mode. It uses inputMappings as the input for the child flow and dynamically specifies the execution name of the child flow from the parent flow's input.
          - type: task
            name: fnfSync
            resourceArn: acs:fnf:::flow/subflow_demo_child
            pattern: sync
            inputMappings: # If inputMappings is not specified, the parameters of the parent flow are used as the input for the child flow based on the default mapping rule.
              - target: childSyncName # The execution name of the child flow. To specify the execution name of the child flow, map the desired name in inputMappings and use it in serviceParams as shown in this example.
                source: $input.childSyncName
            serviceParams:  # The service parameters for Serverless Workflow integration.
              Input: $  # Use the mapped inputMappings as the input parameter to start the child flow. Use this method unless you are certain about the behavior and syntax of other methods for specifying the input.
              ExecutionName: $.childSyncName # If you use a variable in serviceParams, make sure the variable exists in inputMappings.

• Wait-for-callback (waitForCallback) mode

  The parent flow starts the child flow and pauses until it receives a callback.

  version: v1
  type: flow
  steps:
    - steps:
      # This step shows how to integrate with Serverless Workflow in waitForCallback mode. It uses inputMappings as the input for the child flow and dynamically specifies the execution name of the child flow from the parent flow's input.
      - type: task
        name: fnfWaitForCallback
        resourceArn: acs:fnf:::flow/subflow_demo_child
        pattern: waitForCallback
        inputMappings: # If inputMappings is not specified, the parameters of the parent flow are used as the input for the child flow based on the default mapping rule.
          - target: task_token # To ensure that the callback can be used in the child flow, explicitly map task_token with a custom name.
            source: $context.task.token  # Get the task token that represents this task from the context object.
          - target: childCallbackName
            source: $input.childCallbackName
        serviceParams:  # The service parameters for Serverless Workflow integration.
          Input: $  # Use the mapped inputMappings as the input parameter to start the child flow.
          ExecutionName: $.childCallbackName # If you use a variable in serviceParams, make sure the variable exists in inputMappings.

Context object

Pass $context.execution.name and $context.flow.name to the child flow to identify the parent flow. In waitForCallback mode, use $context.task.token to pass the parent flow's execution identifier to the child flow for the callback.

Input and output rules for child flows

• Request/response mode

  The child flow receives the task's input, accessible via $Input.

  The output is the StartExecution API response; the child flow's own output is ignored. Three values are available by default: $local.ExecutionName, $local.FlowName, and $local.RequestId. Use outputMappings in the parent step to process these values.

     - type: task
       pattern: requestResponse
       ...
       outputMappings: # Parameters available in requestResponse mode: $local.ExecutionName, $local.FlowName, $local.RequestId.
         - target: subflow_children_request_id
           source: $local.RequestId # The request ID for starting the child flow.
         - target: subflow_children_exec_name
           source: $local.ExecutionName # The execution name of the child flow.
         - target: subflow_children_flow_name
           source: $local.FlowName # The flow name of the child flow.

• Synchronous mode

  The child flow receives the task's input, accessible via $Input.

  The child flow's Output (from the DescribeExecution API response) becomes the step output in the parent flow. Use outputMappings to process this output further.

• Wait-for-callback mode

  The child flow receives the task's input, accessible via $Input.

  The callback data becomes the step output. With ReportTaskSucceeded, the Output parameter value becomes the step output. With ReportTaskFailed, the Error and Cause parameter values become the step output. Use outputMappings to process this output further.