Tous les produits
Search

Ce produit

    CloudFlow:Service integration modes

    Centre de documentation

    CloudFlow:Service integration modes

    Dernière mise à jour :Aug 11, 2026

    CloudFlow utilise des états Task pour appeler des services Alibaba Cloud et des ressources externes au sein d'un workflow. Le mode d'intégration définit la manière dont un état Task gère la réponse du service : attente synchrone, attente de la fin d'une tâche asynchrone ou mise en pause jusqu'à réception d'un rappel d'un système externe.

    Trois modes d'intégration sont disponibles :

    • RequestComplete : envoi d'une requête et attente de la réponse (valeur par défaut).

    • WaitForSystemCallback : envoi d'une requête asynchrone et attente que le système signale la fin du traitement.

    • WaitForCustomCallback : envoi d'une requête accompagnée d'un jeton de tâche et mise en pause jusqu'à ce qu'un système externe renvoie le résultat via un rappel.

    Choisir un mode d'intégration

    Utilisez le tableau suivant pour déterminer le mode adapté à votre cas d'utilisation.

    Critères RequestComplete WaitForSystemCallback WaitForCustomCallback
    Quand l'utiliser Le service cible renvoie une réponse synchrone Le service cible exécute une tâche asynchrone et signale lui-même sa fin Un système externe ou une action humaine doit être finalisé avant la poursuite du workflow
    Avancement de l'état Après réception de la réponse Une fois la tâche terminée Après appel de ReportTaskSucceeded ou ReportTaskFailed
    Scénario typique Appel synchrone d'une fonction Function Compute Soumission d'une tâche batch longue Attente d'une approbation humaine ou d'un microservice externe
    **Valeur invocationType** Sync Async Sync ou Async
    Tous les services ne prennent pas en charge les trois modes. Pour consulter la liste de compatibilité par service, reportez-vous à la section Modes d'intégration .

    RequestComplete

    RequestComplete est le mode d'intégration par défaut. L'état Task envoie une requête au service cible et attend la réponse avant de passer à l'état suivant. L'appel étant synchrone, le workflow reçoit le résultat dès la fin de l'invocation.

    Définissez TaskMode sur RequestComplete (ou omettez ce paramètre, car il s'agit de la valeur par défaut) :

    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

    Utilisez WaitForSystemCallback pour les invocations asynchrones où le service cible signale lui-même la fin du traitement. L'état Task soumet la requête puis se met en attente : le workflow n'avance qu'une fois la tâche terminée.

    Définissez TaskMode sur WaitForSystemCallback et invocationType sur 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

    Pour obtenir la liste des services prenant en charge ce mode, consultez la section Services Alibaba Cloud qui prennent en charge l'intégration normale.

    Comportement en cas d'annulation de tâche

    Si une tâche WaitForSystemCallback est arrêtée, CloudFlow peut ne pas être en mesure d'annuler la tâche sous-jacente. Les tâches non annulées continuent de s'exécuter et peuvent engendrer des frais. Pour éviter des coûts imprévus, annulez manuellement la tâche d'intégration.

    Tentatives d'annulation automatique par CloudFlow

    CloudFlow tente d'annuler la tâche dans la mesure du possible dans les scénarios suivants :

    • L'exécution du workflow est arrêtée.

    • Une autre branche d'un état Parallel échoue avec une erreur interceptée.

    • Une itération d'un état Map échoue avec une erreur non interceptée.

    Par exemple, si le workflow contient des tâches asynchrones avec des flux enfants ou des fonctions Function Compute, appelez l'opération d'API StopExecution pour arrêter le workflow. CloudFlow arrête d'abord les flux enfants, puis les fonctions liées aux tâches asynchrones dans le workflow.

    Raisons possibles d'échec de l'annulation

    • Le rôle d'exécution ne dispose pas des autorisations nécessaires pour appeler l'opération d'API correspondante.

    • Le service cible est temporairement indisponible.

    WaitForCustomCallback

    WaitForCustomCallback met le workflow en pause et attend qu'un système externe signale le résultat. Lors de l'exécution de l'état Task, un jeton de tâche est généré et transmis au système externe. Une fois le traitement terminé, le système externe appelle l'opération d'API ReportTaskSucceeded ou ReportTaskFailed en fournissant le jeton et le résultat. Le workflow reprend alors son cours vers l'état suivant.

    Contrairement au sondage (polling), les rappels réduisent la latence et éliminent la charge inutile sur le serveur. Combinés aux files d'attente de messages, ils étendent le périmètre d'orchestration de CloudFlow à tous les types de ressources informatiques, et pas seulement à Function Compute.

    How WaitForCustomCallback works

    Définissez TaskMode sur 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

    Accéder au jeton de tâche

    Dans le champ Parameters, utilisez l'expression $Context.Current.TaskToken pour accéder au jeton de tâche actuel. Le préfixe $Context pointe vers l'objet de contexte d'exécution.

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

    Exemple : vérification de crédit avec un microservice externe

    Cet exemple illustre l'intégration de CloudFlow avec un microservice externe pour effectuer une vérification de crédit. Le workflow suit les étapes suivantes :

    1. Il invoque une fonction Function Compute en utilisant WaitForCustomCallback. La fonction envoie un message, incluant le jeton de tâche, à Simple Message Queue (anciennement MNS).

    2. Le microservice externe récupère le message depuis la file d'attente et effectue la vérification de crédit.

    3. Le microservice appelle ReportTaskSucceeded ou ReportTaskFailed en fournissant le jeton et le résultat de la vérification.

    4. CloudFlow reprend le workflow et passe à l'état suivant.

    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

    Exemple : intégration avec un service auto-géré

    Utilisez Simple Message Queue (anciennement MNS) et les rappels API pour intégrer CloudFlow à un service auto-géré. Dans ce modèle, Simple Message Queue sert d'intermédiaire entre CloudFlow et le service externe. Le service externe interroge la file d'attente pour récupérer les tâches, les traite, puis rappelle CloudFlow avec le résultat.

    Ce modèle ne se limite pas à Simple Message Queue : tout service de messagerie ou de stockage intermédiaire peut servir de canal de communication.

    Self-managed service integration

    Étapes suivantes