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»

Automatización del ALM de desarrollo en Microsoft Dynamics 365 for Finance and Operations

Aquí puedes leer mi guía completa sobre Dynamics 365 for Finance and Operations y Azure DevOps.

Ya he escrito unos cuantos posts sobre la ALM (Application Lifecycle Management) de desarrollo  para Dynamics 365 for Finance and Operations in the past:

La posibilidad de hacer CI/CD real es una de mis cosas favoritas de MSDyn365FO, pasar del «¿Qué control de código?» a «O usas control de código o muere» ha sido una maravilla. Nunca me cansaré de decirlo.

Sigue leyendo «Automatización del ALM de desarrollo en Microsoft Dynamics 365 for Finance and Operations»

Parsea XML y JSON en MSDyn365FO fácilmente

Hace un tiempo tuve que crear un interfasado entre MSDyn365FO yun sistema externo que devolvía los datos en XML. Decidí usar las clases XML de X++ (XmlDocument, XmlNodeList, XmlElement, etc…) para parsear el XML y acceder a los datos. Estas clases son horrorosas. Sacas el trabajo pero de una forma fea fea. Hay un método mejor para parsear XML o JSON en MSDyn365FO.

Sigue leyendo «Parsea XML y JSON en MSDyn365FO fácilmente»

Gestión de características: crear una característica personalizada

La gestión de características (Feature management) lleva disponible en Microsoft Dynamics 365 for Finance and Operations desde hace un tiempo. Antes de eso las características se activaban con el flighting, ejecutando una consulta en SQL en las máquinas de desarrollo y UAT (y en prod lo hacía el equipo de DSE).

Ahora tenemos una área de trabajo (workspace) muy bonito que muestra todas las características disponibles, y el flighting sigue por aquí también. La principal diferencia es que el flighting se usa para activar características a clientes en concreto, como una preview de una feature.

Sigue leyendo «Gestión de características: crear una característica personalizada»

Application Checker: mejores practicas de programación?

Si no has trabajado en un ISV hay muchas posibilidades de que nunca te hayas preocupado de las Best Practices de Dynamics (BP), o quizá sí. Yo no he trabajado para un ISV pero cuando empecé a trabajar con AX me dieron el documento de BP de desarrollo y he intentado seguir la mayoría cuando programo.

Pero las BPs se podían ignorar y no seguirlas sin problema. Esto es por lo que Microsoft va a publicar…

Application Checker

Application Checker es una herraminta que pretende cambiar esto. Va a forzar algunas reglas que nuestro código tendrá que cumplir, de otra forma no va a compilar (y quizá ni se despliegue en los entornos).

Tuvimos un pequeño avance en el pasado MBAS, en la sesión “X++ programming with quality” de Dave Froslie y Peter Villadsen. Desafortunadamente la sesión no se grabó.

Application Checker: mejores practicas de programación? 1

Application Checker: mejores practicas de programación? 2

App checker usa BaseX, una herramienta de análisis XML, y alimenta a Socratex, que usará Microsoft para auditar la calidad del código. No sé si Socratex será publicado y no recuerdo si se dijo nada durante la charla.

El conjunto de reglas se puede encontrar en elproyecto de GitHub de Application Checker y todavía es WIP. Creo que hay muuuuchas cosas a decidir antes de que esto sea GA, y algunas reglas me preocupan y asustan 😛

Tipos de reglas

Hay distintos tipos de reglas, algunas provocarán errores y otras warnings. Por ejemplo:

ExtensionsWithoutPrefix.xq: esta regla provocará un error evitando que tu código compile. Comprueba que una clase de extensión que acabe en _Extension y el atributo ExtensionOf. En caso de que así sea debe tener un prefijo. Por ej.: si extendemos la clase CustPostInvoice no se puede llamar CustPostInvoice_Extension, necesita un prefijo como CustPostInvoiceAAS_Extension.

Application Checker: mejores practicas de programación? 3

SelectForUpdateAbsent.xq: esta regla lanzará un warning. Si hay una cláusula forUpdate en un select y no se llama a doUpdate, update, delete, doDelete o write posteriormente nos lo hará saber.

Application Checker: mejores practicas de programación? 4

A día de hoy hay 21 reglas en el proyecto de GitHub. Se puede contribuir al proyecto, o puedes crear tus propias reglas sin mandarlas al proyecto y forzarlas en las máquinas de desarrollo con añadirla a la carpeta local de reglas. Yo crearía una que hiciera que después de un if/while/for/switch sea obligatorio dejar el espacio en blanco, pero eso sólo es cosa de mi TOC al escribir/leer código.

Pruébalo en tu código

Podemos usar Application Checker en nuestras VMs de desarrollo desde, creo, el PU26. Sólo tenemos que instalar JRE y BaseX en la máquina y seleccionar el check al hacer una full build.

Application Checker: mejores practicas de programación? 5

Algunos ejemplos

ComplexityIndentationCombined.xq

Esta consulta comprueba la (agarráos a la silla)This query checks the (wait for it…) complejidad ciclomática de los métodos. Lo intentaré explicar… la complejidad ciclomática es una métrica de calidad de software, y es el número de caminos independientes que puede seguir el código. Dependiendo del número de ifs, whiles, switches, etc… el código puede tener distintas salidas por distintos caminos, es es lo que calcula la complejidad.

Tomando este ejemplo, que es muy sencillo para demostrarlo, vemos la gran cantidad de caminos que podría seguir:

En App checker el error aparece cuando la complejidad es más de 30. He usado el analizador de complejidad Lizard para calcular la complejidad del método y es de 49.

La regla también comprueba la profundidad de indentación, fallando si es mayor de 2. Al final el propósito de estas reglas es que troceemos métodos largos en partes más pequeñas, lo que también ayudará a que nuestro código sea más extensible, como hizo Microsoft con las clases Data Provider de los informes.

Application Checker: mejores practicas de programación? 6

BalancedTtsStatement.xq

Con esta regla tengo sentimientos encontrados. La regla comprueba que los ttsbegin y ttscommit de un método estén dentro del mismo ámbito. Así que esto ya no será posible:

Application Checker: mejores practicas de programación? 7

Imagina que has desarrollado una integración con una aplicación externa que introduce datos en una tabla intermedia y que luego se procesan esos datos de forma secuencial. No quieres que si algo falla haya un throw para que el proceso siga con el siguiente registro, así que llamas a ttsabort, guardas el error y continúas. Si esto no es posible… cómo deberemos hacerlo? Crear un lote que genere una tarea por cada línea a procesar?

Además, los modelos del estándar están llenos de ttscommit dentro de ifs.

RecursiveMethods.xq

Application Checker: mejores practicas de programación? 8

Esta regla bloqueará el uso de recursividad en métodos estáticos. No tengo muy claro por qué. Application checker debería ser una forma de promover buenas prácticas, no prohibir algunos patrones. Si alguien mete un método recursivo en producción y no se llega nunca a la condición de salida… hola testeo?

Algunas reflexiones finales

¿Va a forzar esto a programar mejor? Lo dudo mucho, pero seguramente no sea el propósito de App Checker. Durante milenios los humanos hemos encontrado la forma de saltarnos las reglas, leyes y todo tipo de restricciones, y esto no será una excepción.

¿Nos ayudará? ¡Joder sí! Pero la mejor forma de asegurarnos de la calidad del código es promoviendo las buenas prácticas en nuestros equipos, a través de formación interna o revisiones de código. E incluso así si a alguien le importa el código limpio un pepino seguirá escribiendo código terrible. Puede que funcione pero no será bonito.

Finalmente, algunas reglas no me convencen. Como lo de evitar la recursividad o el tema de los tts. Tendremos que esperar a ver qué reglas se lanzan finalmente y cómo se va a implantar Application checker en el ALM de MSDyn365FO, bloqueando (o no) los despliegues de código o si se va a incluir en el proceso de build.

Operaciones «set-based» lentas?

