Migración de datos de NAV a Business Central

0
56

La migración de datos consiste en la preservación de los datos entre las distintas versiones de NAV / Business Central. Es el apartado mas simple de una migración pues los pasos vienen dados y simplemente hay que seguirlos.

Aunque sea un proceso simple hay algunas estrategias que pueden ahorrarnos tiempo dependiendo de la tarea a realizar. En esta entrada voy a explicar dos aproximaciones para una migración a extensiones. La primera es la que expone Microsoft actualmente para realizar una migración de datos a las nuevas versiones de Business Central, la segunda es la que fue usada antes de conocer o existir el primer método y como necesidad ante el paso por múltiples versiones.

Primer método de migración de datos a extensiones en Business Central

Microsoft pone a nuestra disposición una forma sencilla de migrar los datos de C/AL a AL, es decir, de tablas modificadas estándar a TableExtensions y de tablas 50k a nuevas tablas 50k en extensiones.

La guía de Microsoft da toda la información del proceso paso a paso de qué se debe hacer. No óbice voy a tratar de forma esquemática los fundamentos del proceso a fin de facilitar su comprensión y aclarar los pasos de la guía.

Para ello nos presenta el siguiente esquema:

Los números indican los puntos de la lista siguiente

La idea principal es:

  • Se parte de todo tal como está en BC14 C/AL.
  • Se crea una extensión para los datos, es decir, solo tablas y sus campos, nada de código y hacemos que los datos de C/AL pasen a las tablas de esa extensión con solo tablas tal cual está en C/AL. (Task 5 en Microsoft)
  • Se crean tres extensiones vacías para poder luego lanzar el código de upgrade a BC22. (2 por Microsoft y luego tantas como extensiones personalizadas vaya a haber finalmente). (Task 4 en Microsoft)
  • Se crea una extension con mismo appId y nombre que la de las tablas del punto 2 y ahí se establece la información de que los datos de esa extensión tienen que pasar a las extensiones de v22 (que serán las app estándar de Microsoft y la/las de las personalizaciones). (Task 5 segunda parte en Microsoft)
  • Se utiliza la o las extensiones definitivas así como las propias de Microsoft para la versión BC22. (Task 13 en adelante en Microsoft)

Para obtener la extensión del segundo punto, es decir, una extensión con todas las tablas tal cual están en BC14 pero en AL se deben seguir los pasos de Migración a extensiones (Código), Dynamics NAV a Business Central, en concreto:

Development Shell (BC14):

Export-NAVApplicationObject -DatabaseServer .\BCDEMO -DatabaseName "BC14" -ExportToNewSyntax -Path "C:\export2al\bc14tablesonly\exportedbc14-tables.txt" -Filter 'Type=Table;Id=1..1999999999' -ExportTxtSkipUnlicensed 

CMD:

Cd "C:\Program Files (x86)\Microsoft Dynamics 365 Business Central\140\RoleTailored Client"

txt2al --source="C:\export2al\bc14tablesonly" --target="C:\export2al\bc14tablesonly\al" --tableDataOnly

Con esto se obtienen todas las tablas en AL y ya puede realizarse la extensión del segundo punto. Lo importante es que en la carpeta «.alpackages» tiene que importarse el fichero «System.app» de la ruta «C:\Program Files (x86)\Microsoft Dynamics 365 Business Central\220\AL Development Environment»:

Si esto se realiza con licencia Premium no habrá ningún problema. Si, por el contrario, se realiza con una licencia Essentials entonces tendremos errores en todos esos campos relacionados con tablas que no han sido exportadas ya que estaban fuera de la licencia. Para ello se puede usar el buscador con regex para eliminar muchas entradas como:

Buscar y eliminar por:
TableRelation = IF\s*\(.*?\)[^;]*;
 TableRelation = .*?;     (Tiene espacio al inicio)
