Category

MSDyn365FO

Category

Ha pasado un tiempo desde que escribí el post “Es Dataverse el futuro de las apps de Finance and Operations?”, y cuando lo escribí Dataverse todavía se llamaba CDS y pasó por un par de cambios de nombre más.

¿Ha cambiado algo desde que escribí ese post? ¿Todavía veo a Dataverse como el futuro de las aplicaciones de Finance and Operations? Bueno, ahora sabemos algunas cosas más, y se han publicado nuevas funcionalidades.

A man with a crystal ball seeing the future of Dataverse
Dime bola de cristal que hay en Dataverse…

Así que echémosle un ojo a la bola de cristal a ver que vemos dentro…

Convergencia

Podemos pensar en la convergencia de la plataforma como el proceso que va a llevar está llevando a Dynamics 365 Finance and Operations y la Power Platform más cerca, y haciéndonos así la vida un poco más fácil cuando queremos integrar ambos.

Si quieres aprender más sobre la convergencia entre FnO y Power Platform, lee esto:

Y también estas sesiones en YouTube (en inglés):

Estad atentos al canal de YouTUbe de ANZD365 FinOpsTeam porque ahora mismo están emitiendo una serie de charlas sobre convergencia y se va a publicar más contenido durante los próximos fines de semana.

Enlazar el ERP con Dataverse es más fácil que nunca

Recuerdo la primera vez que configuré Dual Write en un entorno cuando todavía estava en preview. Todo era manual y había parte de prueba y error en el proceso.

¿Has desplegado un entorno de Finance and Operations últimamente? Hay una sección para Dataverse, y después de marcar un check, va a desplegar de forma automática un entorno de Dataverse que se enlazará al de FnO que estamos desplegando. ¡Una vez estén listos, configurar Dual Write es facilísimo!

¿Y las Virtual Entities qué? Las podemos usar en nuestras soluciones de Power Platform en lugar del conector de Finance and Operations. Esto también hará la vida de los desarrolladores de Dataverse más fácil, porque podrán acceder a los datos del ERP de una forma que están acostumbrados y conocen bien.

Add-ins en Dataverse

Todos los add-ins que podemos instalar para extender Finance and Operations se están instalando en Dataverse. ¿Tienes que instalar el add-in de Visibilidad de Inventario o el de Export to Azure Data Lake add-ins? ¡Pues primero necesitarás enlazar un entorno de Dataverse!

¿Veremos la AxDB en Dataverse?

No creo que ni a corto ni medio plazo, pero igual en un futuro lejano… o quizá nunca. Si veis la charla de Sunil Garg, deja muy claro que, ahora mismo, hacer que el ERP y CRM/Dataverse convivan en la misma base de datos no está en los planes de la convergencia. ¡Pero por lo menos ya estamos todos en los mismos servidores elastic-pool de Azure SQL!

También pienso que dada la naturaleza transaccional del ERP es un poco difícil que esto ocurra. Pero quién sabe, porque el producto está evolucionando a tal velocidad que, quizá, algún día, lo veamos.

Desarrolladores X++

Si desarrollas X++ igual te estás preguntando: “Con todo esto de la convergencia, debería ir aprendiendo sobre la Power Platform?”.

¡Por supuesto que deberías! Pero no porque X++ vaya a desaparecer, esto lo deja clarísimo Sunil Garg en su sesión del Pakistan UG “Finance Operation & Power Platform convergence roadmap” (minuto 9:25).

Pero los desarrolladores de X++ tenemos que dejar de pensar que somos SOLO desarrolladores de X++. Juanan y yo lo hemos dicho en varias de nuestras charlas, ya no somos solo desarrolladores de X++. Primero, el cambio a Azure y ahora la irrupción de la Power Platform: tenemos que pensar en todo esto como herramientas que complementan nuestros desarrollos en X++. Y no solo complementar, en algunos casos incluso sustituirlos, como sería usar Logic Apps para conectar a un servidor FTP.

Si quieres leer más sobre builds, releases y el ALM de desarrollo de Dynamics 365 puedes leer mi guía sobre MSDyn365 y Azure DevOps ALM.

Mover datos desde producción a un entorno sandbox es algo que tenemos que hacer regularmente para tener datos reales para testear o debugar. Es un proceso lento que requiere de bastante tiempo y que se puede automatizar como expliqué en el post LCS DB API: automatizando la copia de la DB de Prod a Dev.

Yo pulsando el botón para subir un data package usando Azure DevOps
Yo pulsando el botón para subir un data package usando Azure DevOps

En este post voy a añadir un paso adicional al refresco de la base de datos: restaurar un data package (DP). ¿Por qué? Porque estoy seguro que todos necesitamos cambiar parámetros o endpoints en los entornos de test después de un refresco desde prod.

Puedes leer más sobre la API REST del DMF, que voy a usar, leyendo este post de Fabio Filardi: Dynamics 365 FinOps: Batch import automation with Azure Functions, Business Events and PowerBI.

Puedes aprender más sobre la API REST de LCS leyendo estos posts que escribí hace un tiempo. Te puede interesar leerlos porque voy a dar por explicadas algunas cosas que voy a referenciar en este post:

En un post anterior vimos como crear data entities personalizadas para usar en Dual-write.

I ahora quizás te estás preguntando, y ¿cómo muevo los mapeos de Dual-write a un entorno de test o producción desde el entorno de desarrollo? ¿Tengo que hacer otra vez todo lo que he hecho en desarrollo en un entorno Sandbox?

Afortunadamente no, no tenemos que hacer todo de nuevo a mano, podemos usar una solución de Dataverse para copiar los mapeos de Dual-write entre entornos.

El gusano de Dataverse
El gusano de Dataverse

Si quieres leer más sobre Dual-write puedes:

Ha pasado un tiempo desde que escribí sobre Application Checker en 2019, y aquí vuelvo a estar. En este post voy a hablar sobre SocrateX y XQuery también, y veremos cómo generar los archivos y bases de datos para analizar el código.

Fake Socrates
Este SocrateX es falsoX

Si quieres aprender más sobre App Checker o SocrateX, puedes leer estos recursos además del post que he enlazado arriba:

Dual-write lleva con nosotros casi dos años ya. Es una de las formas que tenemos de integrar Dynamics 365 Finance and Operations y Dataverse junto a las Virtual Entities.

La solución estándar viene con varias entidades listas para sincronizar. Esta ha sido una de las mejoras que se han introducido desde que Dual-write salió en preview, cuando Juanan y yo hicimos la demo en el Dynamics Saturday de Madrid de 2019.

Dual write
En realidad el Dual write funciona así

¿Pero qué pasa si lo que queremos es desarrollar una Data entity personalizada de MSDyn365FO y usarla en Dual-write? Pues es muy fácil, pero hay algunas cosas que tenemos que tener en cuenta.

Llega el fin de las máquinas Tier-1 gestionadas por Microsoft, y esto nos deja sin la capacidad de poder sincronizar la DB o ejecutar tests, a no ser que despleguemos una nueva máquina de build en nuestra suscripción o la de nuestro cliente. Por supuesto esto puede traer preocupación por los costes de esta máquina, y para eso tenemos Azure DevTest Labs.

He escrito este post gracias a la sesión de Joris de Gruyter en la pasada DynamicsCon: Azure Devops Automation for Finance and Operations Like You’ve Never Seen! Y también ha habido bastante investigación y (un monton de) prueba y error por mi parte hasta que todo ha funcionado.

Azure DevTest Labs
Configurando la VM de Build en Azure DevTest Labs

Si quieres saber más sobre builds, releases y el ALM de desarrollo de Dynamics 365 puedes leer mi guía sobre MSDyn365 y Azure DevOps ALM.

Si habitualmente recibes los correos de notificación de LCS de tus proyectos ya sabrás esto: todas las máquinas Tier 1 gestionadas por Microsoft desaparecerán a partir del 1 de diciembre!

Tier 1 VMs will be gone
¿Como que desaparecerán?

Esto es lo que dice el correo:

As communicated previously, Microsoft is removing the use of Remote Desktop Protocol (RDP) to access environments managed by Microsoft. As RDP access is required for development, going forward customers will be required to develop using a Cloud Hosted Environment or download a local “Virtual Hard Disk” (VHD) within Lifecycle Services. Cloud Hosted Environments will allow customers to manage the compute, size, and cost of these environments. This infrastructure change will ensure that customers decouple development tools from any running environment.

In addition, effective November 1, Tier 1 environments will not be included in the purchase of Dynamics 365 Finance, Dynamics 365 Supply Chain Management, Dynamics 365 Project Operations, or Dynamics 365 Commerce apps. The ability to purchase additional Add-On tier 1 environments will also be removed at this time. Beginning December 1, Remote Desktop Protocol (RDP) access for the existing Tier 1 Developer environments, managed by Microsoft, will be removed and decommissioned. Customers will need to preserve or move data within these environments by this date. See the FAQ below with links to existing documentation.

Microsoft will continue to invest in development tools and processes to allow customers to extend the rich capabilities available within Dynamics 365. Learn about one of these key investments, which allows for build automation that uses Microsoft-hosted agents and Azure Pipelines. This approach helps customers avoid the setup, maintenance, and cost of deploying build virtual machines (VMs). It also reuses the existing setup of build agents to run other .Net build automation.

Azure credits will be provided for qualifying customers to use for deploying Tier 1’s using Cloud Hosted Environments. Complete this survey to submit your request.

