order-fraudulent-process
1. Descripción general
Según el pom.xml, el proyecto se describe como "Order Fraudulent Process". Es un microservicio batch (runner) que localiza pedidos marcados como fraudulentos o duplicados en la base de datos de logística, genera un informe Excel (XLSX) por cada categoría, lo sube a Slack, y marca los pedidos como notificados.
2. Información técnica
| Campo | Valor |
|---|---|
artifactId | order-fraudulent-process |
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 que extienden una clase base común AbstractOrderProcessRunner (no mencionada en la documentación previa del proyecto, pero que centraliza la lógica compartida de consulta, generación de XLSX y subida a Slack).
| Orden | Runner | Propósito |
|---|---|---|
| 1 | OrderFraudulentProcessRunner | Pedidos FRAUDULENT_ORDER/POSSIBLE_FRAUDULENT_ORDER → XLSX → Slack → FRAUDULENT_ORDER_SEND |
| 2 | OrderDuplicatedProcessRunner | Pedidos ORDER_DUPLICATED → XLSX (con columna adicional de ID externo) → Slack → ORDER_DUPLICATED_SEND; llama a System.exit() al terminar |
.config—OrderFraudulentProcessConfig(wiring de beans).
flowchart TD
A["1. OrderFraudulentProcessRunner"] -->|consulta| B[(logistics · Order)]
B -->|genera XLSX| C[documents/]
C -->|getUploadUrl + completeUpload| D[Slack]
B -->|actualiza estado| E[FRAUDULENT_ORDER_SEND]
F["2. OrderDuplicatedProcessRunner"] -->|consulta| B
F -->|genera XLSX| C
F -->|actualiza estado| G[ORDER_DUPLICATED_SEND]
Ambos runners siguen el mismo patrón de dos pasos para subir el fichero a Slack: getUploadUrl (obtiene URL de subida) y completeUpload (publica en el canal slack.channel-atc.id). El fichero XLSX se genera con Apache POI en un directorio local documents/, con nombre {yyyyMMddHH}_orders_fraudulents.xlsx / {yyyyMMddHH}_orders_duplicated.xlsx, y se elimina tras la subida.
4. Dependencias principales
| Dependencia | Propósito |
|---|---|
spring-boot-starter | Núcleo de Spring Boot (sin web, es un runner CLI) |
org.apache.poi:poi-ooxml | Generación de los informes XLSX |
com.hawkersco:logistics-commons | OrderService, entidad Order |
com.hawkersco:slack-client | SlackClient, SlackUtils, subida de ficheros a Slack |
com.hawkersco:pi-function-commons | DateUtils, DirectoryUtils |
5. API / Endpoints
No aplica a este proyecto. Es un batch/runner sin capa REST.
6. Integraciones externas
| Sistema | Protocolo | Dirección | Detalle |
|---|---|---|---|
| Slack | HTTP (SlackClient, subida de ficheros en 2 pasos) | Saliente | Envío de informes XLSX de pedidos fraudulentos/duplicados al canal de ATC |
PostgreSQL (logistics) | JDBC | Entrante/Saliente | Lectura de pedidos por estado y actualización tras notificar |
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 |
slack.client.url / .auth.token / .channel-atc.id | Configuración de Slack (con un canal alternativo comentado) |
⚠️ 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 el token de bot de Slack. Ninguna se ha reproducido en este documento. Se recomienda rotar ambas credenciales 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). Entidad relevante: Order. 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 dos veces al día, a las 8:00 y a las 16:00 (schedule: "0 8,16 * * *"). Se ejecutan en orden los 2 runners 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 Slack.
# Compilar
mvn package
# Ejecutar tests
mvn test
# Ejecutar un test concreto
mvn test -Dtest=OrderFraudulentProcessApplicationTests
# Ejecutar la aplicación
java -jar target/order-fraudulent-process-1.0.25.jar
# Activar perfil de producción
java -jar target/order-fraudulent-process-1.0.25.jar -Dspring.profiles.active=pro
Al ser un CommandLineRunner, no expone Actuator/health: la verificación se hace revisando el log de consola o los ficheros recibidos en el canal de Slack.
11. Despliegue
- Imagen: construida con
jib-maven-plugin(baseeclipse-temurin:25-jre,containerizingMode=packaged), publicada eneurope-west3-docker.pkg.dev/pi-saldum/pi-repo/order-fraudulent-process:<tag>. - Orquestación: Kubernetes
CronJoben el clúster GKEpi-cluster-hw, namespacepi, ejecutándose dos veces al día. - CI/CD (Jenkins): pipeline real de 3 etapas —
Checkout→Build & Push→Deploy to GKE.
Job de Jenkins: https://jenkins-pi.hawkersco.net/job/order-fraudulent-process/
12. Manejo de errores y logging
No hay una estrategia de excepciones centralizada (no hay @ControllerAdvice, es un runner). La lógica común de generación/subida vive en AbstractOrderProcessRunner. Logging mediante java.util.logging.Logger/SLF4J según la clase.
13. Notas y consideraciones
AbstractOrderProcessRunnerno mencionada en elCLAUDE.mdexistente: los dos runners activos extienden esta clase base abstracta, que centraliza la consulta a BD, la generación del XLSX y la subida a Slack en dos pasos — elCLAUDE.mddescribe ambos runners como si cada uno implementara su propia lógica de forma independiente, cuando en realidad comparten una base común. No es una inconsistencia funcional, solo una omisión arquitectónica en la documentación previa.- El resto de la arquitectura descrita en
CLAUDE.md(los 2 runners y su orden, el flujo de subida a Slack en 2 pasos, el formato de nombre de fichero) coincide con el código real, verificado directamente enOrderFraudulentProcessRunneryOrderDuplicatedProcessRunner. - Ver alerta de seguridad en la sección 7 sobre credenciales reales expuestas en
application.properties.