Microsoft Dynamics AX 7 Virtual Launch Event

AX 7 virtual launch

Como cabía esperar, el lanzamiento oficial del próximo Microsoft Dynamics AX se llevará a cabo a principios del mes que viene en un evento público y online que repetirá a diferentes horas para facilitar su asistencia desde todo el mundo.

Se puede encontrar más información en la web del evento pero aquí va lo básico:

  • Sesiones
    • March 8, 2016 / 6:00 pm – 7:00 pm PST (de 3h a 4h de la mañana en España)
    • March 9, 2016 / 8:00 am – 9:00 am PST (de 17h a 18h en España, si lo he convertido bien)
  • Agenda
    • Executive Welcome
    • Customer Demos & Insights
    • Transform business faster
    • Grow at your pace—evolve your business with the choice and flexibility of the cloud

Yo no me lo pierdo. ¿Y tu? :)

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

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

Esta plantilla está compuesta por nodos que representan las acciones que se van a ir ejecutando, incluyendo tanto acciones por defecto del sistema (básicamente las que controlan el flujo de ejecución), como acciones nuevas que hemos añadido a través de los ensamblados que hemos descargado de codeplex, a estos nodos o acciones las llamamos Actividades (activities).

Estas actividades realizan tareas específicas y concretas como ejecutar un script de PowerShell, controlar el flujo permitiendo condiciones (if) o bucles, o en nuestro caso cosas como compilar el código X++, compilar CIL, sincronizar la base de datos de AX, manejar modelos, etc., tienen este aspecto en el toolbox de Visual Studio:

tfs-vs-toolbox

Es por esto que una plantilla genérica descargada de internet no es probable que funcione al primer intento, tal como nos ocurrió en el capítulo anterior. Este workflow debe ser adaptado a nuestros entornos, a nuestros servidores, debemos especificar si los pasos son los correctos y, aunque lo fueran, configurar determinados aspectos específicos en cada caso como el nombre de los servidores, las rutas del disco donde almacenar los objetos que maneja la build (ficheros XPO por ejemplo), etc.

En la anterior imagen mostraba el workflow por defecto que Joris comparte en su web, que es un muy bueno como punto de partida para empezar, a continuación os muestro un workflow utilizado en un entorno real para que se pueda apreciar la diferencia, y la potencia que nos ofrece poder modificar exactamente cómo queremos construir nuestra aplicación:

TFS-AX2012-VS2013-WorkflowOverview

Como decía, si hemos seguido los pasos de los artículos anteriores de esta serie, podremos incluir la plantilla descargada en un proyecto de Visual Studio con las referencias correctas para poder editarla. Veremos el workflow en la ventana principal de Visual Studio, las actividades que podemos arrastrar y soltar al workflow en la ventana Toolbox (mostrarla desde el menú View si no está visible) y cada uno de las actividades nos mostrará sus propiedades, que serán lógicamente diferentes dependiendo del tipo de actividad:

tfs-activ-visualstudio-edit

Joris hizo un buen trabajo diseñando las actividades, de manera que todas las que tienen que ver con AX utilizan unos parámetros coherentes con el resto, recibiéndo parámetros comunes que podemos almacenar en variables del proceso para facilitar el mantenimiento, ya sea variables internas que el proceso puede utilizar, o parámetros de entrada que recibe de forma externa, para así poder cambiar el comportamiento de la Build sin tener que modificar la plantilla cada vez:

tfs-vs-variables

Los Argumentos del proceso nos permiten definir parámetros de entrada, que podremos pasar al proceso cuando elijamos esta plantilla en la Definición de Build, al crearla. Muy útil para tener diferentes Builds (diferentes definiciones) que, utilizando la misma plantilla, realizan diferentes acciones dependiendo de los parámetros de entrada de cada definición. Por ejemplo, compilar una Rama u otra, o utilizar diferentes entornos para compilar dependiendo de un fichero de configuración:

tfs-vs-build-definition

Esto no se incluye en la plantilla por defecto, así que será tarea nuestra modificarla, bien simplemente para cambiar las rutas y valores apropiados a nuestros entornos, bien para sustituir estos valores por variables tal como he hecho yo, y a partir de aquí no hay una norma ni balas de plata, todo depende del esfuerzo que queramos dedicar al proceso y a lo que queramos conseguir con nuestros procesos.

Una vez terminada nuestra plantilla, e incluso mientras la estamos desarrollando, el proceso muestra cada una de las actividades que va ejecutando y el tiempo que tarda en cada una de ellas. Ésto nos va a permitir comprobar qué va haciendo y en caso de problemas, saber cuál de las actividades ha fallado. Se almacena un log de todas las Builds ejecutadas, aunque podemos cambiar la política de retención en la definición ya que probablemente no queramos guardar el resultado de todas las builds ejecutadas desde siempre, sino sólo las que nos sean útiles.

tfs-building-progress

Tanto si la build termina correctamente como si da algún error, se nos muestra un informe detallado al finalizar que puede verse tanto en Visual Studio como en la web de TFS, ya usemos TFS on premise o Visual Studio Team Services.

tfs-building-report

