Un blob binario con 30 años de reglas de negocio dentro
Un operador logístico europeo nos entregó 612 archivos .fmb el año pasado. Tamaño total: 184 MB. Dentro de esos archivos había 28.400 triggers, 9.100 LOVs y aproximadamente 1,2 millones de líneas de PL/SQL incrustado — nada almacenado como texto, todo serializado en un formato que Oracle nunca ha publicado formalmente. La empresa había perdido el historial de control de versiones en 2011. Los archivos .fmb eran la fuente de verdad.
Ese escenario es la norma, no la excepción. Hemos analizado 2.400 archivos .fmb en proyectos de migración, y los contenidos son notablemente consistentes.
Qué es realmente un archivo .fmb
Un .fmb es una serialización binaria propietaria de un módulo de Oracle Forms. No es un volcado de base de datos ni un AST simple. Es un árbol de objetos — bloques, ítems, triggers, canvas, ventanas, LOVs, grupos de registros, unidades de programa — cada uno etiquetado con un código de tipo y una carga útil de longitud variable. El formato ha cambiado sutilmente entre Forms 4.5, 6i, 10g, 11g y 12c, pero la estructura central es estable.
Los archivos complementarios cuentan una historia similar. Un .fmx es el binario compilado de runtime. Un .fmt es una exportación de texto que Oracle proporciona, pero tiene pérdidas — las coordenadas de diseño, los metadatos de fuentes y algunos valores predeterminados de propiedades se eliminan o reescriben. Las migraciones que dependen solo de .fmt pierden entre el 4% y el 9% del comportamiento original.
El árbol de objetos, en números
En nuestra muestra, un .fmb promedio contiene:
- 14 bloques de datos
- 96 ítems
- 47 triggers
- 18 LOVs y grupos de registros
- 6 canvas
- 2.100 líneas de PL/SQL incrustado
La distribución está fuertemente sesgada. El 10% superior de los archivos contiene más de la mitad de la lógica total. Hemos visto archivos .fmb individuales con 480 triggers y 14.000 líneas de PL/SQL — generalmente la pantalla de asientos del libro mayor o la pantalla principal de entrada de pedidos.
Dónde vive realmente la lógica de negocio
Los desarrolladores de Forms tenían cuatro lugares para poner código: triggers a nivel de formulario, triggers a nivel de bloque, triggers a nivel de ítem y unidades de programa adjuntas al módulo. En la práctica, la mayor parte de la lógica termina a nivel de ítem, dentro de WHEN-VALIDATE-ITEM, POST-QUERY y KEY-NEXT-ITEM.
-- Carga típica de WHEN-VALIDATE-ITEM dentro de un .fmb
IF :ORDERS.TOTAL_AMOUNT > 50000 AND :ORDERS.APPROVAL_ID IS NULL THEN
MESSAGE('Orders over 50000 require approval');
RAISE FORM_TRIGGER_FAILURE;
END IF;
Ese fragmento está almacenado dentro del binario como una cadena con prefijo de longitud adjunta a un nodo de ítem. Encontrarlo requiere recorrer el árbol de objetos. Multiplique por 47 triggers por archivo y 612 archivos y la extracción se convierte en un problema de parser, no un problema de grep.
Las propiedades que nadie documenta
Más allá del código, cada ítem tiene entre 80 y 140 propiedades: valores predeterminados, máscaras de formato, condiciones de consulta, pistas de navegación, vinculaciones de columna de base de datos y coordenadas de diseño. Aproximadamente el 30% de estas propiedades codifican comportamiento que los desarrolladores asumían como “así es como funciona Forms” — LOVs en cascada desencadenados por herencia de máscara de formato, por ejemplo, o comportamiento de commit implícito vinculado a la propiedad Database Block.
Cuando reconstruimos una pantalla en TypeScript, estas propiedades implícitas representan la mayoría de las sorpresas. El código visible de los triggers es la parte fácil.
Análisis sin el runtime de Oracle
La mayoría de las herramientas de migración llaman a Forms Builder o a la API de Forms para leer archivos .fmb. Ese enfoque funciona, pero requiere una instalación licenciada de Oracle y limita el rendimiento de extracción a aproximadamente 40 archivos por hora. Construimos un parser binario directo que lee el árbol de objetos sin el runtime. Procesa los mismos 612 archivos en menos de 90 segundos y produce un descriptor JSON para cada módulo.
El descriptor se convierte en la entrada para todo lo posterior: el generador TypeScript, el inventario de controles para auditoría y la herramienta de comparación visual que compara las pantallas antiguas y nuevas lado a lado.
La conclusión
Un archivo .fmb no es una caja negra. Es un árbol bien estructurado envuelto en un envoltorio binario no documentado. Una vez que el envoltorio se abre, 30 años de reglas de negocio se vuelven buscables, comparables y migrables — en ese orden. Cada migración que hemos entregado comenzó con un análisis completo de los archivos fuente, porque cada atajo en esa etapa se manifiesta como un defecto seis meses después.