j.a.estevan

Una característica bastante molesta que te encuentras programando para Microsoft Dynamics AX es la manera en la que se tratan los saltos de líneas al presentar texto en formularios utilizando etiquetas. Por ejemplo, la siguiente línea:

Presenta un diálogo normal con un texto en varias líneas (hace caso del carácter \n para poner un salto de línea):

Sin embargo al convertir el mismo texto en una etiqueta, el resultado es distinto:

Y ocurre lo mismo si se utiliza una etiqueta con comodines (%1, %2, …) y la función strFmt de esta manera:

Para que la etiqueta haga caso del salto de línea hay que utilizar la función strFmtLB:

Y así si funcionará:

Pero esta función no sustituye a la anterior. Esto es, en caso de tener comodines y saltos de página habrá que incluir las dos funciones. Esto es bastante molesto cuando modificas una etiqueta y pones un salto de línea. Da la impresión de haberse roto algo que antes sí funcionaba, y es que esta función no esta incluida nunca en el código si no es necesaria de forma explícita.

Cuando se desarrolla para Microsoft Dynamics AX es muy común tener que consultar tipos de datos, nombres de campos, tablas, etc. para mantener la coherencia entre objetos nuevos y estándar. Esta consulta se puede hacer mediante las propiedades de los formularios (el botón Configurar del menú contextual estándar) y consultando el diseño o la query que se muestra en este formulario o yendo directamente al objeto del AOT:

Pero si esta consulta la tenemos que hacer muy a menudo, como al principio de un gran desarrollo, es molesto tener que hacer todos estos pasos cada vez y se puede consultar mucho mas fácilmente de esta manera:

Aunque esto es algo que tiende a desaparecer en el próximo Microsoft Dynamics AX 2012, de momento es una funcionalidad muy útil en la versión 2009, ya que es la única manera de solventar algunas limitaciones técnicas.

Me estoy refiriendo a la posibilidad de utilizar el .NET CLR Interop para ejecutar desde nuestro código X++ librerías desarrolladas en .NET (ya sea C# o VB.NET). Esta integración también tiene sus propias limitaciones pero amplía de manera notable las posibilidades de desarrollo en AX 2009.

Voy a hacer un ejemplo paso a paso, y el primer paso es crear la propia librería desde Visual Studio. En mi caso voy a utilizar (el ya súper antiguo) Visual Studio 2005 para crear un nuevo proyecto “Biblioteca de clases”:

El código va a ser muy sencillo para no complicar la prueba, simplemente devolverá el nombre del equipo donde se ejecuta el código (esto se puede utilizar para comprender la ejecución de código en el cliente (devolverá la máquina local) o en el servidor (devolverá el AOS):

Enviar correos desde Microsoft Dynamics AX mediante código X++ es muy sencillo, pero requiere de demasiado código si se quiere aplicar de manera reutilizable.

Para enviar un email utilizando la clase SysMailer estándar haremos algo parecido a esto:

A veces en nuestros desarrollos queremos limitar ciertos procesos a usuarios que tengan activa determinada clave de seguridad (Security Key):

(la imagen es de la documentación oficial)

 Para hacerlo utilizaremos las funciones que el estándar dispone para ello. Encontramos un ejemplo de utilización en la clase estándar SysTest:

Están disponibles los objetos actualizados de Microsoft Dynamics AX para cumplir con los requisitos de la Ley de Morosidad según el BOE-A-2010-10708:

• Microsoft Dynamics AX 4.0 SP2
• Partner Source *
• Customer Source *

• Microsoft Dynamics AX 2009 SP1
• Hotfix *

* requiere login

Hace ya algunos meses que venimos hablando de Microsoft Dynamics AX 2012, desde su presentación en la Microsoft Dynamics AX Technical Conference 2011 de la que ya hablamos en su día, se ha publicado muchísima información sobre las novedades que nos esperan en esta nueva versión.

Aprovechando el Microsoft Dynamics AX 2012 Virtual Launch Event de esta semana se han liberado también multitud de materiales oficiales muy interesantes, algunos accesibles sólo desde Partner Source, y otros totalmente abiertos:

En primer lugar son muy interesantes las demos interactivas que se han publicado en la web oficial del producto y ofrecen una oportunidad de simular de primer mano la utilización de la nueva interfaz tanto para temas de desarrollo como funcional. Sin instalar nada, desde la propia web utilizando Silverlight, vale la pena probarlos:

En Microsoft Dynamics AX, como en la gran mayoría de ERP’s, se pueden facturar líneas de forma parcial y agruparlas según diferentes criterios. El usuario puede elegir el número de líneas que desee:

y facturarlas completamente o en parte, dejando el resto pendiente de facturar o no, agrupandolas en facturas por clientes, por dirección, etc.:

Dado el tamaño y la inmensa funcionalidad incluida en Microsoft Dynamics AX, parece lógico pensar que se han seguido diferentes patrones de diseño para implementarlo, y en efecto así es.

Conocer y respetar estos patrones de diseño y tambien las buenas practicas es muy importante para mantener un buen nivel en nuestros desarrollos y procurar no “romper” el funcionamiento estándar de la aplicación con nuestras modificaciones, si bien no todos ellos estan completamente documentados, la mayoría se perfeccionan con la experiencia, pero la base se puede aprender mediante la documentación oficial:

• Microsoft Dynamics AX Design Patterns

Estos patrones no son arbitrarios, como se puede comprobar la mayoría se basan en patrones de diseño mas o menos estándar o al menos comunmente reconocidos como válidos, por ejemplo:

Una característica muy interesante de Microsoft Dynamics AX es su capacidad para realizar auditoría de cualquier tabla que necesitemos de manera estándar y configurable mediante la funcionalidad “Registro de base de datos“.

Este registro es muy sencillo de configurar, se eligen las tablas y los campos que se desean auditar. Por ejemplo, en este caso queremos guardar un registro de las modificaciones en la tabla de proyectos: