Azure functions y Dynamics 365 Finance and Operations

Este es otro post sobre resolver problemas en Dynamics 365 usando herramientas externas. De todas formas, empiezo a dejar de pensar en todo lo relacionado con Azure como algo no externo. En este caso mostraré distintos escenarios usando Azure functions con Dynamics 365.

Escribí esto hace tres semanas y tenía la intención de que fuera un post de dos partes, pero después de ver este fantástico post sobre Azure functions de Fabio Filardi no sé si podría añadir nada más y probablemente lo deje aquí. ¡Leedlo!

En este post veremos qué son las Azure functions, cómo crear una localmente y publicarla en Azure.

Azure functions

Las Azure functions son un servicio serverless que nos permiten ejecutar código sin tener que desplegarlo en ningún servidor (porque son serverless). Es una herramienta magnífica que nos permite escribir código en .NET, JavaScript o Java, y desplegarlo y ejecutarlo en segundos.

Las funciones pueden ser ejecutadas por distintos eventos como llamadas HTTP, colas, Azure Event Hub y Grid o Service Bus, entre otros. Estos eventos serán los que lancen nuestra función. Vamos a ver un ejemplo en el que crearemos, desplegaremos y ejecutaremos una función con una llamada POST por HTTP.

Nota: las Azure functions se pueden crear desde el portal de Azure, pero usar Visual Studio es más potente (y más fácil también) y nos permitirá tener el código en Azure DevOps.

Creamos un nuevo proyecto en Visual Studio y seleccionamos Azure Functions:

Azure Functions in Visual Studio 2019
Azure Functions en Visual Studio 2019

Le damos un nombre y seleccionamos el trigger «Http trigger»:

Azure Functions triggers
Triggers de Azure Functions

La solución se abrirá con algo de código de ejemplo. Lo podemos ejecutar localmente dándole a F5:

Azure Functions running locally
Azure Functions ejecutándose localmente

Como podéis ver, al ejecutar el código obtenemos una URL local a la que llamamos para lanzar la función. Podemos probarlo usando Postman.

¡Un truquillo rápido!

Pero qué pasa si necesitamos testear esta función desde un servicio externo que no puede acceder a nuestra URL local? Dejad que os enseñe un truqui que me enseñó Juanan: usar ngrok.

ngrok creará un túnel y nos dará una URL pública para acceder a nuestra función de forma local. Descargadlo, descomprimidlo y poned ngrok.exe donde queráis ejecutarlo. Después abrimos el terminal y ejecutamos esto:

Dónde 7071 debería ser el mismo puerto en el que se ejecuta la función. Tendremos esto:

Azure functions y Dynamics 365 Finance and Operations 1
Azure Functions y ngrok, la pareja perfecta!

Ahora podemos llamar a nuestra función local desde donde sea usando la URL pública que nos da ngrok. Veréis además todas las llamadas en el termional. ngrok es genial! Me encanta!

Llamando a la función

Primero, vamos a ver el código:

Esta funciójn acepta llamadas GET y POST, y si le pasáis un valor en el parámetro ‘name’ tendremos una respuesta distinta que si no le pasamos nada.

Llamaré la URL local pasándole un parámetro y a ver qué obtenemos:

Azure functions y Dynamics 365 Finance and Operations 2
Respuesta de las Azure functions

En cuanto al código, podemos hacer exáctamente lo mismo que haríamos en cualquier otro proyecto de .NET por ejemplo. Podemos añadir cualquier librería de nuget, crear clases adicionales y usarlas en al función, etc. Las Azure functions nos pueden ayudar a solucionar muchos problemas y el coste es ridículo! Con el tier gratuito podemos hacer 1 millon de ejecuciones, GRATIS! El único coste que tendríamos sería la cuenta de almacenamiento, pero hablamos de céntimos al mes.

Desplegar la función

Azure functions y Dynamics 365 Finance and Operations 3
Estoooy haciendooo click derecho, publicar!!

Para desplegar la fucnión primero necesitamos crearla desde el portal de Azure. Una vez esté creada vamos a Visual Studio y hacemos click derecho en el proyecto y le damos a Publish.

Creo que será la única vez en la que podremos hacer click derecho, publicar sin que nadie nos quiera matar.

Ahora seleccionamos «Consumption plan» y seleccionamos uno existente.

Azure functions y Dynamics 365 Finance and Operations 4

Creamos el perfil y nos pedirá que seleccionemos una suscripciñon de Azure y un grupo de recursos existentes. Seleccionamos la suscripción en la que hemos creado la función y su grupo de recursos:

Azure functions publish
Publicando la Azure function

Finalmente hacemos click en Publish y se desplegará nuestra función en Azure.

Publish the function!
Publicamos la function!

Vamos al portal de Azure, seleccionamos la función que hemos creado antes y a «Functions»:

Azure functions y Dynamics 365 Finance and Operations 5

Ahí veréis vuestra función, la podéis seleccionar y darle a «Get Function Url» para tener el endpoint que la lanza:

Azure functions y Dynamics 365 Finance and Operations 6

