Gateway Fluid

para disparar um evento/ webhook para fluid para iniciar a execução de um fluxo, é necessário fazê lo via gateway disparando fluxos via eventos/ webhooks para disparar um evento/webhook e iniciar a execução de um fluxo utilizando o gateway fluid, é necessário ter acesso a três informações essenciais gateway host o endereço do gateway varia de acordo com os workspaces definidos para cada cliente consulte o gateway host com a equipe responsável do projeto ou via abertura de chamados docid\ ck gzx9wvruka7rnp2cxt flow name este é o nome do fluxo criado no console da plataforma é usado para identificar qual fluxo será acionado pelo evento/webhook veja mais em canvas docid 1q9gpdjozxjskaag7 b2p api key a chave de api gerada na plataforma fluid essa chave é essencial para autenticar e autorizar o acesso ao gateway fluid saiba mais em api keys docid\ u9rzulsup oxxcqf5mu 8 certifique se de ter essas informações em mãos antes de criar um evento/ webhook no gateway fluid o gateway host , flow name e api key são necessários para configurar corretamente o disparo do evento no ambiente fluid os métodos/verbos suportados para o disparo no gateway são get post put patch delete head options o gateway host é um endereço de acordo com os workspaces docid\ bqstxq1kzn1hn1c3fxv2z definidos para cada cliente consulte o o seu gateway host com a nossa equipe limites técnicos o tamanho máximo permitido para requisições ao nosso gateway é de 10mb certifique se de que os payloads enviados estejam dentro desse limite para evitar erros eventos/ webhooks síncronos devem ser usados com fluxos com tempo de resposta de até 29 segundos caso o fluxo leve 29 segundos ou mais para finalizar, use o disparo assíncrono disparando um evento assíncrono o evento assíncrono retorna imediatamente um http status code 200 e um eventid , permitindo que o fluxo seja executado em segundo plano este método é adequado quando não é necessário obter uma resposta imediata e quando o fluxo puder ser executado de forma assíncrona curl location '{gateway host}/v2/flows/{flow name}?key={api key}' \\ \ header 'content type application/json' \\ \ data '{ "teste" "body" }' definindo a execução sequencial (serial) caso a execução de um fluxo não possa ser paralelizada, seja por restrição de rate limit de alguma api ou por requisitos de consistência de dados, é possível disparar o fluxo informando um parâmetro para execução serial curl location '{gateway host}/v2/flows/{flow name}?key={api key}\&serial=true' \\ \ header 'content type application/json' \\ \ data '{ "teste" "body" }' com o parâmetro de query serial=true habilitado, o fluxo será executado um atrás do outro, sem concorrência a configuração para execução de fluxos sequencialmente, um por vez, incorre numa configuração prévia por parte da equipe da fluid e pode acarretar no aumento de consumo de créditos disparando um evento síncrono um evento/ webhook para disparar um fluxo de forma síncrona mantém a requisição aberta até obter a resposta após a execução do fluxo é útil quando a resposta do fluxo é necessária imediatamente quando do disparo do evento para tornar o evento síncrono , inclua o parâmetro de query sync=true o corpo da resposta de um disparo síncrono será vazio , a menos que informado o parâmetro return step contendo o nome do passo que irá retornar a resposta (ver abaixo em " definindo o response de um fluxo síncrono ") curl location '{gateway host}/v2/flows/{flow name}?sync=true\&key={api key}' \\ \ header 'content type application/json' \\ \ data '{ "teste" "body" }' se o disparo síncrono for feito com o método/verbo get , não é necessário passar o parâmetro sync=true na url eventos/ webhooks síncronos devem ser usados com fluxos com tempo de resposta de até 29 segundos caso o fluxo leve 29 segundos ou mais para finalizar, use o disparo assíncrono definindo o response de um fluxo síncrono para retornar um response em um evento síncrono, informe o nome do passo ( step name ) do fluxo que gerará o retorno usando o parâmetro de query return step curl location '{gateway host}/v2/flows/{flow name}?sync=true\&return step={step name}\&key={api key}' \\ \ header 'content type application/json' \\ \ data '{ "teste" "body" }' @deprecated return array na versão anterior v1 do fluid gateway, caso o retorno do passo fosse um array de objetos , era necessário adicionar um parâmetro chamado return array com valor true , nesta última versão ( v2 ) já não é mais necessário, o gateway identifica automaticamente o tipo de response definindo o header content type do response por padrão, o content type do response em eventos síncronos é application/json para definir outro valor para este header , passe o parâmetro hct na query via url curl location '{gateway host}/v2/flows/{flow name}?sync=true\&hct=application/vnd vtex checkout minicart v1%2bjson\&key={api key}' \\ \ header 'content type application/json' \\ \ data '{ "teste" "body" }' atribuindo tags no disparo de eventos para atribuir tags docid\ ttiu emxmpmfjbsvija1 no disparo de fluxos via eventos docid\ umtr8dli6rnl8us2v8o1a basta informá las como parâmetros de query ( query params ) com o nome tags e as valores separados por vírgula, da seguinte forma \&tags=tag1,tag2 curl location '{gateway host}/v2/flows/{flow name}?key={api key}\&tags=tag1,tag2' \\ \ header 'content type application/json' data '{"teste" "body"}' é possível atribuir tags tanto na execução síncrona quanto assíncrona de fluxos as tags utilizadas no disparo de fluxos devem seguir as seguintes regras são permitidas até 3 tags por fluxo cada tag pode ter no máximo 36 caracteres devem ser compostas apenas por letras minúsculas, números e hífen as tags são normalizadas, os espaços e acentos são removidos caso as regras acima não sejam respeitadas, o gateway retornará um erro com status code 400 disparando um fluxo no modo rascunho (versão não publicada) quando for necessário disparar um fluxo para testar uma alteração que ainda não foi publicada, isso é possível através do teste de fluxo docid\ pvuplth uswaxj9j6uukr no canvas ou via gateway através do parâmetro de query draft=true , como no exemplo abaixo curl location '{gateway host}/v2/flows/{flow name}?key={api key}\&draft=true' configurando a requisição feita para o gateway pré processando o corpo da requisição caso seja necessário o tratamento do body enviado para o gateway removendo um prefixo, existe a configuração trim prefix disponível via query parameter no disparo curl location '{gateway host}/v2/flows/{flow name}?key={api key}\&trim prefix=data%3d' \\ \ header 'content type application/x www form urlencoded' \\ \ data 'data={"retorno" {"estoques" \[{"estoque" {"id" 123,"codigo" "","nome" "nome do produto","estoqueatual" 1,"depositos" \[{"deposito" {"desconsiderar" "n","id" "123","nome" "geral","saldo" 21,"saldovirtual" 21}}]}}]}}' esse é um recurso importante na integração com o erp bling docid\ rla13f jty 896sv2kzrk para tratar o corpo do callback disparado pelo erp com esse tratamento, o fluxo configurado na fluid passará a contar exclusivamente com o json enviado pela bling, sem a necessidade de fazer o tratamento do body no fluxo conclusão a utilização correta do gateway fluid (v2) é essencial para a execução eficaz de fluxos de processamento de forma síncrona ou assíncrona ao seguir esta documentação, você poderá disparar eventos de forma adequada e configurar fluxos para responder de acordo com suas necessidades certifique se de consultar o gateway host correto com a equipe responsável e ajustar os parâmetros conforme necessário para integrações bem sucedidas utilizando esta versão do fluid api gateway