Year: 2015

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: https://www.youtube.com/watch?v=I5u3hJ81BDE
Read More »

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.
Read More »

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
(más…)