time-server-test-adapter

Test harness mínimo para probar el adapter kumare-adapter-spring-visma-time vía REST, sin base de datos.

Qué hace

Expone 6 endpoints que son passthroughs directos al API de VismaTime (GeoVictoria), usados para ejercitar el adapter durante desarrollo:

Método	Path	Acción
GET	/time/api/clientele/clients/employee	Lista empleados
POST	/time/api/clientele/clients/punch/list	Lista marcaciones
POST	/time/api/clientele/clients/punch/page	Lista marcaciones (paginado)
POST	/time/api/clientele/clients/punch/add	Agrega una marcación
POST	/time/api/clientele/clients/punch/delete	Borra una marcación
POST	/time/api/clientele/clients/punch/multiple	Agrega varias marcaciones
POST	/time/api/clientele/clients/attendance/book	Libro de asistencia (rango de fechas + usuarios)

La colección Postman está en postman/visma-time.postman_collection.json.

Correr

mvn spring-boot:run

No requiere Postgres ni ninguna otra base de datos — el autoconfig de JPA/DataSource está excluido explícitamente en IqrApplication porque kumare-base-server-spring trae spring-boot-starter-data-jpa transitivamente aunque no haya entidades locales.

Credenciales de Visma (visma.server, visma.user, visma.password) en src/main/resources/application.properties, sobreescribibles con las variables de entorno VISMA_SERVER, VISMA_USER, VISMA_PASSWORD.

Trazas

Con logging.level.io.kumare=DEBUG (ya configurado) se ven en el log:

• Cada request entrante y su respuesta (RequestTraceInterceptor): método, path, status, duración.
• Cada llamada saliente al API de Visma (LoggingInterceptor de kumare-base-server-spring): URL, headers (sanitizados), body, status, duración.

Estructura

Este proyecto se clonó de otra app IQR y se recortó: solo queda io.kumare.iqr.mod.clientele.action.client (las acciones Visma) más el framework base (io.kumare.iqr.app.*). Los módulos de negocio originales (authentication, biz, loyalty, pocket, taxonomy) y el CRUD local de Client/ClientRelation se eliminaron por no tener relación con probar el adapter.