Aller au contenu

Interactions dynors-core ↔ dynors-internal (RAGNAR, TAKKU, ...)

Objectif : expliquer comment les outils internes DYNORS (dans dynors-internal) consomment dynors-core et orchestrent les projets clients.

Pour la version détaillée, voir core/INTERACTIONS_DYNORS_INTERNAL.md.

RAGNAR – Vue haute

  • ERP ESN interne DYNORS.
  • Gère :
  • opportunités commerciales,
  • contrats,
  • suivi des projets.
  • Utilise :
  • dynors-db pour son tenant interne (ragnar_internal),
  • dynors-security pour JWT, rôles/permissions après auth LDAP.
  • Auth des employés : LDAP (géré par RAGNAR, pas par dynors-security).

TAKKU – Configurateur central

  • Application interne qui :
  • crée les tenants (via TenantService de dynors-db),
  • initialise schémas/bases (TenantInitializationService),
  • configure la sécurité par tenant (TenantSecurityLoader de dynors-security),
  • génère les projets clients (templates, config Gradle/Maven),
  • prépare les déploiements.

Flux typique :

1. RAGNAR → opportunité gagnée
2. TAKKU → crée le tenant (dynors-db)
3. TAKKU → configure la sécurité (dynors-security)
4. TAKKU → génère le projet client (backend + éventuellement frontend)
5. Le projet client → consomme dynors-core selon la config générée

HEISENBERG, RED, etc.

  • HEISENBERG (Time Tracking) :
  • utilise TenantContext de dynors-db pour isoler les temps par tenant.
  • RED (CRM) :
  • utilise dynors-db (tenants) + dynors-security (rôles/permissions) selon les besoins.

L’idée générale : - dynors-core fournit les briques techniques (db, security, logging...). - dynors-internal utilise ces briques pour gérer l’activité ESN et préparer les projets clients. - Les projets clients consomment dynors-core en suivant les conventions définies par TAKKU.