Desarrollo en Dynamics AX 7: La nueva arquitectura

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.

packages models projects

Continue Reading…

Procesos BUILD automáticos con TFS y AX 2012 (2/2) (ALM-X)

En el artículo anterior de esta serie definimos el proceso principal para configurar una Build de Microsoft Dynamics AX 2012 en TFS, en resumen:

  • Instalar y configurar los componentes de TFS necesarios en el servidor de build (Agente, Controlador, etc.).
  • Crear un nuevo proyecto con las actividades personalizadas y la plantilla por defecto.
  • Subir todo esto al repositorio de código fuente en TFS o Team Services para que el Controlador pueda acceder a ellos.
  • Añadir estas referencias a Visual Studio para que éste reconozca las actividades nuevas.
  • Crear una nueva definición de Build utilizando la plantilla descargada.

Nos quedábamos ejecutando esta definición de Build recién creada con todas las opciones, actividades y plantilla por defecto, y tras todo lo cual recibíamos un error. Frustrante, ¿No? Puede que si, pero si lo pensamos es bastante lógico, veamos:

Una Build no es más que un workflow que ejecuta una serie de pasos en un determinado orden. Este workflow es la Plantilla (template) que nos hemos descargado, un fichero con extensión XAML que, si hemos seguido todos los pasos hasta aquí, podremos incluir en un proyecto o solución de Visual Studio y editarlo desde ahí, y que tiene este aspecto:

SimpleWorkflowTFS2013-Joris

Continue Reading…