Límites de la API de protección de servicio

Para garantizar una disponibilidad y un rendimiento coherentes para todos los usuarios, aplicamos algunos límites a cómo se usan las API. Estos límites están diseñados para detectar cuándo las aplicaciones cliente realizan demandas extraordinarias en los recursos del servidor.

Estos límites no deben afectar a los usuarios normales de clientes interactivos. Solo las aplicaciones cliente que realizan un volumen extraordinario de solicitudes de API deben verse afectadas. Estos límites proporcionan un nivel de protección frente a aumentos aleatorios e inesperados en los volúmenes de solicitudes que amenazan las características de disponibilidad y rendimiento de la plataforma Microsoft Dataverse.

Cuando una aplicación cliente realiza solicitudes extraordinariamente exigentes, Dataverse sigue el patrón común para los servicios en línea. Se devuelve un error que indica que se han recibido demasiadas solicitudes.

• Con la API web, se devuelve un error 429 Demasiadas solicitudes .
• Con el SDK de Dataverse para .NET, obtendrá un error OrganizationServiceFault con uno de los tres códigos de error específicos.

Obtenga información sobre los errores de límite de la API de protección del servicio que se devuelven.

Impacto en las aplicaciones cliente

Es responsabilidad de las aplicaciones cliente administrar errores de límite de API de protección de servicios. Exactamente cómo administrar este error depende de la naturaleza de la aplicación.

Aplicaciones cliente interactivas

Los límites de protección de servicio son lo suficientemente altos como para que sea poco frecuente que un individuo use una aplicación cliente interactiva para encontrarlos durante el uso normal. Sin embargo, es posible cuando la aplicación cliente permite operaciones masivas. Los desarrolladores de aplicaciones cliente deben tener en cuenta cómo se aplican los límites de la API de protección de servicios y diseñar la interfaz de usuario para reducir la posibilidad de que los usuarios envíen solicitudes extremadamente exigentes al servidor. Incluso cuando lo hacen, todavía deben esperar que se puedan producir errores de límite de API de protección de servicios y estar preparados para controlarlos.

Los desarrolladores de aplicaciones cliente no deben simplemente lanzar el error para mostrar el mensaje al usuario. El mensaje de error no está pensado para los usuarios finales. Más información sobre estrategias específicas para las operaciones de reintento

Aplicaciones de integración de datos

Las aplicaciones diseñadas para cargar datos en Dataverse o realizar actualizaciones masivas deben administrar errores de límite de API de protección de servicios. Estas aplicaciones priorizan el rendimiento para que puedan completar su trabajo en la cantidad mínima de tiempo. Estas aplicaciones deben tener una estrategia para volver a intentar las operaciones. Hay varias estrategias que se pueden aplicar para obtener el rendimiento máximo. Obtenga información sobre cómo maximizar el rendimiento

Aplicaciones del portal

Las aplicaciones del portal generalmente envían solicitudes de usuarios anónimos a través de una cuenta principal de servicio. Dado que los límites de la API de protección de servicios se basan en cada usuario, las aplicaciones del portal pueden alcanzar los límites de la API de protección de servicios en función de la cantidad de tráfico que experimenta el portal. Al igual que las aplicaciones cliente interactivas, no muestre al usuario final del portal los errores de los límites de la API de protección de servicios. La interfaz de usuario del portal debe deshabilitar más solicitudes y mostrar un mensaje que indica que el servidor está ocupado. El mensaje podría incluir la hora en que la aplicación puede comenzar a aceptar nuevas solicitudes, calculada utilizando la duración de Retry-After devuelta con el error.

Impacto en complementos y actividades de flujo de trabajo personalizadas

Los complementos y las actividades de flujo de trabajo personalizadas aplican lógica de negocios desencadenada por solicitudes entrantes. Los límites de protección de servicios no se aplican a las operaciones de datos que se originan en complementos y actividades de flujo de trabajo personalizadas. Los complementos y las actividades de flujo de trabajo personalizadas se cargan y se ejecutan dentro del servicio de espacio aislado. Las operaciones de Dataverse que se ejecutan en el servicio sandbox no utilizan los puntos de conexión públicos de la API.

Si la aplicación realiza operaciones que desencadenan lógica personalizada, el número de solicitudes enviadas por complementos o actividades de flujo de trabajo personalizadas no se contará para los límites de la API de protección de servicios. Sin embargo, el tiempo de cálculo adicional que estas operaciones contribuyen se agregan a la solicitud inicial que las desencadenó. Este tiempo de cálculo forma parte de los límites de la API de protección de servicios. Obtenga información sobre cómo se aplican los límites de la API de protección de servicios