La Build también guarda información muy útil en el disco duro del servidor (por defecto), o donde le indiquemos que lo haga. Es nuestra responsabilidad definir cuál es el resultado que queremos obtener del proceso, que puede ser desde símplemente compilar el código, un XPO con los objetos, un modelo, una model store, etc… podemos combinar las actividades para obtener lo que queramos. En cualquier caso, probablemente guardemos este resultado en el disco, donde el propio proceso almacena todo el código descargado de TFS, y las actividades de AX almacenan ficheros temporales utilizados durante el proceso.

Además, TFS almacena un log muy completo que incluye información detallada para cada actividad, incluyendo los parámetros de entrada y cualquier información de salida, dependiendo de la actividad. Estos logs son muy útiles para depurar nuevas plantillas al crearlas, y también para diagnosticar problemas en Builds reales que puedan fallar.

tfs-build-run-edit

Si una build falla, siempre podemos re-lanzarla utilizando la opción Retry Build en Visual Studio.

tfs-build-run-retry

O bien podemos ejecutarla directamente desde el portal web, muy útil ya que podemos ejecutar una nueva Build sin necesidad de tener acceso al servidor donde se ejecuta. Normalmente la web de TFS será más accesible que los propios servidores donde se ejecuta el proceso.

tfs-vso-queue

Call to action!

Hace mucho que empecé a escribir esta serie y espero que haya sido útil a alguien, que algún equipo trabaje ahora más tranquilo gracias a las técnicas aprendidas aquí, entonces todo este trabajo habrá valido la pena. ¿Es tu caso? ¿Esta serie de artículos te han ayudado? Si es así por favor cuéntamelo por mail, twitter, en el formulario de contacto,… en fin, como quieras. Estoy preparando otro proyecto relacionado con este tema y me ayudaria conocer tus impresiones. Al fin y al cabo esto no sirve para nada si no resulta interesante para la comunidad. ¡Gracias! 😀

Microsoft Dynamics AX Public Preview (AX7 CTP8)

La versión previa del esperado nuevo Microsoft Dynamics AX (o AX 7) ha sido liberada durante los últimos días para partners y clientes con un cotrato BREP (Business Ready Enhancement Plan) activo. Los detalles pueden encontrarse en los siguientes enlaces (requieren login):

Recordemos que esta es una versión sólo apta para formación y demos, no apta en ningún caso para desplegar entornos de producción. En un artículo anterior, ya describimos como desplegar estos entornos de desarrollo y pruebas en nuestra suscripción de Azure desde Dynamics Lifecycle Services (LCS).

Para poder utilizar esta versión previa, hay que apuntarse previamente, proceso que está bien descrito en la recientemente liberada Wiki de AX 7, concretamente en el siguiente enlace:

Y también en este artículo de Satish Thomas

Si no queremos utilizar la versión Azure, podemos descargar una imagen de disco virtual para ejecutar una máquina virtual localmente, tanto de LCS como del sitio Connect (connect.microsoft.com), al cual tendremos acceso después de apuntarnos a la vista previa del producto, concretamente en la sección Descargas del grupo Dynamics ERP Feedback.

Microsoft Connect

Para empezar a conocer todas las novedades, no te pierdas la nueva wiki pública de AX 7 (el nuevo sitio oficial para obtener ayuda, no más TechNet ni MSDN) ni el siguiente vídeo:

Microsoft Dynamics AX 7 y el nuevo X++

El nuevo Microsoft Dynamics AX también trae consigo “el nuevo X++“. La mayoría de cambios recibidos por el nuevo X++ son relativos al compilador y las herramientas para desarrollarlo. El compilador es totalmente nuevo, haciendo de X++ un lenguaje más del stack de .NET, lo que ha permitido integrarlo totalmente con Visual Studio y evitar el compilado en dos partes de versiones anteriores: No más p-code, todo el código X++ es compilado ahora directamente a CIL. Pero de esto hablaremos otro día, hoy vamos a ver los cambios en el lenguaje en sí mismo, en la sintaxis, disponibles en la nueva versión:

luke-skywalker

Mejoras respecto a AX 2012

  • Finally… añadido el bloque finally a las estructuras try..catch. Su funcionamiento es el mismo que en C#, este bloque se ejecuta siempre se produzcan o no errores en el bloque try.
  • Se puede inicializar el valor de las variables de clase en la propia declaración.
  • Se pueden declarar variables en cualquier parte del código, ya no es necesario realizar todas las declaraciones al principio de los métodos, lo que permite declarar variables en un ámbito más específico (dentro de bucles, por ejemplo).
  • Se añade el tipo especial var, que permite al compilador inferir el tipo concreto de la variable. Su funcionamiento es el mismo que en C# pero cuidado, en .NET se usa este tipo para manejar tipos genéricos, en X++ los tipos genéricos no están disponibles todavía.
  • Añadida la instrucción using para que podemos utilizar igual que en C#, esto es:
    • Para abreviar las referencias a espacios de nombres complicados:
using System.Collections;

