Child flows of Serverless Workflow - CloudFlow - Alibaba Cloud Documentation Center

The feature of integrating child flows of Serverless workflow allows you to execute another flow in a flow. This topic describes scenarios, integration modes, context objects, and input and output rules of child flows of Serverless workflow.

Scenarios

The feature of integrating child flows of Serverless workflow can be applied in the following scenarios:

Divide a flow into multiple child flows to reduce the flow complexity.
Facilitate the reuse of flows. You can put some common steps in a flow and reuse these steps in other flows.
Remove limits of the current single flow. For example, a single flow can contain a maximum of 5,000 events by default and the maximum execution time is one year.
Implement error handling for the overall output of the flow. For example, you can design a parallel step as a child flow and handle errors that occur in the execution of the child flows in the parent flow.

Integration modes

Serverless workflow supports three integration modes: request/response, synchronous, and wait-for-callback modes.

Request/response mode

In this mode, the parent flow starts to execute the next step immediately after the child flow is started. The following piece of code defines the flow:

version: v1
type: flow
steps:
  - type: task
    name: fnfInvoke
    resourceArn: acs:fnf:::flow/subflow_demo_child
    pattern: requestResponse # The default mode. You do not need to specify this parameter.
    inputMappings: # If inputMappings is not specified, the default mapping rule is used. In other words, the parameters of the parent flow are used as the input into the child flow.
      - target: childName # The execution name of the child flow that will be initiated in the service.
        source: $input.childName
    serviceParams:  # The parameters of the service that is integrated in Serverless workflow. You do not need to specify this parameter. If this parameter is not specified, a random string is used as the name of this execution, and the parameter included in inputMappings is used as the input into the child flow.
      Input: $  # Use the mapped input parameter as the input parameter to initiate the child flow.
      ExecutionName: $.childName # If a variable is specified in serviceParams, ensure that this variable exists in inputMappings.

Synchronous mode

In this mode, the parent flow starts a child flow and proceeds to the next step after the execution of the child flow is completed. The following piece of code defines the flow:

version: v1
type: flow
steps:
  - type: parallel
    name: parallelTask
    branches:
      - steps:
        # In this step, Serverless workflow is integrated in the synchronous mode, where inputMappings is used as the input into the child flow, and the execution name of the child flow is dynamically specified based on the input into the parent flow.
        - type: task
          name: fnfSync
          resourceArn: acs:fnf:::flow/subflow_demo_child
          pattern: sync
          inputMappings: # If inputMappings is not specified, the default mapping rule is used. In other words, the parameters of the parent flow are used as the input into the child flow.
            - target: childSyncName # The execution name of the child flow that will be initiated in the service. If you want to specify an execution name for the child flow, perform input mapping for the target execution name and use the mapped result in serviceParams, as shown in this example.
              source: $input.childSyncName.
          serviceParams:  # The parameters of the service that is integrated in Serverless workflow.
            Input: $  # Use the mapped input parameter as the input parameter to initiate the child flow. We recommend that you use the provided method unless you explicitly specify the behavior and syntax for Input in other ways.
            ExecutionName: $.childSyncName # If a variable is specified in serviceParams, ensure that this variable exists in inputMappings.

Wait-for-callback mode

In this mode, the parent flow starts a child flow and enters the suspended state until it receives a callback notification. The following piece of code defines the flow:

version: v1
type: flow
steps:
  - steps:
    # In this step, Serverless workflow is integrated in the wait-for-callback mode, where inputMappings is used as the input into the child flow, and the execution name of the child flow is dynamically specified based on the input into the parent flow.
    - type: task
      name: fnfWaitForCallback
      resourceArn: acs:fnf:::flow/subflow_demo_child
      pattern: waitForCallback
      inputMappings: # If inputMappings is not specified, the default mapping rule is used. In other words, the parameters of the parent flow are used as the input into the child flow.
        -target: task_token # To ensure that callbacks can be used in the child flow, map task_token to a custom name.
          source: $context.task.token  # Obtain the task token that identifies the task from the context object.
        - target: childCallbackName
          source: $input.childCallbackName
      serviceParams:  # The parameters of the service that is integrated in Serverless workflow.
        Input: $  # Use the mapped input parameter as the input parameter to initiate the child flow.
        ExecutionName: $.childCallbackName # If a variable is specified in serviceParams, ensure that this variable exists in inputMappings.

Context object description

In the integration modes for child flows, you can pass the $context.execution.name and $context.flow.name variables to a child flow to identify the parent flow that starts the child flow. In the wait-for-callback mode, $context.task.token is used to pass the identifier of the parent flow to the child flow to implement the callback.

Input and output rules for child flows

Request/response mode
In this mode, the input into a child flow derives from that of the corresponding task step. You can obtain the input by specifying $Input in the child flow.
The start information of the child flow (response from the call to StartExecution) is used as the output, whereas the output of the child flow is ignored by the parent flow. After a child flow is started, the following start information of the child flow is provided by default: $local.ExecutionName, $local.FlowName, and $local.RequestId. If you want to map other output parameters of the child flow to the parent flow, you can map them by performing output mapping in the corresponding step in the parent flow.
```
   - type: task
     pattern: requestResponse
     ...
     outputMappings: # In the request/response mode, you can obtain the $local.ExecutionName, $local.FlowName, and $local.RequestId parameters.
       - target: subflow_children_request_id
         source: $local.RequestId # The ID of the request that initiates the child flow.
       - target: subflow_children_exec_name
         source: $local.ExecutionName # The execution name of the child flow that will be initiated.
       - target: subflow_children_flow_name
         source: $local.FlowName # The flow name of the child flow that will be initiated.          
```
Synchronous mode
In this mode, the input into a child flow derives from that of the corresponding task step. You can obtain the input by specifying $Input in the child flow.
The output of the child flow, which is the Output in the response from the call to DescribeExecution, is returned to the parent flow as the output of this step in the parent flow. You can use this output in subsequent steps of the parent flow. If you want to map other output parameters of the child flow to the parent flow, you can map them by performing output mapping.
Wait-for-callback mode
In this mode, the input into a child flow derives from that of the corresponding task step. You can obtain the input by specifying $Input in the child flow.
The output of the callback is used as the output of this step in the parent flow. The value of the Output parameter that you pass in when you call the ReportTaskSucceeded operation is used as the output of this step in the parent flow. The values of the Error and Cause parameters that you pass in when you call the ReportTaskFailed operation are used as the output of this step in the parent flow. If you want to map other output parameters of the child flow to the parent flow, you can map them by performing output mapping.