La sala de máquinas – Doctrina DAL
(Parte 3 de la serie de 6 partes “El manual de la migración”)
En la Parte 1, definimos la Estrategia y el enfoque de Clean Cut. En la Parte 2, establecimos la Gobernanza y la importancia del Enriquecimiento del Usuario. Ahora, las reuniones han terminado. La sala de juntas está vacía. Solo estás tú, el servidor y un archivo con miles de registros de Maestros de Artículos.
Bienvenidos a la Sala de Máquinas.
Aquí es donde el plan teórico se topa con la cruda realidad de los bits y los bytes. En el ecosistema de Infor LN, esta fase suele malinterpretarse. Muchos consultores creen que la migración es simplemente escribir un script para insertar datos en tablas. Se equivocan. Los sistemas ERP como Infor LN son un organismo complejo de lógica empresarial. Si se intenta forzar su funcionamiento, colapsará.
Hoy exploraremos el núcleo técnico de la migración: el marco de intercambioinnegociable doctrina DALy la trampa psicológica de los falsos positivos.
El conjunto de herramientas: más que solo SQL
En los viejos tiempos de los ERP locales, teníamos acceso directo a la base de datos. Si queríamos crear un cliente, teóricamente podíamos escribir una sentencia SQL directamente en la tabla. En la era moderna de CloudSuite, esa puerta está cerrada y protegida. Debemos usar las herramientas oficiales que proporciona la plataforma.
Si bien el mercado ofrece potentes herramientas externas e Infor proporciona alternativas como los complementos de Excel (perfectos para actualizaciones pequeñas y puntuales), mencionaremos los esquemas de intercambio como el principal medio para la migración, ya que es una solución integrada que ya está disponible para que todos la utilicen.
Los esquemas de intercambio representan el mejor equilibrio entre rendimiento e integridad. Al ser una herramienta nativa integrada directamente en Infor LN, procesa los datos localmente en el servidor, respetando plenamente la validación de la lógica de negocio (DAL). Es la herramienta principal diseñada precisamente para este propósito.
Considera Exchange Schemes no como una simple herramienta de importación, sino como un motor de traducción. Te permite asignar tus archivos planos a las estructuras de tabla internas de LN, gestionando las conversiones sobre la marcha. Tanto si tu archivo de origen utiliza formatos de fecha específicos como si requiere una asignación de campos compleja, Exchange lo convierte automáticamente a la lógica interna de LN. Además, permite la gestión por lotes, lo que garantiza que puedas agrupar las importaciones y respetar las dependencias, como cargar los grupos de artículos antes que los propios maestros de artículos.
La doctrina DAL: Velocidad vs. Seguridad
Este es el concepto técnico más importante de toda la serie. Infor LN se basa en una capa de acceso a datos (DAL). Esta es una capa de software que se sitúa entre la interfaz de usuario (o la herramienta de importación) y las tablas físicas de la base de datos.
Para obtener detalles técnicos sobre cómo DAL mantiene la integridad del negocio, consulte la descripción general oficial de Infor LN DAL.
Cuando creas una orden de producción manualmente en una pantalla, no solo estás introduciendo datos. La capa de acceso a datos (DAL) trabaja en segundo plano para realizar la validación y garantizar que el artículo exista. Gestiona los valores predeterminados, rellenando automáticamente el almacén según la lógica del grupo de artículos. Y lo que es más importante, gestiona los disparadores.
Crear un encabezado puede desencadenar la creación de operaciones de enrutamiento predeterminadas o asignar inventario en una tabla completamente diferente.
Seamos honestos: la capa de acceso a datos (DAL) tiene ventajas y desventajas. El principal inconveniente es la velocidad, ya que validar la lógica registro por registro es computacionalmente costoso. Deshabilitar la DAL aumenta drásticamente la velocidad de migración, lo que permite cargar millones de filas en minutos. Sin embargo, esta velocidad tiene un alto precio: la seguridad.
Al omitir la capa de acceso a datos (mediante los modos de actualización de tabla), se elimina una medida de seguridad. El sistema no realiza comprobaciones de integridad en el momento de la inserción; acepta sin más los datos que se le proporcionan. El riesgo reside en cargar datos incorrectos que, aunque parezcan correctos en la tabla de la base de datos, generen un caos en cuanto un usuario intente interactuar con ellos.
Por ejemplo, podrías cargar un elemento, pero como la capa de acceso a datos (DAL) no se activó, algunos campos ocultos importantes quedan vacíos. Cuando un usuario hace clic en ese elemento en la interfaz de usuario, la pantalla se bloquea o muestra errores crípticos.
En mi opinión: omitir la capa de acceso a datos (DAL) no está prohibido, pero requiere extrema precaución. Debe reservarse para casos excepcionales y ser gestionado únicamente por consultores técnicos expertos que sepan con exactitud qué campos ocultos y tablas relacionadas deben completarse manualmente para mantener la coherencia del sistema. Para la mayoría de las migraciones, la ruta de la DAL, aunque más lenta, es la opción más segura.
La trampa del falso positivo
Una vez que decida usar la capa de acceso a datos (DAL), deberá prepararse para un fenómeno específico que suele causar pánico: el error de falso positivo. La DAL está diseñada para ser exhaustiva. Al importar una estructura compleja, como una orden de compra con 50 líneas, el sistema valida cada línea individualmente. Sin embargo, para cada línea que procesa, la DAL suele volver a validar la lógica del encabezado para garantizar la coherencia.
Imagina migrar una orden de compra donde el proveedor está marcado con un código de error. Cuando se carga la primera línea, la capa de acceso a datos (DAL) verifica el encabezado y registra un error: " El proveedor tiene problemas de calidad". Cuando se carga la segunda línea, vuelve a registrar el error. Al finalizar, verás un registro con 500 errores. En realidad, migraste correctamente 10 órdenes y el sistema simplemente te recordó la advertencia 500 veces.
Para gestionar esto, el equipo responsable de la migración debe filtrar los registros. Durante las pruebas, identifique los mensajes lógicos repetitivos y no bloqueantes y cree una lista segura de códigos que en realidad son solo ruido. Si no se explica este mecanismo a los usuarios de negocio con antelación, perderán la confianza en la integridad de los datos al ver un registro en rojo.
Rendimiento frente a integridad
Pasemos a otro nivel. No hablamos solo de la velocidad de inserción, sino de la gestión de la ventana de transición. Al manejar grandes volúmenes de datos, como la migración de miles de líneas de órdenes abiertas, el tiempo de procesamiento estimado puede superar fácilmente la ventana de fin de semana de 48 horas disponible.
La solución no consiste en eludir la capa de acceso a datos (DAL), sino en optimizar la estrategia de procesamiento por lotes mediante el procesamiento paralelo. En lugar de cargar un archivo masivo de forma secuencial, divida los datos en fragmentos lógicos más pequeños. Ejecute varios lotes simultáneamente en diferentes conjuntos de datos que no se solapen en las mismas tablas. Este enfoque permite aprovechar al máximo la capacidad de procesamiento del servidor e integrar la carga de trabajo masiva en el horario de fin de semana sin comprometer la seguridad ni la integridad de la DAL.
Conclusión
Ya tenemos las herramientas seleccionadas. Sabemos interpretar los registros sin entrar en pánico. El motor está listo, pero un motor de alto rendimiento es inútil si no se conoce el circuito.
En la siguiente parte, construiremos el mapa. Hablaremos del Plan de Migración de Transición, el documento maestro que dicta exactamente qué sucede, cuándo sucede y quién presiona el botón durante el fin de semana crítico de la puesta en marcha.
Escrito por Andrea Guaccio
26 de marzo de 2026