Descubre la funcionalidad «eventos y suscripciones» en Microsoft Dynamics NAV

Todo el mundo que conoce Navision (Dynamics NAV) siempre dirá que las migraciones son lo más complicado de realizar –en las versiones antiguas-, porque te puedes encontrar de todo. En una base de datos que ha podido tocar mucha gente, unos pueden haberlo hecho mejor; otros no tan bien; unos habrán seguido una metodología; otros no; otros, debido a las prisas, han metido la solución directamente entre el código estándar; o han comentado algo que puede afectar en la nueva versión; vamos, un sin fin de cosas.

Todo el mundo evoluciona, incluso al principio. El código que personalmente realizaba, sólo se limitaba a que funcionase y esa era la única preocupación. Pero a lo largo del tiempo puedes ver que, lo importante -además del funcionamiento por supuesto-, es, que el código sea limpio, entendible y elegante.

Tanto en NAV (C/AL) como en cualquier otro tipo de lenguaje de programación, el código, a mi entender debería cumplir ciertas características, como:

• Limpieza
• Simplicidad
• Elegancia

Probablemente muchos de los que leáis esto, sois programadores, y puede que, hayáis tocado algo de NAV o simplemente os guste programar. Diréis que hay muchas más características que el código debe cumplir y seguro que estáis en lo cierto, pero a mi modo de ver, en cualquier tipo de solución que ofrezcamos, el código debería ser limpio, es decir, lo más claro posible, que sólo con verlo ya sepamos cual es la intención de lo que quería hacer el programador. Simple, siempre, al menos en NAV, hay una solución óptima, es decir, podemos aprovechar la funcionalidad estándar y con una pequeña modificación crear la funcionalidad que el cliente requiera, o en vez de escribir una función de 8 páginas, podemos usar una función de sólo 8 líneas y hacerla recursiva para que haga lo mismo. Siempre hay un camino para hacerlo simple, pero no siempre es lo más fácil. Y por qué no, elegante, el código debe ser bonito.

Antes, en versiones antiguas -hablo de NAV 2015 y anteriores- esto se podía hacer de muchas maneras, desde creando funciones u objetos, derivando todo el código fuera del objeto implicado, e intentar insertar el menor código posible dentro del estándar; o bien, inventar algún método para hacer lo mismo y que llamara a funciones en objetos. De alguna u otra manera, siempre había que modificar el código, la cuestión era que la modificación fuera lo más sencilla y simple para que la migración/actualización a futuras versiones fuera lo menos traumática posible.

Con esto quiero decir que Microsoft se está tomando en serio la plataforma NAV para ayudar a los programadores proporcionando herramientas para realizar un buen diseño a la hora de hacer un buen código y dotarlo de calidad.

En la última versión Microsoft Dynamics NAV 2016 vemos que han añadido una funcionalidad llamada eventos y suscripciones. Esto quiere decir que podemos generar Eventos en objetos, para posteriormente poder usarlos a nuestra necesidad.

Veamos cómo funciona con un pequeño ejemplo.

Habitualmente una de las modificaciones más habituales, es por parte del cliente hacer algo <lo que sea> cuando se registra un pedido/factura/abono en ventas/compras, es decir, algo adicional a lo que hace el estándar. Para ello, con el modelo antiguo crearíamos una función o meteríamos el código dentro de la propia Codeunit 80 para el caso de ventas y la Codeunit 90 para el caso de compras. Con la nueva funcionalidad de Eventos, podemos hacer lo mismo pero de forma muy diferente. Podríamos generar un evento en la Codeunit 80 para que posteriormente cualquier otro objeto consuma dicho evento y haga lo que necesitamos, pero el propio objeto ya dispone de Eventos listos para consumir. De esta forma, tendremos nuestra solución aislada del resto de la aplicación y sin tocar el objeto origen.

Para ello entramos en modo diseño en el objeto Codeunit 80:

Y vemos las funciones existentes:

Si vemos las propiedades de la función OnAfterPostSalesDoc() podemos ver las siguientes opciones:

Event, con valores No, Publisher y Subcriber, por defecto tendrá el valor, No, lo que significa que es una función normal, pero si seleccionamos Publisher, será que generamos un nuevo evento. Subscriber lo que permitirá es suscribirnos algún evento ya creado.

La propiedad EventType, es para seleccionar qué tipo de evento vamos a generar. Puede tener los valores Business e Integration. Business serán para eventos que generan los ISVs y Microsoft y los de tipo Intregration será cuando se utilice normalmente con otras aplicaciones como podrían ser Microsoft CRM.

Con la propiedad IncludeSender tendremos la posibilidad acceder a las funciones globales que tenga el objeto que publica el evento (lo cual no está nada mal). Para nuestro ejemplo he establecido las propiedades que podéis ver en la imagen anterior. Y no tocamos nada en nuestra codeunit 80. Con esto, sólo hace falta que alguien lo consuma.

Vamos a generar un objeto nuevo, en este caso una nueva Codeunit, por ejemplo 50000 y la llamaremos Show Message After Post. Una vez generado, creamos una función y le indicamos que será de tipo Subcriber del objeto Codeunit Sales-Post (Codeunit 80).

Le indicaremos que será de la función OnAfterPostSalesDoc() que vimos previamente, en la propiedad EventFunction. Y ya podemos escribir nuestro código:

En este caso, el código sólo se limitará a mostrar un mensaje por pantalla, pero podríamos haber hecho lo que quisiéramos -para este ejemplo pondremos el texto directamente en código, pero deberíamos haber usado una TextConstant para hacerlo bien 😉

Salvamos.

Vamos a generar y registrar una factura de venta para probar nuestro maravilloso código:

Registraremos una factura al cliente 10000 GDE Distribución S.A.:

 

Una vez creada la factura, procederemos a su registro con la acción Registrar.

Y voilà, nuestro mensaje aparece tal y como habíamos pensado, al final del registro del documento.

Con esto quiero mostraros cómo usar eventos en objetos y sin escribir ni una sólo línea de código en el objeto origen, podemos consumirlo y crear toda la funcionalidad adicional que necesitemos, así las migraciones serán mucho más sencillas, ya que el objeto estándar no se ha tocado. Además, si quisiéramos que la aplicación funcionase de forma estándar, sólo deberíamos borrar el objeto creado, ya que es nuestro objeto el que consume un evento.

Aquí vemos cómo hemos consumido Eventos que nos proporciona la plataforma NAV, pero también podemos crear nuestros propios eventos y añadirlos donde nos más interese:

Ya no hay excusas para hacer las cosas bien.

Ahora Feel the code, Neo!

Descubre aquí más información sobre el desarrollo de proyectos con Microsoft Dynamics NAV.

Julio Poémape es NAV Architect en Sogeti España desde Abril 2015 aportando  conocimiento y experiencia. Julio empezó su carrera en 1999 como desarrollador de aplicaciones en NAV, pasando por diferentes roles en la implantación de soluciones a empresas, técnico, consultor y diseñador. MCP y MCTS, también ha trabajado con Microsoft Dynamics CRM y realizado diversas integraciones con otras aplicaciones como Sharepoint, desarrollos Web y .NET.