CloudFlow:Overview

Integration modes

Serverless Workflow supports the following integration modes:

• Request-response mode: In this mode, when you invoke a third-party service, Serverless Workflow proceeds to the next step immediately after it gets an HTTP response. This is the default mode.
  In a step of a flow defined in FDL, the resourceArn parameter defines the service, and the pattern: requestResponse parameter defines the service integration mode. The latter parameter is optional. If it is not specified, the default integration mode is used. In this mode, Serverless Workflow proceeds to the next step immediately after it receives an invocation response. The following example shows a child flow, in which Serverless Workflow is the integrated service:

  version: v1
  type: flow
  steps:
    - type: task
      name: testSubflow
      resourceArn: acs:fnf:::flow/flowABC #Defines the child flow.
      pattern: requestResponse #Sets the service integration mode to the request-response mode, which is the default mode.
    - type: pass
      name: dummy       

  In this example, when the testSubflow step is executed, the flowABC child flow is triggered. After flowABC is triggered, the flow proceeds to the dummy step, while flowABC may still be running.

• Synchronous mode: In this mode, a service generally provides an API for asynchronous execution. After Serverless Workflow invokes the API, Serverless Workflow waits for the relevant task to complete and the execution result to be returned before it proceeds to the next step.

  For specific integrated services, Serverless Workflow waits for the relevant task to complete and then proceeds to the next step. This type of service provides an asynchronous API to start a task. You must submit the task and wait for the task to complete before the next step starts.

  In a step of a flow defined in FDL, the resourceArn parameter defines the service, and the pattern: sync parameter defines the service integration mode. The following example shows a child flow, in which Serverless Workflow is the integrated service:

  version: v1
  type: flow
  steps:
    - type: task
      name: testTask
      resourceArn: acs:fnf:::flow/flowABC #Defines the child flow.
      pattern: sync #Sets the service integration mode to the synchronous mode.
    - type: pass
      name: dummy          

  In this example, when the task step is executed, a Serverless Workflow child flow is triggered. After the child flow is triggered, the flow waits for its execution result and then proceeds to the next step. When the testTask step is executed, the flowABC child flow is triggered. After flowABC is triggered, the flow waits for its execution result. After flowABC is completed, the flow proceeds to the dummy step. At this point, flowABC has been completed.

• Wait-for-callback mode: In this mode, when you invoke a third-party service and pass in the task token, Serverless Workflow waits for you to use the token to notify the flow of the execution result before the flow proceeds to the next step.

  The callback task suspends the current flow at the task scheduling point until the callback instruction for the corresponding task token is received. In a step of a flow defined in FDL, the resourceArn parameter defines the service, and the pattern: waitForCallback parameter defines the service integration mode. The following example shows a child flow, in which Serverless Workflow is the integrated service:

  version: v1
  type: flow
  steps:
    - type: task
      name: testSubflow
      resourceArn: acs:fnf:::flow/flowABC #Defines the child flow.
      pattern: waitForCallback #Set the service integration mode to the wait-for-callback mode.
    - type: pass
      name: dummy            

  In this example, when the testSubflow step is executed, the flowABC child flow is triggered. After flowABC is triggered, the flow is paused to wait for a callback that is implemented with the invocation of the ReportTaskSucceed or ReportTaskFailed operation. After the flow receives and processes a callback request, it proceeds to the dummy step, regardless of whether flowABC has been completed. The callback is initiated by you.

Context objects

A context object is an internal JSON object in a flow execution instance, which contains information about the execution and steps. This object allows access from external services. To implement the access, you can map the context object to a specific variable in inputMappings. The following example shows the structure of the available context objects:

"context": {
    "flow": {
      // The unique ID, name, and string type of the flow.
        "id": "val1",
        "name "val2",
    },
    "execution": {
         // The name of the execution.
        "name": "val3"
    },
    "step": {
        // The name of the step.
        "name": "val4"
      // The event ID of the step.
        "eventId": "val5"
      // The iteration index. This parameter is valid in a foreach step.
        "IterationIndex": "val6",
    },
    "task": {
      // The identifier of the step, which is a string. This parameter is valid in the wait-for-callback mode.
        "token": "val7",
    },
}       

To integrate the Serverless Workflow service, you must obtain from the child flow the information about the parent flow that invokes this child flow, and obtain taskToken in this invocation step. taskToken will be used in the callback. You can obtain the target and source fields in the following way:

    ...
        inputMappings:
      - target: current_flow_name 
        source: $context.flow.name 
      - target: current_execution_name 
        source: $context.execution.name 
      - target: current_step_task_token 
        source: $context.task.token            

Integrated cloud services