miravia-create-db
1. Descripción general
Según el pom.xml, el proyecto se describe como "Orders Miravia save to DB". Es un microservicio batch (runner) que sincroniza pedidos pendientes y cancelados del marketplace Miravia con la base de datos de logística.
2. Información técnica
| Campo | Valor |
|---|---|
artifactId | miravia-create-db |
groupId | com.hawkersco |
version | 1.0.25 |
| Java | 25 |
| Spring Boot | 4.0.6 |
| Tipo de artefacto | jar (ejecutable, Spring Boot batch/CLI) |
| Módulos | No aplica (proyecto de módulo único) |
3. Arquitectura y diseño
No es una API REST: es una aplicación Spring Boot CLI con 2 CommandLineRunner activos y 1 deshabilitado.
| Orden | Runner | Estado | Propósito |
|---|---|---|---|
| 1 | MiraviaCreateDBRunner | Activo | Obtiene pedidos pendientes de los últimos 5 días y los persiste si no existen ya |
| 2 | MiraviaCancelledRunner | Activo | Obtiene pedidos cancelados de los últimos 15 días y los marca como CANCELLED_BY_USER |
| 0 | MiraviaUpdateDBRunner | Deshabilitado (@Component comentado) | Herramienta de depuración para un pedido concreto (DEBUG_ORDER_NUMBER); si se activara, llamaría a System.exit(0) al terminar |
.config—MiraviaCreateDbConfig(wiring de beans),MiraviaClientProperties..utils—MiraviaCreateDbUtils(transformación de pedidos Miravia a entidades JPA).
flowchart TD
A["1. MiraviaCreateDBRunner<br/>pendientes, 5 días"] -->|token vía pi-generate-credentials| B[Miravia API]
A -->|"si no existe ya"| C[(logistics · Order/OrderMarketplace)]
D["2. MiraviaCancelledRunner<br/>cancelados, 15 días"] --> B
D -->|marca CANCELLED_BY_USER| C
Flujo: el runner 1 obtiene un token OAuth del servicio interno pi-generate-credentials (getToken("MIRAVIA")), pagina los pedidos pendientes de Miravia (/orders/get, 5 días, lotes de 50), y para cada uno no presente ya en OrderMarketplace obtiene el detalle (/order/get + /order/items/get) y persiste Customer → Order → OrderLine → Shipment → ShipmentLine → OrderShipment → OrderShipmentStatus → OrderMarketplace. El nombre interno del pedido usa el prefijo MIEU. El runner 2 obtiene los pedidos cancelados de los últimos 15 días y actualiza su estado si ya existen en BD. El identificador de fuente de Miravia es 45.
4. Dependencias principales
| Dependencia | Propósito |
|---|---|
spring-boot-starter | Núcleo de Spring Boot (sin web, es un runner CLI) |
com.miravia:miravia | SDK oficial de Miravia |
com.hawkersco:miravia-client | DTOs/cliente HTTP de Miravia |
com.hawkersco:pi-generate-credentials-client | Obtención de tokens OAuth por nombre de marketplace |
com.hawkersco:logistics-commons | Entidades JPA y servicios |
com.hawkersco:slack-client | Notificaciones de error |
com.hawkersco:pi-function-commons | Utilidades de fecha |
5. API / Endpoints
No aplica a este proyecto. Es un batch/runner sin capa REST.
6. Integraciones externas
| Sistema | Protocolo | Dirección | Detalle |
|---|---|---|---|
Miravia API (api.miravia.es) | HTTP REST (SDK oficial) | Entrante | Lectura de pedidos pendientes y cancelados |
Servicio interno pi-generate-credentials | HTTP | Entrante | Obtención de token OAuth de Miravia |
| Slack | HTTP (SlackClient) | Saliente | Notificaciones de error |
PostgreSQL (logistics) | JDBC | Entrante/Saliente | Lectura/escritura de pedidos |
7. Configuración
En producción (application-pro.properties) las credenciales llegan por variables de entorno inyectadas como Secret de Kubernetes; en local (application.properties) el repositorio contiene actualmente valores reales hardcodeados (ver alerta de seguridad).
| Clave | Descripción |
|---|---|
spring.datasource.* | Credenciales de la BD logistics |
miravia.client.url / .appkey / .appsecret | Credenciales de la API de Miravia |
credentials-client.api.host | URL del servicio interno pi-generate-credentials |
slack.client.url / .auth.token / .channel.id | Configuración de Slack |
⚠️ Alerta de seguridad
El fichero src/main/resources/application.properties (perfil local) contiene actualmente credenciales reales en texto plano: contraseña de la base de datos PostgreSQL logistics (la misma ya señalada como expuesta en múltiples proyectos de este ecosistema), y la clave/secreto de aplicación de Miravia (la misma ya señalada como expuesta en logistics-status-process, que comparte estas credenciales de Miravia). Ninguna se ha reproducido en este documento. Se recomienda rotar la contraseña de BD y las credenciales de Miravia, y sustituir los valores hardcodeados por credenciales de un entorno de desarrollo aislado.
8. Persistencia
Base de datos PostgreSQL logistics (spring.jpa.hibernate.ddl-auto=none). Entidades relevantes: Order, OrderLine, Customer, Shipment, ShipmentLine, OrderShipment, OrderShipmentStatus, OrderMarketplace. No hay Flyway/Liquibase en este repositorio.
9. Procesos programados y mensajería
No hay @Scheduled ni listeners de colas: la periodicidad la impone el CronJob de Kubernetes, que ejecuta el contenedor cada 5 minutos (schedule: "0/5 * * * *"). Se ejecutan en orden los 2 runners activos de la tabla de la sección 3.
10. Ejecución en local
Requisitos previos: JDK 25, Maven, acceso a la BD logistics y credenciales válidas de Miravia.
# Compilar
./mvnw clean install
# Compilar sin tests
./mvnw clean install -DskipTests
# Ejecutar el JAR
java -jar target/miravia-create-db-1.0.25.jar
# Ejecutar con perfil de producción
java -jar target/miravia-create-db-1.0.25.jar --spring.profiles.active=pro
No hay suite de tests significativa (jenkins/scripts/test.sh es un placeholder). Al ser un CommandLineRunner, no expone Actuator/health: la verificación se hace revisando el log de consola o el estado de los pedidos en la BD logistics.
11. Despliegue
- Imagen: construida con
jib-maven-plugin(baseeclipse-temurin:25-jre,containerizingMode=packaged), publicada eneurope-west3-docker.pkg.dev/pi-saldum/pi-repo/miravia-create-db:<tag>. - Orquestación: Kubernetes
CronJoben el clúster GKEpi-cluster-hw, namespacepi, ejecutándose cada 5 minutos. - CI/CD (Jenkins): pipeline real de 3 etapas —
Checkout→Build & Push→Deploy to GKE.
Job de Jenkins: https://jenkins-pi.hawkersco.net/job/miravia-create-db/
12. Manejo de errores y logging
No hay una estrategia de excepciones centralizada (no hay @ControllerAdvice, es un runner). Los errores por pedido se registran con Level.WARNING sin interrumpir el resto del lote. Logging mediante java.util.logging.Logger estándar (consola).
13. Notas y consideraciones
CLAUDE.mdverificado y consistente con el código: los 2 runners activos y su orden, el runner de depuración deshabilitado (MiraviaUpdateDBRunner,getOrder()=0pero sin@Component), el flujo de datos y el prefijoMIEUcoinciden con lo observado directamente en el código.- Ver alerta de seguridad en la sección 7 sobre credenciales reales expuestas en
application.properties, compartidas conlogistics-status-process.