Reintentar operaciones

Cuando se produce un error de límite de API de protección de servicio, proporciona un valor que indica la duración antes de que se puedan procesar las nuevas solicitudes del usuario.

• Cuando se devuelve un error 429 desde la API web, la respuesta incluye un encabezado Retry-After con el número de segundos.
• Con el SDK para .NET, se devuelve un valor TimeSpan en la colección OrganizationServiceFaultErrorDetails con la clave Retry-After.

Duración del Retry-After

La Retry-After duración depende de la naturaleza de las operaciones enviadas en el período anterior de 5 minutos. Cuanto más exigentes sean las solicitudes, más tiempo tarda en recuperarse el servidor.

Actualmente, debido a la forma en que se evalúan los límites, puede esperar superar el número de solicitudes y límites de tiempo de ejecución durante un período de 5 minutos antes de que los límites de la API de protección de servicios surtan efecto. Sin embargo, si se supera el número de solicitudes simultáneas, se devuelve un error inmediatamente. Si la aplicación sigue enviando solicitudes exigentes, la duración se amplía para minimizar el impacto en los recursos compartidos. Esto hace que el período de duración del reintento individual sea más largo, lo que significa que su aplicación ve períodos más largos de inactividad mientras espera. Este comportamiento podría cambiar en el futuro.

Cuando sea posible, se recomienda intentar lograr una tasa coherente empezando por un número menor de solicitudes y aumentando gradualmente hasta que empiece a alcanzar los límites de la API de protección de servicios. Después, deje que el servidor indique cuántas solicitudes puede controlar en un período de 5 minutos. Mantener limitado el número máximo de solicitudes en este período de 5 minutos y aumentar gradualmente mantiene baja la duración de reintento, optimizando el rendimiento total y minimizando los picos en los recursos del servidor.

Reintento de aplicaciones interactivas

Si el cliente es una aplicación interactiva, debe mostrar un mensaje que indica que el servidor está ocupado mientras vuelve a intentar la solicitud realizada por el usuario. Es posible que quiera proporcionar una opción para que el usuario cancele la operación. No permita que los usuarios envíen más solicitudes hasta que se complete la solicitud anterior que envió.

Reintento de aplicaciones no interactivas

Si el cliente no es interactivo, la práctica habitual es esperar a que pase la duración antes de volver a enviar la solicitud. Esto suele hacerse pausando la ejecución de la tarea actual mediante task.Delay o métodos equivalentes.

Cómo volver a intentar

A continuación se describe cómo reintentar aplicaciones .NET mediante el SDK de Dataverse para .NET o la API web:

SDK para .NET

Si usa el SDK para .NET, se recomienda usar las clases PowerPlatform.Dataverse.Client.ServiceClient o Xrm.Tooling.Connector.CrmServiceClient . Esas clases implementan los métodos IOrganizationService y pueden administrar los errores de límite de API de protección de servicios que se devuelven.

Las versiones de Xrm.Tooling.Connector después de la versión 9.0.2.16 (mayo de 2019) se pausarán y volverán a enviar automáticamente la solicitud después del Retry-After período de duración.

Si la aplicación usa actualmente las clases Xrm.Sdk.Client.Client.OrganizationServiceProxy o Xrm.Sdk.WebServiceClient.OrganizationWebProxyClient de bajo nivel, reemplace las por la ServiceClient clase o CrmServiceClient . El OrganizationServiceProxy está en desuso.

Más información:

• Compile aplicaciones cliente de Windows mediante las herramientas XRM.
• Desuso del tipo de autenticación de Office365 y la clase OrganizationServiceProxy para conectarse a Dataverse

API web

Si usa la API web con una biblioteca cliente, es posible que admita el comportamiento de reintento esperado para los errores 429. Consulte con el publicador de la biblioteca cliente.

Si usa PowerShell, el parámetroMaximumRetryCount del cmdlet de PowerShellInvoke-RestMethod especifica cuántas veces PowerShell reintenta una solicitud cuando se recibe un código de error entre 400 y 599, ambos incluidos o 304. Esto significa que PowerShell reintenta los errores de protección del servicio Dataverse 429 al incluir un valor para este parámetro. Más información sobre la administración de límites de protección del servicio Dataverse mediante PowerShell

