Limitation du débit pour les agents

La limitation du débit est une méthode permettant de limiter les messages à une certaine fréquence maximale. En règle générale, votre application doit limiter le nombre de messages qu’elle publie dans une conversation ou une conversation de canal individuelle. Cela garantit une expérience optimale et les messages ne s’affichent pas en tant que courrier indésirable pour vos utilisateurs.

Pour protéger Microsoft Teams et ses utilisateurs, les API de bot fournissent une limite de débit pour les demandes entrantes. Les applications qui dépassent cette limite reçoivent un état d’erreur HTTP 429 Too Many Requests. Toutes les demandes sont soumises à la même stratégie de limitation de débit, y compris l’envoi de messages, d’énumérations de canaux et d’extractions de listes.

Étant donné que les valeurs exactes des limites de débit sont susceptibles d’être modifiées, votre application doit implémenter le comportement d’interruption approprié lorsque l’API retourne HTTP 429 Too Many Requests.

Gérer les limites de débit

Lors de l’émission d’une opération Bot Builder SDK, vous pouvez gérer Microsoft.Rest.HttpOperationException et vérifier le code d’état.

Le code suivant montre un exemple de limites de débit de gestion :

try
{
    // Perform Agent Framework operation
    // for example, await connector.Conversations.UpdateActivityAsync(reply);
}
catch (HttpOperationException ex)
{
    if (ex.Response != null && (uint)ex.Response.StatusCode ==  429)
    {
        //Perform retry of the above operation/Action method
    }
}

Une fois que vous avez géré les limites de débit pour les agents, vous pouvez gérer HTTP 429 les réponses à l’aide d’une interruption exponentielle.

Gérer HTTP 429 réponses

Vous devez prendre des précautions simples pour éviter de recevoir des HTTP 429 réponses. Par exemple, évitez d’émettre plusieurs demandes à la même conversation personnelle ou de canal. Au lieu de cela, créez un lot de demandes d’API.

L’utilisation d’un backoff exponentiel avec une instabilité aléatoire est la méthode recommandée pour gérer les 429. Cela garantit que plusieurs requêtes n’introduisent pas de collisions lors de nouvelles tentatives.

Après avoir traité HTTP 429 réponses, vous pouvez passer en revue l’exemple pour détecter les exceptions temporaires.

Exemple de détection d’exceptions temporaires

Le code suivant montre un exemple d’utilisation du backoff exponentiel à l’aide du bloc d’application de gestion des erreurs temporaires :

public class BotSdkTransientExceptionDetectionStrategy : ITransientErrorDetectionStrategy
    {
        // List of error codes to retry on
        List<int> transientErrorStatusCodes = new List<int>() { 429 };

        public bool IsTransient(Exception ex) 
          {
          {
              if (ex.Message.Contains("429"))
                  return true;

              HttpResponseMessageWrapper? response = null;
              if (ex is HttpOperationException httpOperationException)
              {
                  response = httpOperationException.Response;
              }
              else
              if (ex is ErrorResponseException errorResponseException)
              {
                  response = errorResponseException.Response;
              }
              return response != null && transientErrorStatusCodes.Contains((int)response.StatusCode);
          }
    }

Vous pouvez effectuer des backoffs et des nouvelles tentatives à l’aide de gestion des erreurs temporaires. Pour obtenir des instructions sur l’obtention et l’installation du package NuGet, consultez ajouter le bloc d’application de gestion des erreurs temporaires à votre solution. Consultez également de gestion des erreurs temporaires.

Une fois que vous avez passé en revue l’exemple de détection des exceptions temporaires, passez par l’exemple de backoff exponentiel. Vous pouvez utiliser le backoff exponentiel au lieu de réessayer en cas d’échec.

Exemple d’interruption

En plus de détecter les limites de débit, vous pouvez également effectuer un backoff exponentiel.

Le code suivant montre un exemple de backoff exponentiel :

/**
* The first parameter specifies the number of retries before failing the operation.
* The second parameter specifies the minimum and maximum backoff time respectively.
* The last parameter is used to add a randomized  +/- 20% delta to avoid numerous clients retrying simultaneously.
*/
var exponentialBackoffRetryStrategy = new ExponentialBackoffRetryStrategy(3, TimeSpan.FromSeconds(2),
                        TimeSpan.FromSeconds(20), TimeSpan.FromSeconds(1));


// Define the Retry Policy
var retryPolicy = new RetryPolicy(new BotSdkTransientExceptionDetectionStrategy(), exponentialBackoffRetryStrategy);

//Execute any bot sdk action
await retryPolicy.ExecuteAsync(() => connector.Conversations.ReplyToActivityAsync( (Activity)reply) ).ConfigureAwait(false);

Vous pouvez également exécuter une méthode System.Action avec la stratégie de nouvelle tentative décrite dans cette section. La bibliothèque référencée vous permet également de spécifier un intervalle fixe ou un mécanisme de backoff linéaire.

Stockez la valeur et la stratégie dans un fichier de configuration pour affiner et ajuster les valeurs au moment de l’exécution.

Pour plus d’informations, consultez modèles de nouvelles tentatives.

Vous pouvez également gérer la limite de débit à l’aide de la limite par agent et par thread.

Limite par agent et par thread

La limite par agent par thread contrôle le trafic qu’un agent est autorisé à générer dans une seule conversation. Une conversation est 1:1 entre l’agent et l’utilisateur, une conversation de groupe ou un canal dans une équipe. Par conséquent, si l’application envoie un message d’agent à chaque utilisateur, la limite de threads n’est pas limitée.

Le tableau suivant fournit les limites par agent et par thread :

Vous pouvez également gérer la limite de débit à l’aide de la limite par thread pour tous les agents.

Limite par thread pour tous les agents

La limite par thread pour tous les agents contrôle le trafic que tous les agents sont autorisés à générer dans une même conversation. Une conversation ici est 1:1 entre l’agent et l’utilisateur, une conversation de groupe ou un canal dans une équipe.

Le tableau suivant fournit la limite par thread pour tous les agents :

Étape suivante

Voir aussi

• Générer des agents pour Teams
• Gérer une opération de longue durée