CloudFlow:Introdução às integrações

Modos de integração

O Serverless Workflow oferece suporte a três modos de integração.

• Modo requisição/resposta: o Serverless Workflow chama um serviço de terceiros e avança para a próxima etapa após receber uma resposta HTTP. Este é o modo de integração padrão.

  Em uma etapa FDL, use resourceArn para especificar o serviço de destino e pattern: requestResponse para definir o modo de integração. Esse parâmetro é opcional. Se omitido, o Serverless Workflow adota o modo requisição/resposta padrão e prossegue para a etapa seguinte assim que a chamada à API retornar. O exemplo abaixo utiliza um fluxo filho no qual o Serverless Workflow atua como serviço integrado.

  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       

  Neste exemplo, a etapa testSubflow aciona o fluxo flowABC. A execução segue então para a próxima etapa, dummy, mesmo que o fluxo flowABC ainda esteja em execução.

• Modo síncrono: o Serverless Workflow integra-se a serviços que fornecem uma API assíncrona para iniciar uma tarefa. Após o envio da tarefa, o Serverless Workflow aguarda sua conclusão antes de passar para a etapa seguinte.

  Os serviços compatíveis com o modo síncrono geralmente expõem uma API assíncrona para iniciar tarefas. O Serverless Workflow envia a tarefa e espera que ela seja concluída antes de avançar.

  Em uma etapa FDL, especifique o serviço de destino com resourceArn e defina o modo de integração usando pattern: sync. O exemplo a seguir emprega um fluxo filho onde o Serverless Workflow é o serviço integrado.

  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          

  Neste cenário, quando a etapa testTask é executada, ela dispara o fluxo flowABC. O workflow só avança para a etapa seguinte, dummy, após a conclusão do fluxo flowABC.

• Modo de espera por callback: o Serverless Workflow chama um serviço e transmite um token de tarefa. O fluxo fica pausado até receber uma instrução de callback contendo esse token.

  Para configurar esse modo em uma etapa FDL, use resourceArn para indicar o serviço alvo e pattern: waitForCallback para estabelecer a integração. O exemplo abaixo demonstra o uso de um fluxo filho tendo o Serverless Workflow como serviço integrado.

  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            

  Ao executar a etapa testSubflow, o fluxo flowABC é acionado. A execução permanece pausada até que um callback seja recebido por meio da API ReportTaskSucceed ou ReportTaskFailed. Uma vez processado o callback, o fluxo segue para a etapa dummy. Nesse intervalo, o fluxo flowABC pode ter sido finalizado ou ainda estar em andamento.

Objeto de contexto

O objeto de contexto é uma estrutura JSON interna disponível durante a execução de uma instância de fluxo. Ele contém informações sobre o fluxo e suas etapas. Use inputMappings para mapear dados desse contexto para variáveis específicas. O exemplo a seguir ilustra a estrutura do objeto de contexto.

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

Por exemplo, ao integrar o serviço Serverless Workflow, talvez seja necessário recuperar informações do fluxo pai e o taskToken da etapa chamadora dentro de um fluxo filho para realizar um callback. O código abaixo demonstra como obter esses campos.

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

Serviços de nuvem integrados