All Products
Search
Document Center

CloudFlow:Service integration modes

Last Updated:Mar 11, 2026

CloudFlow uses Task states to invoke Alibaba Cloud services and external resources within a workflow. The integration mode controls how a Task state handles the service response -- whether it waits synchronously, waits for an asynchronous job to finish, or pauses until an external system sends a callback.

Three integration modes are available:

  • RequestComplete -- Send a request and wait for the response (default).

  • WaitForSystemCallback -- Send an asynchronous request and wait for the system to report completion.

  • WaitForCustomCallback -- Send a request with a task token and pause until an external system calls back with the result.

Choose an integration mode

Use the following table to determine which mode fits your use case.

CriteriaRequestCompleteWaitForSystemCallbackWaitForCustomCallback
When to useThe target service returns a synchronous responseThe target service runs an asynchronous job and reports completion on its ownAn external system or human action must complete before the workflow continues
How the state advancesAfter the response arrivesAfter the job completesAfter ReportTaskSucceeded or ReportTaskFailed is called
Typical scenarioInvoke a Function Compute function synchronouslySubmit a long-running batch jobWait for human approval or an external microservice
invocationType valueSyncAsyncSync or Async
Not all services support all three modes. For a per-service compatibility list, see Integration modes.

RequestComplete

RequestComplete is the default integration mode. The Task state sends a request to the target service and waits for the response before advancing to the next state. Because the call is synchronous, the workflow receives the result as soon as the invocation completes.

Set TaskMode to RequestComplete (or omit it, since this is the default):

Type: StateMachine
Name: myWorkFlow
SpecVersion: v1
StartAt: InvokeFunction
States:
  - Type: Task
    Name: an example of function invocation.
    Action: FC:InvokeFunction
    TaskMode: RequestComplete
    Parameters:
      resourceArn: acs:fc:{regionId}:{accountId}:functions/dataji/LATEST
      invocationType: Sync
      body: xxxx
    End: true

WaitForSystemCallback

Use WaitForSystemCallback for asynchronous invocations where the target service reports completion on its own. The Task state submits the request and then waits -- the workflow does not advance until the job finishes.

Set TaskMode to WaitForSystemCallback and invocationType to Async:

Type: StateMachine
Name: myWorkFlow
SpecVersion: v1
StartAt: InvokeFunction
States:
  - Type: Task
    Name: an example of function invocation.
    Action: FC:InvokeFunction
    TaskMode: WaitForSystemCallback
    Parameters:
      resourceArn: acs:fc:{regionId}:{accountId}:functions/dataji/LATEST
      invocationType: Async
      body: xxxx
    End: true

For a list of services that support this mode, see Alibaba Cloud services that support normal integration.

Task cancellation behavior

If a WaitForSystemCallback task is terminated, CloudFlow may not be able to cancel the underlying job. Uncanceled jobs continue to run and may incur charges. To avoid unexpected costs, cancel the integration task manually.

When CloudFlow attempts automatic cancellation

CloudFlow makes a best-effort cancellation attempt in these scenarios:

  • The workflow execution is stopped.

  • Another branch in a Parallel state fails with a caught error.

  • An iteration of a Map state fails with an uncaught error.

For example, if the workflow contains asynchronous tasks with child flows or Function Compute functions, call the StopExecution API operation to stop the workflow. CloudFlow stops the child flows first and then the asynchronous task-related functions in the workflow.

Why cancellation may fail

  • The execution role lacks the permissions required to call the corresponding API operation.

  • The target service is temporarily unavailable.

WaitForCustomCallback

WaitForCustomCallback pauses the workflow and waits for an external system to report the result. When the Task state runs, it generates a task token that you pass to the external system. After the external system finishes processing, it calls the ReportTaskSucceeded or ReportTaskFailed API operation with the token and the result. The workflow then advances to the next state.

Compared with polling, callbacks reduce latency and eliminate unnecessary load on the server. Combined with message queues, callbacks extend the orchestration scope of CloudFlow to all types of computing resources -- not just Function Compute.

How WaitForCustomCallback works

Set TaskMode to WaitForCustomCallback:

Type: StateMachine
Name: myWorkFlow
SpecVersion: v1
StartAt: InvokeFunction
States:
  - Type: Task
    Name: an example of function invocation.
    Action: FC:InvokeFunction
    TaskMode: WaitForCustomCallback
    Parameters:
      resourceArn: acs:fc:{regionId}:{accountId}:functions/dataji/LATEST
      invocationType: Sync
      body: xxxx
    End: true

Access the task token

Inside the Parameters field, use the expression $Context.Current.TaskToken to access the task token for the current task. The $Context prefix points to the runtime context object.

Parameters:
  resourceArn: acs:fc:{regionId}:{accountId}:functions/dataji/LATEST
  invocationType: Async
  body:
    payload.$: $Input
    taskToken.$: $Context.Current.TaskToken

Example: credit check with an external microservice

This example demonstrates how CloudFlow integrates with an external microservice to perform a credit check. The workflow:

  1. Invokes a Function Compute function using WaitForCustomCallback. The function sends a message -- including the task token -- to Simple Message Queue (formerly MNS).

  2. The external microservice pulls the message from the queue and runs the credit check.

  3. The microservice calls ReportTaskSucceeded or ReportTaskFailed with the token and the credit check result.

  4. CloudFlow resumes the workflow and advances to the next state.

Credit check workflow
Type: StateMachine
Name: myWorkFlow
SpecVersion: v1
StartAt: InvokeFunction
States:
  - Type: Task
    Name: an example of function invocation.
    Action: FC:InvokeFunction
    TaskMode: WaitForCustomCallback
    Parameters:
      resourceArn: acs:fc:{regionId}:{accountId}:functions/dataji/LATEST
      invocationType: Async
      body:
        payload.$: $Input
        taskToken.$: $Context.Current.TaskToken
    End: true

Example: integrate with a self-managed service

Use Simple Message Queue (formerly MNS) and API callbacks to integrate CloudFlow with a self-managed service. In this pattern, Simple Message Queue acts as the intermediary between CloudFlow and the external service. The external service polls the queue for tasks, processes them, and calls back CloudFlow with the result.

This pattern is not limited to Simple Message Queue -- any intermediate messaging or storage service works as the communication channel.

Self-managed service integration

What's next