Gli agenti RBM ricevono messaggi ed eventi tramite una relazione di pubblicazione/abbonamento con Google Cloud Pub/Sub. Quando un utente risponde ai messaggi del tuo agente, la piattaforma RBM pubblica quei messaggi in un argomento Pub/Sub univoco a cui solo l'agente ha accesso. L'agente accede a questi messaggi ed eventi tramite una sottoscrizione al suo argomento univoco.
Pub/Sub supporta due tipi di sottoscrizioni: push e pull. Con una sottoscrizione push, Cloud Pub/Sub invia i messaggi a un URL webhook configurato. Con una sottoscrizione pull, sei responsabile della scrittura del codice per creare un listener di messaggi di lunga durata e di confermare i messaggi man mano che li ricevi.
L'approccio più conosciuto e popolare per la maggior parte degli sviluppatori è l'abbonamento push. Se hai utilizzato API di terze parti, probabilmente hai lavorato con gli URL di callback/webhook. Sebbene questo approccio sia semplice, richiede un URL disponibile pubblicamente, che obbliga gli sviluppatori a eseguire il deployment sui server web pubblici ogni volta che vogliono testare una modifica.
In questo articolo ti mostrerò come configurare un abbonamento pull per i test locali e come usare questo abbonamento in un ambiente di produzione con App Engine di Google Cloud.
Configurazione di Pub/Sub per una sottoscrizione pull
Se non hai già configurato Pub/Sub per l'agente, segui le istruzioni in Cloud Pub/Sub per creare la tua sottoscrizione iniziale.
Dopo aver creato l'abbonamento, è facile passare da un modello push a un modello pull. Vai a Google Cloud Console, quindi alla sezione Pub/Sub > Abbonamenti. Fai clic sul menu extra accanto all'abbonamento che hai creato per l'agente e seleziona Modifica. Dovresti vedere una schermata di configurazione simile all'immagine qui sotto.
Imposta Tipo di consegna su Pull e fai clic su Salva.
Configurazione di un gestore di abbonamenti pull asincrono
Successivamente, devi aggiornare l'agente RBM per estrarre i messaggi dalla sottoscrizione. Puoi trovare informazioni su come eseguire questa operazione con vari linguaggi di programmazione in Pulsione asincrona o dare un'occhiata ad alcuni degli esempi dell'agente RBM, molti dei quali utilizzano un modello pull.
Il codice seguente illustra come configurare un listener di abbonamenti pull pull in 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 };
}
Per testare gli agenti localmente, devi soltanto chiamare initPubsub quando l'app Express si avvia e vedrai le risposte di stampa messageHandler nella tua console.
Configurazione e deployment su App Engine di Google
In un ambiente di produzione, devi assicurarti che l'abbonamento sia sempre disponibile. Un approccio semplice è affidarsi a un cron job per reinizializzare periodicamente il listener di messaggi Pub/Sub.
In App Engine, i cron job possono essere utilizzati per pianificare le attività con intervalli diversi. Un cron job è configurato con una descrizione, un URL e un intervallo. Nelle app Node.js, le configuri in un file cron.yaml, che puoi implementare in App Engine utilizzando Google Cloud SDK. Per ulteriori informazioni sulle configurazioni di configurazione della lingua, vedi Pianificazione dei job con cron.yaml.
Poiché l'attività cron ha bisogno di un URL, devi aggiungere un endpoint URL al router dell'app espresso da chiamare tramite cron, che a sua volta chiamerà il metodo initPubsub dalla sezione precedente per avviare il 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();
});
All'interno del callback, devi anche rimuovere il listener prima che venga eseguita nuovamente l'attività pianificata. Ad esempio, se il cron job viene eseguito ogni minuto, configuri il parametro CRON_JOB_TIMEOUT su 60.
Di seguito è riportata la configurazione del file cron.yaml per eseguire questo endpoint ogni minuto.
cron:
- description: "Processing Pub/Sub messages"
url: /pubsubCallback
schedule: every 1 mins
Per eseguire il deployment delle attività cron in App Engine, esegui questo comando:
gcloud app deploy cron.yaml
Dopo il deployment, App Engine configura automaticamente l'attività cron, che sarà visibile in App Engine > Cron job come mostrato di seguito.
Conclusione e TL;DR
L'uso di una sottoscrizione pull consente di testare ed eseguire il debug localmente, contribuendo a velocizzare i cicli di sviluppo e ridurre il tempo necessario per creare agenti RBM. Sebbene il modello pull richieda una configurazione e un codice aggiuntivi rispetto al modello push, l'impostazione è semplice e deve essere configurata una sola volta. I cron job consentono di assicurarsi che l'abbonamento pull sia sempre disponibile per gestire il flusso dei messaggi dell'agente e App Engine rende la configurazione e la manutenzione a bassissimo costo.
Buona fortuna e buona programmazione!