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:

• Necesito precio para unos accesorios de baño para mañana {contrato a precio fijo, alcance fijo, plazo fijo}
• Sin problema, le cuestan 50€ cada uno {confirmación del contrato}
• Perfecto, pero los quiero colocados en la pared {ampliación de alcance no prevista}
• OK, se los doy colocados en la pared {aceptación ¿? de la ampliación} :
  

Obviamente esta situación es ficticia, pero el resultado es real. Esa “instalación” lleva así desde hace más de un mes en un baño público y nada indica que la situación vaya a mejorar en a corto plazo. Alguien ha dado esa instalación por “hecho” pero esa no es la impresión que da cuando necesitas secarte las manos.

Me gustaría analizar cómo se ha llegado aquí porque es algo que vemos todos los días cuando hablamos de software, que es a lo que vamos:

Leer el resto del artículo →

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:

Voy a procurar no extenderme mucho para contar lo sucedido en estos dos días de conferencias que hemos podido disfrutar en la Universidad Jaime I de Castellón, empezando como no podía ser de otra manera felicitando la impecable organización por parte de los organizadores de Agile Spain. Un 10 para ellos y mi agradecimiento.

Después comentar que es mi primer evento “masivo” en la comunidad Agile Spain así que no tengo la oportunidad de hacer una valoración comparativa como otros compañeros están haciendo. Como es obvio, sólo voy a comentar las charlas a las que asistí. Ha quedado un poco largo, si te aburre puedes bajar directamente a las conclusiones

Insanity: doing the same thing over and over again and expecting different results.- Albert Einstein

(Locura es hacer lo mismo una y otra vez y esperar resultados diferentes)

Como expuse en mi anterior post: ¿Sure Step vs Agile? Condenados a entendernos, estoy convencido de que un cambio de filosofía hacia el mundo ágil no sólo es positivo sino que es totalmente posible dentro del mundo de los grandes ERP en general, y del canal Dynamics en particular.

Como exponía en ese artículo, hay varios handicap que superar como la resistencia al cambio (hay que cambiar la mentalidad de muchas personas involucradas), la falta de confianza en el sistema para proyectos de largo alcance o incluso la falta de colaboración del cliente. Sin embargo hay ciertos trabajos muy típicos de esta industria que son ideales para empezar a experimentar con este cambio, a pesar de que el proyecto, en general, se gestione con Sure Step:

• Migraciones (cambios de versión): Una migración es un proceso totalmente acotado con tareas claramente definidas y planificables, pero lo importante es que en este proceso no es tan importante la documentación (a menudo no es para nada importante) como la implicación del cliente en el proceso tanto para la realización de diversas pruebas al finalizar cada tarea, como para solucionar consultas sobre la marcha en caso de imprevistos (en las migraciones siempre hay imprevistos). Lo de “ágil” se vuelve literal ya que cuando el proceso de migración termina se tiene que implantar en tiempos de parada del cliente, casi siempre en un fin de semana.

• Soporte post-arranque: Cuando se da por finalizada una implantación nueva y el cliente empieza a utilizar el sistema, a menudo se dará cuenta de que hay pequeños (o grandes) detalles que quiere modificar porque no se habían previsto durante las fases previas. La buena gestión de estas modificaciones puede diferenciar el éxito o el fracaso de una implantación ya que una cosa es que el proyecto finalice, y otra que el cliente de por cubiertas sus necesidades (o las que cree que lo son). Hacerle participe del coste y el esfuerzo de esos “extra” puede ser determinante para cerrar la implantación con todas las partes satisfechas.

• Actualciones de mantenimiento: De la misma manera que en el punto anterior, trabajar con un sistema programable como lo son todos los grandes ERP’s hace que siempre haya pequeños o grandes cambios a realizar para optimizar el trabajo diario. La buena gestión de las necesidades, el desarrollo y la implantación de los cambios sin interferir el trabajo de los usuarios es determinante para que los mantenimientos se finalicen con éxito y sin fricciones.

Si alguien ya ha empezado o esta interesado en estos cambios me encantaría recibir opiniones en los comentarios. Y si alguien quiere comentar o debatir en persona estaré en la próxima Conferencia Agile-Spain 2011 (#cas_2011)

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 unos días tuve una conversación muy interesante con un compañero de trabajo a raíz de mi anterior post El ratoncito ágil y La ruta de los elefantes. Este compañero defendía con bastante convicción la metodología de gestión de proyectos tradicional y me proponía diferentes motivos por los que en nuestro negocio no podían funcionar otras como Scrum o en general metodologías de filosofía ágil o lean (método, sin embargo, ámpliamente reconocida en el mundo de la fabricación industrial) seguro que os suenan:

1. Scrum (o la gestión ágil en general) no es apropiada para proyectos grandes (en tiempos, equipos, costes, …) con diferentes equipos en diferentes roles (comerciales, analistas, consultores, programadores, jefes de proyecto, …) y a menudo en diferentes ubicaciones.
2. Para aplicar estos métodos hay que cambiar la forma de trabajar de muchas personas integrantes de la empresa, y del equipo en particular, desde el comercial hasta el programador pasando por todos los roles intermedios, y esto tiene un coste y un riesgo a menudo inasumible.
3. A menudo ni siquiera el cliente está preparado para trabajar de manera ágil. No entiende las implicaciones o simplemente no está dispuesto o preparado para implicarse tanto durante toda la duración del proyecto. Espera pedir lo que necesita, y que se lo den todo hecho.