En Microsoft Dynamics 365 for Finance and Operations podemos ejecutar operaciones CRUD en el código de dos formas, operaciones set-based (que podríamos traducir como basadas en conjuntos más o menos) y registro a registro.

La recomendación de Microsoft es usar siempre las operaciones set-based, si es posible, como se puede ver en la sesión Implementation Best Practices for Dynamics 365: Performance best practices for a successful Dynamics 365 Finance and Operations implementation del pasado Business Applications Summit de junio.

¿Por qué?

Set-based Vs. Registro a registro

Cuando ejecutamos una query en MSDyn365FO usando la capa de acceso a datos lo que ocurre es que nuestra consulta termina convertida en un comando SQL. Podemos ver las diferencias usando el método getSQLStatement de la clase xRecord con un generateonly en la query (y un forceliterals para mostrar los valores de los parámetros) para obtener la consulta de SQL. Por ejemplo si ejecutamos el siguiente código:

Operaciones "set-based" lentas? 9

Obtenemos esta consulta de SQL:

 

Podemos ver que se seleccionan todos los campos y que los filtros en el where incluyen la cuenta que hemos filtrado (además del DataAreaId y Partition).

Cuando se ejecuta un while select en MSDyn365FO, lo que ocurre en SQL Server es que se ejecuta una consulta por cada vuelta del while. Lo mismo ocurre si se ejecuta un update o delete dentro del bucle. Esto se conoce como operación registro a registro.

Imaginad que queréis actualizar la nota de todos los clientes que sean del grupo de clientes 10. Podríamos hacerlo con un while select de esta manera:

Operaciones "set-based" lentas? 10

Esto ejecutaría tantas consultas en SQL como clientes del grupo 10 existan, una por cada vuelta del bucle. O podríamos usar operaciones set-based:

Operaciones "set-based" lentas? 11

Esto ejecutará la actualización de todos los clientes del grupo 10 en una única consulta de SQL Server en vez de una por cliente:

Existen tres operaciones set-based en MSDyn365FO, update_recordset para actualizar, insert_recordset para crear registros y delete_from para borrarlos de forma masiva. Además de poder hacer inserciones masivas con las listas de tipo RecordSortedList y RecordInsertList.

Ejecutar estos métodos en vez de while selects debería ser por lo general más rápido porque se lanza una sola consulta SQL. Pero…

¿Por qué son lentas mis operaciones set-based?

Existen algunos escenarios documentados en los que las operaciones set-based se convierten en operaciones registro a registro como podemos ver en la siguiente tabla:

DELETE_FROM UPDATE_RECORDSET INSERT_RECORDSET ARRAY_INSERT Use … to override
Non-SQL tables Yes Yes Yes Yes Not applicable
Delete actions Yes No No No skipDeleteActions
Database log enabled Yes Yes Yes No skipDatabaseLog
Overridden method Yes Yes Yes Yes skipDataMethods
Alerts set up for table Yes Yes Yes No skipEvents
ValidTimeStateFieldType property not equal to None on a table Yes Yes Yes Yes Not applicable

En el ejemplo, si el método update de la CustTable está sobreescrito (que lo está) la operación del update_recordset se ejecutará como si fuera un while select, actualizando registro a registro.

En el caso del update_recordset esto se puede solucionar llamando al método skipDataMethods antes de ejecutar el update:

Operaciones "set-based" lentas? 12

Esto hace que no se ejecute el método update (o insert si se hace un insert_recordset), más o menos como si se hiciera un doUpdate en el loop. El resto de los métodos también se pueden saltar con el método correspondiente que aparece en la última columna de la tabla.

Así que, para actualizaciones masivas siempre deberíamos usar operaciones set-based, y activar esto también en las data entities con la propiedad EnableSetBasedSqlOperations.

Y ahora viene otro pero.

¿Debería usar siempre operaciones set-based para actualizaciones masivas?

Bueno, depende de con qué datos estemos trabajando. Hay un post magnífico de Denis Trunin llamado «Blocking in D365FO(and why you shouldn’t always follow MS recommendations)» que explica un ejemplo perfecto de cuándo las operaciones set-based podrían ser perjudiciales.

