Mises à jour: Consultez les notes de version pour découvrir les nouvelles fonctionnalités et les mises à jour du produit.

Cette page a été traduite par l'API Cloud Translation.

Webhooks

Un webhook est un rappel HTTPS créé par un partenaire qui spécifie la manière dont votre agent doit répondre aux messages et aux événements. Après avoir configuré votre webhook, vous pouvez commencer à recevoir des messages ; et les événements.

Webhooks de partenaires et d'agents

Vous pouvez configurer votre webhook au niveau du partenaire ou de l'agent. d'application.

Le webhook de partenaire s'applique à chaque agent dont vous gérez la gestion. Si vos agents ont un comportement similaire, ou si vous n'avez qu'un seul agent, Utilisez le webhook partenaire.
Les webhooks d'agents s'appliquent aux agents individuels. Si vous gérez plusieurs agents avec un comportement distinct, vous pouvez Définissez un webhook différent pour chaque agent.

Si vous avez configuré un webhook de partenaire et un webhook d'agent, l'agent le webhook a la priorité sur son agent spécifique, tandis que le webhook de partenaire s'applique à tous les agents n'ayant pas leur propre webhook.

Configurer un webhook d'agent

Vous recevez les messages envoyés à votre agent dans le webhook de votre partenaire. Si vous voulez pour qu'un agent spécifique arrive sur un webhook différent, définissez une Webhook de l'agent.

Ouvrez la console développeur Business Communications. et connectez-vous avec votre compte Google partenaire RBM.
Cliquez sur votre agent.
Cliquez sur Integrations (Intégrations).
Pour Webhook, cliquez sur Configurer.
Dans le champ URL du point de terminaison du webhook, saisissez l'URL de votre webhook commençant par "https://".
Notez la valeur clientToken. Vous en avez besoin pour vérifier que les messages que vous recevez proviennent de Google.
Configurez votre webhook pour qu'il accepte une requête POST avec les le paramètre clientToken et envoyer une réponse 200 OK avec la valeur en texte brut ; du paramètre secret en tant que corps de la réponse.

Par exemple, si votre webhook reçoit une requête POST avec les éléments suivants : corps du contenu
```
{
  "clientToken":"SJENCPGJESMGUFPY",
  "secret":"1234567890"
}
```
votre webhook doit confirmer la valeur clientToken et, si clientToken est la bonne réponse. Renvoyez une réponse 200 OK avec 1234567890 sous la forme le corps de la réponse:
```
// 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);
});
```
Dans la console développeur, cliquez sur Valider. Quand RBM valide votre webhook, la boîte de dialogue se ferme.

Vérifier les messages entrants

Étant donné que les webhooks peuvent recevoir des messages de n'importe quel expéditeur, vous devez vérifier que Google a envoyé des messages entrants avant de traiter leur contenu.

Pour vérifier que Google a envoyé un message que vous avez reçu, procédez comme suit:

Extrayez l'en-tête X-Goog-Signature du message. Il s'agit d'une valeur hachée, de la charge utile du corps du message, encodée en base64.
Décodez la charge utile RBM en base64 dans l'élément message.body de la requête.
À l'aide du jeton client du webhook (que vous avez spécifié lors de la configuration webhook) comme clé, créez un HMAC SHA512 des octets de la charge utile du message décodé en base64 et le résultat est encodé en base64.
Comparez le hachage X-Goog-Signature à celui que vous avez créé.
- Si les hachages correspondent, vous avez confirmé que Google a envoyé le message.
- Si les valeurs de hachage ne correspondent pas, vérifiez votre processus de hachage sur une propriété connue .
  
  Si votre processus de hachage fonctionne correctement et que vous recevez une qui vous a été envoyé de manière frauduleuse, nous contacter.

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);

Gestion des messages

Le renvoi de tout élément autre que 200 OK à partir d'un webhook est considéré comme une distribution. l'échec.

Les développeurs doivent garder à l'esprit que l'envoi de messages à un taux élevé générer des notifications webhook à des taux élevés et doivent concevoir leur code pour pour s'assurer qu'ils peuvent les utiliser au rythme attendu. Il est important que les développeurs prennent en compte les situations susceptibles de provoquer des réponses aux échecs, y compris Réponses 500 de leur conteneur Web, délais avant expiration ou échecs en amont. Thing à prendre en compte:

Assurez-vous que vos protections contre les attaques DDoS sont configurées pour gérer les le taux de notifications Webhook.
Assurez-vous que les ressources telles que les pools de connexions à la base de données ne sont pas épuisées et génèrent des délais avant expiration ou des réponses 500.

Comportement en cas d'échec de distribution

RBM utilise un mécanisme d'intervalle entre les tentatives lorsqu'il reçoit une réponse autre que 200 OK à partir d'un appel webhook. RBM augmentera le temps d'attente entre de nouvelles tentatives d'exécution jusqu'à 600 secondes. Les retraits se poursuivront pendant sept jours, après quoi le message est supprimé.

Implications des webhooks au niveau de l'agent

RBM met en file d'attente les messages d'un partenaire dans une file d'attente. Où un partenaire utilise-t-il les webhooks d'agent, il est important de garder à l'esprit que l'échec le webhook aura une incidence sur la diffusion vers d'autres webhooks. Les webhooks appartenant à d'autres les agents sont appelés pendant la période d'interruption en cas d'échec du message. les messages ayant échoué sont mis en file d'attente pour être réessayés, les taux de distribution globaux chutent et d'autres sont affectées.

Il est important que les développeurs comprennent ce modèle et codent en conséquence, dans la mesure du possible, à accepter les messages et à les mettre en file d'attente en vue de leur traitement et minimiser le risque de renvoi d'un échec.

Étapes suivantes

Une fois votre webhook configuré, votre agent peut recevoir des messages de votre appareils de test. Envoyer un message pour valider votre configuration.

Cloud Pub/Sub