CloudFlow:Présentation des intégrations

Modes d'intégration

Serverless Workflow prend en charge trois modes d'intégration.

• Mode requête/réponse : Serverless Workflow appelle un service tiers et passe à l'étape suivante dès réception d'une réponse HTTP. Il s'agit du mode d'intégration par défaut.

  Dans une étape FDL, utilisez resourceArn pour spécifier le service cible et pattern: requestResponse pour définir le mode d'intégration. Ce paramètre est facultatif. S'il est omis, Serverless Workflow utilise le mode requête/réponse par défaut et passe immédiatement à l'étape suivante après le retour de l'appel d'API. L'exemple suivant utilise un sous-flux où Serverless Workflow est le service intégré.

  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       

  Dans cet exemple, l'étape testSubflow déclenche le flux flowABC. L'exécution passe ensuite à l'étape suivante, dummy, tandis que le flux flowABC peut encore être en cours d'exécution.

• Mode synchrone : Serverless Workflow s'intègre aux services qui proposent une API asynchrone pour démarrer une tâche. Après soumission de la tâche, Serverless Workflow attend sa fin avant de passer à l'étape suivante.

  Les services compatibles avec le mode synchrone exposent généralement une API asynchrone pour démarrer une tâche. Serverless Workflow soumet la tâche et attend sa terminaison avant de passer à l'étape suivante.

  Dans une étape FDL, utilisez resourceArn pour spécifier le service cible et pattern: sync pour définir le mode d'intégration. L'exemple suivant utilise un sous-flux où Serverless Workflow est le service intégré.

  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          

  Dans cet exemple, lorsque l'étape testTask s'exécute, elle déclenche le flux flowABC. Le workflow ne passe à l'étape suivante, dummy, qu'une fois le flux flowABC terminé.

• Mode d'attente de rappel : Serverless Workflow appelle un service et transmet un jeton de tâche. Le flux reste en pause jusqu'à la réception d'une instruction de rappel incluant ce jeton.

  Dans une étape FDL, utilisez resourceArn pour spécifier le service cible et pattern: waitForCallback pour définir le mode d'intégration. L'exemple suivant utilise un sous-flux où Serverless Workflow est le service intégré.

  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            

  Dans cet exemple, lorsque l'étape testSubflow s'exécute, elle déclenche le flux flowABC. Le flux reste en pause jusqu'à la réception d'un rappel via l'API ReportTaskSucceed ou ReportTaskFailed. Une fois le rappel traité, le flux passe à l'étape dummy. Entre-temps, le flux flowABC peut déjà être terminé ou toujours en cours d'exécution.

Objet de contexte

L'objet de contexte est un objet JSON interne disponible au sein d'une instance d'exécution de flux. Il contient des informations sur le flux et ses étapes. Utilisez inputMappings pour mapper les données de contexte à des variables spécifiques. L'exemple suivant illustre la structure de l'objet de contexte.

"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"
    }
}       

Par exemple, lors de l'intégration du service Serverless Workflow, vous devrez peut-être récupérer les informations du flux parent et le taskToken de l'étape appelante dans un sous-flux pour effectuer un rappel. L'exemple suivant montre comment récupérer ces champs.

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

Services Cloud intégrés