Cómo utilizar Upgrade Codeunits en NAV 2017
Desde la versión 2015 de Microsoft Dynamics NAV hasta la presente, se han venido incorporando al producto bastantes novedades a nivel de desarrollo. Después de haber pasado cierto periodo de madurez, inexplicablemente algunas de éstas no han gozado de tanta popularidad como merecieran, aún siendo tremendamente útiles. Una de estas características es la utilización de upgrade codeunits.
Habitualmente nos habremos topado con este concepto en los entornos de migración de versiones de NAV, como parte del proceso estándar de actualización de datos.
Sin embargo, podemos utilizar esta técnica en tareas más mundanas o habituales, siempre que haya que actualizar la estructura de una o varias tablas.
Un sencillo escenario habitual
Para ilustrar el uso de upgrade codeunits, vamos a realizar un ejemplo simplificado a partir de un escenario muy sencillo.
Imaginemos que tenemos una tabla en NAV, con la siguiente definición de campos:
Esta tabla, en el entorno de producción de nuestro cliente, contiene datos:
Sobre esta tabla, queremos hacer un cambio en su estructura. Concretamente, queremos cambiar el ID, el nombre, y el tipo de datos del último campo, de forma que la tabla resultante quede así:
Vamos a suponer que ya hemos realizado los cambios en esta tabla en un entorno de desarrollo, y ahora queremos actualizar el entorno de producción del cliente. Como hemos visto, en el entorno de producción esta tabla actualmente contiene datos, así que no podemos cambiar su definición tan fácilmente si no queremos perderlos.
Veamos cómo podemos llevar a cabo esos cambios sin perder información.
Cara a cara con el problema
Si intentásemos actualizar esta tabla en el entorno del cliente importando un fichero .fob con la tabla modificada, nos toparemos con este problema.
El sistema detectará que hay cambios potencialmente destructivos en la nueva tabla que estamos importando, y nos avisará de ello.
La sincronización, evidentemente, fallará:
Y la tabla nueva se habrá importado, pero como su esquema no se ha sincronizado con SQL Server, no podremos utilizarla. Y entonces sí tenemos un problema.
Vamos a ver qué tendríamos que haber hecho para actualizar correctamente los objetos sin perder datos.
El proceso de actualización de datos
Vamos a seguir estos pasos.
- En nuestro entorno de desarrollo, lo primero que vamos a hacer es crear una copia de la tabla afectada, que llamaremos Temp Mov. Proceso. Esta nueva tabla tendrá necesariamente los mismos campos clave que la original, y el campo o campos que se vayan a modificar. El resto de campos y todo el código asociado a triggers no será necesario.
En nuestro caso tendremos esta nueva tabla:
- Realizamos los cambios en la tabla original, quedándose finalmente así:
- Creamos una nueva codeunit. Será nuestra Upgrade codeunit.
Deberemos marcar la propiedad Subtype = Upgrade.
Esta codeunit deberá tener al menos dos funciones:
- Una función que sirva para copiar y guardar los datos actuales de las tablas afectadas por la actualización, en otra tabla o tablas temporales. Esta función tendrá la propiedad FunctionType = TableSyncSetup.
- Una función que sirva para, a partir del contenido de las tablas temporales que hemos guardado anteriormente, restaurar (con o sin manipulación previa) los datos a la nueva estructura de datos de la nueva tabla. Esta función tendrá la propiedad FunctionType = UpgradePerCompany (caso más habitual) o UpgradePerDatabase.
Opcionalmente es posible crear una tercera función para comprobar que se cumplen ciertas precondiciones que indicaremos nosotros, antes de realizarse la actualización de datos. Esta función deberá tener la propiedad FunctionType = CheckPrecondition.
- Creamos la función para guardar los datos en la tabla temporal. Es necesario marcar la propiedad FunctionType = TableSyncSetup, y añadir como parámetro por referencia un registro de la tabla virtual 2000000135 Table Synch. Setup. [ También necesitaremos una variable local que apunte a la codeunit 9900 Data Upgrade Mgt. ]
- Este paso es opcional. Hemos decidido que el sistema no permitirá actualizar los datos si hay registros en la tabla Lín. Diario General, así que hemos creado una función de testeo de precondiciones. Hemos de marcar la propiedad FunctionType = CheckPrecondition.
- Por último, escribimos una función que lee los registros de la tabla temporal, y los devuelve a los nuevos campos o campos modificados de la tabla original. Es necesario que esta función tenga la propiedad FunctionType = UpgradePerCompany.
- El resultado final de nuestra upgrade codeunit será algo así:
- Exportamos estos objetos a un fichero .fob: Nuestra tabla modificada, nuestra tabla temporal, y nuestra upgrade codeunit.
- Abrimos el entorno de producción del cliente, o aquél que queramos actualizar, e importamos el fichero .fob:
Elegimos sincronización con Validación:
- Inmediatamente después, realizamos la actualización de datos, invocando manualmente la opción Herramientas –> Actualización de datos –> Iniciar…:
- Y ya hemos terminado. Hemos actualizado la estructura de la tabla Proceso sin perder los datos. Podemos comprobarlo:
Comentarios adicionales
¿Qué ha pasado con nuestra función de tipo CheckPrecondition? Si la base de datos destino no hubiese cumplido los requisitos (en nuestro caso, no debería haber registros en la tabla Lín. Diario General), el proceso de actualización se hubiese detenido con un error, y tendríamos que usar los comandos de Powershell para averiguar el motivo del mismo:
Conclusión
Aunque la solución a este tipo de escenarios puede implementarse por código realizando usualmente varios procesos manuales (a los que estamos más que habituados), conviene plantearse la utilización de upgrade codeunits en aquellos casos en los que el volumen de datos a actualizar sea muy grande, o tengamos varias empresas.
Sus principales bazas residen en su alto rendimiento de proceso y en la posibilidad de semiautomatizar su ejecución mediante los comandos de Powershell.
Como siempre, estoy abierto a críticas constructivas. Así que podéis hacernos llegar vuestros comentarios o correcciones respecto a este artículo con total libertad. Un saludo.
Fran Blanco
Dynamics
Si quieres contactar con nosotros puedes enviarnos un email a mkt@aitana.es, usar el formulario de contacto o llamar al 902 500 358.