class ClaseEjemploXpp
{
    public static void main(Args args)
    {
        // No es necesario especificar el tipo completo
        // System.Collections.Arraylist

        ArrayList arrayList = new ArrayList();
        arrayList.Add('Prueba');
    }
}

Para crear alias a espacios de nombres:

using SysCol = System.Collections;

class ClaseEjemploXpp
{
    public static void main(Args args)
    {
        SysCol.ArrayList arrayList = new SysCol.ArrayList();
        arrayList.Add('Prueba');
    }
}

Para garantizar el uso correcto de tipos como los IDisposable, por ejemplo (más información aquí):

using (Font font = new Font())
{
    // font.Method(...);
}

// ES EQUIVALENTE A:

Font font = new Font();
try
{
    // font.Methods(...);
}
finally
{
    font.Dispose();
}
  • Las variables de clase pueden ser estáticas.
  • Las clases pueden tener un constructor estático mediante la nueva palabra clave typenew. Por ejemplo:
class ClaseConConstructor
{
    static str variableDeClaseEstatica = "Inicializada";

    static void typenew()
    {
        variableDeClaseEstatica = "Asignada sin this.";
    }
}
  • Los atributos aplicados en clases y métodos pueden omitir el sufijo Attribute en su nombre, igual que ocurre en C#. Por ejemplo, para un atributo llamado [PruebaAttribute] también será válido utilizar sólo [Prueba].
  • Los delegados que antes podían declararse en clases, ahora también se pueden declarar en tablas formularios y consultas (objetos Query).
  • La relación entre estos delegados y los métodos manejadores se realiza ahora mediante atributos.
  • Dentro de formularios, se pueden encontrar clases anidadas dentro de clases. La clase base representa el formulario (una instancia de FormRun) y las clases interiores manejan los componentes del formulario (Controles, Orígenes de datos, etc.).

Incompatibilidad con versiones anteriores

Aunque se ha intentado reducir al mínimo los problemas de retro-compatibilidad en el lenguaje, el cambio de plataforma ha llevado inevitablemente a descatalogar las partes del lenguaje que gestionan aspectos de la plataforma que ya no existen, como los siguientes:

  • Eliminadas las siguientes instrucciones: changeSite, pause, windows. Provocan errores de compilación.
  • Puesto que todo el código se ejecuta ahora en CIL en el servidor, ya no tienen sentido las sentencias client y server. No provocan errores de compilación pero son ignoradas y deben eliminarse.
  • En Microsoft Dynamics AX 2012 había algunas diferencias en cuanto a la ejecución del mismo código en CIL o interpretando el p-code. En la nueva versión todos estos casos funcionan igual que en su anterior ejecución CIL. Por ejemplo:
    • El tipo base real es ahora un System.Decimal en todos los casos. La precisión decimal se ha modificado respecto al tipo real de p-code. Esta diferencia provocaba a menudo pequeñas variaciones de decimales cuando el código se ejecutaba en CIL respecto a su interpretación en p-code.
  • La asignación directa de un array a otro array se realiza por referencia. En p-code se realizaba por valor.

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

En los post anteriores de esta serie hemos visto cómo configurar un servidor TFS (local o en la nube) y cómo utilizarlo para gestionar nuestras tareas, controlar el código fuente y gestionar versiones mediante ramas, entre otras cosas. Para cerrar el círculo debemos procesar toda esa información, código y versiones en algo que podamos entregar a nuestros clientes/usuarios.

Aquí es donde entran en juego los procesos automáticos de construcción y compilado, llamados procesos Build. Ejecutar una Build en TFS es relativamente sencillo si trabajamos con lenguajes .NET, pero para hacerlo con AX tendremos que trabajar un poco antes para preparar el entorno e instalar los componentes necesarios en los servidores.

Tenemos un resumen bastante bueno de los componentes necesarios a nivel general en el siguiente enlace. Los componentes a instalar dependerá de si utilizamos un TFS local o en la nube.

Primero debemos familiarizarnos con algunos conceptos clave:

  • Build Service: Servicio que acepta peticiones de ejecución de Build.
    • Un servicio está asociado a una colección de proyectos en TFS.
    • Habitualmente sólo necesitamos un servicio por colección de proyectos.
  • Build Controller: Orquesta la Build y delega el trabajo en los Build Agents.
    • Un controlador está asociado a un Build service.
    • Puede que necesitemos varios controladores si tenemos varios entornos preparados para ejecutar Build. En ese caso asignaremos lo agentes a cada controlador para crear diferentes colas de proceso.
  • Build Agent: Servicio que realiza la Build.
    • Un agente se registra en un controlador
    • Debe instalarse en la misma máquina que el AOS que va a ejecutar el proceso
    • Se debe instalar un agente por cada AOS que tengamos procesando Build.

Es posible instalar y ejecutar varios servicios, controladores y agentes, pero para empezar es suficiente con instalar uno de cada. En nuestro caso es necesario que todos estos componentes estén instalados en nuestros servidores, ya que van a requerir utilizar instancias de AX. Pero el código fuente puede estar en una instancia de TFS en la nube sin ningún problema, cada componente puede estar en servidores diferentes, como se muestra en el siguiente esquema:

VSO Build Overview