FlightSort
La parte más delicada del despliegue

Cada aeropuerto habla su propio idioma. Así lo traducimos, sin adivinar.

Ningún sistema de handling usa los mismos códigos que otro. Antes de que FlightSort muestre una sola ficha de vuelo, un proceso guiado traduce la nomenclatura real de su base de datos al modelo de FlightSort — y lo verifica contra datos reales antes de dejarlo pasar a producción.

01

El problema: no hay dos aeropuertos iguales

Los códigos de estado de un vuelo — facturación abierta, embarcando, puerta cerrada, despegado — no son un estándar. Son la nomenclatura interna de cada sistema de handling, y cambia de una instalación a otra.

Ejemplo ilustrativo — nomenclatura real de una instalación, mapeada al modelo de FlightSort
BRDEmbarcando
LSCÚltima llamada
CLSPuerta cerrada
AIR, RDY, FLY, OBK, FIRDespegado
CAN, SUS, DIVCancelado

Nótese el código RDY del ejemplo: en el lenguaje operativo suena a "listo para salir, aún en tierra" — pero en esta instalación concreta se agrupa junto al resto de códigos de despegue. Adivinarlo sin verificar contra datos reales es exactamente el tipo de error que el proceso de mapeo está diseñado para evitar.

02

El proceso de mapeo, paso a paso

Un asistente guiado recorre la instalación de principio a fin. Nada se asume: cada paso se puede probar contra la base de datos real antes de continuar.

Paso 1–2

Datos del aeropuerto y conexión

Se identifica el motor de base de datos y se establece una conexión de solo lectura — el mismo principio que en el resto de la integración: FlightSort nunca escribe en los sistemas del aeropuerto.

Paso 3

Mapeo de tablas y columnas

Se indica dónde vive cada dato — vuelos, contadores de facturación, códigos de estado — dentro del esquema real de esa instalación. El asistente sugiere automáticamente qué capacidades de la interfaz tienen sentido activar según lo que encuentra.

Mínimos para operarIdentidad del vuelo (aerolínea, número, STD) · Estado del vuelo · Mensajes BSM (equipaje facturado) · Equipajes en camino
OpcionalespBSM (equipaje ya embarcado) · Mostradores ciegos · ETD · Equipaje especial
Paso 4

Generación e instalación de los procedimientos

A partir del mapeo, se generan e instalan los procedimientos que alimentan a FlightSort — con permisos mínimos de solo lectura, nunca de escritura.

Paso 5

Verificación de columnas

Se comprueba que cada procedimiento instalado devuelve exactamente la forma de datos que FlightSort espera, antes de dar el paso siguiente.

Paso 6

Códigos reales y comprobación final

El asistente consulta la base de datos real y muestra qué códigos de estado existen de verdad en esa instalación — no una lista genérica. Ahí es donde se resuelve el ejemplo del RDY: con datos reales delante, no con una tabla de equivalencias supuesta.

Bloqueo de seguridad — ver sección siguiente
03

El punto que no se puede fallar

De todos los estados de un vuelo, uno solo dispara una alarma real en FlightSort: Despegado. Todos los demás son trazabilidad. Por eso es el único que el asistente no deja pasar sin verificar.

Validación bloqueante — paso 6

Si el grupo "Despegado" queda vacío, o sus códigos no aparecen en ningún vuelo real, la instalación no continúa.

No basta con rellenar el campo — el asistente contrasta la configuración contra códigos observados de verdad en la base de datos de esa instalación. Una lista con códigos que simplemente no existen ahí se trata exactamente igual que una lista vacía: la instalación se detiene hasta corregirlo.

Es una decisión de diseño deliberada, coherente con cómo funciona el resto del producto: si el único estado que importa para la alarma no está bien mapeado, ninguna otra pantalla, color o notificación de FlightSort puede compensarlo. Se corrige aquí, antes de producción — no después, con un vuelo real de por medio.
04

Motores de base de datos

El asistente de mapeo funciona hoy sobre Oracle, con el flujo completo descrito arriba. El resto de motores está en el roadmap.

Motor
Estado
Alcance
🔶 Oracle
Disponible
Flujo completo: mapeo, generación e instalación de procedimientos, descubrimiento de códigos reales y validación bloqueante del estado crítico.
🔷 SQL Server
Roadmap
En desarrollo — el objetivo es ofrecer el mismo nivel de guiado y verificación que hoy tiene Oracle, no una versión reducida.

¿Cómo se vería el mapeo de su aeropuerto?

Con acceso de solo lectura a su base de datos, podemos mostrarle en una sesión qué códigos reales tiene su instalación y cómo se traducirían.

Solicitar una demo