Mapa general del ecosistema

Objetivo

Explicar cómo se conectan entre sí los sistemas del ecosistema Sy Energy: quién produce cada dato, por dónde viaja y quién lo consume.

Sirve para ubicar un problema antes de abrir un repositorio: si falta un dato en sy-energy, este mapa dice qué eslabón anterior hay que revisar.

Audiencia

Soporte, infraestructura y desarrollo interno.

Alcance

Flujos de datos entre sistemas. No describe el detalle interno de cada sistema; para eso está la sección de cada proyecto.

Estado documental

• Estado: Borrador
• Última actualización: 2026-08-02
• Owner: Pendiente
• SME requerido: desarrollo interno
• Fuente resumida: configuración de colas, comandos y clientes de integración de cada repositorio.

Resumen operativo

El ecosistema tiene un sistema central, sy-energy, y cuatro cadenas de datos que lo alimentan. Todas las cadenas siguen el mismo patrón: un bot obtiene el dato de una fuente externa, lo deja en S3 o en una cola SQS, y un servicio PHP lo consume y lo persiste.

Cadena	Fuente externa	Termina en
Documentos y facturación CENACE	API de CENACE y portal SIM	sy-energy
Precios del mercado (MDA / MTR)	Portal público de CENACE	mem-api y sy-energy
Tarifas CFE	Portal público de CFE	cfe-rates-microservice y sy-energy
Demanda de alta tensión	SQL Server de Bravos	sy-energy

Desarrollo

Cadena 1 — Documentos y facturación CENACE

CENACE (API / portal SIM)
        │
        ├── ecd:sync ──────────────► sy-energy  (Estados de Cuenta Diarios)
        │
        └── memsim-cenace-scrapers (bots Lambda)
                 ▲ SQS            │ SQS / API
                 │                ▼
              sy-energy  ◄────────┘

sy-energy dispara los bots del SIM con bot:queue --slug=<bot>, que encola una petición en SQS. Cada bot es una Lambda que entra al portal SIM con las credenciales del participante (.cer, .key, usuario y contraseña), ejecuta su tarea y devuelve el resultado a sy-energy.

Bots involucrados y para qué sirven:

Bot	Rol en la cadena
rea	Descarga la REA para desplegarla en sy-energy.
cenace-notifications	Retira la notificación inicial del SIM que bloquea a los demás bots.
cenace-documents	Descarga facturas emitidas por CENACE para generar complementos de pago.
upload	Sube al SIM los documentos que sy-energy deja en S3 y regresa la respuesta del portal.
status	Verifica el estatus de las facturas cargadas al SIM.
bank-one / bank-two / bank-three	Etapas de referencia bancaria: validar FUF y totales, crear el FOP y devolverlo a sy-energy.

Orden importante

cenace-notifications debe correr antes que los demás bots. Si queda una notificación pendiente en el SIM, el resto de los bots no logra navegar el portal.

Cadena 2 — Precios del Mercado Eléctrico Mayorista

Portal CENACE (MDA / MTR)
        │  Selenium
        ▼
mem-sync-prices (Lambda) ──► S3 (CSV crudos)
                                  │ evento S3 / SQS
                                  ▼
                        mem-parse-csv-prices (Lambda)
                                  │ SQS (un mensaje por nodo)
                                  ▼
                              mem-api ──► BD MEM ──► mem-frontend
                                              │
                                              └──► sy-energy (sync:prices)

mem-auth-service no participa en el flujo de datos: autentica a los usuarios que consultan mem-frontend.

sy-energy consume información de nodos y precios del MEM para sus cálculos de pass-through (produce:prices, consume:prices, sync:prices).

Cadena 3 — Tarifas CFE

cfe-rates-microservice ──SQS──► cfe-rates-scraper (Lambda + Selenium)
           ▲                              │
           └────────SQS (respuesta)◄──────┘
           │
           └──► sy-energy (tarifas CFE por centro de carga)

El microservicio pide tarifas con app:ask-bot-cfe-rates, publicando un mensaje por región en la cola de solicitudes. El scraper entra al portal de CFE, extrae la tabla de cargos para la tarifa pedida (dit, dist, gdmth, pdbt) y publica el resultado en la cola de respuesta, que el microservicio consume con un worker dedicado.

Además, subir un CSV de tarifas al microservicio dispara trabajos de almacenamiento por división y tipo en una segunda cola.

Cadena 4 — Demanda de alta tensión (CFE TX)

SQL Server de Bravos  ──►  cfetx-microservice  ──SQS──►  sy-energy

cfetx-microservice consulta mediciones cada 5 minutos, las agrupa por medidor y las publica en SQS. En sy-energy, un worker dedicado por participante las consume.

Acceso restringido

La base de datos de Bravos está protegida por autorización de IP. Las consultas solo funcionan desde servidores previamente autorizados; no se pueden reproducir desde un entorno local cualquiera.

Cadena 5 — Demanda de centros de carga

MediMEM ──► demand-sync-service ──cola interna──► sy-energy

sy-energy la dispara diariamente con service:demand-sync.

Dependencias transversales

Componente	Rol
AWS SQS	Transporte entre servicios PHP y bots Lambda. Se usan colas FIFO por participante para lo que requiere orden.
AWS S3	Archivos crudos: CSV de precios, documentos a cargar al SIM, respaldos de base de datos.
AWS Secrets Manager	Credenciales de base de datos usadas por la rutina de respaldo.
Supervisor	Mantiene vivos los workers de cola de cada servicio en el servidor.
Cron	Ejecuta el scheduler de Laravel cada minuto y las rutinas de respaldo.

Las dos últimas se gestionan desde server-configs.

Multi-participante

sy-energy no corre como una sola instancia: se despliega una instancia por participante del mercado, cada una con su base de datos y su juego de colas.

Los nombres de cola siguen un patrón por código de participante, por ejemplo EcdSync-prod-CXXX.fifo o CenaceBalance-CXXX-prod.fifo, donde CXXX es el código del participante. Al diagnosticar un incidente, verificar siempre de qué participante es la instancia y la cola.

Riesgos y gaps

• El detalle de qué colas específicas conectan sy-energy con cada bot del SIM está pendiente de confirmar contra la configuración productiva.
• Falta confirmar si sy-energy consume precios directamente de la base de datos del MEM o vía API de mem-api.
• No está documentado el manejo de reintentos y colas DLQ entre cadenas.

Próxima revisión

Al terminar la documentación de los sistemas satélite.