Bradery Client

1. Descripción general

bradery-client (description del pom.xml: bradery-client, sin texto descriptivo adicional) es una librería mínima que actúa como modelo de datos compartido dentro del ecosistema de microservicios de Hawkers para la integración con el marketplace The Bradery.

El proyecto no define controladores REST, repositorios ni servicios: se limita a un conjunto de POJOs (pojos/) que representan los pedidos recibidos de The Bradery y la información de tracking/envío asociada. Su propósito es evitar que cada microservicio que procesa pedidos de The Bradery (recepción de pedidos, envío de confirmaciones de tracking) tenga que redefinir estas estructuras de datos, garantizando un modelo común y consistente entre los distintos consumidores.

Aunque incluye una clase @SpringBootApplication con main() (BraderyClientApplication), no hay evidencia en el código de un propósito de servicio desplegable real (sin controladores, listeners ni lógica de negocio); su función principal dentro del ecosistema es la de librería de modelo de datos versionada vía Maven.

---

2. Información técnica

Propiedad	Valor
artifactId	bradery-client
groupId	com.hawkersco
version	1.0.25-SNAPSHOT
Java	25
Spring Boot	4.0.6
Tipo de artefacto	JAR ejecutable (incluye clase @SpringBootApplication con main, aunque su uso real dentro del ecosistema es como librería de modelo de datos)
Módulos	Proyecto mono-módulo
Repositorio Maven	Google Artifact Registry — europe-west3-maven.pkg.dev/pi-saldum/pi-repo-maven

---

3. Arquitectura y diseño

Paquetes principales

com.hawkersco.braderyclient
├── pojos/                          # POJOs de modelo de datos (Lombok, sin JPA)
│   ├── TheBraderyOrder.java         # Pedido completo + clase anidada TheBraderyOrderLine
│   └── TheBraderyInfo.java          # Información de tracking/envío
└── BraderyClientApplication.java   # Clase @SpringBootApplication (arranque mínimo)

No hay capas de controller, service, repository, client ni config: el proyecto está intencionadamente acotado a los modelos de datos.

Modelo de datos

• TheBraderyOrder: representa un pedido completo de The Bradery. Contiene orderNumber y una lista de TheBraderyOrderLine (clase estática anidada), cada una con los datos de la línea de pedido (SKU, EAN, código de barras, talla, precio, cantidad, descripción) y los datos completos del cliente (nombre, apellido, direcciones, código postal, ciudad, país, teléfono, email) — es decir, los datos de cliente se repiten por línea en lugar de estar a nivel de cabecera de pedido.
• TheBraderyInfo: representa la información de tracking de un envío (número de pedido, número de tracking, SKU, cantidad, transportista, URL de tracking).

Todas las clases usan Lombok (@NoArgsConstructor, @AllArgsConstructor, @Getter, @Setter, @ToString), no tienen anotaciones JPA (no son entidades) ni anotaciones de validación JSR-303. Los precios usan BigDecimal (price), no tipos primitivos.

No aplica diagrama de flujo: no existe lógica de procesamiento ni orquestación en este proyecto, solo definición de estructuras de datos.

---

4. Dependencias principales

Dependencia	Propósito
org.springframework.boot:spring-boot-starter	Núcleo de Spring Boot (necesario para la clase @SpringBootApplication).
org.projectlombok:lombok (1.18.42)	Generación de getters/setters/constructores/toString en los POJOs.
org.springframework.boot:spring-boot-starter-test (test)	Soporte de test de Spring Boot.

Extensión de build relevante: com.google.cloud.artifactregistry:artifactregistry-maven-wagon (2.2.1) — necesaria para publicar/resolver contra el Google Artifact Registry corporativo.

---

5. API / Endpoints

No aplica. El proyecto no define ningún @RestController ni expone endpoints propios.

---

6. Integraciones externas

Sistema	Protocolo / Mecanismo	Dirección del flujo
The Bradery (marketplace)	No implementado en este proyecto — solo modela la estructura de datos (TheBraderyOrder, TheBraderyInfo) que otros microservicios usan para (de)serializar pedidos y tracking. Pendiente de verificar el protocolo real (SFTP/API/webhook) al residir en el microservicio consumidor.	N/A (solo modelo de datos).
Microservicios Hawkers consumidores	Dependencia Maven (com.hawkersco:bradery-client)	Saliente (esta librería es consumida como dependencia de código, no se comunica en runtime con ellos).

