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

Continue Reading…

[HowTo] Desplegar Microsoft Dynamics AX 7 en Azure

El nuevo Microsoft Dynamics AX, como sabemos, sólo está disponible en su versión para Azure por el momento. En cualquier caso, incluso cuando se publique la versión on-premise los entornos de desarrollo van a ser máquinas virtuales autocontenidas que podemos desplegar en Azure o montar en entornos locales.

Vamos a aprovechar que hoy Scott Guthrie (Executive VP Microsoft Cloud and Enterprise) ha anunciado la disponibilidad de la la preview pública durante la Convergence 2015 EMEA en Barcelona, para a ver cómo desplegar una de esas máquinas de desarrollo/demo y empezar a echar un vistazo a la plataforma, es muy fácil.

Microsoft Dynamics Lifecycle Services

Empezamos, como no puede ser de otra forma, en Lifecycle Services, sección Cloud-hosted environments, y seleccionamos Add. A partir de aquí seguimos el sencillo asistente para indicar el tipo de máquina que queremos desplegar, y en el último caso indicamos Azure como plataforma de despliegue. También odríamos elegir Locally para descargar el disco duro virtual de la máquina e instalarla en nuestros propios servidores.

Si seleccionamos Locally, se descarga el disco duro virtual y acaba el asistente. Si seleccionamos Azure, el asistente continúa y nos pide cuántas máquinas queremos desplegar y el tamaño de las mismas (ver tamaños de Azure aquí). Obviamente, cuanto mayor tamaño mejor rendimiento pero también mayor consumo de nuestros recursos de AX. En esta demo sólo voy a desplegar una máquina de desarrollo. Si elegimos desplegar máquinas de Build a la vez, ésta quedará configurada automáticamente mediante TFS, pero esto lo veremos en otro artículo.

Es posible que esto cambie en el futuro, pero en la versión previa de LCS disponible ahora mismo es necesario pulsar el botón Advanced settings e indicar nuestro login a VSO para que se pueda realizar a configuración del gestor de código fuente. Si no se incluye esta información el despliegue fallará. Podemos echar un vistazo a estas opciones avanzadas que nos permite configurar muchas propiedades de los servicios que se van a desplegar en Azure.

El proceso de despliegue tarda un buen rato, dependiendo de cuantas máquinas estemos creando. En cualquier caso puede tardar varias horas. Una vez terminado tendremos una página en LCS desde donde podremos realizar diferentes acciones.

  • Por un lado podemos conectar a la máquina virtual descargando un fichero RDP pulsando sobre el nombre de la máquina, desde donde podremos ejecutar las herramientas de desarrollo (Visual Studio).
  • En la página se nos muestran los usuarios y contraseñas utilizadas para el usuario Administrador.
  • Podemos iniciar y detener el entorno cuando queramos para ahorrar recursos de Azure mientras no la utilicemos.
  • Ofrece información sobre todos los recursos desplegados, que también podemos consultar desde el portal de administración de nuestra suscripción de Azure.
  • Pero lo más importante es que nos permite conectar directamente en el AX hospedado en este entorno. Recordad que AX es ahora una web, así que podemos conectar directamente a estas aplicaciones mediante el navegador web utilizando los enlaces disponibles en esta página (Login to Dynamics AX7, Login to Dynamics Retail, Login to Cloud Point of Sale) con los usuarios indicados.

Cuando la máquina se detiene desde esta sitio en LCS, las máquinas virtuales y servicios (el AOS) se detienen también, pero no el almacenamiento y otros servicios como el Directorio Activo, es normal ya que el almacenamiento sigue siendo utilizado aunque la máquina se pare (nuestros datos siguen en sus discos duros). Esto no es mayor problema ya que estos servicios son realmente baratos incluso ahora, antes de que se publiquen los packs de precios para Dynamics AX que nos permitirán ahorrarnos todos estos cálculos creando un plan de licencias por usuario sin tener en cuenta los recursos utilizados.

Una vez desplegada nuestra máquina de desarrollo, estamos listos para seguir con los siguientes artículos! 🙂