Service integration modes supported by workflows - CloudFlow

CloudFlow uses task-type states to invoke various services. You can use service integration modes to control the transition of service invocation states. This topic describes the common service integration modes: RequestComplete, WaitForSystemCallback, and WaitForCustomCallback.

Precautions

You can use the RequestComplete, WaitForSystemCallback, and WaitForCustomCallback service integration modes to integrate services. However, not all invoked services support these three integration modes. For information about the integration modes supported by different services, see Integration modes.

RequestComplete

If you specify a service that you want to invoke in a task-type state, the RequestComplete service integration mode is used by default. You can also explicitly specify the RequestComplete integration mode. After the response is complete, the workflow enters the next state.

The following example shows how to use the RequestComplete integration mode to invoke a function of Function Compute.

States:
  -Name: an example of function invocation.
    Type: Task
    Action: FC::InvokeFunction
    Parameters:
      resourceArn: acs:fc:::services/myService1.LATEST/functions/myFunction1
      invocationType: Sync
      body: xxxx

In the preceding example, you can also explicitly specify the integration mode as RequestComplete.

States:
  -Name: an example of function invocation.
    Type: Task
    TaskMode: RequestComplete
    Action: FC::InvokeFunction
    Parameters:
      resourceArn: acs:fc:::services/myService1.LATEST/functions/myFunction1
      invocationType: Sync
      body: xxxx

WaitForSystemCallback

For specific task integration services and asynchronous invocations in Function Compute, workflows wait for tasks to complete before workflows enter the next state if you use the WaitForSystemCallback integration mode.

In this case, you must explicitly specify the WaitForSystemCallback integration mode in the States section. Example:

States:
  -Name: an example of function invocation.
    Type: Task
    TaskMode: WaitForSystemCallback
    Action: FC::InvokeFunction
    Parameters:
      resourceArn: acs:fc:::services/myService1.LATEST/functions/myFunction1
      invocationType: Async
      body: xxxx

In the WaitForSystemCallback integration mode, workflows wait for tasks to complete before workflows enter the next state.

If tasks that use the WaitForSystemCallback integration mode are terminated, CloudFlow cannot cancel the tasks. You may be charged unexpected fees for the integration service. To prevent unexpected fees, you must manually cancel the integration tasks. CloudFlow can automatically terminate an integration task in the following cases:

The workflow is stopped.
Another branch in the Parallel state fails due to a captured error.
An iteration of the Map state fails and the corresponding error is not captured.

The workflow engine tries its best to cancel the task. For example, if a workflow uses the WaitForSystemCallback integration mode and invokes an asynchronous task that contains a sub-flow or a function of Function Compute and you call the StopExecution API operation of CloudFlow to stop the current workflow, CloudFlow stops the sub-flow and then the asynchronous task-related function in the workflow. However, the workflow engine may not be able to cancel the task for the following reasons:

Your execution role has no the permissions to call the corresponding API operation.
The service is temporarily interrupted.

WaitForCustomCallback

The WaitForCustomCallback integration mode is a callback mode that contains a task token. In this mode, you can suspend a workflow and control the execution of the workflow based on the logic that you defined in the integration service. For example, if a user approval is required during the flow execution, the integration invocation initiates the approval flow of an external system. After the approval flow is completed, the system calls back the workflow and returns the approval result. Then, the workflow continues to execute subsequent steps. After an integration invocation that uses the WaitForCustomCallback integration mode is initiated, the current task is automatically suspended. The flow does not advance until the integrated service calls the ReportTaskSucceeded or ReportTaskFailed API operation to report the execution result of the task.

States:
  -Name: an example of function invocation.
    Type: Task
    TaskMode: WaitForCustomCallback
    Action: FC::InvokeFunction
    Parameters:
      resourceArn: acs:fc:::services/myService1.LATEST/functions/myFunction1
      invocationType: Async
      body: xxxx

The following figure shows how the WaitForCustomCallback integration mode works. Compared with polling, a callback effectively reduces the delay and unnecessary pressure on the server. In addition, the combination of callbacks and queues can orchestrate tasks in other services than Function Compute and extend the orchestration scope of CloudFlow to all types of computing resources.

Example: service integration workflow that uses the WaitForCustomCallback integration mode

CloudFlow is integrated with an external microservice

This section describes how CloudFlow is integrated with an external microservice to perform credit checks. CloudFlow sends a message that contains a task token to Message Service. The external microservice is integrated with Message Service, obtains the message from the message queue of MNS, and then returns the result and the original task token. Then, CloudFlow continues subsequent flows. The following figure shows the complete workflow.

Example:

States:
  -Name: an example of function invocation.
    Type: Task
    TaskMode: WaitForCustomCallback
    Action: FC::InvokeFunction
    Parameters:
      resourceArn: acs:fc:::services/myService1.LATEST/functions/myFunction1
      invocationType: Async
      body:
         payload.$: $Input
         taskToken.$: $Context.Current.TaskToken

If you use the WaitForCustomCallback integration mode, you can use the $Context.Current.TaskToken expression to access the task token in the Parameters field of the States section. The initial $Context specifies the path to the context object and obtains the task token of the current task.

Then, the external microservice calls the ReportTaskSucceeded or ReportTaskFailed API operation to send the token and task execution status. The workflow transits to the next state.

CloudFlow is integrated with a self-managed service

The following figure shows how to use the MNS queque service and API callbacks to integrate CloudFlow with a self-managed service. This extends the usage of CloudFlow. MNS can be any intermediate storage service.