Skip to main content

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

CampoValor
artifactIdorder-fraudulent-process
groupIdcom.hawkersco
version1.0.25
Java25
Spring Boot4.0.6
Tipo de artefactojar (ejecutable, Spring Boot batch/CLI)
MódulosNo 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).

OrdenRunnerPropósito
1OrderFraudulentProcessRunnerPedidos FRAUDULENT_ORDER/POSSIBLE_FRAUDULENT_ORDER → XLSX → Slack → FRAUDULENT_ORDER_SEND
2OrderDuplicatedProcessRunnerPedidos ORDER_DUPLICATED → XLSX (con columna adicional de ID externo) → Slack → ORDER_DUPLICATED_SEND; llama a System.exit() al terminar
  • .configOrderFraudulentProcessConfig (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

DependenciaPropósito
spring-boot-starterNúcleo de Spring Boot (sin web, es un runner CLI)
org.apache.poi:poi-ooxmlGeneración de los informes XLSX
com.hawkersco:logistics-commonsOrderService, entidad Order
com.hawkersco:slack-clientSlackClient, SlackUtils, subida de ficheros a Slack
com.hawkersco:pi-function-commonsDateUtils, DirectoryUtils

5. API / Endpoints

No aplica a este proyecto. Es un batch/runner sin capa REST.

6. Integraciones externas

SistemaProtocoloDirecciónDetalle
SlackHTTP (SlackClient, subida de ficheros en 2 pasos)SalienteEnvío de informes XLSX de pedidos fraudulentos/duplicados al canal de ATC
PostgreSQL (logistics)JDBCEntrante/SalienteLectura 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).

ClaveDescripción
spring.datasource.*Credenciales de la BD logistics
slack.client.url / .auth.token / .channel-atc.idConfiguració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 (base eclipse-temurin:25-jre, containerizingMode=packaged), publicada en europe-west3-docker.pkg.dev/pi-saldum/pi-repo/order-fraudulent-process:<tag>.
  • Orquestación: Kubernetes CronJob en el clúster GKE pi-cluster-hw, namespace pi, ejecutándose dos veces al día.
  • CI/CD (Jenkins): pipeline real de 3 etapas — CheckoutBuild & PushDeploy 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

  • AbstractOrderProcessRunner no mencionada en el CLAUDE.md existente: 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 — el CLAUDE.md describe 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 en OrderFraudulentProcessRunner y OrderDuplicatedProcessRunner.
  • Ver alerta de seguridad en la sección 7 sobre credenciales reales expuestas en application.properties.