ValidateTableRelation = false;
ValidateTableRelation = true;
AccessByPermission = TableData .*?;
field\(\d+;[^}]*FieldClass = FlowField;[^}]*\}   (Hay que darle un salto de carro al final)

Hecho esto, los pocos errores que queden pueden realizarse de forma manual, ya habremos quitado todos los TableRelation los AccessByPermission y los campos calculados y ya estará lista la extensión.

La siguiente es una imagen de la extensión vacía de la base application de Microsoft del punto 3:

A continuación la extensión del cuarto punto donde las dos primera «id» son las de Microsoft y la tercera sería la de la extensión con personalizaciones:

En esta última app es donde se le indica a qué extensiones tiene que llevar todos los datos de la extensión de solo tablas que se realizó en el primer paso.

Segundo método de migración de datos a extensiones en Business Central

Este método lo he utilizado antes de conocer la existencia del primero (o de que existiera) y después de conocer la existencia del primero para, a mi juicio, minorar los potenciales errores y reducir los tiempos de trabajo para la migración de datos. La idoneidad de la utilización de este método se basa en:

  • Existen tantos objetos de tabla en licencia libres como tablas nuevas y tablas estándar con campos nuevos hay en la base de datos. (O se dispone de una licencia de partner, que no tiene limitación en el uso de objetos)
  • Hay que pasar por muchas versiones de NAV para llegar a BC, es decir, supondría crear manualmente los campos en las tablas estándar de todas y cada una de las versiones por las que se pase.


Dada una migración con los siguientes pasos:

Crear los campos nuevos en tablas de cada versión puede llevar bastante tiempo y dar lugar a errores humanos en demasiados puntos como para encontrar, a posteriori, el problema.

El método se pasa en traspasar todo a tablas nuevas, es decir, duplicar las tablas 50k y crear nuevas tablas con la clave primaria de la tabla estándar modificada y sus nuevos campos. En el ejemplo anterior significaría tener una tabla 70.000 igual a la 50.000 y una tabla 70.001 con los campos «Document Type», «Document No.» y el campo nuevo.
Esto facilita la tarea por cuanto en todas las versiones es meter los objetos estándar de cada versión y estas nuevas tablas 70k.

Ahora bien, la ardua tarea de pasar los datos a las tablas 70k se antoja complicada. Para este traspaso yo he venido utilizando un programa, NimbleText. Este programa lo que realiza es poder reiterar una estructura de texto en base a variables. De esta forma, una vez se ha hecho la primera función de traspaso de datos, se puede utilizar esa estructura para el resto de tablas de la siguiente manera.

1º Se realiza un proceso con la primera función de traspaso y se exporta en txt:

Se copia la función en NimbleText y se anota la estructura de las numeraciones internas que deben asignarse manualmente en .txt y el resto de cuestiones:

De esta manera el «$0» se sustituirá por el primer elemento de arriba y el «$6», por ejemplo, por el último. Una vez se genera el resultado del programa se obtiene una cadena que podemos copiar y pegar en el .txt y de esa forma ya estarían realizadas todas las funciones de traspaso de datos a las tablas 70k:

Una vez hecho esto, la migración entre versiones será como la de una versión estándar pues todos los objetos serán estándar salvo las tablas 70K.

En el punto de BC14, se debe realizar un proceso para devolver los datos de las tablas 70K a las tablas y TableExtension nuevas. Para ello deben haber sido creadas las extensiones con los objetos de tabla y TableExtensions correspondientes y preparar otro proceso para traspasar la información. Para ese proceso también se utilizará el programa NimbleText.

En este caso hay una parte un poco mas laboriosa ya que, aunque con las tablas 50k se puede hacer un mero Transferields y un Insert, con las tablas estándar habrá que hacer un Get y ese Get depende de la clave primaria, no óbice el modus operandi es el mismo:

Ahora ya está toda la información según la estructura de tablas final por lo que solo queda realizar las conversiones de BBDD entre versiones e instalar las distintas APP de Microsoft para terminar la migración.