Limites de la plateforme

La plateforme ne fournit pas une quantité infinie de ressources et le nombre d’appels d’API pouvant être effectués est limité.

L’architecte de solution doit s’assurer que la solution ne dépasse pas les limites imposées par la plateforme avec une conception appropriée et en faisant en sorte que le code personnalisé puisse gérer le dépassement des limites.

Requêtes d’API

Les requêtes dans Microsoft Power Platform consistent en diverses actions qu’un utilisateur effectue sur divers produits. La liste suivante décrit ce qui constitue une requête d’API, de manière globale :

• Power Apps : toutes les requêtes d’API aux connecteurs et à Microsoft Dataverse.
• Power Automate : toutes les requêtes d’API aux connecteurs, aux actions HTTP et aux actions intégrées, depuis l’initialisation des variables à une action de composition simple. Les actions réussies et échouées sont décomptées par rapport à ces limites. De plus, les tentatives et les requêtes supplémentaires de la pagination comptent également comme des implémentations d’actions. En général, chaque étape d’un flux de cloud Power Automate est une requête d’API.
• Dataverse : toutes les opérations de création, de lecture, de mise à jour et de suppression (CRUD), d’affectation et de partage, y compris les requêtes internes du système et les requêtes de l’utilisateur nécessaires pour effectuer des transactions CRUD, ainsi que les opérations spéciales telles que le partage ou l’affectation. Ces requêtes peuvent provenir de tout client ou de toute application et utiliser tout point de terminaison. Elles incluent, mais sans s’y limiter, des plug-ins, des flux de travail classiques et des contrôles personnalisés qui effectuent les opérations susmentionnées.

Limites de droit d’utilisation

Les limites de droit d’utilisation représentent le nombre de requêtes d’API que les utilisateurs sont autorisés à effectuer chaque jour. La limite allouée dépend du type de licence qui est attribuée à chaque utilisateur. Les limites de droit d’utilisation d’API sont basées sur une période de 24 heures, comme indiqué dans le tableau suivant :

Dataverse permet de disposer d’identités ne nécessitant aucune licence utilisateur pour interagir avec le service. Voici les quatre types d’utilisateur :

• Utilisateurs de l’application
• Utilisateurs non interactifs
• Utilisateurs administratifs
• Utilisateur SYSTÈME

Chaque abonné a une capacité de requête de base par abonné qui ne peut être utilisée que par ces utilisateurs et non par les utilisateurs disposant de licences standard. Cette capacité de requête de base est basée sur le type d’abonnement, comme suit :

• Si un abonné a au moins un abonnement à Dynamics 365 Enterprise, il bénéficie de 100 000 requêtes par 24 heures.
• Si un abonné a au moins un abonnement à Dynamics 365 Professional, il bénéficie de 50 000 requêtes par 24 heures.
• Si un abonné a au moins un abonnement à Microsoft Power Apps ou Power Automate, il bénéficie de 25 000 requêtes par 24 heures.

Le module complémentaire de capacité Power Apps et Power Automate permet aux clients d’augmenter les limites pour un utilisateur donné. Chaque module complémentaire de capacité ajoute 10 000 requêtes par 24 heures à la limite.

Limites de service

Outre la limite de requêtes d’API quotidiennes, d’autres limites de protection des services sont spécifiques à chaque service. Comme pour les limites quotidiennes, ces limites aident à maintenir la qualité du service en protégeant celui-ci contre les comportements malveillants ou perturbateurs qui pourraient autrement entraver le service pour tous les clients.

Les limites de l’API de protection des services permettent de garantir que utilisateurs exécutant des applications ne puissent pas interférer l’un avec l’autre selon les contraintes de ressources. Ces limites n’affecteront pas les utilisateurs standard de la plateforme. Seules les applications qui effectuent de nombreuses requêtes d’API peuvent être affectées. Ces limites fournissent un niveau de protection contre les pics aléatoires et inattendus des volumes des requêtes, qui menacent les caractéristiques de disponibilité et de performances de la plateforme Dataverse.

Microsoft limite le nombre de connexions simultanées par compte d’utilisateur, le nombre de requêtes d’API par connexion et le temps d’exécution pouvant être utilisé par connexion. Ces limites sont évaluées dans une fenêtre glissante de cinq minutes. Lorsque l’une de ces limites est dépassée, une exception est levée par la plateforme.

Stratégies et modèles de nouvelles tentatives

La logique personnalisée qui utilise les API doit gérer les nouvelles tentatives. Lorsqu’une erreur de limite de l’API de protection des services se produit, elle fournit une valeur indiquant la durée avant que toute nouvelle demande de l’utilisateur puisse être traitée.

L’API web renvoie une erreur 429 si la limite est atteinte. La réponse inclut un Retry-After avec le nombre de secondes. Avec le Service d’organisation, une valeur TimeSpan est renvoyée dans la collection OrganizationServiceFault.ErrorDetails avec la clé Retry-After.

Pour en savoir plus, consultez Limites de protection des services.

Réduire les appels d’API

La conception de la solution ne doit pas dépendre d’une capacité infinie disponible. Les limites ont été définies à un niveau suffisamment élevé, afin qu’il soit rare qu’un utilisateur d’une application interactive les rencontre lors d’une utilisation normale.

Les applications conçues pour charger des données dans Dataverse ou effectuer des mises à jour en bloc doivent également être en mesure de gérer les erreurs de limite de l’API de protection des services. Ces applications donnent la priorité au débit afin de pouvoir terminer leur travail en un minimum de temps. Elles doivent avoir une stratégie pour réessayer les opérations.

Les applications du portail envoient généralement des demandes d’utilisateurs anonymes via un compte principal de service. Étant donné que les limites de l’API de protection des services sont basées sur chaque utilisateur, les applications du portail peuvent atteindre les limites de l’API de protection des services en fonction de la quantité de trafic reçu par le portail.

Les intégrations doivent être optimisées pour réduire le nombre d’appels d’API.

L’architecte de solution doit également tenir compte de la haute disponibilité dans la conception de la solution.