Varios temas ya se han creado en torno al 429, pero las explicaciones varían. Por eso, creo un tema separado para mi propia situación.
Estoy usando una cuenta OEM de entrada y en los últimos días me he enfrentado con frecuencia a los errores 429 en varias bases de datos.
¿Pueden verificar si hay algo mal en mi configuración o tal vez en la cuenta?
Casualmente, esta semana recibí mi primera factura, ¿no sé si eso podría estar relacionado?
¿Qué texto aparece cuando se hace clic en “Camino” en la URL mostrada y se autentica en el navegador?
Gracias por la rápida respuesta. Mi monitoreo en vivo e histórico está completamente vacío (aunque se hayan realizado actividades, y también si selecciono varias entradas por página), por lo que no puedo realizar lo anterior.
Eso es nuevo para mí también; normalmente la historia se reflejaba bien aquí.
Si se puede enviar el enlace genérico, puedo ajustarlo con el nombre correcto de la base de datos.
{
"error": {
"code": "itgenboe405",
"message": "El límite diario de 3.600.000 ms de duración desde la caché ha sido superado por 15.374.848 ms.",
"target": null,
"details": [
{
"code": "TraceIdentifier",
"target": null,
"message": "0HNM205IHUBV1:00000001"
},
{
"code": "Name",
"target": null,
"message": "TotalDurationMsPerDay"
},
{
"code": "LimitValue",
"target": null,
"message": "3600000"
},
{
"code": "CurrentValue",
"target": null,
"message": "18974848"
},
{
"code": "RemainingValue",
"target": null,
"message": "0"
},
{
"code": "RemainingDurationWindowSec",
"target": null,
"message": "29510"
},
{
"code": "LifetimeSecFromUtc",
"target": null,
"message": "86400"
},
{
"code": "SessionId",
"target": null,
"message": "user-ab84ed3c-6881-4976-8163-8826889b4089"
},
{
"code": "DatabaseUid",
"target": null,
"message": "c004b18c-db00-410d-b3df-7b5a7488aab4"
},
{
"code": "SubscriptionType",
"target": null,
"message": "SUBOEMGRW"
},
{
"code": "SubscriptionCode",
"target": null,
"message": "L968699804"
}
],
"innererror": null
}
}
El itgenboe405 indica que se ha excedido la duración total por día (TotalDurationMsPerDay).
Se recomienda optimizar la duración total de todas las solicitudes. La duración permitida dentro de esta forma es de 1 hora, pero ha habido aproximadamente 4 horas de actividad continua.
Un resumen de todos los códigos de error que conducen a un 429 se puede encontrar en:
Gracias por la respuesta. Preguntas:
Por cierto, yo también encuentro la duración bastante larga, especialmente considerando que mis clientes tienen algunas tablas de aproximadamente 400k (2 o 3) y el resto son todas pequeñas dimensiones. Los tiempos de actualización con carga completa duran unos 30-45 minutos.
¿Hay algo que se pueda hacer en la configuración de la base de datos para acelerar esto? ¿Tamaños de página, por ejemplo?
Se trata de la duración de la solicitud. Esta 1 hora se aplica a todo el entorno cubierto por el plan.
Si se trata de 1 a 2 millones de filas, entonces esto debería poder hacerse fácilmente en 1 hora en la mayoría de las plataformas.
El consejo es optimizar las consultas.
A partir de la versión 26.0.100, también se puede ver directamente en la Monitorización cuál es la causa de la superación de los límites:
En este ejemplo se muestra itgenboe655. La traducción correspondiente aún no está disponible, pero estará disponible en unos días.
También en “Posibles soluciones” se puede ver dónde se encuentra la documentación, a saber, aquí.
Vale, entonces veo que se trata de la cantidad de llamadas API por día. ¿Pero esto se aplica por base de datos? ¿O se aplica el límite a todas las bases de datos una vez que se excede en alguna parte?
Todos los límites se aplican a todas las actividades dentro de un entorno, incluso a través de las bases de datos.
Los límites, en general, están diseñados con mucha amplitud. Si llegas a encontrarte con ellos, se recomienda mirar qué acciones están consumiendo una parte desproporcionada e irrazonable del límite y optimizarlas.
He revisado la salida de monitoreo y veo efectivamente una duplicidad considerable, pero mirando mi propio código en Power BI, el código en sí no es ineficiente sino la configuración inherente de PowerBI:
Para cada consulta, la metadata (odata4/$metadata) se solicita de nuevo, aunque sea la misma metadata. Además, no son posibles las tablas de staging, por lo cual cada consulta envía nuevamente una petición a Invantive. Por ejemplo, para la tabla de órdenes de venta (ExactOnlineREST.SalesOrder.SalesOrderLines@eol):
| 09-06-2026 01:10:21 |
| 09-06-2026 01:13:40 |
| 09-06-2026 01:15:11 |
| 09-06-2026 01:18:30 |
| 09-06-2026 01:20:01 |
Dado que el conector está diseñado para Power BI y este es un problema inherente a la forma de refrescar en PBI, no sé bien qué puedo hacer.
Además, el punto: Si el límite se aplica a todo mi entorno en OEM, y hay 4 clientes ahí con una actualización diaria cada uno, llego mucho más rápido a ese límite que si estos 4 clientes tuvieran una cuenta propia. Mientras que pago lo mismo que esos 4 clientes juntos. ¿Verdad?
Cada actualización por ambiente tiene una duración de unos 1500 segundos, lo cual está bien con un límite de 10k. Con 4 ambientes (y espero agregar más) esto son 6000 por día. Con desarrollo y quizás un momento adicional de actualización durante el día, sobrepaso rápidamente esos 10k.
Consejos:
SalesOrderLines@eol a una tabla acumulativa o incremental. Esto puede reducir la duración hasta un factor de 1.000.Los límites para un plan OEM regular son significativamente mayores que para un plan regular.
Gracias por la respuesta. Usé SalesOrderLines en lugar de la versión bulk porque hay algunas columnas que no están en la versión bulk. Sin embargo, pude acelerar considerablemente aplicando filtrado más temprano. También haré esto para otras consultas para que no se rompa el folding.
Otra gran contribución al tiempo de actualización es ‘odata4/$metadata’. ¿Hay algo que se pueda hacer al respecto o es inherente al número de consultas que se están ejecutando?
Si está bien, entonces todos los campos de SalesOrderLines también deberían encontrarse en SalesOrderLinesBulk y viceversa. ¿Qué campos específicos faltan?
Obtener el $metadata debería tardar solo unos milisegundos después de la primera adquisición. Se recomienda verificar que no haya demasiadas solicitudes simultáneas en ejecución, lo que provoque que tengan que esperar más tiempo.
Los siguientes campos están presentes en SalesOrderLines, pero no en SalesOrderLinesBulk:
| Campo | Descripción |
|---|---|
CustomField |
Carga útil del campo personalizado |
DeliveryStatus |
Estado de entrega de la línea |
InvoiceStatus |
Estado de factura de la línea |
OrderStatus |
Estado del pedido en la línea |
Margin |
Margen de la línea |
QuantityDelivered |
Cantidad entregada |
QuantityInvoiced |
Cantidad facturada |
TaxSchedule |
Programa de impuestos (GUID) |
TaxScheduleCode |
Código del programa de impuestos |
TaxScheduleDescription |
Descripción del programa de impuestos |
Me interesan especialmente los campos del estado de la factura y de la entrega.
A partir de la versión 26.0.285, el tiempo reportado en el código itgenboe405 ya no incluirá el tiempo de espera, sino solo el tiempo de ejecución. Esto aumentará el espacio disponible, especialmente si un proceso se ha descontrolado o si llegan muchas solicitudes al mismo tiempo y alguna de ellas tiene que esperar.
Esta pregunta se ha cerrado automáticamente tras 1 semana de inactividad. La última respuesta dada ha sido marcada como solución.
Por favor, formule una nueva pregunta en un tema aparte si el problema se presenta de nuevo. Incluya un enlace a este tema en la nueva pregunta pegando la URL en el texto.