ISV License Generator v0.3 con soporte para SHA-2

Hace un tiempo publiqué una primera versión del ISV License Generator que nos ayuda a generar una licencia para un solución ISV de Microsoft Dynamics 365 for Finance and Operations, pero usando un token criptográfico USB en vez de un certificado de tipo software.

ISV License Generator
ISV License Generator

En la nueva versión 0.2 he implementado el soporte para SHA-2/SHA-256 y se mantiene el soporte para SHA-1 hasta que esté obsoleto.

Puedes descargar ISV License Generator v0.2 (lee más abajo para la versión 0.3!)y contribuir o ver el código en Github.

Por favor, si alguien lo ha usado que deje un comentario o me comente por Twitter en @adria_ariste. Sólo me gustaría saberlo 😛

Fin de soporte de SHA-1

La razón para añadir soporte para el algoritmo SHA-256 es que SHA-1 va a dejar de usarse para firmar las licencias a principios de 2021 porque es menos seguro por una debilidad encontrada en el algoritmo, mayor rendimiento de los procesadores y la llegada de la computación en la nube.

Debido a esta debilidad la recomendación es dejar de usar el algoritmo SHA-1, y de hecho en muchos ya no se está usando, no sólo Dynamics 365, y este cambio también nos impacta en la herramienta AXUtil para firmar las licencias por línea de comandos. Microsoft ya ha hecho los cambios en la librería AXUtilLib para soportarlo y yo simplemente he aplicado esos cambios a mi versión de la DLL.

Esto también va a afectarnos en otro campo de Finance and Operations: el framework de dimensiones. Leed este post para más información: Verify hash function changes after update to Dynamics 365 Finance 2020 release wave 2.

Migrado a .NET Core 3.1

La herramienta ISV License Generator se ha migrado a .NET Core 3.1. Sólo he tenido que hacer unos pequeños cambios y ahora, en teoría, se podría usar mi librería AXUtilLib en una app de Linux o MaxOS.

Puedes descargar ISV License Generator v0.3 aquí.

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!

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 4
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 5
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 6
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 7

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 8

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 9

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 10

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