Throttling por prioridad para integraciones en Dynamics 365

¡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:

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:

Priority-based throttling
Prioridad para throttling
Throttling por prioridad para integraciones en Dynamics 365 1
Tipos de autenticación para throttling

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í:

Throttling configuration
Configuración del throttling

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:

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:

Throttling por prioridad para integraciones en Dynamics 365 2
Monitorear el throttling desde LCS

¿Qué no es el throttling?

Dejad que robe una de las diapositivas del tech talk porque tenemos que recordar esto bien:

What is throttling not?
¿Qué no es el throttling?

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.

Self-service y SSRS: activa la preview en PDF en tu VM de desarrollo

Si estás trabajando con los (ya no tan) nuevos entornos Tier 2 de tipo self-service en Dynamics 365 for Finance and Operations, puede que ya te hayas dado cuenta de esto: los informes en los entornos Tier 2+ y producción no están usando el visor de informes de SSRS, sino que se imprimen en un visor PDF bien bonito.

¿Pero qué pasa en una máquina de desarrollo?

Si quieres saber más sobre los entornos self-service puedes leer estos posts que escribí hace un tiempo:

Visor de informes en tu VM

Si pruebas a imprimir un informe desde tu máquina de desarrollo, todavía verás el viejo visor HTML de SSRS en lugar de la preview en PDF. Esto es normal y está bien documentado.

¿Pero y a mi por qué debría importarme esto?

Para mi hay una razón muy clara: la forma en la que el visor de SSRS y la vista previa en PDF renderizan el informe es distinta, y algunas veces MUY distinta. Y esto puede ser un problema.

Imagínate esto: es lunes, empieza una nueva semana, has descansado y recargado las pilas, y tienes la suerte de que te asignan un maravilloso nuevo informe! «Joder qué suerte! Buena forma de empezar la semana» dice NADIE.

Me when I'm assigned a SSRS report
Yo cuando me asignan un report

Lo siento, tenía que decirlo. Así que te tiras unas cuantas horas modificando un report, viendo el resultado, comprobando que los 40 malditos campos que tiene cada línea no causarán un salto de página, y listo. Haces el check-in y el día siguiente alguien te dice que, en UAT, los datos están saliendo en 2 páginas separadas. ¿Por quééééééééé?

Bueno, es porque los visores no renderizan el report igual. Debería ser muy parecido pero al final no lo es.

Arreglando tu máquina de desarrollo

Como dije antes esto está bien documentado, pero cuando nos metieron en la preview privada de los self-service no lo estaba. Afortunadamente mi compañero Ferni Tudela encontró que en la clase SrsReportRunUtil había un método que comprobaba si el entorno era de tipo self-service:

Una alternativa en ese momento fue extender el método y devolver siempre true, así tu VM era un falso entorno service fabric.

Pero ahora tenemos una manera mejor de hacer esto, navegamos a la URL de nuestro entorno y añadimos &mi=SysReportAdministration. Esto abrirá el formulario de opciones de informes, en el que tenemos que marcar el primer checkbox:

Report options
Report options

Reiniciamos IIS y ya estaremos listos para empezar a usarl el visor de PDF. Espero que esto ayude a alguien que tenga que hacer reports.

Añade un Menu Item a un diálogo de SysOperation

Hoy toca uno corto. Hace un tiempo ya expliqué como añadir un lookup multiselección a un diálogo de SysOperation, y en este post voy a contar como añadir un Menu Item a un diálogo de SysOperation como un Function Button.

Antes de que se introdujera el SysOperation Framework en AX2012, usábamos el RunBase Framework, y quizá hacer estas cosas parecía más fácil/rápido con el RunBase porque teníamos toda la lógica en una única clase. Pero al final lo que tenemos que hacer es prácticamente lo mismo pero en la clase UIBuilder.

Dejad que os muestre y explique el código. Sólo voy a enseñar el DataContract y la UIBuilder porque son las únicas que nos interesan en este caso.

Clase DataContract

Por favor, ignorad todo el hardcodeo 😛

En la clase Data Contract he definido un miembro de tipo VendAccount. También he creado un grupo usando el atributo SysOperationGroup y puesto el campo VendAccount dentro de este usando el atributo SysOperationGroupMember en el método parm.

También he definido la clase UIBuilder usando el atributo SysOperationContractProcessing.

Clase UIBuilder

