¡Al fin tendremos funcionalidad de throttling para integraciones por OData!
Es uno de los requerimientos más habituales por parte del cliente: la necesidad de integrar Dynamics 365 con otros sistemas. Y con el (en su día) nuevo AX7 obtuvimos una forma nueva de integrarnos usando los endpoints REST de OData y las entidades expuestas.
Pero las integraciones que usan OData tienen un rendimiento más bien bajo, y para integraciones de alto volumen es mejor usar la API REST de paquetes del Data management. Si usamos la API REST de OData para integraciones de un volumen mayor al que deberíamos vamos a tener problemas de rendimiento.
La funcionalidad de throttling está en preview pública desde la versión 10.0.13, actualmente en PEAP. Se activará obligatoriamente en abril de 2021. Te puedes unir al grupo de Yammer Data Management, Data Entities, OData and Integrations para más información. Recuerda que para unirte a este grupo tienes que haberte unido promero al Programa Insider para Dynamics 365.
Si quieres saber más sobre OData y throttling puedes leer estos recursos:
- Priority-based throttling.
- Tech talk: Throttling Overview for Fin/Ops Integrations. Puedes pasar de leer este post y ver esta sesión con todos los detalles y más!
- Consumir Servicios REST y OData en #MSDyn365FO desde Postman y Parte 2 en jatomas.com.
Throttling
¿Por qué tendremos esta funcionalidad? El throttling es una forma de controlar la ejecución de algunos procesos, y está presente en muchas APIs REST que hay por ahí. Pero nosotros no lo teníamos.
El problema con OData es que cuando haces mas llamadas de las que puede procesar, el rendimiento del sistema se verá afectado porque los recursos que ejecutan las llamadas de OData y el resto del sistema son los mismos. Y esto es así tanto para sesiones interactivas (gente de verdad usando MSDyn365FO) como para las no interactivas.
¡Y aquí es donde el throttling nos va a ayudar! Con él podremos definir prioridades para distintas integraciones para conservar el rendimiento del sistema.
Configurar prioridades
Para configurar las prioridades necesitamos ir a Administración del sistema – Configurar – Throttling priority mapping (parece que aun no están las etqiuetas en español) donde veremos esto:
Si desplegamos el campo Authentication type veremos dos tipos distintos de autenticación: AAD application y User. El tipo AAD aplicará a las integraciones que accedan a FnO usando el client Id + ssecret de AAD (OData, servicios web personalizados), y el tipo User aplicará a el usuario que seleccionemos. Por ejemplo, si un usuario necesita hacer cargas de datos usando el add-in de Excel de forma periódica podemos poner una prioridad alta. Tal que así:
En la imagen de arriba podemos ver que hay una integración que usa AAD con prioridad baja (Low) y dos usuarios con prioridad media y alta (Medium y High). Si el sistema llega al punto que necesita regular (throttle) las integraciones, el usuario JULIA tendrá la máxima prioridad para seguir usando OData, después el usuario JOHN y finalmente la integración por AAD.
Esto quiere decir que la integracion por AAD será la primera en fallar, aunque ahora veremos que en realidad ya no fallan ;), luego la de JOHN, y JULIA será la última porque es la responsable de un proceso de negocio crítico.
Peticiones reguladas
Hasta ahora no teníamos forma de notificar a la otra integración que la llamada a nuestro endpoint fallaba. No lo sé exactamente pero probablemente recibíamos un timeout o un error 503, sin muchos más detalles. Con esta funcionalidad podemos responder a las llamadas con el código de error 429 Too Many Requests:
if (!response.IsSuccessStatusCode)
{
if ((int)response.StatusCode == 429)
{
int seconds = 30;
//Try to use the Retry-After header value if it is returned.
if (response.Headers.Contains("Retry-After"))
{
seconds = int.Parse(response.Headers.GetValues("Retry-After").FirstOrDefault());
}
Thread.Sleep(TimeSpan.FromSeconds(seconds));
// Retry sending the request.
}
}Esto al fin dará algo de información sobre los errores y además le podremos decir al otro lado que pruebe otra vez en un tiempo. Y en vez de probar una y otra vez, porque no tenemos un error, y hacer el problema más y más grande mandando más peticiones, podemos cambiar la lógica de la integración y probar de nuevo en X segundo/minutos.
Monitorear el throttling desde LCS
Recordad que se puede monitorear el throttling en la página de cada entorno en LCS:
¿Qué no es el throttling?
Dejad que robe una de las diapositivas del tech talk porque tenemos que recordar esto bien:
Quiero sobretodo hacer hincapié en el segundo punto: el throttling no es una solución al mal diseño o código… Es una herramienta que nos ayuda a prevenir un problema y notificar a las interaciones que sus peticiones se están rechazando, pero no arreglará los problemas que nazcan de unas fases de diseño o código deficientes.
Y, como dije al principio, si todavía no habéis visto la sesión Throttling Overview for Fin/Ops Integrations, hacedlo porque es muy informativa.
