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 duas informações essenciais 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 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 docid\ u9rzulsup oxxcqf5mu 8 certifique se de ter essas informações em mãos antes de criar um evento/ webhook no gateway fluid acesse docid\ qc2bdoeya5ngzvso0vlxb para saber como obter a url de disparo por webhook os métodos/verbos suportados para o disparo no gateway são get post put patch delete head options controle de idempotência para saber mais sobre como a idempotência dos disparos é tratado, acesse docid\ we6vd6 excfvkub zubz7 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 a partir da release docid\ tdz42y8ajlhrthcdo9f g , o corpo e o status code da resposta agora refletem o resultado real do fluxo executado, conforme as regras abaixo caso return step não seja informado → retorna o response e status code do último passo executado com return step , mas ocorre erro em algum passo antes dele → retorna o response e status code de erro do último passo executado com return step executado com sucesso → retorna o response e status code do passo informado no return step anteriormente a esta release, o corpo da resposta de um disparo síncrono seria 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 redefinindo o response de um fluxo síncrono para retornar um response e status code de um passo que não seja o último a ser executado em um fluxo durante a chamada síncrona, 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\&key={api key}' \\ \ header 'content type application/json' \\ \ data '{ "teste" "body" }' 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 docid\ ttiu emxmpmfjbsvija1 no disparo de fluxos via 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 demais configurações 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 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' 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 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 obtendo o ip de origem do disparo o header x forwarded from contendo o ip de origem do disparo é encaminhado para o fluxo, podendo ser tratado se necessário (como numa validação de whitelist) 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