[AX TIP] Errores Interop CLR y nivel de transacciones

Hace un tiempo publiqué un artículo explicando las buenas prácticas recomendadas para el manejo de excepciones CLR y cómo mostrarlas correctamente en el InfoLog de Dynamics AX. Sin embargo olvidé entonces un detalle importante que hay que tener en cuenta al capturar estas excepciones, que es el nivel de transacciones en la base de datos (TTS Level).

En el siguiente código de ejemplo, nuestro try..catch NO funcionará. Si se produce un error en el try, por ejemplo, si el método get_Content() no existe en el objeto en tiempo de ejecución, la ejecución del código terminará directamente sin mostrar nada en el InfoLog, lo que no es muy deseable.

Esto es debido a que, para poder capturar una excepción CLR, el nivel de transacciones debe ser 0. O lo que es lo mismo, no podemos capturar errores del Interop dentro de una transacción. Para que este código funcione tendremos que re-escribirlo para que el manejo de ese objeto CLR genérico se realice antes de abrir la transacción.

CLRObject       obj;


ttsBegin;  // ttsLevel + 1

info(strFmt("TTS level: %1", appl.ttsLevel())); // TTS level: 1

try
{
    obj = response.get_Content();
    if (!CLRInterop::isNull(obj))
    {
        // ...
    }
}
catch(Exception::CLRError) // Este catch nunca se ejecutará porque ttsLevel > 0
{
    error(AifUtil::getClrErrorMessage());
}

ttsCommit; // ttsLevel - 1

En realidad, y debido al alto riesgo de que se produzcan errores CLR que deben capturarse y procesarse de forma especial, el manejo de objetos CLR debe encapsularse siempre en clases o métodos específicos donde quede claro su funcionamiento y aislado el riesgo de problemas.

Errores Interop CLR y manejo de Infolog en Microsoft Dynamics AX 2012

Al trabajar con objetos del framework .NET (algo muy común en AX 2012), debemos tener en cuenta el tratamiento de errores CLR. El tratamiento de errores en Dynamics AX es transparente y no necesita dedicarle demasiada atención durante el desarrollo en X++, pero cuando interviene el Interop con .NET, el manejo de los errores CLR se debe especificar de forma explícita.

El código que suelo utilizar habitualmente (copiado y pegado de mi repositorio personal) como punto de inicio es el siguiente:

static void JAEE_CLRError(Args _args)
{
    System.Exception ex;
   
    new InteropPermission(InteropKind::ClrInterop).assert();  
   
    try
    {
        System.Int32::Parse("JAEE");  // Error: no se puede convertir un texto a Int32
    }
    catch (Exception::CLRError)
    {
        ex = ClrInterop::getLastException();
        if (ex != null)
        {
            info(ex.get_Message());
            ex = ex.get_InnerException();
            if (ex != null)
                error(ex.ToString());
        }
    }    
    catch (Exception::Internal)
    {
        ex = ClrInterop::getLastException();
        if (ex != null)
            info(ex.get_Message());
    }  
   
    CodeAccessPermission::revertAssert();
}

Continue Reading…

Error: “The database XXX is not recognized as a model store” al copiar una base de datos AX 2012

Hay un error muy común desde la versión AX 2012 R2 que ocurre normalmente al mover o copiar bases de datos de un servidor o de un entorno a otro. Este error (The database XXX is not recognized as a model store) ocurre al iniciar el AOS tras mover las bases de datos y tiene el siguiente aspecto:

Error "The database XXX is not recognized as a model store"

Este error es bastante extraño, porque recordemos que la base de datos modelo (Model Store, base de datos separada que existe desde la versión R2) no puede configurarse en la utilidad de configurador del cliente ni del servidor:

Server Config

Sin embargo, a pesar de esto, esta base de datos sí se configura mediante varios parámetros del AOS que almacenan tanto el nombre de la base de datos como el servidor, y se almacenan en el registro de Windows (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dynamics Server\6.0\XX\NombreConfig).

Registro de windows

Por lo tanto para solucionar este error podemos modificar directamente estos valores en el registro de Windows (es la forma más sencilla), o podemos exportar la configuración del servidor desde la utilidad de configuración, modificar este parámetro en el fichero editándolo directamente con un editor de texto, e importando la configuración de vuelta mediante la utilidad de configuración. Quizás esta última opción es más trabajosa, pero es más fácil de exportar e importar rápidamente en otros servidores.

Error: Concurrent number of AOS for this application exceeds the licensed number

Otro error recurrente al mover o copiar entornos o bases de datos es referente al número máximo de AOS que podemos ejecutar en una misma instalación por cuestiones de licencia. Esto ocurre en diferentes versiones y revisiones pero en mi caso me lo estoy encontrando sobre todo en AX 2012:

Object Server 01:  Concurrent number of AOS' for this application exceeds the licensed number AX 2012

Para solucionarlo, podemos ejecutar esta sentencia en la base de datos que hemos copiado:

UPDATE dbo.SysServerSessions SET Status = 0 WHERE Status = 1;

Esto liberará las sesiones que hayan quedado almacenadas en la base de datos antes de copiarla, permitiendo conectarle un AOS diferente, lo que es totalmente válido para una licencia normal y bastante típico al copiar bases de datos de producción para refrescar entornos de pruebas o desarrollo.

NOTA: Ejecutar sentencias SQL directamente sobre la base de datos siempre supone un riesgo. Ejecutar con precaución y en entornos de testeo.

Microsoft Dynamics AX 2012, servicios web, .NET Interop, cliente-servidor y arquitectura de aplicación

¡Vaya título! ¿Qué tienen que ver todos estos conceptos y por qué debería tenerlos en cuenta? Es posible que no sea una situación que se nos presente todos los días, pero hay veces donde hay que tener todos esos conceptos en cuenta para hacer que un fragmento de X++ funcione correctamente. Este ha sido mi caso: Tengo que consumir un servicio web externo desde Microsoft Dynamics AX 2012. Parece fácil, ¿no?. El servicio web se va a consumir en un proceso por lotes (servidor), pero también debe poder llamarse manualmente desde formularios (cliente).

En Microsoft Dynamics AX 2009, para utilizar un servicio debíamos añadir una referencia de servicio al AOT. En la versión 2012 creamos un proyecto Visual Studio de tipo Librería de clases. En ese proyecto de Visual Studio agregamos una referencia de servicio y agregamos el proyecto al AOT. No voy a entrar en detalle sobre ésto porque esta bien explicado por ejemplo en este white paper.

Una de las cosas a tener en cuenta acerca de los conceptos del título de este post está en las propiedades del proyecto en Visual Studio:

Propiedades Proyecto Visual Studio

Lo relevante aquí es marcar Deploy to Client si queremos que la DLL se despliegue a los clientes y Deploy to Server si queremos que se despliegue al servidor. De esta manera, el sistema copiará la librería cuando sea necesario a la carpeta correspondiente, descargándola de la base de datos (de la Model Store) donde está almacenada. Dependiendo de cómo se ejecute el código X++ que utiliza esta librería podemos marcar uno u otro o los dos.

Continue Reading…

AX TIP: Error en el Role Center de la MV Demo de Dynamics AX 2009

La máquina virtual demo de Microsoft Dynamics AX 2009 da un error al ejecutar el Role Center:

Esto es porque la dirección a la que está apuntando la instalación de Dynamics AX (http://sharepoint/)no es accesible por el navegador. Se puede solucionar cambiando esta dirección en la configuración de AX pero siempre me ha resultado mas facil hacerlo de esta forma para mantener los accesos directos que vienen en la máquina demo:

Continue Reading…