Webhooks

Um webhook é um URL especificado pelo parceiro em que a plataforma do RCS for Business posta mensagens e eventos. Esse URL funciona como um endpoint que recebe solicitações POST HTTPS com dados sobre os eventos. Isso significa que os dados são enviados ao seu aplicativo com segurança por HTTPS.

Um URL de webhook pode ser assim: https://[your company name].com/api/rbm-events. Depois de configurar o webhook, você pode começar a receber mensagens e eventos.

Webhooks de parceiros e de agentes

É possível configurar o webhook no nível do parceiro ou do agente.

O webhook do parceiro se aplica a todos os agentes que você mantém. Se os agentes tiverem um comportamento semelhante ou se você tiver apenas um agente, use o webhook do parceiro.
Os webhooks de agente se aplicam a agentes individuais. Se você opera vários agentes com comportamentos distintos, é possível definir um webhook diferente para cada um deles.

Se você tiver configurado um webhook de parceiro e um webhook de agente, o webhook de agente terá precedência no agente específico, enquanto o webhook de parceiro será aplicado a todos os agentes que não tiverem um webhook próprio.

Configurar um webhook de agente

Você recebe mensagens enviadas ao seu agente no webhook do parceiro. Se você quiser que mensagens de um agente específico cheguem a um webhook diferente, defina um webhook do agente.

Abra o Business Communications Developer Console e faça login com a Conta do Google do seu parceiro do RCS for Business.
Clique no seu agente.
Clique em Integrations.
Em Webhook, clique em Configurar.
Em URL do endpoint do webhook, insira o URL do webhook começando com "https://".
Anote o valor de clientToken. Você precisa dele para verificar se as mensagens recebidas são do Google.
Configure seu webhook para aceitar uma solicitação POST com o parâmetro clientToken especificado e envie uma resposta 200 OK com o valor de texto simples do parâmetro secret como o corpo da resposta.

Por exemplo, se o webhook receber uma solicitação POST com o seguinte conteúdo do corpo:
```
{
  "clientToken":"SJENCPGJESMGUFPY",
  "secret":"1234567890"
}
```
então seu webhook precisa confirmar o valor clientToken e, se clientToken estiver correto, retornar uma resposta 200 OK com 1234567890 como o corpo da resposta:
```
// clientToken from Configure
const myClientToken = "SJENCPGJESMGUFPY";

// Example endpoint
app.post("/rbm-webhook", (req, res) => {
  const msg = req.body;
  if (msg.clientToken === myClientToken) {
      res.status(200).send(msg.secret);
      return;
  }
  res.send(400);
});
```
No Developer Console, clique em Verificar. Quando o RCS for Business verifica seu webhook, a caixa de diálogo é fechada.

Verificar mensagens recebidas

Como os webhooks podem receber mensagens de qualquer remetente, verifique se o Google enviou as mensagens recebidas antes de processar o conteúdo delas.

Para verificar se o Google enviou uma mensagem que você recebeu, siga estas etapas:

Extraia o cabeçalho X-Goog-Signature da mensagem. É uma cópia com hash e codificada em base64 do payload do corpo da mensagem.
Decodifique em base64 o payload do RCS for Business no elemento message.body da solicitação.
Usando o token do cliente do webhook (que você especificou ao configurar o webhook) como uma chave, crie um HMAC SHA512 dos bytes do payload da mensagem decodificada em base-64 e codifique o resultado em base64.
Compare o hash X-Goog-Signature com o hash que você criou.
- Se os hashes forem iguais, você confirmou que o Google enviou a mensagem.
- Se os hashes não corresponderem, verifique o processo de hash em uma mensagem conhecida.
  
  Se o processo de hash estiver funcionando corretamente e você receber uma mensagem que acredita ter sido enviada de forma fraudulenta, entre em contato com nossa equipe.

Node.js

  if ((requestBody.hasOwnProperty('message')) && (requestBody.message.hasOwnProperty('data'))) {
    // Validate the received hash to ensure the message came from Google RBM
    let userEventString = Buffer.from(requestBody.message.data, 'base64');
    let hmac = crypto.createHmac('sha512', CLIENT_TOKEN);
    let data = hmac.update(userEventString);
    let genHash = data.digest('base64');
    let headerHash = req.header('X-Goog-Signature');

    if (headerHash === genHash) {
      let userEvent = JSON.parse(userEventString);

      console.log('userEventString: ' + userEventString);
      handleMessage(userEvent);
    } else {
      console.log('hash mismatch - ignoring message');
    }
  }

  res.sendStatus(200);