Como siempre, desarrollar en un ERP es bastante delicado, y escenarios parecidos pueden tener soluciones totalmente diferentes. Simplemente hay que analizar y tomar la decisión.

Actualizar Visual Studio 2019 para #MSDyn365FO

¿Harto de desarrollar en Visual Studio 2015? ¿Te sientes abandonado en el pasado? No te preocupes, ¡es posible usar Visual Studio 2017/2019 para desarrollo de Microsoft Dynamics 365 for Finance & Operations!

¿Cuáles son sus ventajas?

¡Absolutamente ninguna! Visual Studio se quedará sin responder sea cual sea la versión que uses porque la extensión de las developer tools está un poco pasada de moda y es la que en realidad causa los cuelgues.

Sí se añade la posibilidad de usar Live Share, que para sesiones de pantalla compartida es mil veces mejor que Teams. Ey, y que estaremos usando la última versión de VS!

¿Cuesta mucho?

No, tiene cero misterio. Lo primero que hay que hacer es descargar Visual Studio 2019 Professional (o Enterprise pero para D365 no sirve de mucho más) e instalarlo:

Actualizar Visual Studio 2019 para #MSDyn365FO 13

Seleccionamos la opción de desarrollo de escritorio .NET y le damos al instalar. Cuando termine abrimos VS y nos conectamos con nuestra cuenta.

El siguiente paso es instalar la extensión de las developer tools de Dynamics. Vamos a la unidad K y en la carpeta DeployablePackages encontraremos unos ZIP que si abrimos veremos que tienen una carpeta DevToolsService/Scripts con la extensión de VS:

Actualizar Visual Studio 2019 para #MSDyn365FO 14

Actualizar Visual Studio 2019 para #MSDyn365FO 15

Otra alternativa es, por ejemplo, descargar el paquete de un Platform Update que también tiene las dev tools y puede que más actualizadas.

Instalamos la extensión y ya nos aparece la opción de VS2019:

Actualizar Visual Studio 2019 para #MSDyn365FO 16

Una vez instalado abrimos VS como administrador y…

Actualizar Visual Studio 2019 para #MSDyn365FO 17

Y también…

Actualizar Visual Studio 2019 para #MSDyn365FO 18

¡Que no cunda el pánico! La extensión está hecha para VS2015 y usarla en una versión más nueva da algunos avisos, pero solo eso, tenemos las herramientas listas y las podemos usar:

Actualizar Visual Studio 2019 para #MSDyn365FO 19Actualizar Visual Studio 2019 para #MSDyn365FO 20

Como decía al principio la extensión de las dev tools es lo que a veces ralentiza o bloquea VS, y Visual Studio 2019 así lo notifica:

Actualizar Visual Studio 2019 para #MSDyn365FO 21Actualizar Visual Studio 2019 para #MSDyn365FO 22

Pese a los avisos se puede trabajar con Visual Studio 2019 sin ningún problema. Yo llevo haciéndolo una semana y no he encontrado ningún problema que me haga volver a la 2015.

Actualización: parece que el editor de reports no funciona y si abrimos un diseño se muestra su XML en vez del diseñador. Gracias a David Murray por avisarme!

Preview de las nuevas dev tools

En octubre de 2019 se va a publicar la versión de preview de las herramientas de desarrollo tal y como se vio en el MBAS de Atlanta. Esperemos ver qué novedades trae tanto en versión de VS como mejora del rendimiento de la extensión.

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory

Si alguna vez necesitas consumir un servicio SOAP desde Dynamics 365 for Finance and Operations, lo primero que tienes que hacer es pedir a los responsables de ese servicio que creen una versión REST. Si eso no es posible, este post es para ti.

Voy a usar este web service que encontré por ahí en http://www.dneonline.com/calculator.asmx para el ejemplo, es una calculadora con las 4 operaciones básicas de suma, resta, división y multiplicación.

