20 Jun Primeros beneficios de la migración con eventos
A partir de Dynamics NAV 2016, Microsoft aportó una nueva posibilidad para realizar el desarrollo de nuestras aplicaciones. Es lo que llamamos eventos. La idea principal es no modificar los objetos estándar de NAV, separando nuestro código únicamente en los objetos personalizados para el cliente. Además, este tipo de desarrollos es el que permitió el desarrollo de extensiones a partir de NAV 2017.
Lo primero que se tiene que tener claro es qué tipos de eventos existen. No voy a entrar en detalle en este aspecto, ya que Internet está lleno de artículos sobre este tema, pero básicamente la idea es que hay dos tipos de eventos: los de integración y los de subscripción. Los primeros son los creados por Microsoft en ciertos puntos clave del código estándar de NAV (o por los partners en los Addons), y a los cuales hacemos referencia para añadir las personalizaciones deseadas, mediante los eventos de subscripción.
La teoría parece buena pero ¿es así? ¿Merece la pena cambiar la lógica de programación a esta característica o, por lo contrario, es un quebradero de cabeza que trae más problemas que beneficios a nuestro equipo de desarrollo? En este blog voy a comentar mis impresiones y los beneficios que hemos encontrado durante los dos primeros años enfocando nuestros desarrollos hacia este camino.
Pues bien, inicialmente no le vimos mucho futuro, ya que era prácticamente imposible realizar cualquier desarrollo utilizando sólo eventos sin modificar nada de código estándar. Siempre chocábamos con alguna función sin evento de integración deseado (sobre todo en las codeunits de registro de compras/ventas o diarios). Era bueno era para gestionar Addones sin poca relación con código estándar. En estos casos se nos abrió la posibilidad de añadir los eventos de integración deseados, para luego relacionarlos con cualquier modificación del cliente, usando eventos de subscripción para estas personalizaciones. De esta forma teníamos un Addon completamente limpio y sin diferencias en los distintos clientes, y facilitaba la gestión y actualización de parches (vendría a ser como si nuestro Addon fuera el código estándar de NAV que no queremos modificar).
Pero todos los puntos hasta entonces negativos cambiaron radicalmente a partir del lanzamiento de Dynamics NAV2018. En esta nueva versión existe un gran aumento de eventos de integración disponibles en código estándar. Por ejemplo, en la codeunit de registro del diario general, los eventos pasaron de 4 a 13, o en la de registro de ventas, de 4 a más de 30. Cierto es que aún hay varios puntos donde se echan de menos, pero las posibilidades son mucho más amplias, y el abanico sigue creciendo, ya que sólo en los 5 primeros Cumulative Updates de esta versión, Microsoft ha publicado un mínimo de 17 nuevos eventos en código estándar (y esperemos que este número no pare de crecer).
Primeras impresiones
Gracias a estas nuevas posibilidades, desde Grup de Serveis Triangle hemos apostado para realizar los desarrollos de NAV2018 y las migraciones a dicha versión intentando aprovechar al máximo los eventos disponibles y, con medio año de puesta en marcha, hemos llegado a distintas conclusiones:
- Con el desarrollo basado en eventos, la actualización de parches estándar, Cumulative Updades o cambios de versión son más eficientes ya que al no modificar tantos objetos estándar, la mayoría se pueden importar directamente sin hacer merges, y en los que lo requieran, las diferencias serán mínimas. Esto se traduce en menor tiempo de desarrollo y un coste más bajo de este tipo de proyectos para el cliente.
- Mejor comprensión del código y de la reestructuración que han sufrido ciertas codeunits. Si bien es verdad que en los primeros desarrollos puede ser complicado para los desarrolladores encontrar el evento adecuado para relacionar nuestro subscriptor (ya sea porque el evento no está en la codeunit sino en una tabla o bien porque el código estándar ha sido restructurado), cuando nos paramos a estudiar detenidamente qué funcionalidad busca conseguir el desarrollo, nos encontramos que muy probablemente exista uno específico para lo que estamos haciendo (unos casos claros podrían ser los OnAfterCheckSalesDoc y OnAfterTestSalesLine para testear la cabecera y las líneas, respectivamente, en el proceso de registro de ventas). Esto aporta una primera comprensión a la idea de la reestructuración de código que se ha producido en las codeunits principales. También aporta una mejor eficiencia y reducción de errores, porque nos aseguramos que lo que queremos desarrollar realmente lo estamos haciendo en el punto correcto, por ejemplo, si estamos haciendo un test del registro de ventas, está bien utilizar los eventos creados para ello (que he indicado anteriormente), no hacerlo en cualquier punto del proceso de registro, aunque a nivel funcional no de errores.
- Por otro lado, el único aspecto negativo que podría indicar sería, para ciertos programadores no involucrados en el desarrollo inicial, la dificultad de encontrar el evento suscriptor creado. Pero para minimizar este problema están los parámetros y las guías de desarrollo de cada Partner, teniendo bien especificado y documentado cómo y dónde se van a crear los eventos subscriptores relacionados con cada funcionalidad.
Así pues, ya que las mejoras aportan beneficios tanto al equipo de desarrollo como al cliente, desde Grup de Serveis Triangle creemos que es positivo realizar este tipo de desarrollos y, si Microsoft sigue aportando nuevos eventos de integración en su código, en el futuro toda la programación en C/AL será reconvertida hacia este objetivo.