x++

Al configurar una variable de modelo de producto, existen dos opciones para configurar como se comportará esta variable en caso de utilizar modelos heredados (un modelo de producto ejecuta otro modelo de producto):



La opción "Valor devuelto" no funciona en AX 3 y 4 (el problema esta corregido en la 2009) debido a un fallo en la programación de las clases estándar del configurador de producto.

Para solucionarlo editar el método de clase \Classes\PBATreeNodeCompile\PBAVarMethods() en su línea #101 y modificar la línea:

PBATableVariable.Vartype            == PBAvartype::Datatype     &&

PBATableVariable.Vartype            <= PBAvartype::Datatype     &&

Si AX 4 está configurado en un idioma que no es inglés (yo lo he probado en castellano pero entiendo que funcionará de la misma manera en otros idiomas), al ejecutar un modelo de producto al que se hayan configurado opciones de gráfico, AX mostrará un error de ejecución. Es un error de traducción del estándar que ya está corregido en la versión 2009.

Para solucionarlo, editar el método de clase \Classes\PBAFrontEndControlWin\run(), en su línea #8, y modificar la línea:

graphicControl = element.design().controlName('Graphic');

graphicControl = element.design().controlName("@SYS40661");

A veces es util poder distribuir a los clientes de AX ficheros auxiliares que van a necesitar para la ejecución del programa, por ejemplo, controles ocx, librerias dll, iconos, imágenes, etc.

Gracias a André Arnaud, que amablemente respondió a una duda mía en los foros de la Microsoft Dynamics Community he descubierto el framework de AX SysFileDeployment que viene perfecto para esta tarea.

La idea de este framework es heredar clases para indicar a AX qué ficheros deben copiarse a la parte cliente cada vez que se realiza una nueva instalación de AX. Este framework tiene bastantes limitaciones pero la ventaja es que en su código se gestiona bastante bien el tema de permisos para copiar ficheros situados en el servidor hacia el cliente.

Comparto las pruebas que yo he realizado por si a alguien le pudieran servir. En primer lugar, hay que generar una nueva clase heredada de SysFileDeploymentFile indicando a AX qué fichero hay que copiar, dónde esta y hacia donde copiarlo. Esta es la estructura básica de la clase heredada, que esta bien autodocumentada por si se necesita mas personalización:

class SysFileDeploymentFileJAEEIcon extends SysFileDeploymentFile
{
	public Filename filename()
	{
		return 'jaestevan.png';
	}
 
	//AOSRunMode::Server
	protected FilenameOpen sourcePath()
	{
		return "C:\\Archivos de programa\\Microsoft Dynamics AX\\50\\Application\\Share\\Include\\";
	}
 
	//AOSRunMode::Client
	protected FilenameSave destinationPath()
	{
		return xInfo::directory(DirectoryType::Include);
	}
}

Una de las limitaciones de este framework es que sólo se ejecuta la primera vez que se ejecuta el cliente en un equipo determinado. Por tanto para distribuir nuevos ficheros o para hacer pruebas, como es mi caso, habría que modificar el método applBuildNo() de la clase ApplicationVersion, para forzar al sistema a actualizar la versión. Haciéndolo de este modo, AX detectará que tenemos ficheros pendientes de actualizar en el servidor y nos mostrará el siguiente diálogo:

Como no me apetecía andar modificando la build de mi entorno de pruebas, he hecho un pequeño Job que simula el código que se ejecutaría automáticamente de manera normal:

static void JAEE_SysFileDeployment(Args _args)
{
    container           classes;
    SysFileDeployment   sysFileDeployment;
    container           classVersion;
    classId             classId;
    ;
 
    classId = classNum(SysFileDeploymentCesserIcon);
    sysFileDeployment = classfactory.createClass(classId);
    classes += [[classId,sysFileDeployment.getServerVersion()]];
 
    classVersion = conpeek(classes, 1);
    classId = conpeek(classVersion, 1);
 
    sysFileDeployment = classfactory.createClass(classId);
    sysFileDeployment.setServerVersion(conpeek(classVersion, 2));
    sysFileDeployment.run();
}

Otra de las desventajas es que parece que esta clase no funciona demasiado bien en AX 4. Yo las pruebas que acabo de hacer en 2009 SP1 sí han funcionado, salvo un pequeño problema con las rutas de origen/destino, supongo que por ejecutar todo el entorno en la misma máquina (cliente, aplicación, AOS, ..).

A partir de aquí que cada uno investigue lo que necesite.

Publicaba en este blog el mes pasado que en la próxima versión de AX, el desarrollo de Enterprise Portal pasa a realizarse exclusivamente sobre Visual Studio. En la actual versión de AX, la 2009, ya podemos usar Visual Studio para desarrollar reports integrados en SQL Server Reporting Services, y desde varias versiones atrás AX publica cubos OLAP sobre servidores SQL Server Analysis Services. Lo que viene a confirmar la intención de integrar AX en el resto de sus productos de area empresarial, así como consolidar tecnologías concretas para trabajos concretos. Es inevitable mirar atrás y acordarse del "Proyect Green"

