Desarrollo en Dynamics AX 7: La Nueva Arquitectura
Table of Contents
Mientras esperamos que se publique la versión definitiva de “El Nuevo” AX o Dynamics AX 7, podemos empezar a comprender las bases del sistema utilizando la información publicada y la Preview pública. Antes de entrar a analizar los detalles de la nueva versión, que son muchos y nos va a llevar bastante tiempo, hay que comprender las bases que han motivado todos esos cambios y que nos van a permitir comprender mejor la nueva forma de desarrollar, que aunque utiliza herramientas parecidas a las versiones anteriores, veremos como son totalmente diferentes.
Model Store vs Local Repository
En versiones anteriores el código y los metadatos se almacenaban en ficheros de capa (AX 2009) y después en bases de datos, ya sea una base de datos dedicada (AX 2012 R2+) o en la propia base de datos de negocio (AX 2012 RTM). Este simple hecho condicionada las herramientas que podíamos utilizar para trabajar con este código y metadatos. Esto es, programar, crear nuevos objetos, hacer pruebas, compilar, etc…
En AX 7 el código se almacena en ficheros en el disco, como en la mayoría de lenguajes modernos, donde tenemos la versión de los ficheros que nosotros estamos modificando. No en ficheros XPO como en ficheros anteriores, sino en un formato nuevo del que hablaremos más adelante, y estos nuevos ficheros pueden abrirse desde Visual Studio utilizando Proyectos y Soluciones propias de este editor para organizar nuestros desarrollos.
Modelos vs Paquetes
Aparte de este cambio en el almacenaje y gestión de los metadatos, en la nueva versión X++ es un lenguaje completo y nativo de la plataforma .NET, y por tanto el compilador y la ejecución son la misma que en los lenguajes .NET. El resultado más evidente de este cambio es que el código compilado (que en la versión anterior se guardaba, también, en base de datos) genera ensamblados (librerías DLL) que se ejecutan en CLR, como el resto de la plataforma .NET.
Estos ensamblados se corresponden a lo que e forma lógica llamamos Paquetes (Packages) dentro de AX 7. Crear nuevos paquetes va a suponer que se compile el código en nuevos ensamblados, permitiendo una granularidad que nos va a permitir unos tiempos de compilado muy eficientes., ya que sólo será necesario compilar los ensamblados que hayan sufrido cambios. Añadiendo a esto que ya no es necesaria una doble compilación (X++ y CIL), ya que todo el código se compila ahora directamente a CIL, vamos a conseguir unos tiempos de compilado muy reducidos que van a facilitar la adopción de buenas prácticas y el uso de herramientas propias de .NET para la mejora de la calidad de los desarrollos, tanto del resultado final como del proceso de ALM en sí, por ejemplo Builds lo bastante rápidas para ejecutarlas en cada check-in de código a TFS, unit testing, etc.).
Extensión vs Personalización
Teniendo claro todo lo anterior estamos en condiciones de entender el cambio más importante al que nos vamos a enfrentar como desarrolladores de la nueva versión. La antigua filosofía para editar un objeto se limitaba simplemente a editarlo. El sistema se encargaba, gracias al sistema de capas, de integrar nuestros cambios con los objetos estándar (o de otros partners o ISV) creando copias de las capas y compilando la versión final. Este es el proceso llamado Overlayering (¿“Sobre-capar”?) que siempre hemos utilizado.
Este proceso todavía es posible en AX 7, donde se llama Personalización (Customization). Cuando personalizamos un objeto, el sistema integra nuestros cambios en un resultado parecido al habitual con capas, y compila la versión final en el ensamblado donde éste código existía originalmente:
Esta es nuestra forma natural de trabajar hasta ahora. En AX 2012 ya teníamos el modelo de Eventos para evitar estas personalizaciones en lo posible, pero no se llegó a extender porque su uso, aunque muy práctico, era bastante limitado.
Sin embargo en AX 7 la forma recomendada para realizar todas nuestras modificaciones es la llamada Extensión. Aunque en el lanzamiento no todos los cambios podrán realizarse por extensión (esto da para otro post) sí se pueden realizar la mayoría, y así debemos hacerlo. Mediante extensiones, los ensamblados originales se mantienen intactos, mientras que las extensiones en sí generan ensamblados nuevos dependientes de los originales.
Este modelo es deseable por muchos motivos, los más evidentes son los referidos a las migraciones de versión. Si nunca tocamos los ensamblados estándar, instalar una nueva versión del producto va a evitarnos casi todos los conflictos, salvo que nuestra extensión no sea compatible con la nueva versión. Incluso en este caso el problema estará acotado a esa extensión (y sus dependencias) y será más fácil solucionarlo, e incluso entenderlo ya que el contexto del cambio estará muy acotado.
Otra ventaja es que de esta forma evitamos compilar casi todos los ensamblados ya que sólo tendremos que compilar las extensiones que hayamos tocado en cada caso, que serán muy pequeñas (estos ensamblados sólo almacenan el delta respecto al original, lo que es diferente, no el objeto entero), lo que nos va a permitir compilar y ejecutar objetos inmediatamente.
Y por último, aunque puede considerarse o no una ventaja directa, esta arquitectura permite una orientación claramente hacia un modelo SaaS en el que Microsoft nos ofrezca un AX 7 estándar en la nube capaz de actualizarse automáticamente, ya que nuestros objetos estarán siempre en ensamblados diferentes. No es algo que esté planeado a corto plazo (que yo sepa), pero abre la posibilidad de que algún día se ofrezca algo parecido.
Todo esto es, por supuesto, una brevísima introducción de conceptos. En futuros post entraremos en detalle sobre todos ellos.
NOTA: Las imágenes de este post están sacadas de la nueva Wiki de AX 7 a la que vale la pena echar un vistazo!