Aller au contenu

TP Backend – dynors-core (Spring Boot)

Objectif : construire un mini backend qui utilise correctement dynors-core (DB multi‑tenant, sécurité, logging), sans dépendre d’un projet métier particulier. Ce TP formalise l’usage du core pour tout nouveau projet (Mediconnect, SuperGest, TRACIUM, modules internes, etc.).

Durée cible : 1 journée (ou 2 demi‑journées) avec accompagnement.

Étape 0 – Pré‑requis

Étape 1 – Squelette projet

  1. Créer un projet Gradle Spring Boot (ex. tp-demo-backend ou mon-module-metier).
  2. Ajouter les dépendances DYNORS (voir Guide projets clients) :
dependencies {
    implementation(platform("com.dynors:dynors-core-bom:1.0.2"))  // Dernière release — voir [Versions et dépendances](../99-annexes/versions-et-dependances.md)
    implementation("com.dynors:dynors-commons")
    implementation("com.dynors:dynors-security")
    implementation("com.dynors:dynors-db")
    implementation("com.dynors:dynors-logging:1.0.0-SNAPSHOT")

    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation("org.springframework.boot:spring-boot-starter-data-jpa")
    implementation("org.springframework.boot:spring-boot-starter-security")
    implementation("org.postgresql:postgresql")
}
  1. Configurer le repository GitLab Maven Registry (voir doc core : CONFIGURATION_CLIENT_PROJETS.md ou équivalent).

Objectif : ./gradlew build compile.

Étape 2 – Configuration application

  1. Classe principale :
  2. @SpringBootApplication avec scanBasePackages incluant com.dynors.db, com.dynors.security.
  3. @EntityScan sur com.dynors.db.tenant.model + le package de vos entités métier.

  4. @EnableJpaRepositories sur com.dynors.db.tenant.repository + le package de vos repositories.

  5. application.yml :

  6. spring.datasource (PostgreSQL local).
  7. spring.jpa.hibernate.ddl-auto=validate (ou update en dev contrôlé).
  8. dynors.db : multi‑tenant, strategy=schema, tier=TIER_2.
  9. dynors.security : JWT activé.
  10. dynors.logging.provider=console.

Objectif : l’application démarre (même sans endpoint métier).

Étape 3 – Modèle métier minimal (tenant‑aware)

  1. Créer une entité métier (ex. Partner ou Customer) dans votre package :
  2. champs : id (UUID), champs métier (nom, email, téléphone, etc.), createdAt, updatedAt.

  3. Pas de tenant_id explicite en stratégie SCHEMA_DEDICATED (isolation par schéma).

  4. Repository étendant TenantAwareRepository<Entité, UUID> :

@Repository
public interface PartnerRepository extends TenantAwareRepository<Partner, UUID> {
    Optional<Partner> findByEmail(String email);
}

  1. Service métier : create, findById, findAll avec validation simple (ex. email unique dans le tenant).

  2. Controller REST : POST /api/partners, GET /api/partners, GET /api/partners/{id}.

Objectif : - POST /api/partners crée un enregistrement. - GET /api/partners liste les données du tenant courant uniquement.

Étape 4 – dynors-logging (DynorsLogger)

  1. Injecter DynorsLogger et TenantContextService dans votre service.
  2. Ajouter :
  3. un log info à la création (avec métadonnées : tenant, service, action, id).
  4. un log error en cas d’exception.

Exemple :

logger.info("Partner créé", Map.of(
    "tenant", tenantContextService.getCurrentTenant(),
    "service", "PartnerService",
    "action", "create",
    "partnerId", created.getId()
));

Objectif : voir les logs en console avec le format DYNORS (métadonnées structurées).

Étape 5 – Authentification (JWT)

  1. Suivre Sécurité & Auth :
  2. entité User simple (username / password hashé) ou utilisation du modèle core.
  3. endpoint /api/auth/login renvoyant un JWT.
  4. Protéger les endpoints métier (/api/partners/**) avec Spring Security + filtre dynors-security.

Objectif : impossible d’appeler /api/partners sans JWT valide.

Étape 6 – Tests & validation

  • Au moins :
  • un test d’intégration (création + lecture via le service).
  • un test vérifiant l’isolation tenant : deux tenants différents → données isolées.
  • Vérifier que l’app démarre avec un tenant défini (header ou config) et que les logs utilisent bien DynorsLogger.

Étape 7 – Aller plus loin (optionnel)

  • Ajouter une seconde entité et une relation (ex. commande liée au partenaire).
  • Utiliser QuotaService pour une règle simple (ex. nombre max d’enregistrements par tenant).
  • Basculer dynors.logging.provider sur sentry dans un profil de test.

Références