Saltar a contenido

RF02 Subida de backups de cajas (físicos y transacciones) a GCP mediante ESB-Karaf

Entendimiento

Servicio que suba mediante ESB-Karaf los ficheros de backup de cajas (Transacciones y tickets físicos) desde los sistemas on-premise Alcampo a un Bucket de GCP.

Situación Actual

La detección de pérdida de datos es manual: un operador de Soporte revisa un informe de Looker Studio comparando el legacy (FAT) contra Silver en BigQuery. Para que estos datos históricos sean accesibles, un proceso externo en Spring Boot carga los backups de las cajas directamente en UAT (Pruebas), utilizándolo como repositorio de consulta de backups para Producción — un uso indebido del entorno.

Una vez identificados los faltantes, la recuperación pasa por scripts ad-hoc heredados que realizan una inyección cruzada de datos entre entornos. Se usa la consulta ticket_to_reprocess_from_uat_pos.sql para leer el contenido JSON crudo (raw) desde la BBDD de UAT y publicarlo "a la fuerza" en el tópico de Pub/Sub de Producción. Esto obliga al pipeline a ingerir el ticket como si fuera un evento nuevo, dependiendo totalmente de que UAT tenga los datos disponibles.

Solución Técnica

Simplificamos la labor de Backup Transacciones PoS radicalmente: actúa como una tubería de transporte agnóstica ("dumb pipe"). Se conecta al sFTP PoS de la caja, coge los ficheros ZIP en crudo (tanto las transacciones ADX_IDT4 como los tickets físicos ALC_TDGT) y los mueve a Google Cloud Storage. No inspecciona el contenido ni invoca bin2raw; Backup Transacciones PoS no abre el paquete ni intenta averiguar los IDs de los tickets. Solo garantiza que el binario llegue íntegro a la nube.

Para evitar el desorden en el destino, Backup Transacciones PoS aplica el patrón de "Bucket Canónico por Interfaz". Deposita los archivos siguiendo una jerarquía de directorios estricta basada en tienda y fecha:

gs://{BUCKET}/{STORE}/{YYYYMMDD}/

Al organizar los ficheros por carpetas antes de que nadie los procese, dejamos el terreno preparado para que el reconciliador (transaction_pos_backup_reconciler) vaya "a tiro hecho" a buscar los datos de un día concreto sin escanear el bucket entero.

Fuera de Alcance

Exclusiones explícitas

Ejecución de bin2raw (Decodificación) — Backup Transacciones PoS no ejecutará ningún proceso de lógica de negocio ni invocará librerías Java externas para interpretar el contenido de los archivos. No transformará binarios a JSON ni extraerá metadatos del interior del ZIP.

Inspección de Contenido (Deep Inspection) — La ruta no abrirá los archivos comprimidos (ADX_IDT4.ZIP o ALC_TDGT.ZIP). No validará si el ZIP está corrupto internamente ni comprobará si dentro hay ficheros de texto o binarios; solo verifica la integridad de la transferencia del fichero como bloque.

Extracción de Identificadores de Negocio — Backup Transacciones PoS ignora qué ticket_id o qué fecha real de venta contiene el archivo. No renombrará los ficheros basándose en su contenido transaccional. La clasificación en carpetas se basa exclusivamente en metadatos externos (fecha de recogida/modificación o estructura de carpetas del sFTP PoS), no en la fecha "fiscal" del ticket.

Registro en Tabla de Control (BigQuery) — Backup Transacciones PoS no tiene conexión con BigQuery. No insertará registros en staging indicando "Backup Recibido". La actualización del estado del inventario es responsabilidad exclusiva de la transaction_pos_backup_reconciler (GCF_1) cuando procese el bucket posteriormente.

Arquitectura

sequenceDiagram
    participant Caja as sFTP PoS
    participant Karaf as ESB-Karaf
    participant GCS as Bucket GCS

    Caja->>Karaf: ADX_IDT4.zip + ALC_TDGT.zip
    Note over Karaf: Sin inspección.<br/>Transporte puro.
    Karaf->>GCS: gs://{BUCKET}/{STORE}/{YYYYMMDD}/
    Note over GCS: GCF_1 procesará después