CloudFlow:Overview

Integration modes

Serverless Workflow supports the following three 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 workflow defined in FDL, the resourceArn parameter defines the service, and the pattern: requestResponse parameter defines the service integration mode. The pattern: requestResponse 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 workflow, 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 workflow. 
      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 workflow is triggered. After flowABC is triggered, the workflow 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 workflow 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 workflow, 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 workflow. 
      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 workflow is triggered. After the child workflow is triggered, the workflow waits for the execution result of the child workflow and then proceeds to the next step. When the testTask step is executed, the flowABC child workflow is triggered. After flowABC is triggered, the workflow waits for its execution result. After flowABC is completed, the workflow 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 workflow of the execution result before the workflow proceeds to the next step.

  The callback task suspends the current workflow at the task scheduling point until the callback instruction for the corresponding task token is received. In a step of a workflow 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 workflow, 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 workflow. 
      pattern: waitForCallback #Sets 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 workflow is triggered. After flowABC is triggered, the workflow is paused to wait for a callback that is implemented with the invocation of the ReportTaskSucceed or ReportTaskFailed API operation. After the workflow 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 workflow 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 workflow. 
        "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 workflow the information about the parent workflow that invokes the child workflow, and obtain taskToken in this invocation. 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