Aller au contenu

Configuration dynors-notify — librairie vs applications

Choisir sa ligne — contrôle du 15 octobre 2026

La stable 2.0.0 est publiée pour Boot 4.1.1 / Spring 7.0.9, Java 17 minimum. Les sections historiques 1.x ci-dessous ne suffisent pas à son adoption. Voir versions, compatibilité et causes des correctifs, le contrat 2, la migration et la configuration 2.

En 2.0.0, utiliser le reçu détaillé de submit : PROVIDER_ACCEPTED n'est pas DELIVERED, UNKNOWN exige une réconciliation avant reprise, SIMULATED ne permet jamais de marquer un message livré. L'ancien send est déprécié et perd de l'information. Le canal noop et sa classe sont retirés ; PUSH sans provider retourne FAILED/NO_PROVIDER. Pas de fallback historique, de retry implicite ou de qualification fournisseur réelle déduite des tests SDK.

dynors-notify (com.dynors:dynors-notify, dépôt dynors-extensions) est une bibliothèque embarquée dans chaque application Spring Boot qui déclare la dépendance. Il n’existe pas de « serveur NOTIFY » unique : chaque app configure son fournisseur d’envoi, ses secrets et ses profils (dev, recette, prod).

Release stable vérifiée

com.dynors:dynors-notify:1.0.6 est publiée depuis le 2026-09-06 sur le registry GitLab 76017499 (30 tests, POM/JAR sans SNAPSHOT, SHA-256 local/distant identique). Cette version corrige la sélection EMAIL avec les identifiants smtp, brevo, resend, sendgrid et mailgun. E-mail et SMS ont des providers réels ; l'ancien NoOp n'était pas un provider push routable. Il est retiré en 2.0.0 ; ne pas le traiter comme une preuve d'envoi.

Le 2026-09-07, AUTH et DOSALI ont résolu 1.0.6 depuis le registry Extensions avec Maven Local vide ; le smoke DOSALI → SLY → AUTH → SMTP/MailHog est vert.

Source et dépôt principal

Contenu aligné sur le dépôt agrégé dynors : docs/CONFIGURATION_DYNORS_NOTIFY.md.
Résolution Maven / registry : Versions et dépendances (core) ; accès token : CONFIGURATION_ACCES_DEPENDANCES.md.

SLY (SelebeYone) et applications tierces

  • dynors.interapp.gateway-url (SLY) et InterAppCallService = appels entre apps DYNORS. La config dynors.notify.* cible les fournisseurs (SMTP, Brevo, Resend…), sans signature de transit SLY sur ces envois.
  • App tierce : assouplir avec stub, base-url si proxy, sans imposer le contrat inter-app — voir le paragraphe homonyme dans CONFIGURATION_DYNORS_NOTIFY.md.

1. Rôles

Couche Responsabilité
dynors-notify Contrat Java (NotificationService, NotificationRequest), auto-config Spring, implémentations SMTP, Brevo, Resend, SendGrid, Mailgun, SMS Orange, construction des payloads API (TransactionalEmailPayloads, pièces jointes EmailMetadataAttachments).
Chaque application Dépendance Maven + entrée dans application.yml / variables d’environnement / Vault : choix du provider, clés API, SMTP, stub ou non, expéditeur par défaut.
Code métier Contenu des messages, templateId / templateVars par cas d’usage, appels à NotificationService.send(...).

Deux apps différentes peuvent donc utiliser Brevo et Resend avec des comptes, domaines et templates distincts.

2. Propriétés principales (dynors.notify.*)

Préfixe commun : dynors.notify.

Clé Rôle
dynors.notify.email.provider smtp · brevo · resend · sendgrid · mailgun — un seul actif par app (bean conditionnel).
dynors.notify.email.enabled Active le provider email (true en général si vous envoyez des mails).
dynors.notify.email.stub true : pas d’appel réseau (logs uniquement) — pratique en dev sans secrets.
dynors.notify.email.from Adresse expéditeur par défaut (souvent surchargée par le template côté Brevo/Resend).
dynors.notify.email.brevo.api-key Clé API Brevo (préférer ${BREVO_API_KEY}).
dynors.notify.email.brevo.base-url Défaut https://api.brevo.com/v3.
dynors.notify.email.resend.api-key Clé Resend (${RESEND_API_KEY}).
dynors.notify.email.mailgun.* Domaine, URL de base, clé — voir javadoc MailgunEmailProvider.
dynors.notify.email.sendgrid.* Idem SendGrid.

SMTP : en plus, configurer spring.mail.* (host, port, username, password, TLS) — classique Spring Boot.

Les clés exactes et les javadoc sont dans les classes *EmailProvider sous le module notify dans dynors-extensions (packages/extensions/notify/.../providers/email/).

3. Secrets et environnements

  • Ne pas commiter les clés dans Git : utiliser variables d’environnement, Vault (stratégie DYNORS), ou fichiers locaux ignorés (.env).
  • En CI/CD : variables masquées dans GitLab / pipeline ; le GITLAB_TOKEN sert au registry Maven (read_registry), pas aux APIs Brevo/Resend (tokens distincts).

4. Templates distants vs HTML inline

Définis sur NotificationRequest : templateId, templateVars.

  • Brevo : templateId doit être l’ID numérique du template dans Brevo (chaîne "42"). Payload JSON : templateId, params ← templateVars, sans htmlContent.
  • Resend : templateId = id ou alias du template (ex. order-confirmation). Payload : template: { id, variables }, sans html.
  • SMTP : pas de rendu de template distant ; seul le corps (body) est envoyé. Les champs templateId / templateVars ne sont pas interprétés par le serveur SMTP (éventuellement enrichissement métier avant l’appel à NOTIFY).

Voir TransactionalEmailPayloads et les tests TransactionalEmailPayloadsTest dans le module notify (repo dynors-extensions).

5. Pièces jointes

Métadonnées standardisées : attachmentPdfBase64, attachmentFilename, attachmentContentType (voir EmailMetadataAttachments). Utilisées par exemple par FISCAL pour joindre un PDF de facture.

6. Politique métier et distinction events

7. Références code

Élément Emplacement
README module dynors-extensions packages/extensions/notify/README.md
Payloads Brevo / Resend .../notify/email/TransactionalEmailPayloads.java
PJ depuis métadonnées .../notify/email/EmailMetadataAttachments.java
Registry Maven Projet GitLab 76017499 — Versions et dépendances

Dernière mise à jour : 2026-09-07 — release stable dynors-notify:1.0.6 consommée par AUTH et DOSALI.