Copiamos la URL y hacemos la llamada desde Postman, o una ventana de un navegador ya que también acepta petciones GET, y le pasamos el nombre en el parámetro:

Azure functions y Dynamics 365 Finance and Operations 7

¡Funciona! Hemos creado una función de Azure en una solución local, testeado localmente y finalmente desplegado en Azure y testeado de nuevo, esta vez en el cloud. Molan las Azure functions o no? A las Azure functions se les puede meter seguridad con AAD, Azure Key Vault, se pueden monitorear usando Application Insights y muchas más opciones.

Una nota final: cuando desplegamos una función como hemos hecho no podemos editar el código desde Azure. Necesitamos hacerlo desde Visual Studio y desplegar de nuevo.

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!

¿Cómo hacemos branching en Dynamics 365?

He escrito este post después de que lo sugiriera Mötz Jensen en un largo y muy interesante hilo de Twitter acerca de control de versiones para Dynamics 365 for Finance and Operations. Este es el tweet de Denis Trunin que lo ha iniciado todo:

Leed las respuestas porque es de lo más interesante que he visto en Twitter en meses!

Branching en MSDyn365FO
Branching en MSDyn365FO

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

Branching

Cuando decidas qué estrategia de branching vas a usar tienes que pensar en qué será lo que mejor le vaya a tu equipo y en seguir el principio KISS. Usa una estrategia lo más sencilla posible! Lo que no quieres es pasarte el día limpiando código y solucionando merges mal hechos no?

También ten en cuenta que tu estrategia de branching puede no ser la misma si trabajas en un proyecto de implantación para un cliente que desarrollando un ISV.

Main – Release

Esta es de las más simples, trabajaremos en la rama Main, todos los desarrolladores. Seguiremos el trabajo ahí hasta el arranque.

Cuando vayamos a arrancar haremos un branch de Main y crearemos Release. Esta nueva rama será la que usaremos para promocionar el código a producción. El desarrollo de nuevas características y bugs se hará en Main.

Cuando terminamos un desarrollo, o arreglamos un bug, haremos un merge del changeset (o changesets) a la rama Release. Sí, haremos cherry picking, sé que tiene mala reputación pero dependemos de que los clientes validen los cambios…

En nuestros proyectos solemos tener por lo menos 2 entornos Tier 2+. Usamos uno para testing y validación. En éste entorno desplegamos el DP creado con la rama Main. En el otro Tier 2+ los usuarios hacen sus pruebas y es el que usamos para promocionar el código a prod. Este segundo entorno es el que se actualizará con el código de Release.

Dev – Main – Release

Esto es algo que hemos estado haciendo últimamente para intentar emular las ramas de desarrollo tipo Git. Estamos usando una rama Dev para cada desarrollador. Trabajamos cada uno en nuestra rama, hacemos todos los check-ins que queremos mientras desarrollamos y, cuando está terminado, lo mergeamos todo en un único changeset a Main. Después hacemos Forward Reverse Integrate de Main a nuestra rama Dev para traer todos los desarrollos de los demás programadores.

Sí, esto implica un poco más de merges en la parte de Dev-Main. Pero la idea es tener una lista limpia de changesets únicos en nuestra rama Main para cada desarrollo. ¿Por qué? Porque… cherry picking…

Trabajaremos con Dev y Main hasta el arranque, entonces haremos branch de Main y crearemos la rama Release. Actualizaremos los entornos Tier 2+ de la misma manera que con la estrategia Main ‘ Release.

Como he dicho la idea es tener una lista limpia de changesets para mover los desarrollos de Main a Release y resolver todos los conflictos de merging en las ramas Dev. Cada desarrollador es responsable de su rama y de resolver los conflictos ahí.

Hemos estado trabajando unos meses de esta forma y los resultados son positivos y no estamos teniendo problemas con la gestión. En el futuro lo probaremos con Git pero esto lo va a explicar Juanan!

Consejitos

Primero de todo: fórmate a ti y a tu equipo. Recuerda, usar un VCS es obligatorio, esto ahora es parte de tu trabajo. Busca a alguien que os pueda ayudar, incluso si no trabaja con AX. Los problemas de desarrollo de software son parecidos independientemente del lenguaje que usemos.

No dejéis changesets pendientes de ser mergeados. La cantidad de conflictos que aparecen es directamente proporcional al tiempo que lleva el changeset esperando a pasar de rama.

Recuerda, Keep it simple, stupid (o Keep it stupid simple), KISS, no te compliques la vida!! No sigas ciegamente los consejos que te da un tipo por internet, porque puede tener problemas distintos que los que tienes en tu proyecto!

Así que así es como hacemos branching en Axazure. ¿Hay formas mejores de hacerlo? Seguro que sí! ¿Se puede mejorar? No tengo la menor duda de que sí! Pero esto nos funciona, que es lo más importante.

Es el CDS el futuro de las apps de Finance and Operations?

Adrià the medium: what will happen with the CDS?
Adrià the medium: what will happen with the CDS?

Después del MBAS del miércoles pasado estoy pensando más en esto. Llegará el día que los datos Dynamics 365 for Finance and Supply Chain Management estén de forma nativa en el CDS?

