Hooks Pattern – Cómo agilizar upgrades de versión y productos

hook_patternEn este post quiero familiarizarme con el diseño de desarrollo que permite reducir en gran medida el tiempo que cuesta realizar upgrades y cambios de versión de productos. El nombre que recibe es el Hooks Pattern.

Este sistema o metodología permite, en el momento de hacer el merge (ya sea manual o automático) reducir en un gran porcentaje (más del 50%) el tiempo invertido en fusionar los objetos de la versión antigua con la nueva versión conservando los componentes personalizados del mismo.

En la oficina nos hemos encontrado múltiples veces con nuevas versiones de un producto basados en la versión internacional (W1) y teniendo que localizarla en la española (ES). Si os habéis encontrado en una situación similar, sabréis que la parte más sencilla es la de pasar los objetos específicos. Esos objetos que están en un rango fuera del estándar, ya sea 50.000-99.999 o rango de add-on, ya que es simplemente importarlos encima y ya.

La parte difícil viene cuando hay que fusionar los estándar. Esa codeunit 12, 80 o 90, esa tabla de documentos… Qué os voy a contar.

¡Y aquí es donde entra el Hooks Pattern! 

Esta metodología promueve la creación de codeunits relacionadas a objetos estándar. De este modo y minimizando el código presente en objetos estándar, facilitaremos en gran medida los upgrades. En cuanto a la nomenclatura de estas codeunits, existe un estándar que podéis ver en el siguiente desplegable.

Nomenclatura Codeunits

 

¿Cómo usar este patrón “gancho”? 

Paso 1: Crear la codeunit “Hook” si no existe ya.

(Imagen de MSDN)

Paso 2: Crear dentro de esta codeunit una función para cada evento mayor de la función a la cual va “enganchada”. Por ejemplo, en el caso de la codeunit de lanzamiento de docs. de venta (414), un evento mayor podría ser OnBeforeReleaseSalesDoc (antes de lanzar doc. de venta).

Paso 3: Asegurarnos de que el primer parámetro de cada función de la codeunit Hook es la variable de tipo “Record” como referencia (el primer “tick” del parámetro activado).

Paso 4: Declarar dentro de la codeunit principal una variable global que apunte a esta nueva codeunit y llamar en cada evento importante a la función de la codeunit de tipo Hook que corresponda en ese momento.

Paso 5: Escribir todo el código que necesitemos modificar en ese momento en esa codeunit nueva.

Al final deberían quedar codeunits con tantas funciones dentro de sí como eventos importantes hayan dentro de los objetos a los que hagan referencia.

(Imagen de MSDN)

 

 

 

 

Este método cuenta con muchos aspectos positivos, pero también algunos negativos. Entre estos últimos destacar que depende el desarrollador mucho de la funcionalidad “Go to Definition” que solo está disponible en las últimas versiones de NAV hasta la fecha mientras que en versiones 5.0 por ejemplo no, o bien que al no ser la metodología estándar es difícil que los usuarios se acojan a ella. Sin contar que hay un consumo de codeunits que antes no existía.

Este método no será para todos, pero puede ser muy válido para ciertas situaciones.

Para más información, podéis dirigiros al blog de Microsoft en la MSDN.









This entry was posted in Best practices, NAV2009, NAV2013, NAV2013R2, Tips&Tricks and tagged , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*