Introduction to integrations

Integration modes

Serverless Workflow supports three integration modes.

• Request/response mode: Serverless Workflow calls a third-party service and proceeds to the next step after receiving an HTTP response. This is the default integration mode.

  In an FDL step, use resourceArn to specify the target service and pattern: requestResponse to specify the integration mode. This parameter is optional. If omitted, Serverless Workflow uses the default request/response mode and proceeds to the next step immediately after the API call returns. The following example uses a child flow where Serverless Workflow is the integrated service.

  version: v1
  type: flow
  steps:
    - type: task
      name: testSubflow
      resourceArn: acs:fnf:::flow/flowABC # Describes the child flow.
      pattern: requestResponse # Describes the integration mode: default (request/response) mode.
    - type: pass
      name: dummy       

  In this example, the testSubflow step triggers the flowABC flow. The execution then proceeds to the next step, dummy, while the flowABC flow may still be running.

• Synchronous mode: Serverless Workflow integrates with services that provide an asynchronous API to start a task. After you submit the task, Serverless Workflow waits for the task to complete before proceeding to the next step.

  Services that support synchronous mode typically expose an asynchronous API to start a task. Serverless Workflow submits the task and waits for it to complete before moving to the next step.

  In an FDL step, use resourceArn to specify the target service and pattern: sync to specify the integration mode. The following example uses a child flow where Serverless Workflow is the integrated service.

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

  In this example, when the testTask step runs, it triggers the flowABC flow. The workflow proceeds to the next step, dummy, only after the flowABC flow is complete.

• Wait-for-callback mode: Serverless Workflow calls a service and passes a task token. The flow pauses until it receives a callback instruction that includes the task token.

  In an FDL step, use resourceArn to specify the target service and pattern: waitForCallback to specify the integration mode. The following example uses a child flow where Serverless Workflow is the integrated service.

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

  In this example, when the testSubflow step runs, it triggers the flowABC flow. The flow pauses until a callback is received from the ReportTaskSucceed or ReportTaskFailed API. After the callback is processed, the flow proceeds to the dummy step. Meanwhile, the flowABC flow may have already finished or may still be running.

Context object

The context object is an internal JSON object available within a flow execution instance. It contains information about the flow and its steps. Use inputMappings to map context data to specific variables. The following example shows the structure of the context object.

"context": {
    "flow": {
      // The unique ID and name of the current flow. Both are strings.
        "id": "val1",
        "name": "val2"
    },
    "execution": {
      // The name of the current execution.
        "name": "val3"
    },
    "step": {
      // The name of the current step.
        "name": "val4",
      // The event ID of the current step.
        "eventId": "val5",
      // The current loop iteration number. This is available in a foreach step.
        "IterationIndex": "val6"
    },
    "task": {
      // The identifier for this step. It is a string and is available in the wait-for-callback mode.
        "token": "val7"
    }
}       

For example, when integrating the Serverless Workflow service, you may need to retrieve the parent flow information and the taskToken of the calling step in a child flow for a callback. The following example shows how to retrieve these fields.

    ...
        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