Gerenciamento de mensagens

Retornar qualquer coisa diferente de 200 OK de um webhook é considerado uma falha na entrega.

Os desenvolvedores precisam ter em mente que o envio de mensagens em altas taxas vai gerar notificações de webhook também em altas taxas. Por isso, é necessário projetar o código para processar as notificações na taxa esperada. É importante que os desenvolvedores considerem situações que podem causar respostas de falha, incluindo respostas 500 do contêiner da Web, tempos limite ou falhas upstream. Algumas coisas a considerar:

Verifique se as proteções contra DDoS estão configuradas para processar a taxa esperada de notificações de webhook.
Confirme se recursos como pools de conexões de banco de dados não estão esgotados e produzem tempos limite ou respostas 500.

Os desenvolvedores precisam projetar os sistemas para que o processamento de eventos do RBM ocorra de forma assíncrona e não impeça o webhook de retornar 200 OK.

Processamento assíncrono de webhook

É importante não processar o evento do RBM no próprio webhook. Qualquer erro ou atraso durante o processamento pode afetar o código de retorno do webhook:

Processamento síncrono de webhook

Comportamento em caso de falha na entrega

Se o webhook retornar algo diferente de um status 200 OK, a plataforma RCS para Empresas usará um mecanismo de espera e nova tentativa para reenviar os dados. Isso significa que o sistema aumenta progressivamente o atraso entre cada tentativa de entrega, até atingir uma frequência máxima de uma nova tentativa a cada 10 minutos para cada mensagem pendente. O ciclo de novas tentativas continua por sete dias. Depois disso, a mensagem é excluída permanentemente.

Implicações dos webhooks no nível do agente

O RCS for Business coloca as mensagens de um parceiro em uma fila. Todos os agentes em uma única conta de parceiro compartilham uma única fila. Por isso, uma falha em um webhook pode bloquear toda a fila, impedindo que os eventos de usuário de todos os agentes cheguem ao parceiro.

Várias mensagens não confirmadas podem causar um aumento enorme nos eventos de nova tentativa. Por exemplo, se um agente não confirmar 1.600 recibos de entrega e a frequência de novas tentativas atingir o limite de 10 minutos, isso poderá gerar aproximadamente 230.000 erros potenciais por dia:

1.600 mensagens × 6 novas tentativas por hora × 24 horas por dia = aproximadamente 230.000 erros por dia

Esse volume de novas tentativas pode bloquear a fila compartilhada do Pub/Sub e causar atrasos significativos no recebimento de eventos do usuário para todas as campanhas de um parceiro.

Práticas recomendadas

Para garantir a confiabilidade do tráfego de produção e evitar bloqueadores de fila, siga estas práticas recomendadas:

Retorne 200 OK imediatamente: o webhook precisa receber a mensagem, armazenar em uma fila local e retornar uma resposta 200 OK em menos de cinco segundos.
Desacoplar o processamento: use workers em segundo plano separados para processar a lógica de mensagens da fila local.
Monitore agentes de teste: trate os agentes de desenvolvimento como agentes de produção, porque eles também podem bloquear a fila de parceiros compartilhada se falharem.
Contas dedicadas para testes: de preferência, use uma conta de desenvolvedor para agentes de produção e uma conta de desenvolvedor dedicada para agentes de teste.
Verificar o tráfego do Google: use o DNS reverso ou o cabeçalho X-Goog-Signature em vez da lista de permissões de IP fixo, já que o Google usa IPs anycast dinâmicos. Para mais informações sobre a verificação manual e a identificação de intervalos de IP do Google, consulte a documentação Verificar solicitações do Google e, especificamente, os arquivos JSON para coletores acionados pelo usuário e coletores acionados pelo usuário do Google.

Próximas etapas

Depois de configurar o webhook, o agente poderá receber mensagens dos seus dispositivos de teste. Envie uma mensagem para validar sua configuração.

Avançar

Dialogflow