Todo lo que necesitemos modificar en el diálogo que genera el SysOperation Framework tiene que hacerse en la clase UIBuilder. Lo que tenemos que hacer es exactamente lo mismo que hubieramos hecho con una RunBase. Obtener los controles del diálogo y modificarlos o añadir elementos.

Obtenemos el grupo VendGrp que hemos creado en la clase Data Contract y le añadimos un control. Este control será del tipo MenuFunctionButton y una vez creado definimos sus propiedades y listo!

Añade un Menu Item a un diálogo de SysOperation 3
¡Un botón Menu Item en un diálogo SysOperation!

Creando (más) comunidad, o intentándolo

En estos últimos días he participado en un evento de comunidad, el 365 Saturday online, y también he empezado a publicar un podcast. Y quería hablar un poco sobre las dos cosas.

Dynamics Power Spain Online 2020

Esta ha sido mi cuarta participación como speaker en los últimos 3 años, y como es habitual he presentado una sesión con Juanan. Esta vez hemos hablado sobre el uso de Azure DevOps con Microsoft Dynamics 365 for Finance and Operations.

Es un tema sobre el que hemos escrito bastante ya, y igual está muy trillado, pero sinceramente creo que todavía hay mucha gente que no lo usa bien, o que simplemente lo usa para el control de versiones. ¡Y eso es malo!

Puedes ver nuestra sesión aquí abajo:

Además otros compañeros de Axazure también han dado charlas, son estas:

Como podéis ver unas cuantas charlas de gente de Axazure. Cuando se fomenta compartir con la comunidad pasa esto! Podéis ver el resto de charlas en el canal de Youtube del 365 Saturday Madrid.

Xpp.dev, el podcast!

Pues sí, Juan Antonio Tomás y un servidor hemos empezado un podcast en 2020! ¿Por qué? Cada vez que sale una nueva funcionalidad, alguna preview, lo que sea, nos tiramos un tiempo hablando de eso. Así que pensamos «¿Y por qué no lo grabamos?». Eso hemos hecho y ahora tenemos un podcast que podéis escuchar aquí:

¡Visitadnos en https://xpp.dev!

Hay otra razón más por la que hacer esto: la comunidad técnica de Finance and Operations de España. Me da una envidia terrible ver la fuerza de las comunidades de Dynamics 365 CE/Power Platform, .NET, Azure y otras. No tenemos esto para AX y es lo que queremos!

Nos gustaría tener una comunidad técnica más grande! Y esperamos que con el podcast y compartiendo las novedades se anime más gente. Por supuesto aceptamos colaboraciones, y si alguien quiere participar sólo tiene que decirlo!

Comunidad

La idea de comunidad que tenemos es algo sencillo y que, creo, hemos aprendido de Antonio Gilabert, y es la esencia del Rincón Dynamics. Una comunidad gratuita y de colaboración donde cualquiera pueda aprender, compartir y conectar. ¿Es fácil no?

Puede haber gente que tampoco entienda por qué lo hacemos, por qué compartimos libremente en vez de quedarnos con todo lo que sabemos para nosotros, que hacer esto hace que perdamos valor profesional, compartimos nuestros secretos! Y esta forma de pensar está tan, tan, tan equivocada! Puedo estar regalando «secretos», pero detrás de los secretos hay más de 10 años de experiencia, y la mezcla de esas dos cosas es lo que forma mi valor.

Sinceramente, sólo le veo cosas positivas en compartir con la comunidad!

Azure hosted build para Dynamics 365 Finance & SCM

¡Contemplad #XppGroupies! ¡El día que tanto hemos estado esperando ha llegado! Las Azure hosted builds (me cuesta mucho decir Build hospedada en Azure) ya están en preview pública con el PU35!! Ya podemos dejar de preguntarle a Joris cuando estará disponible, porque ya lo está!! Leed los Docs!!

He podido escribir esto porque, gracias a Antonio Gilabert, hemos podido probarlo durante la preview privada en Axazure durante unos meses. Y por supuesto gracias a Joris por habernos invitado a la preview!

Azure hosted builds
Cabalgando los Azure Pipelines por Caza Pelusas

¿Qué significa esto? No necesitamos ya la VM para ejecutar pipelines! Es broma, sí la necesitamos! Si estámos ejecutando tests o sincronizando la DB como parte de nuestro pipeline todavía necesitamos la VM. Pero podemos mover las builds de CI al agente de Azure.

También puedes leer mi guía sobre MSDyn365FO y Azure DevOps ALM.

