Estado General
Bugs y Vulnerabilidades
Cobertura y Mantenibilidad
Este repositorio forma parte del Trabajo de Fin de Grado (TFG) de Manuel García Baldo en la Universidad de
Oviedo.
Su objetivo es mantener actualizados los datos de estaciones de servicio y precios de combustibles en España,
obtenidos desde la API de Hidrocarburos del MITMA, para que estén disponibles y actualizados en la aplicación
Android principal del proyecto.
Este módulo se ejecuta como un cron programado cada 30 minutos, que descarga, procesa y sincroniza la información
con una base de datos Supabase (PostgreSQL).
De esta forma, la aplicación Android puede consultar los datos más recientes sin depender directamente de la API
externa, mejorando la disponibilidad, velocidad y fiabilidad.
El proyecto incluye:
- Sistema de cron: Planificador automático que ejecuta las actualizaciones cada 30 minutos como un job.
- Módulo HTTP: Gestiona las peticiones y la recepción de datos JSON.
- Parsers JSON -> DTO -> Entidades: Transforman los datos obtenidos desde la API MITMA en entidades Java.
- Persistencia: Sincronización eficiente con la base de datos Supabase usando operaciones por lotes.
- Servicio de Loggers: Toda la ejecución queda registrada en los logs correspondientes.
- Servicio de correo: Dispone de un servicio de correo para enviar los resultados de la ejeución e informar de cualquier posible error durante su ejecución.
Antes de ejecutar el cron, es imprescindible configurar correctamente las variables de entorno relacionadas con la conexión a la base de datos y, de manera opcional, el servicio de correo.
| Variable | Descripción |
|---|---|
DB_URL |
Dirección del host de la base de datos |
DB_USER |
Usuario con permisos de lectura y escritura |
DB_PASS |
Contraseña correspondiente |
⚠️ Importante:
Si estas variables no se definen correctamente, los servicios no podrán establecer conexión con la base de datos y no se iniciará el proceso de actualización.
Para habilitar el envío de notificaciones por correo (alertas de errores o avisos importantes), se deben definir estas variables de entorno:
| Variable | Descripción |
|---|---|
ENV_MAIL_EMAIL |
Dirección de correo desde la que se enviarán los mensajes |
ENV_MAIL_PASSWORD |
Contraseña (mucho mejor Token de acceso) de la cuenta de correo |
ENV_MAIL_TO_EMAIL |
Dirección o lista de correos destinatarios de las notificaciones |
⚠️ Recomendación de seguridad:
- Nunca incluir la contraseña (
ENV_MAIL_PASSWORD) directamente en el repositorio.- Defínela como variable de entorno en el servidor:
El cron se activa automáticamente cada 30 minutos mediante un planificador interno basado en
ScheduledExecutorService mediante la libería de Quartz. La programación es configurable desde las properties del
proyecto.
Realiza peticiones HTTP a la API de Hidrocarburos del MITMA, obteniendo un JSON con la información de todas las estaciones de servicio y precios actualizados.
Los datos recibidos se transforman en entidades (EESS, Municipio, Provincia, etc.) mediante parsers dedicados.
Las entidades se sincronizan con la base de datos Supabase usando operaciones por lotes (batch) o procesamiento concurrente con hilos para optimizar el rendimiento.
Cada ejecución genera logs detallados con:
- Número de estaciones procesadas.
- Errores detectados.
- Tiempo total de ejecución.
- etc
Durante el desarrollo se detectó un problema crítico con la resolución de direcciones IP:
- El entorno local del cron usaba IPv4.
- Supabase, en su infraestructura actual, solo acepta tráfico entrante por IPv6 en su versión Online, con la que se empezó a trabajar.
Esto generaba errores de conexión del tipo Connection refused o timeout, incluso con credenciales correctas.
La causa estaba en la resolución DNS: el dominio de Supabase devolvía registros AAAA (IPv6), mientras el entorno
local intentaba conectarse por IPv4.
- Ejecutar el cron en entornos con soporte IPv4 nativo. Con la BD Supabase en un modo especial para poder aceptar conexiones IPV4.
- En entornos sin IPv6, usar contenedores o máquinas dual-stack (IPv4/IPv6) para permitir la conexión.
*En el sistema final la BD será local, en un servior propio por lo que no habrá este problema.
El cron actúa como motor de actualización de los datos que la aplicación Android del TFG utiliza.
La app permite a los usuarios:
- Consultar precios actualizados de combustibles (Gasolina 95, Gasóleo A, GLP, etc.).
- Localizar estaciones cercanas con mapas interactivos.
- Ver horarios, direcciones y coordenadas.
- Aplicar filtros por tipo de combustible o ubicación.
El cron garantiza que estos datos estén siempre actualizados en Supabase, sin depender directamente de la API MITMA (más lenta y menos estable para uso en producción).
- ✅ Código operativo y funcional.
- ⚙️ Persistencia estable y validada.
- 🔄 Sistema de cron en producción cada 30 minutos.
- 🧩 Pendiente de optimizaciones menores y mejora del sistema de logs.
El despliegue de los servicios cron y backend en el servidor se realiza mediante un sistema de auto-actualización
automática.
Este sistema se encarga de:
- Comprobar periódicamente si hay nuevas releases publicadas en GitHub.
- Descargar y reemplazar los JAR correspondientes.
- Reiniciar los servicios de forma segura.
- Garantizar arranque automático tras reinicios del servidor.
Este enfoque permite mantener los servicios actualizados y seguros sin exponer puertos ni la IP del servidor, evitando la necesidad de CI/CD remoto que conecte directamente con la infraestructura.
Para ver todos los detalles de configuración, scripts, servicios systemd y timers, consulta el repositorio completo:
Server-Cron-Backend-AutoUpdate
El cron dispone de archivos de propiedades que permiten ajustar su comportamiento y adaptarlo a diferentes entornos o bases de datos.
-
application.properties
Contiene la configuración general del cron, incluyendo conexión a la base de datos, parámetros del scheduler, logging y correo. -
queries.properties
Contiene las consultas SQL que se ejecutan para sincronizar los datos con la base de datos.⚠️ Si cambias la estructura de la BD o deseas personalizar las consultas, aquí es donde se deben adaptar. -
Endpoints de la API
Los endpoints utilizados para obtener los datos desde la API del MITMA están definidos dentro del proyecto y pueden modificarse si fuese necesario cambiar la fuente de datos.
- Si existe la carpeta
/configdentro del directorio donde se encuentra el cron, el servicio cargará los archivos de ahí. - Si no existe, el cron usará los valores por defecto incluidos en el JAR, debiendo, aún así, introducir las variables de entorno.
- Esto permite:
- Mantener configuraciones personalizadas sin modificar el JAR original.
- Adaptar queries, endpoints o propiedades generales de forma sencilla según el entorno.
🔹 Recomendación:
Puedes crear tus propias versiones deapplication.properties,queries.propertiesyendpoints.propertiesdentro de/configpara ajustar el cron a entornos específicos, bases de datos distintas o cambios en la API.
Manuel García Baldo
Universidad de Oviedo
Trabajo de Fin de Grado - Ingeniería Informática (2025)
Este proyecto se distribuye bajo licencia MIT.
Puede utilizarse, modificarse o redistribuirse libremente, siempre que se cite la fuente original.