Al ver la sesión de Ryan Jones «What’s new in the Common Data Service«, me planteo si esa debería ser la pregunta, o debería ser cuándo estará de forma nativa en el Common Data Service?

El Common Data Service

El CDS es una plataforma que nos permite guardar datos y que la usan distintas business applications. Pero no es sólo eso, mirad esta imagen:

The CDS
CDS (screenshot from Ryan Jones session on MBAS)

Podríamos poner MSDyn365FO encima de esa plataforma verdad? Soporta bases de datos relacionales, almacenamiento, reporting, workflows, seguridad, etc. Por supuesto esto no se haría de un día para otro, pero igual algo de forma progresiva. Como lo que tendremos con las virtual entities de FnO en CDS!

Con las virtual entities todavía no tendremos los datos de Finance y SCM en CDS, porque las virtual entities:

Virtual entities enable the integration of data residing in external systems by seamlessly representing that data as entities in Common Data Service, without replication of data and often without custom coding.

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/virtual-entities/get-started-ve

«Sin replicación de datos». Cuando se accede a una virtual entity en el Common Data Service su estado se obtiene de forma dinámica del sistema externo.

The CDS capabilities
CDS + Operations (screenshot from Ryan Jones session on MBAS)

Como podemos ver en la imágen todas las data entities públicas estarán de forma nativa en el CDS. Esto quiere decir que podremos usar las capacidades de la Power Platform para Finance and Operations tan rápido y fácil como las usan nuestros compañeros de Customer Engagement. Por lo menos para las entidades públicas.

Si necesitáramos que los datos estuvieran físicamente en ambas aplicaciones tendríamos que usar Dual Write. Recordad que Dual Write sincroniza los datos entre Finance and Operations y Customer Engagement/CDS en tiempo casi real.

CDS + Operations: Under the Hood
CDS + Operations: Under the Hood (screenshot from Ryan Jones session on MBAS)

Si queréis saber un poco más sobre el Dual Write podéis echarle un vistazo a la sesión «And finally… Dual Write!» que hicimos Juan Antonio y yo en el Dynamics 365 Saturday de Madrid de 2019. Está un poquito anticuada ya porque en este año que ha pasado se ha añadido bastante funcionalidad pero da una idea de lo que se puede conseguir.

¿Lo vamos a ver?

Quién sabe, sólo estoy especulando, yo soy un minundi pero no puedo dejar de pensar en que Microsoft está invirtiendo mucho en el CDS. Y que las apps de Finance and Operations son el único producto de Dynamics 365 cuyos datos no residen en el Common Data Service.

Además estamos viendo como algunas funcionalidades de FnO están siendo replicadas y luego extendidas en el CDS como, por ejemplo, Dynamics 365 Human Resources o Dynamics 365 Project Operations. Esto está creando un problema, porque ahora mismo tienes que crear una integración entre las dos aplicaciones si quieres tener algún tipo de intercambio de datos. FnO en el Common Data Service los solucionaría.

Esto también crea un poco de confusión a los clientes, que piensan que esa integración existe de fábrica, cuando no es así. El nombre de los productos lo sugiere, pero no pasa.

Debemos tener en cuenta que esto no pasaría en el próximo año, ni en los dos ni en los tres siguientes. Esto sería algo a largo plazo. No sé cómo será con las aplicaciones de CDS, pero las de Dynamics 365 for Finance y SCM tienen una cantidad bien hermosa de tablas, y migrar todo al Common Data Service seguro que es una cantidad de trabajo enorme.

¿Y qué pasaría con las herramientas de desarrollo? ¡También tendrían que cambiar! Veremos hacia donde se dirige el producto y nosotros con él, pero seguro que ya no podemos pensar en Finance and Operations sin el CDS.

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»

LCS DB API: automatizando la copia de la DB de Prod a Dev

El nuevo endpoint de la LCS DB API para exportar una base de datos ha sido publicado! Con él ya tenemos una forma de automatizar el refresco de datos de tu Dynamics 365 FnO desde producción a un entorno de desarrollo Tier 1.

LCS DB API Automation
LCS DB API Automation

Puedes aprender más acerca de la LCS DB API leyendo estos posts que escribí hace un tiempo. Es una buena idea echarles un vistazo porque hay algunos pasos que doy por explicados:

También puedes leer la guía completa 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 a la organización de Yammer podéis pedir acceso al grupo «Self-Service Database Movement / DataALM» donde recibiréis toda la info necesaria para uniros a la preview y activar la funcionalidad en LCS.

Sigue leyendo «LCS DB API: automatizando la copia de la DB de Prod a Dev»

¿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»

1 2 3 Power Mime!

Vamos ya hacia la tercera semana en casa, y con unas cuantas más por delante necesitamos algo de entretenimiento.

La semana pasada Eva me propuso hacer una app con la Power Platform para jugar a juegos de mímica con mis compañeros de Axazure. Ella la diseñaría gráfica y funcionalmente y yo haría el (no) código. ¡Y eso es lo que hicimos!

1 2 3 Power Mime!
1 2 3 Power Mime!
Sigue leyendo «1 2 3 Power Mime!»

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…