Si escribió su propia biblioteca, puede incluir comportamientos similares a los que se incluyen en este código de ejemplo para una biblioteca de clases del asistente WebAPIService (C#).

/// <summary>
/// Specifies the Retry policies
/// </summary>
/// <param name="config">Configuration data for the service</param>
/// <returns></returns>
static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy(Config config)
{
    return HttpPolicyExtensions
      .HandleTransientHttpError()
      .OrResult(httpResponseMessage => httpResponseMessage.StatusCode == System.Net.HttpStatusCode.TooManyRequests)
      .WaitAndRetryAsync(
         retryCount: config.MaxRetries,
         sleepDurationProvider: (count, response, context) =>
         {
            int seconds;
            HttpResponseHeaders headers = response.Result.Headers;

            if (headers.Contains("Retry-After"))
            {
               seconds = int.Parse(headers.GetValues("Retry-After").FirstOrDefault());
            }
            else
            {
               seconds = (int)Math.Pow(2, count);
            }
            return TimeSpan.FromSeconds(seconds);
         },
         onRetryAsync: (_, _, _, _) => { return Task.CompletedTask; }
      );
}

En este ejemplo se usa Polly, una biblioteca de control de errores transitorios y resistencia de .NET que permite a los desarrolladores expresar directivas como Retry, Circuit Breaker, Timeout, Bulkhead Isolation y Fallback de forma fluida y segura para subprocesos.

Encabezados de respuesta HTTP

Si usa solicitudes HTTP con la API web, puede realizar un seguimiento de los valores de límite restantes con los siguientes encabezados de respuesta HTTP:

Header	Descripción del valor
x-ms-ratelimit-burst-remaining-xrm-requests	El número restante de solicitudes para esta conexión
x-ms-ratelimit-time-remaining-xrm-requests	Duración combinada restante para todas las conexiones que usan la misma cuenta de usuario

No debe depender de estos valores para controlar el número de solicitudes que envíe. Están diseñados para fines de depuración. Si va a quitar la cookie de afinidad, estos valores se restablecen al conectarse a otro servidor.

Aplicación de los límites de la API de protección de servicios

Dos de los límites de la API de protección de servicios se evalúan en una ventana deslizante de 5 minutos (300 segundos). Si se excede cualquiera de los límites dentro de los 300 segundos anteriores, se produce un error de límite de API de protección del servicio en las solicitudes posteriores para proteger el servicio hasta que finalice el tiempo de duración de Retry-After.

Los límites de la API de protección de servicios se evalúan por usuario. Cada usuario autenticado está limitado de forma independiente. Solo las cuentas de usuario que realizan demandas extraordinarias son limitadas. Otros usuarios no se verán afectados.

Los límites de la API de protección de servicios se aplican en función de tres facetas:

• Número de solicitudes enviadas por un usuario.
• Tiempo de ejecución combinado necesario para procesar las solicitudes enviadas por un usuario.
• Número de solicitudes simultáneas enviadas por un usuario.

Si el único límite estaba en el número de solicitudes enviadas por un usuario, sería posible omitirlo. Las otras facetas se agregaron para contrarrestar estos intentos. Por ejemplo:

• Puede enviar menos solicitudes agrupandolas en operaciones por lotes.
  • El límite del tiempo de ejecución combinado contrarresta esto.
• En lugar de enviar solicitudes individualmente en sucesión, podría enviar un gran número de solicitudes simultáneas antes de que se apliquen los límites de la API de protección de servicios.
  • El límite de solicitudes simultáneas lo contrarresta.

Cada servidor web disponible para su entorno aplica estos límites de forma independiente. La mayoría de los entornos tienen más de un servidor web. Los entornos de prueba solo se asignan a un solo servidor web. El número real de servidores web que están disponibles para su entorno depende de varios factores que forman parte del servicio administrado que proporciona Dataverse. Uno de los factores es el número de licencias de usuario que adquirió.

En la tabla siguiente se describen los límites predeterminados de api de protección de servicios aplicados por servidor web:

Medida	Description	Límite por servidor web
Número de solicitudes	Número acumulado de solicitudes realizadas por el usuario.	6000 dentro de la ventana deslizante de 5 minutos
Tiempo de ejecución	Tiempo de ejecución combinado de todas las solicitudes realizadas por el usuario.	20 minutos (1200 segundos) en la ventana deslizante de 5 minutos
Número de solicitudes simultáneas	Número de solicitudes simultáneas realizadas por el usuario	52 o superior

Importante

Estos límites están sujetos a cambios y pueden variar entre distintos entornos. Estos números representan valores predeterminados y se proporcionan para proporcionarle una idea de los valores que puede esperar.

Errores de límite de la API de protección de servicio devueltos

En esta sección se describen los tres tipos de errores de límite de API de protección de servicios que se pueden devolver, así como factores que provocan estos errores y posibles estrategias de mitigación.

• El Código de error es el valor de error numérico devuelto por el SDK para .NET OrganizationServiceFault.ErrorDetails.
• El código hex es el valor de error hexadecimal devuelto por el Web API.

Número de solicitudes

Este límite cuenta el número total de solicitudes durante el período anterior de 300 segundos.

Código de error	Código hexadecimal	Message
-2147015902	0x80072322	Number of requests exceeded the limit of 6000 over time window of 300 seconds.

No se espera que un usuario típico de una aplicación interactiva pueda enviar 1200 solicitudes por minuto para superar este límite, a menos que la aplicación permita a los usuarios realizar operaciones masivas.

Por ejemplo, si una vista de lista habilita la selección de 250 registros a la vez y permite a un usuario realizar alguna operación en todos estos registros, el usuario tendría que realizar esta operación 24 veces en un intervalo de 300 segundos. El usuario tendría que completar la operación en cada lista en un plazo de 12,5 segundos.

Si la aplicación proporciona esta funcionalidad, debe tener en cuenta algunas de las estrategias siguientes:

• Reducir el número total de registros que se pueden seleccionar en una lista. Si el número de elementos mostrados en una lista se reduce a 50, el usuario tendría que realizar esta operación 120 veces en un plazo de 300 segundos. El usuario tendría que completar la operación en cada lista en un plazo de 2,5 segundos.
• Combine las operaciones seleccionadas en un lote. Un lote puede contener hasta 1000 operaciones y evita el número de solicitudes límite. Sin embargo, debe estar preparado para el límite de tiempo de ejecución.

Tiempo de ejecución

Este límite realiza un seguimiento del tiempo de ejecución combinado de las solicitudes entrantes durante el período anterior de 300 segundos.

Código de error	Código hexadecimal	Message
-2147015903	0x80072321	Combined execution time of incoming requests exceeded limit of 1,200,000 milliseconds over time window of 300 seconds. Decrease number of concurrent requests or reduce the duration of requests and try again later.

Algunas operaciones requieren más recursos que otros. Las operaciones por lotes, la importación de soluciones y consultas muy complejas pueden ser muy exigentes. Estas operaciones también se pueden realizar simultáneamente en solicitudes simultáneas. Por lo tanto, en el período de 5 minutos, es posible solicitar operaciones que requieran más de 20 minutos de tiempo de cálculo combinado.

Este límite se puede encontrar cuando se usan estrategias mediante operaciones por lotes y solicitudes simultáneas para evitar el número de solicitudes límite.

Solicitudes simultáneas

Este límite realiza un seguimiento del número de solicitudes simultáneas.

Código de error	Código hexadecimal	Message
-2147015898	0x80072326	Number of concurrent requests exceeded the limit of 52.

Las aplicaciones cliente no se limitan a enviar solicitudes individuales secuencialmente. El cliente puede aplicar patrones de programación paralelos o varios métodos para enviar varias solicitudes simultáneamente. El servidor puede detectar cuándo responde a varias solicitudes del mismo usuario simultáneamente. Si se supera este número de solicitudes simultáneas, se produce este error. El límite puede ser mayor que 52 en algunos casos.

El envío de solicitudes simultáneas puede ser una parte clave de una estrategia para maximizar el rendimiento, pero es importante mantenerlo bajo control. Cuando se usa la programación paralela en .NET , el grado predeterminado de paralelismo depende del número de núcleos de CPU en el servidor que ejecuta el código. No debe superar el límite. La propiedad ParallelOptions.MaxDegreeOfParallelism se puede establecer para definir un número máximo de tareas simultáneas.

Más información sobre el envío de solicitudes paralelas

Cómo maximizar el rendimiento

Cuando tiene una aplicación que debe priorizar el rendimiento para mover la mayoría de los datos en el período más corto, hay algunas estrategias que puede aplicar.

Permitir que el servidor le indique cuánto puede controlar

No intente calcular cuántas solicitudes se van a enviar a la vez. Cada entorno puede ser diferente. Aumente gradualmente la tasa de envío de solicitudes hasta que empiece a alcanzar los límites y, a continuación, dependa del valor límite de API Retry-After de protección de servicios para indicarle cuándo enviar más. Este valor mantiene el rendimiento total en el nivel más alto posible.

Usar varios subprocesos

El mayor límite en el número de subprocesos simultáneos es algo que la aplicación puede usar para tener una mejora significativa en el rendimiento. Esto es cierto si las operaciones individuales son relativamente rápidas. En función de la naturaleza de los datos que está procesando, es posible que tenga que ajustar el número de subprocesos para obtener un rendimiento óptimo. Más información sobre el envío de solicitudes en paralelo

Evitar lotes grandes

El procesamiento por lotes hace referencia al envío de varias operaciones en una sola solicitud.

La forma más rápida en la mayoría de los escenarios es enviar solicitudes individuales con un alto grado de paralelismo. Si cree que el tamaño del lote podría mejorar el rendimiento, es mejor comenzar con un tamaño de lote pequeño de 10 y aumentar la concurrencia hasta que empiece a recibir errores de límite de API de protección de servicios que deba volver a intentar.

Con el SDK para .NET, esto significa usar ExecuteMultipleRequest, que normalmente permite enviar hasta 1000 operaciones en una solicitud. La principal ventaja que proporciona es que reduce la cantidad total de carga XML que se debe enviar a través de la conexión. Esto proporciona algunas ventajas de rendimiento cuando la latencia de red es un problema. En el caso de los límites de protección del servicio, aumenta el tiempo total de ejecución por solicitud. Los lotes de mayor tamaño aumentan la posibilidad de encontrar límites de tiempo de ejecución en lugar de límites en el número de solicitudes.

En el pasado, ExecuteMultiple las operaciones se limitaban a solo 2 a la vez debido al impacto en el rendimiento que esto podría tener. Este ya no es el caso, ya que los límites de la API de tiempo de ejecución de protección del servicio han hecho que ese límite sea redundante.

Cuando se usa la API web, la carga JSON más pequeña enviada a través de la conexión para las solicitudes individuales significa que la latencia de red no es un problema. Más información sobre la ejecución de operaciones por lotes mediante la API web

Nota:

Las operaciones por lotes no son una estrategia válida para omitir los límites de derechos. Los límites de la API de protección de servicios y los límites de derechos se evalúan por separado. Los límites de derecho de uso se basan en operaciones CRUD y se acumulan independientemente de si están incluidas en una operación por lotes. Más información sobre los límites de derechos

Estrategias para administrar los límites de la API de Service Protection

En esta sección se describen las formas en que puede diseñar los clientes y sistemas para evitar errores de límite de API de protección de servicios. También puede considerar cómo administrar las licencias para reducir el impacto.

Actualización de la aplicación cliente

Los límites de la API de Service Protection se han aplicado a Dataverse desde 2018, pero hay muchas aplicaciones cliente escritas antes de que existan estos límites. Estos clientes no esperaban estos errores y no pueden controlar los errores correctamente. Debe actualizar estas aplicaciones y aplicar los patrones a las operaciones de reintento descritas anteriormente.

Avanzar hacia la integración en tiempo real

Recuerde que el punto principal de los límites de la API de protección de servicios es suavizar el impacto de las solicitudes muy exigentes que se producen durante un breve período de tiempo. Si los procesos empresariales actuales dependen de grandes trabajos periódicos nocturnos, semanales o mensuales que intenten procesar grandes cantidades de datos en un breve período de tiempo, considere la posibilidad de habilitar una estrategia de integración de datos en tiempo real. Si puede alejarse de los procesos que requieren operaciones muy exigentes, puede reducir el impacto que tienen los límites de protección del servicio.

Preguntas más frecuentes

En esta sección se incluyen las preguntas más frecuentes. Si tiene preguntas que no se responden, publiquelas con el botón Comentarios situado en la parte inferior de esta página para enviar comentarios sobre esta página.

Uso una aplicación ETL con licencia. ¿Cómo obtengo un rendimiento óptimo?

Trabaje con el proveedor de aplicaciones ETL para obtener información sobre qué configuración se va a aplicar. Asegúrese de que usa una versión del producto que admite el comportamiento de Retry-After.

¿Estos límites se aplican a la búsqueda de Dataverse?

No. La búsqueda nativa de Dataverse es una API diferente (api/search en lugar de api/data) y tiene reglas diferentes. Cuando se usa la API de búsqueda de Dataverse, hay un límite de una solicitud por segundo para cada usuario.

Más información sobre los límites de protección de Dataverse Search Service

¿Cómo se aplican estos límites a cuántas solicitudes tiene derecho un usuario a cada día?

Estos límites no están relacionados con los límites de derechos. Más información sobre los límites de derechos

¿Se aplican límites de forma diferente para los usuarios de la aplicación?

No. Los límites se aplican a todos los usuarios de la misma manera.

Consulte también

Administrar Power Platform/Licencias y administración de licencias/Límites de solicitudes y asignaciones
Información general sobre los límites de API de Dataverse
Uso de Dataverse Web API
Uso del SDK de Dataverse para .NET