---

7. Configuración

No aplica. El proyecto no incluye application.properties ni application.yml propios, ni variables de entorno definidas.

---

8. Persistencia

No aplica. Los POJOs no tienen anotaciones JPA (@Entity) ni están asociados a tablas de base de datos; son estructuras de datos puras (DTOs) para intercambio entre servicios.

---

9. Procesos programados y mensajería

No aplica. No se han encontrado @Scheduled, @KafkaListener, @RabbitListener ni runners batch en el proyecto.

---

10. Ejecución en local

Requisitos previos: JDK 25, Maven (o el wrapper ./mvnw incluido).

Build e instalación en repositorio Maven local (omitiendo tests, como en CI):

./mvnw -B -DskipTests clean install

Build con tests:

./mvnw clean install

Ejecutar un test concreto:

./mvnw test -Dtest=ClassName#methodName

Ejecutar el JAR (arranque mínimo, sin controladores ni lógica):

java -jar target/bradery-client-1.0.25.jar

No aplica verificación vía Actuator/health: el proyecto no expone endpoints de salud (no se ha encontrado spring-boot-starter-actuator entre las dependencias). Los microservicios consumidores deben declarar com.hawkersco:bradery-client:<version> en su pom.xml para usar sus POJOs.

---

11. Despliegue

El despliegue consiste en la publicación del artefacto Maven al Google Artifact Registry corporativo.

Pipeline Jenkins (Jenkinsfile, agente any, JDK25 + Maven3):

1. Checkout del repositorio.
2. Publish to Artifact Registry: mvn deploy -DskipTests, publicando en artifactregistry://europe-west3-maven.pkg.dev/pi-saldum/pi-repo-maven (definido en distributionManagement del pom.xml).

Según CLAUDE.md, el pipeline CI ejecuta sudo mvn -B -DskipTests clean install vía jenkins/scripts/mvn.sh y archiva target/*.jar — este script no se ha localizado físicamente en el repositorio explorado (Pendiente de verificar su ubicación exacta).

Job de Jenkins:

https://jenkins-pi.hawkersco.net/job/bradery-client/

---

12. Manejo de errores y logging

No aplica. El proyecto no contiene lógica de negocio, por lo que no define excepciones propias, códigos de error ni configuración de logging (no hay logback.xml/log4j2.xml).

---

13. Notas y consideraciones

• Datos de cliente duplicados por línea de pedido: TheBraderyOrderLine incluye los datos completos del cliente (nombre, dirección, contacto) en cada línea en lugar de modelarlos una sola vez a nivel de TheBraderyOrder. Esto es coherente con el formato de exportación plano típico de integraciones de marketplace (una fila = una línea de pedido con todos los campos), pero implica redundancia de datos si se procesa como estructura anidada en memoria.
• Nombres de campo en francés: varios campos de TheBraderyOrderLine están en francés (commande, quantite, taille, prenom, nom, adresse1, adresse2, ville, pays, telephone, mail), reflejando previsiblemente el formato de payload/fichero original de The Bradery (marketplace francés). Mantener esta nomenclatura al añadir campos nuevos si siguen mapeando directamente al formato de origen.
• qty como String en TheBraderyInfo: a diferencia de TheBraderyOrderLine.quantite (tipo int), la cantidad en la información de tracking se modela como String, lo que puede requerir conversión/parsing explícito en el código consumidor y es una inconsistencia de tipado entre ambas clases.
• Sin anotaciones de validación: ningún campo usa validación JSR-303 (@NotNull, @NotBlank, etc.), por lo que la validación de los datos recibidos de The Bradery es responsabilidad completa del microservicio consumidor.
• Clase de aplicación sin uso aparente: BraderyClientApplication levanta un contexto Spring Boot completo sin controladores, listeners ni beans de negocio; su propósito real (facilitar tests de integración, plantilla heredada de otros proyectos, etc.) no es evidente desde el código (Pendiente de verificar).