Sinceramente ha sido un poco de sorpresa. Se había informado que los accesos por RDP iban a desaparecer como pone en el correo, y la desaparición de la máquina de build lleva siendo un rumor desde hace 2 años por lo menos. Pero esto es bastante drástico y ¡con muy poco tiempo de aviso! ¡Quedan menos de dos meses para diciembre!

Pero esperad… en vez de especular, Evaldas Landauskas ha preguntado a microsoft y parece que las máquinas no se borrarán de inmediato el día 1 sino progresivamente:

¡Actualización!

Esta noche hemos recibido otro correo de LCS con más detalles y fechas actualizadas. Así que al final se ha aplazado todo un poco y este es el plan:

  • 1 de noviembre de 2020: no se podrán desplegar ni adquirir más entornos Tier 1. Los que no estén desplegados se borrarán.
  • 1 de diciembre de 2020: se eliminará el acceso por RDP.
  • 30 de enero de 2021: se mandarán notificaciones sobre el parado y borrado de las VM Tier 1.

¿Qué hacer ahora?

Esto depende de qué uso estés haciendo de la máquina y si tienes entornos Tier 1 add-on. Y otra prgunta seguramente sea el coste de reemplazar esa máquina virtual.

Sólo la uso como servidor de build

Si sólo usas la máquina Tier 1 como servidor de build tienes dos opciones:

  • Desplegar una máquina de build en tu suscripción
  • Configurar las builds en Azure

Necesitarás una máquina virtual de build si ejecutas tests o sincronizas la DB como parte de tu proceso de build. Es la única forma. Sobre los costes: podrías desplegar una VM de tipo B8MS con 2 discos SSD Premium de 128GB por unos 280€ al mes. Incluso se podría probar a usar una B4MS por unos 160€/mes.

Esto es más o menos lo mismo que cuesta una máquina Tier 1 de las gestionadas por Microsoft. Y si sólo ejecutas los tests y la sincronización una vez al día puedes rebajar los costes un poco más si arrancas y paras la VM desde tu pipeline.

Si no lo necesitáis, o queréis una build de CI que sólo compile el código, simplemente configurad las builds hospedadas de Azure.

La uso de máquina de desarrollo

Si usas máquinas gestionadas por microsoft add-on ara desarrollo tendrás que desplegar nuevas máquinas de desarrollo en tu suscripción (o la de tu cliente).

¿Preocupados por el coste extra? No lo estéis. Si desplegáis máquinas DS12 V2, con 3 discos SSD Premium de 128GB, y las usáis durante 8 horas al día, 20 días al més, el coste es de unos 120€ al mes.

En ambos casos, si leéis el correo, veréis que Microsoft dará créditos de Azure en compensación por estas VMs, pero no sabemos cuántos. Espero que esto haga la transición más sencilla pero estoy seguro que habrá bastante gente quejándose 😂

Podéis leer sobre algunos usos más de la máquina Tier 1 en el blog de Nathan Clouse.

Estoy seguro de que muchos de nosotros hemos tenido que desarrollar algún tipo de librería en .NET para solucionar algo en Dynamics 365 Finance and Operations. Creas un proyecto de C#, lo compilas y añades la referencia en tu proyecto de FnO. ¡Ya no tienes que hacer eso! Puedes añadir el proyecto a tu repositorio de código, compilarlo en tu pipeline y ¡la DLL se añade al deployable package!

He estado haciendo estas pruebas a raíz de una conversación en Yammer, y a pesar de que he conseguido compilar .NET y X++ en la misma pipeline sin problemas, he encontrado algun problema o limitación.

Si quieres leer más sobre builds, releases y el ALM de desarrollo de Dynamics 365 puedes leer mi guía sobre MSDyn365 y Azure DevOps ALM.

Empecé con este blog en febrero de 2019 y acaba de llegar a las 50.000 visitas, ¡más de 40.000 en los últimos 12 meses!

Gracias a todas las personas que lo han visitado, comentado, compartido o que me han escrito. Me encanta recibir feedback de la gente que lee lo que escribo.

Y como ya habréis notado también he cambiado el diseño del blog. Gracias a Eva González por su ayuda con el blog, el nuevo logo y las imágenes y cabeceras.

¡Ahora a por 50.000 visitas más!

Desde la versión 10.0.12 de Dynamics 365 for Finance and Operations podemos usar las entidades de FnO como Virtual Entities de Dataverse. Esto nos permite crear Power-Apps de tipo model-driven para Finance and Operations sin necesidad de copiar datos entre Finance and Operations y Dataverse. Esto abre muchos escenarios y nuevas formas de integrar Finance/Supply Chain Management con Customer Engagement.

Si queréis saber más sobre la configuración y uso de las Virtual Entities para FnO podéis:

ariste.info