Recordar que esto esta en preview privada. Si queréis uniros a la preview primero necesitáis ser parte del Insider Program donde podéis uniros al «Dynamics 365 for Finance and Operations Insider Community«. Una vez invitados deberías ver un nuevo proyecto en LCS llamado PEAP Assets, y dentro de la Asset Library en la sección Nuget package encontraréis los nugets.

Sigue leyendo «Azure hosted build para Dynamics 365 Finance & SCM»

¿Compruebas los warnings del compilador de Dynamics 365?

Los avisos del compilador. Warnings. No son errores, sólo warnings. Puedes ignorarlos totalmente y olvidarte de ellos, verdad? Bueno, espero que no lo estés haciendo.

«¡Pero si incluso en el código estándar de Microsoft aparecen warnings!, podrías decir. Y eso es totalmente cierto, pero no es tu código, es el de Microsoft. Si una funcionalidad que usas se rompe porque Microsoft no tuvo cuidado de los warnings, puedes abrir un soporte y arreglarlo es el trabajo de Microsoft. Si tu código rompe alguna funcionalidad porque pasaste de los warnings, es tu trabajo arreglarlo, y tu cliente va a quererlo igual de rápido que tu querrías que Microsoft arreglara su error.

Por esto es por lo que deberíamos estar avisados de los warnings (badum tss). Ay… en inglés tenía «más gracia».

Sigue leyendo «¿Compruebas los warnings del compilador de Dynamics 365?»

Messaging API: añadir acciones a la barra de mensajes

Con la última versión 10.0.10 de Dynamics 365 for Finance and SCM nos llega una feature nueva que nos permitirá añadir acciones a la barra de mensajes usando la Messaging API, como lo que teníamos en AX2012 con la clase SysInfoAction.

Recordad que esto está en la última versión de preview. Podéis acceder a las previews si os apuntáis al Dynamics 365 Insider Program.

Sigue leyendo «Messaging API: añadir acciones a la barra de mensajes»

Descomprimir (ZIP) un Stream en Dynamics 365 FnO

Ya que Microsoft Dynamics 365 for Finance & Operations es un erp en la nube, no podemos trabajar con archivos en las unidades del AOS. Era bastante habitual tener integraciones con ficheros en AX, donde tenías un archivo en una carpeta compartida y se procesaba.

Por supuesto que todavía podemos trabajar con ficheros, por ejemplo desde una cuenta de almacenamiento en Azure como muestra Miquel Vidal en su blog o con la herramienta Recurring Integrations Scheduler.

Descomprimir Streams de .NET

La mayor parte de las funcionalidades que consisten en cargar o descargar ficheros de MSDyn365FO usan Streams de .NET, normalmente de la clase hija MemoryStream.

Así que, cómo descomprimimos uno de estos archivos ZIP? Por ejemplo, el formato de diario de pago de proveedores ISO20022 está comprimido. ¿Qué pasa si necesitamos el contenido del ZIP?

Pues tendremos que usar la clase ZipArchive del namespace System.IO.Compression, y es muy, muy sencillo. Por ejemplo:

Edit: este código sólo es válido para un ZIP que contenga un único fichero. Si el archivo comprimido tiene más de un archivo hay que procesar cada Stream dentro del while.

Tenemos que copiar el stream unzippedStream (que en realidad es un DeflateStream) a un MemoryStream (que tiene que estar inicializado) antes de hacer el return.

Recordad que para acceder a una colección de .NET tenemos que usar un enumerator para poder recorrer los elementos. Si no véis el método usando la notación de punto escribidlo a mano. Escribir código de .NET en X++ todavía no está afinado del todo…

Añadir lookup multiselección en un diálogo de SysOperation Framework

¡Primer post del 2020! ¡Feliz año nuevo! Sí, ya se que estamos a pasado mediados de enero…

Cuando añades un campo en un Data Contract de la SysOperation Framework el lookup que genera el framework (si el EDT lo tiene) es un lookup simple, de selección única. Vamos a ver cómo crear un lookup que permita la selección múltiple en MSDyn365FO.

El SysOperation Framework y MVC

Pero antes un poco de introducción. El SysOperation Framework se introdujo en Dynamics AX 2012 para sustituir al RunBase Framework, y se usa para crear procesos que se ejecutarán por lotes. Las clases de RunBase siguen estando en Dynamics 365 for Finance and Operations. Algunos procesos estándar las siguen usando, mientras otras las usan para luego llamar a clases del SysOperations Framework.

Sigue leyendo «Añadir lookup multiselección en un diálogo de SysOperation Framework»