Consumir un servicio SOAP en .NET

Empecemos por lo más básico. ¿Cómo consumimos un servicio SOAP en Visual Studio? Muy fácil. Sólo hay que añadir una referencia de servicio en tu proyecto:

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory 23

Apuntar al servicio web de tu elección:

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory 24

Esto va a crear la referencia en Visual Studio:

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory 25

Una vez hecho esto podemos crear una instancia del cliente del servicio y llamar a sus métodos:

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory 26

3 + 6 = 9, parece que funciona.

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations

Para consumir un servicio web en FnO crea un nuevo proyecto, haz click derecho en referencias y añade la referencia de servicio:

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory 27

Emmm… no, no se puede, no hay referencias de servicio.

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations (espero…)

El problema es que en las máquinas de desarrollo de 365 no podemos añadir las referencias de servicio en Visual Studio.

¿Qué dice la documentación sobre esto? Bueno, igual que en AX2012 necesitamos crear una clase en .NET que consumira el servicio web y a través de la que accederemos a él desde 365. Muy bien!

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory 28

Ya lo tenemos. Una referencia a nuestra librería y una runnable class que hará el trabajo:

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory 29

A ejecutarlo:

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory 30

¿Qué?

An exception of type ‘System.InvalidOperationException’ occurred in System.ServiceModel.dll but was not handled in user code

Additional information: Could not find default endpoint element that references contract ‘AASSOAPCalculatorService.CalculatorSoap’ in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.

¿Contrato? ¿Qué contrato? No sé nada de un contrato. Nadie me ha dicho nada de un contrato! ¿Qué dice la Wikipedia del SOAP?

Soap is the term for a salt of a fatty acid or for a variety of cleansing and lubricating products produced from such a substance.

Creo que no es ese el SOAP que buscaba… (en inglés era más gracioso 🙁 )

SOAP provides the Messaging Protocol layer of a web services protocol stack for web services. It is an XML-based protocol consisting of three parts:

  • an envelope, which defines the message structure and how to process it

  • a set of encoding rules for expressing instances of application-defined datatypes

  • a convention for representing procedure calls and responses

El sobre es el contrato. Un contrato de datos es un acuerdo entre un servicio y un cliente que descibe qué datos se van a intercambiar. Ese contrato.

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations (esta es la buena)

Si vemos el proyecto que hemos creado para consumir el servicio hay un archivo que se llama app.config:

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory 31

En este archivo tenemos el endpoint que usa la DLL. Este valor es fijo, y en caso de que tengamos un endpoint de pruebas y uno de producción tendríamos que crear una librería para cada uno de ellos. También vemos el contrato que usa, AASSOAPCalculatorService.CalculatorSoap. Como #MSDyn365FO es un ERP basado en web podríamos solucionar esto añadiendo el nodo de  system.serviceModel en el web.config del servidor, no? (app.config para apps de escritorui, web.config para apps web). Sí, pero sólo podríamos hacerlo en desarrollo porque en producción no tenemos acceso al servidor, y en cuanto los entornos Tier2+ se migren a self-service será imposible ahí también.

¿Qué hacemos entonces? Fácil, ChannelFactory<T> al rescate.! ChannelFactory<T> nos permite crear una instancia de la factory para nuestro contrato del servicio y después crear un canal entre el cliente y el servicio. El cliente sería nuestra clase en D365and y el servicio el endpoint (obviamente).

Hacemos lo siguiente:

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory 32

El objeto BasicHttpBinding puede ser un BasicHttpsBinding si el servicio web corre sobre HTTPS. El objeto EndpointAddress es la URL del servicio. Instanciamos un contrato del servicio de nuestra clase con el binding y el endpoint y creamos el canal. Ahora podemos llamar al servicio web y sus métodos y…

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory 33

Funciona! Y lo que es mejor, si hay distintos endpoints con este método podemos parametrizarlos y solo necesitamos una DLL para todos los endpoints!

Pero de verdad, evitad los servicios SOAP, tiremos todos de REST.