- Démarrage
- À propos d'OData et des références
- Fichiers énumérés (Enumerated Files)
- Authentification
- Création des requêtes d'API
- Autorisations par point de terminaison
- Codes de réponse
- Optimisation des limites de débit et des champs de données volumineux
- Définition Swagger
- API Orchestrator
- Demandes d'alertes
- Requêtes relatives aux actifs
- Requêtes de calendriers
- Requêtes relatives aux environnements
- Requêtes de dossiers
- Requêtes de tâches génériques
- Requêtes relatives aux tâches
- Requêtes relatives aux bibliothèques
- Requêtes relatives aux licences
- Requêtes relatives aux paquets (Packages Requests)
- Requêtes relatives aux autorisations
- Demandes d'espaces de travail personnels
- Requêtes relatives aux processus
- Traiter les requêtes liées à la stratégie de conservation des données
- Demandes d'éléments de la file d'attente
- Requêtes en matière de stratégie de rétention des files d’attente
- Requêtes relatives aux Robots
- Requêtes relatives aux rôles (Roles Requests)
- Requêtes relatives aux planifications
- Requêtes relatives aux paramètres
- Requêtes de compartiments de stockage
- Requêtes de tâches
- Demandes de catalogues de tâches
- Demandes de formulaires de tâches
- Requêtes relatives aux locataires
- Requêtes relatives aux transactions
- Requêtes relatives aux utilisateurs
- Requêtes relatives aux Webhooks
Optimisation des limites de débit et des champs de données volumineux
- Elles garantissent la prévisibilité du système : connaître la limite d'appels API permet de mieux concevoir et de mieux gérer vos applications. Cela assure un environnement prédictible, ce qui réduit les éventuelles surprises dues à des dépassements de limite inattendus.
- Elles améliorent les performances : en contrôlant le trafic sur nos serveurs, nous assurons des performances optimales et des réponses plus rapides, ce qui améliore considérablement votre expérience produit.
- Elles renforcent la sécurité : les limites détaillées ci-dessous agissent comme un niveau de sécurité supplémentaire, protégeant votre système face à d'éventuelles cybermenaces.
- Elles garantissent une utilisation adéquate : nos limites de débit garantissent une attribution équitable des ressources à tous les utilisateurs, ainsi qu'un fonctionnement fluide, même au cours des périodes d'utilisation maximale.
Les limites et les optimisations des champs de données volumineux décrites ci-dessous nécessitent certains ajustements de votre part, mais nous sommes convaincus qu’elles généreront des avantages à long terme.
Voici les limites que nous appliquons :
Endpoint |
Limits |
Date d’entrée en vigueur | Exemples |
---|---|---|---|
|
|
Locataires Communauté (Community), Contrôle de validité (Canary) et Enterprise : juillet 2024 |
|
|
|
Locataires Communauté (Community), Contrôle de validité (Canary) et Enterprise : juillet 2024 |
|
|
100 requêtes d’API/jour/locataire |
Locataires Community, Canary et Enterprise : octobre 2024 |
S/O |
| 100 requêtes d’API/jour/locataire |
Locataires Community, Canary et Enterprise : octobre 2024 |
S/O |
|
100 requêtes d’API/jour/locataire |
Locataires Community, Canary et Enterprise : octobre 2024 |
S/O |
|
100 requêtes d’API/jour/locataire |
Locataires Community, Canary et Enterprise : octobre 2024 |
S/O |
1 Une utilisation hors automatisation fait référence à des appels API provenant d’intégrations d’API extérieures aux processus, tels que les scripts PowerShell et les outils de surveillance tiers.
2 Une utilisation avec automatisation fait référence des appels API provenant des activités Obtenir les éléments de file d’attente (Get Queue Items), Obtenir les tâches (Get Jobs) et Requête HTTP d’Orchestrator (Orchestrator HTTP Request).
GET/odata/Jobs(<job_id>)
n’est pas limité.
Ces limites ne s’appliquent pas à l’ajout d’éléments de file d’attente ni au traitement des tâches. Ainsi, il n’y a aucun impact sur l’ajout d’un élément de file d’attente, sa suppression, la configuration de son état, ou encore le démarrage et le traitement d’un certain nombre de tâches.
Vous pouvez suivre votre utilisation d’API par mois ou par jour en vous rendant sur l’onglet Audit d’API de la fenêtre Surveillance, au niveau du locataire.
En-tête |
Description |
Exemple |
---|---|---|
|
Toutes les demandes au-delà des limites susmentionnées reçoivent une réponse HTTP 429 comportant cet en-tête. Elle affiche le nombre de secondes que vous devez attendre avant que le point de terminaison ne soit à nouveau disponible. |
Retry-After: 10 signifie que la limite de débit sur le point de terminaison expire dans dix secondes. Toutes les nouvelles tentatives dans ces dix secondes entraîneront une réponse 429.
|
|
Nombre d’appels restants |
X-RateLimit-Remaining: 30 signifie qu’il vous reste 30 appels dans la plage horaire actuelle
|
Si le nombre de requêtes par minute est inférieur à 10, il sera renvoyé comme 0.
Les activités suivantes sont affectées par ces limites :
- Get Job
- Obtenir les éléments de file d'attente (Get Queue Items)
- Requête HTTP d’Orchestrator (Orchestrator HTTP Request), lorsque celle-ci est utilisée pour appeler les points de terminaison
GET /odata/Jobs
ouGET /odata/QueueItems
Retry-after
, ce qui signifie qu'elles procèdent automatiquement à de nouvelles tentatives des opérations Orchestrator. Afin d'en bénéficier, veillez à toujours utiliser la dernière version des activités système.
Voici ce que nous vous recommandons de faire pour veiller à ce que vous ne dépassiez pas nos limites et que vous en tiriez pleinement parti :
- Analysez votre utilisation des API et les informations que vous récupérez à partir de nos points de terminaison de type
GetAll
, mentionnés plus haut. - Ajustez la fréquence des appels de votre API ainsi que les procédures d’extraction de données pour vous aligner sur ces seuils, le cas échéant.
- Utilisez l’option d’exportation de données en temps réel d’Insights pour effectuer des exportations en temps réel.
- Consultez les sections Exportation des tâches et Exportation des éléments de la file d’attente pour obtenir des exemples de récupération des données des tâches et des éléments de la file d’attente à des fins de création de rapports et d’archivage uniquement.
Important :
- Ces points de terminaison sont limités à 100 requêtes API/jour/locataire.
Une fois cette limite dépassée, une erreur #4502 s’affiche indiquant que la limite quotidienne par locataire a été atteinte. La limite se réinitialise à 00 h 00 UTC.
- N’utilisez pas ces points de terminaison à des fins de récupération de données en temps réel.
- Ces points de terminaison sont limités à 100 requêtes API/jour/locataire.
- Veillez à toujours utiliser la dernière version des activités système.
- Contactez votre gestionnaire de compte ou notre équipe d’assistance si vous avez des questions ou désirez avoir plus de précisions.
Ces alertes, disponibles dans la section Limites de débit d'API de vos paramètres d'alerte, vous avertissent lorsqu'une limite a été dépassée et fournissent des informations utiles sur le point de terminaison impacté.
- Le volume des requêtes a dépassé la limite le dernier jour : niveau de gravité Avertissement
- Alerte envoyée quotidiennement, dans l'application et par e-mail.
- Vous y êtes abonné par défaut.
- Inclut le nom du point de terminaison pour lequel le nombre de requêtes a été dépassé.
- Il comprend un lien vers la fenêtre de surveillance de l’audit d’API au niveau du locataire, centrée sur la vue quotidienne. Plus de détails ici.
- Vous devez disposer de l’autorisation Audit - Consultation.
- Le volume des requêtes a dépassé la limite : niveau de gravité Erreur
- Alerte envoyée toutes les dix minutes, dans l'application et par e-mail.
- Vous y êtes désabonné par défaut.
- Inclut le nom du point de terminaison pour lequel le nombre de requêtes a été dépassé.
- Il comprend un lien vers la fenêtre de surveillance de l’audit d’API au niveau du locataire, centrée sur la vue détaillée de 10 minutes. Plus de détails ici.Remarque : il peut y avoir un délai de 10 minutes entre le moment où la limite est dépassée et le moment à laquelle l'alerte est envoyée.
- Vous devez disposer de l’autorisation Audit - Consultation.
Scénarios d’alerte
Vous recevez une alerte dans les scénarios suivants :
- Lorsque vous dépassez 100 demandes d’API/minute/locataire via une utilisation sans automatisation.
- Lorsque vous dépassez 1 000 demandes d’API/minute/locataire via une utilisation avec automatisation.
Les points de terminaison d’API utilisés pour récupérer des listes de tâches et d’éléments de file d’attente peuvent s’avérer problématiques lorsqu’ils sont utilisés à des fins de surveillance en temps réel et d’exportation de données. Par exemple :
-
Si la requête concerne 1000 éléments et que chaque élément représente 1 Mo de données volumineuses, la réponse à un seul appel d’API peut atteindre une taille de 1 Go. Dans la mesure où certains intermédiaires n’autorisent pas les réponses d’une taille aussi importante, cela conduit à un échec des requêtes.
-
Lorsque des filtres complexes sont utilisés et que la pagination d’une file d’attente contient plusieurs millions d’éléments de file d’attente, les requêtes peuvent conduire une expiration du délai de traitement après quelques dizaines de pages. Cela est lié à la quantité de données devant être extraites de la base de données.
Jobs - GetAll
. Voici les champs concernés :
Endpoint |
Champs omis |
Ce que vous pouvez utiliser à la place |
Date d’entrée en vigueur |
---|---|---|---|
|
|
|
Locataires Communauté (Community) et Contrôle de validité (Canary) : mars 2024 Locataires Enterprise : juillet 2024 |
GET /odata/Jobs
, que ce soit via une API ou via les activités Obtenir les tâches (Get Jobs), Obtenir les éléments de file d’attente (Get Queue Items) ou Requête HTTP d’Orchestrator (Orchestrator HTTP Request), vous devez déterminer si vous utilisez l’un des champs répertoriés. Si c’est le cas, veuillez noter que le contenu de ces champs sera renvoyé comme étant nul.
Nous vous recommandons de tester les processus dans vos locataires Canary afin d’en évaluer l’impact.
GET/odata/QueueItems
sont optimisées grâce à l'application des limitations de taille suivantes à ses champs :
Champ |
Limite | Date d’entrée en vigueur |
Comment savoir si vous êtes impacté |
Comment résoudre ce problème |
---|---|---|---|---|
Progression (Progress) |
1 048 576 caractères |
> Locataires Communauté (Community) et Contrôle de validité (Canary) : avril 2024 > Locataires Enterprise : mai 2024 |
Un message d’erreur spécifique est renvoyé si les données que vous essayez de télécharger dépassent ces limites. |
Nous vous recommandons d'utiliser des compartiments de stockage et/ou le stockage d'objets blob de Data Service si vous devez stocker davantage de données. |
104 857 caractères |
Tous les locataires : septembre 2024 | |||
AnalyticsData/Analytics |
5 120 caractères |
> Locataires Communauté (Community) et Contrôle de validité (Canary) : juin 2024 > Locataires Enterprise : septembre 2024 | ||
OutputData/Output |
51 200 caractères | |||
SpecificContent/SpecificData |
256 000 caractères | |||
ProcessingException - Reason |
102 400 caractères | |||
ProcessingException - Details |
102 400 caractères |
Ces limites sont calculées sur la base du style d’encodage UTF-16, qui est principalement utilisé par SQL Server pour stocker des données.
Les informations sont stockées dans SQL Server via des types de données comme NVARCHAR. Dans ces types de données, chaque caractère, y compris les caractères largement utilisés provenant de langues telles que le chinois, le japonais et le coréen, est stocké sur 2 octets. Cela peut prêter à confusion lorsque vous vérifiez la charge utile des données à l’aide du Bloc-notes ou en UTF-8, car ils affichent 1 octet par caractère (principalement ASCII 0-127 abc123, etc.).
Par exemple, si vous deviez stocker un caractère chinois comme 文 dans un fichier texte encodé à l’aide d’UTF-8, il serait stocké sous la forme d’une séquence de 3 octets (E6 96 87), utilisant ainsi plus d’espace de stockage. La différence entre les styles d’encodage rend le nombre de caractères non fiable en tant que limite.
Le filtre suivant est également limité afin d'optimiser les performances :
Filtrer (Filter) |
Limite |
Date d’entrée en vigueur |
Comment savoir si vous êtes impacté |
Comment résoudre ce problème |
---|---|---|---|---|
|
> Si vous n'utilisez pas le filtre
$top , vous recevez 100 enregistrements par défaut.
> Si vous utilisez le filtre
$top , vous recevez un maximum de 100 enregistrements. Tout dépassement de ce seuil de 100 génère un message d'erreur 400 Bad Request .
|
> Locataire Communauté (Community) et Contrôle de validité (Canary) : juin 2024 > Locataires Enterprise : septembre 2024 |
Entreprise : nous prévoyons d'envoyer une notification par e-mail aux administrateurs lorsque nous détectons l'utilisation de ce filtre dans des appels API. Nous vous remercions également de surveiller cela attentivement de votre côté. |
Nous vous recommandons de modifier en conséquence votre logique d'utilisation du processus ou de l'API lorsque vous prévoyez de dépasser cette limite. |
Jobs
et QueueItems
:
- Consultez les sections les sections Exportation des tâches et Exportation des éléments de la file d’attente pour obtenir des exemples de récupération des données des tâches et des éléments de la file d’attente.
- Utilisez l’option d’exportation de données en temps réel d’Insights.
- Contactez votre gestionnaire de compte ou notre équipe d’assistance si les méthodes précédentes ne fonctionnent pas pour vous.
Les limites de débit et les modifications des champs de données volumineux ne seront pas implémentées dans les environnements locaux.
Si vous utilisez une version autonome d’Orchestrator et que vous envisagez de passer au cloud, vous pouvez utiliser les journaux des requêtes IIS afin de déterminer le volume des requêtes pour les points de terminaison impactés. L’analyse dépendra de votre méthode d’agrégation des journaux, pour laquelle vous pouvez par exemple utiliser l’analyseur de journaux Microsoft.
Pour évaluer l’impact sur les champs de données volumineux, nous vous recommandons de tester vos processus dans les locataires Canary.