Os agentes do RBM recebem mensagens e eventos por meio de uma relação de publicação/assinatura com o Google Cloud Pub/Sub. Quando um usuário responde às mensagens do seu agente, a plataforma RBM publica essas mensagens em um tópico exclusivo do Pub/Sub que só pode ser acessado pelo agente. O agente acessa essas mensagens e esses eventos por meio de uma assinatura do tópico exclusivo.
O Pub/Sub aceita dois tipos de assinaturas: push e pull. Com uma assinatura de push, o Cloud Pub/Sub envia mensagens para um URL de webhook que você configura. Com uma assinatura de pull, você é responsável por escrever código para criar um listener de mensagens de longa duração e confirmar mensagens ao recebê-las.
A abordagem mais conhecida e conhecida pela maioria dos desenvolvedores é a assinatura de push. Se você já usou APIs de terceiros, provavelmente já trabalhou com URLs de retorno de chamada/webhook. Embora essa abordagem seja simples, ela exige um URL disponível publicamente, que obriga os desenvolvedores a implantarem servidores da Web públicos sempre que desejam testar uma alteração.
Neste artigo, você aprenderá como configurar uma assinatura de pull para testes locais e como usar essa assinatura em um ambiente de produção com o App Engine do Google Cloud.
Como configurar o Pub/Sub para uma assinatura de pull
Se você ainda não tiver configurado o Pub/Sub do agente, siga as instruções no Cloud Pub/Sub para criar a assinatura inicial.
Depois de criar sua assinatura, é simples alternar de um modelo de push para pull. Acesse o Console do Google Cloud e a seção Pub/Sub > Assinaturas. Clique no menu flutuante ao lado da assinatura que você criou para o agente e selecione Editar. Você verá uma tela de configuração semelhante à imagem abaixo.
Defina o Tipo de entrega como Pull e clique em Salvar.
Como configurar um gerenciador de assinatura de pull assíncrono
Em seguida, atualize seu agente do RBM para receber mensagens da assinatura. Leia sobre como fazer isso com várias linguagens de programação em Pull assíncrono ou veja alguns dos exemplos de agentes do RBM que usam um modelo de pull.
O código abaixo demonstra como configurar um listener de assinatura de pull assíncrono no Node.js:
function initPubsub() {
let pubsub = new PubSub({
projectId: REPLACE_WITH_GCP_PROJECT_ID,
keyFilename: REPLACE_WITH_SERVICE_ACCOUNT_KEY_FILE_LOCATION,
});
// references an existing subscription, (e.g. rbm-agent-sub)
let subscription = pubsub.subscription(PUB_SUB_SUBSCRIPTION_NAME);
// create an event handler to handle messages
let messageHandler = (message) => {
console.log(`Received message ${message.id}:`);
console.log(`\tData: ${message.data}`);
console.log(`\tAttributes: ${message.attributes}`);
let userEvent = JSON.parse(message.data);
// TODO: process the userEvent to create another RBM message
// "Ack" (acknowledge receipt of) the message
message.ack();
};
// Listen for new messages
subscription.on('message', messageHandler);
return { messageHandler: messageHandler, subscription: subscription };
}
Para testar os agentes localmente, basta chamar initPubsub quando o app Express for iniciado. Você verá as respostas de impressão messageHandler no console.
Como configurar e implantar no App Engine do Google
Em um ambiente de produção, você precisa garantir que a assinatura esteja sempre disponível. Uma abordagem simples é confiar em um cron job para reinicializar o listener de mensagens do Pub/Sub periodicamente.
No App Engine, os cron jobs podem ser usados para programar tarefas com intervalos diferentes. O cron job é configurado com uma descrição, um URL e um intervalo. Em aplicativos Node.js, configure-os em um arquivo cron.yaml, que pode ser implantado no App Engine usando o SDK do Google Cloud. Leia sobre outras configurações de idioma em Como programar jobs com cron.yaml.
Como a tarefa cron precisa de um URL, você precisa adicionar um endpoint de URL ao roteador do app expresso a ser chamado pelo cron, que, por sua vez, chamará o método initPubsub da seção anterior para iniciar o listener.
router.get('/pubsubCallback', function(req, res, next) {
let pubsubConfig = initPubsub();
// Stop listening once the timeout is hit
setTimeout(() => {
pubsubConfig.subscription.removeListener('message', pubsubConfig.messageHandler);
}, CRON_JOB_TIMEOUT * 1000);
res.status(200).send();
});
Dentro do retorno de chamada, você também precisa remover o ouvinte antes que a tarefa agendada seja executada novamente. Por exemplo, se o cron job for executado a cada minuto, configure o parâmetro CRON_JOB_TIMEOUT para ser igual a 60.
Veja abaixo a configuração do arquivo cron.yaml para executar esse endpoint a cada minuto.
cron:
- description: "Processing Pub/Sub messages"
url: /pubsubCallback
schedule: every 1 mins
Para implantar as tarefas do cron no App Engine, execute o seguinte:
gcloud app deploy cron.yaml
Após a implantação, o App Engine configura automaticamente a tarefa cron, que pode ser visualizada em App Engine > Cron jobs, conforme mostrado abaixo.
Conclusão e TL;DR
O uso de uma assinatura de pull permite testar e depurar localmente, o que ajuda a acelerar os ciclos de desenvolvimento e reduz o tempo necessário para criar agentes do RBM. Embora o modelo pull exija algumas configurações e códigos adicionais em comparação com o modelo push, a configuração é simples e só precisa ser definida uma vez. Os cron jobs são uma maneira fácil de garantir que sua assinatura de pull esteja sempre disponível para lidar com o fluxo de mensagens do agente e que o Google App Engine torne a configuração e a manutenção muito baratas.
Boa sorte e uma boa codificação!