Quando um pipeline é configurado e publicado com o HTTP Trigger, um endpoint HTTP é criado automaticamente. Você pode visualizar esse endpoint após a implantação - basta clicar no cartão do pipeline na tela de Runtime.

Com esse trigger, você tem a flexibilidade de definir diferentes tipos de conteúdo tanto para a requisição como para a resposta do endpoint.

Dê uma olhada nos parâmetros de configuração do trigger:

  • Methods: serve para configurar os verbos HTTP a serem suportados pelo endpoint após a implantação. Caso nenhum valor seja informado, será assumido o valor default: POST, PUT, GET, PATCH, DELETE e OPTIONS.

  • Request Content Types: determina os tipos de conteúdo que o endpoint pode receber. Se o parâmetro for deixado vazio, qualquer Content-type é aceito.

  • Response Content Types: tipos de conteúdo a serem retornados pelo endpoint quando o processamento no pipeline terminar. Esse parâmetro não pode ser deixado vazio (a resposta depende de tratamento com o mock + Double Braces).

  • Maximum Timeout: tempo limite para que o pipeline processe informações antes de retornar uma resposta (padrão = 30000, limite = 300000). Em milissegundos. Caso o processamento demore mais do que a determinação do parâmetro, a requisição é finalizada e retorna status-code 500, porém sem corpo nenhum.

  • Maximum Request Size: tamanho máximo do payload (em MB). O limite máximo do payload configurável é de 5MB. Caso o payload enviado pelo consumidor do endpoint ultrapasse o limite, será retornada uma mensagem indicando que o tamanho máximo foi ultrapassado e um status-code 413 com a seguinte mensagem:

{
"message": "Request size limit exceeded"
}

  • External API: se a opção estiver ativada, a API é publicada em um gateway externo.

  • Internal API: se a opção estiver ativada, a API é publicada em um gateway interno. Nesse caso, o IP interno é acessível apenas através da VPN dedicada ou do Pipeline Executor. O pipeline pode ter tanto a opção de External API quanto a Internal API habilitadas simultaneamente.

  • API Key: se a opção estiver ativada, o endpoint pode ser consumido apenas se for enviada uma chave de API previamente configurada na Plataforma.

  • Token JWT: se a opção estiver ativada, o endpoint pode ser consumido apenas se for enviado um token JWT previamente gerado por outro endpoint com essa capacidade. Leia o artigo da implementação JWT para obter mais detalhes.

  • Additional API Routes: se a opção estiver ativada, o trigger permite que você configure novas rotas. Veja mais sobre esse parâmetro abaixo.

  • Routes: exibido somente quando o parâmetro Additional API Routes estiver habilitado. É aqui que você consegue definir as rotas adicionais do endpoint.

  • Allow Redelivery Of Messages: se a opção estiver ativada, permite o reenvio da mensagem em caso de falha do Pipeline Engine. Leia o artigo sobre o Pipeline Engine para obter mais detalhes.

Additional API Routes

Conforme explicado anteriormente, essa opção serve para configurar rotas novas no endpoint.

Ao implantar um pipeline, uma URL é criada automaticamente. No entanto, você pode customizar a rota de acordo com o que for mais conveniente. Isso inclui também o recebimento de parâmetros através da rota.

Depois que os pipelines são implantados, as URLs adquirem a seguinte estrutura:

https://{env}.godigibee.io/pipeline/{realm}/v{n}/{pipeline-name}

  • {env}: valor a ser definido de acordo com o Environment utilizado na implantação (Test ou Prod)

  • {realm}: corresponde ao Realm

  • v{n}: versão principal (major) do pipeline

  • {pipeline-name}: nome dado ao pipeline

Rota estática customizada

Vamos supor que você criou o pipeline product-list. Levando em consideração o comentário acima, a sua URL teria a seguinte aparência:

https://test.godigibee.io/pipeline/realm/v1/product-list

Agora veja como configurar uma rota estática para esse caso.

Com essas configurações aplicadas e o pipeline implantado, você obtém uma nova URL:

https://test.godigibee.io/pipeline/realm/v1/products

Rota customizada com parâmetro no caminho

Usando como exemplo o mesmo pipeline configurado anteriormente, veja como configurar a rota:

Com essas configurações aplicadas e o pipeline implantado, você obtém uma nova URL:

https://test.godigibee.io/pipeline/realm/v1/products/:id

Nesse caso, o consumidor do endpoint pode enviar uma requisição contendo o id de um produto e retornar apenas as informações dele. Exemplo da URL na requisição:

https://test.godigibee.io/pipeline/realm/v1/products/10156

Para utilizar esse valor enviado pela rota dentro do pipeline, recorra à sintaxe Double Braces:

{{ message.queryAndPath.id }}

HTTP Trigger em Ação

Veja a seguir como o trigger se comporta em determinada situação e a sua respectiva configuração.

API de consulta de informações com retorno em XML

Observe como configurar um pipeline com o HTTP Trigger para retornar uma informação de dentro do pipeline em formato XML e como o retorno deve ser tratado especificamente para esse trigger.

Primeiramente, crie um novo pipeline e configure o trigger. A configuração pode ser feita da seguinte forma:

Com as configurações acima, você determina que:

  • o endpoint funciona apenas com o verbo GET;

  • a requisição aceita somente content-type relacionados ao XML;

  • o response retorna somente content-type relacionados ao XML.

Além disso, você determina que a API é do tipo externa e não precisa de token para a comunicação.

IMPORTANTE: esse exemplo serve apenas para fins educacionais. Em alguns casos você não deve deixar o endpoint aberto por questões de segurança.

Agora observe como configurar um MOCK no pipeline para que ele seja o provedor de dados que o endpoint retorna ao final. Coloque o componente indicado, conecte-o ao trigger e configure-o com o seguinte JSON:

{
"data": {
"products": [
{
"name": "Samsung 4k Q60T 55",
"price": 3278.99
},
{
"name": "Samsung galaxy S20 128GB",
"price": 3698.99
}
]
}
}

O próximo passo é adicionar um componente que transforme o JSON previamente criado em um padrão XML. Para isso, utilize o JSON To XML Transformer, adicione-o no canvas e conecte-o logo após o JSON Generator colocado previamente. Mantenha a configuração da seguinte forma:

Feito isso, o último passo é formatar e determinar como será realizado o retorno dessas informações para o consumidor. Coloque um MOCK novamente, sendo que dessa vez a sua função é apenas formatar a resposta. Conecte-o à saída do JSON To XML Transformer.

Para a configurar esse MOCK, utilize o seguinte JSON:

{
"code": 200,
"body": {{ message.data }},
"Content-Type": "text/xml"
}

  • code: HTTP Status Code a ser retornado pelo endpoint após a finalização da requisição

  • body: corpo da mensagem de resposta (Double Braces estão sendo utilizados para repassar a informação convertida no passo anterior). Esse item precisa ser necessariamente uma string. Se o dado que você deseja enviar é um JSON, utilize a função TOSTRING.

  • Content-type: tipo de conteúdo do corpo da resposta. Todos os tipos são suportados, porém precisam ser declarados no campo Response Content Types.

Ao finalizar todas essas configurações, você deve ter um pipeline parecido com o que a imagem abaixo demonstra:

Após a implantação, pegue a url gerada e envie uma requisição do tipo GET. O endpoint deve retornar o status-code 200, conforme definido anteriormente, e o corpo da resposta deve ter a seguinte aparência:

<?xml version='1.0' encoding='UTF-8' standalone='no' ?>
<doc>
<products>
<name>Samsung 4k Q60T 55</name>
<price>3278.99</price>
</products>
<products>
<name>Samsung galaxy S20 128GB</name>
<price>3698.99</price>
</products>
</doc>

Sempre que você realizar uma requisição ao endpoint criado, a estrutura da mensagem que o trigger entrega ao pipeline é sempre a mesma e segue este padrão:

{
"body": "<xml>\n\t<id>1</id>\n</xml>\t",
"form": {},
"headers": {
"Host": "pipeline-trigger-http:8100",
"Connection": "keep-alive",
"X-Forwarded-For": "***",
"X-Forwarded-Proto": "http",
"X-Forwarded-Host": "***",
"my-custom-header": "a"
},
"queryAndPath": {
"id": "1"
},
"method": "POST",
"contentType": "application/xml"
}

  • body: conteúdo a ser enviado no payload do request para ser transformado em string neste campo

  • form: se o form-data for utilizado no request, os dados enviados são entregues neste campo

  • headers: os headers enviados no request são entregues neste campo, mas alguns são preenchidos automaticamente de acordo com a ferramenta utilizada para realizar o request

  • queryAndPath: os parâmetros de query e path passados na URL são entregues neste campo

  • method: método HTTP utilizado no request a ser entregue neste campo

  • contentType: quando informado no request, o valor do Content-type é repassado para o pipeline dentro deste campo

Encontrou sua resposta?