En otro paso mas en el acercamiento de la tecnología AX hacia .NET, hace unas semanas se publicó un video en Channel 9  mostrando el trabajo del equipo de desarrollo de AX orientado a la generación de código intermedio MSIL (Microsoft Intermediate Language). Si bien anuncian que este trabajo no se verá implementado en la próxima versión de AX, de llegar a completarse sería un avance importante en cuanto al rendimiento y a las posibilidades de integración de futuras versiones del producto.

Microsoft anuncia retirar en la siguiente versión de Axapta el interfaz X++ para el desarrollo de Enterprise Portal, sustituido en la última version AX 2009 por el interfaz ASP.NET.

Se puede consultar el anuncio en Partner Source y Customer Source

Aprovecho la entrada para enlazar un documento interesante sobre el mismo tema publicado recientemente: White Paper: Overview of Enterprise Portal

Al hacer "click derecho" sobre un objeto en Dynamics Axapta se ejecuta el metodo showContextMenu, el cual como siempre, podemos sobrecargar. Esta es la pinta que tiene inicialmente:

public int showContextMenu(int MenuHandle)
{
    int ret;
 
    ret = super(MenuHandle);
 
    return ret;
}

No tiene ningún misterio, es como la mayoría de métodos sobrecargados. Vamos a sustituirlo por este otro código:

int showContextMenu(int MenuHandle)
{
    int         ret;
    PopupMenu   menu;
    int         menuItem;
    ;
 
    // Crea un nuevo menú utilizando el manejador recibido por parámetros
    menu = PopupMenu::create(MenuHandle, this.hWnd());
 
    // Añade un nuevo Menu Item al menú recién creado
    menuItem = menu.insertItem("Mi nuevo menú");
 
    // Abre el menú
    ret = menu.draw();
 
    // Comprueba el Menu Item que se ha pulsado
    if (ret == menuItem)
    {
        // Si es el mío, pongo código aqui
 
        Box::info('Pon tu código aquí!');
 
        return 0;
    }
 
    // Si ha pulsado alguno que no es el mío, se lo devuelvo al estándar
    return ret;
}

Como se puede ver en el ejemplo, podemos añadir por código un nuevo MenuItem al menu contextual y a la vez, capturar la pulsación del mismo para poder ejecutar nuestro propio código de respuesta.

Desde un blog publicado por el personal de desarrollo de Microsoft, publican una serie de cambios (no necesariamente los únicos cambios) que se van a realizar en el lenguaje X++ (el lenguaje de Microsoft Dynamics AX) en la próxima versión del producto (de momento, Dynamics AX 6)

Se puede ver el artículo aquí: Forhcoming changes to the X++ language

La mayoría son cambios orientados a mejorar la seguridad del código, dejando ver el esmero con el que mejoran la calidad tanto del compilador como de los desarrollos que pueden salir de él.

Me gustaría empezar a colgar pequeños "trucos" o trozos de código útiles, por un lado con un fin divulgativo para que si a alguien le sirve, lo utilice; y por otro lado con un fin documental para hacer una pequeña biblioteca de código y poder consultarla en caso necesario. Sugerencias seran bien recibidas, como siempre. Como es el primero, empezare por uno muy sencillo:

Se trata de utilizar la clase SysOperationProgress para mostrar el diálogo estandar de progreso, que podemos (y debemos) utilizar en procesos que se puedan alargar mas de unos pocos segundos.

SysOperationProgress p = new SysOperationProgress();
int i;
;
 
#AviFiles
 
p.setCaption("Título del diálogo");
p.setAnimation(#AviTransfer);
p.setTotal(100000);
 
for (i=1; i <= 100000; i++)
{
    p.setText(strfmt("Progreso %1", i));
    p.incCount();
}

Su utilización es bien sencilla y se puede complicar, por ejemplo para añadir varias barras de progreso en el mismo diálogo, jugando, por ejemplo, con los parámetros del constructor de la clase.

Documentar el código es importante. Nadie seria capaz de rebatir esto, pero es costoso y esto tambien es dificil de rebatir. Asi que todas las herramientas capaces de agilizar esta tarea siempre son bien recibidas.

Segun se puede leer en mfp's two cents, la nueva versión de Axapta incluye la posiblidad de incluir la documentacion en formato XML directamente en el código, de la misma forma que se puede hacer en Visual Studio, por ejemplo, utilizando plantillas generadas automáticamente y que tienen la posiblidad de ser extraidas para utilizar en sitios externos, como publicarlos en MSDN.