Configuration des destinations de livraison

Contrat natif

Disponible à partir de Paiement 2.0.1 ; absent de la release 2.0.0 inchangée. Cette capacité ne modifie pas les contrats événementiels.

Une application d'exploitation peut injecter une collection dans DYNORS_PAIEMENT_DELIVERY_COLLECTION_JSON, reliée à dynors.paiement.delivery.collection-json. Paiement ne connaît ni Forge ni SIRRAT.

{"dawalale|tenant-fixture|owner-fixture":["dawalale:/api/v1/internal/payment-facts"],"elisa|tenant-fixture|owner-fixture":[]}

Les identifiants ci-dessus sont synthétiques. La clé est exactement application|tenant|entité légale. Chaque valeur est une liste de destinations ; une liste vide ne crée aucune livraison. Les listes gardent leur ordre. Plusieurs portées partagent une seule valeur de configuration.

La collection ne filtre pas par nom d'événement. Les types, versions, schémas, effets métier et règles particulières de projection Books restent définis par le code et ses contrats. L'événement de confirmation existant est paiement.payment.completed, schemaVersion=1.

Validation et refus

Le chargement refuse JSON invalide, clés dupliquées, documents multiples, racine autre qu'objet, portée mal formée, destinations non textuelles/vides, doublons et caractères de contrôle. Maximum : 65 536 octets UTF-8. Le contenu ne peut importer des propriétés Spring arbitraires et ne transporte pas de secret.

La table historique dynors.paiement.delivery.targets reste utilisable sans cette option. Une table historique non vide combinée à une collection non vide syntaxiquement déclarée est refusée au démarrage, même si celle-ci vaut {}. Aucun arbitrage silencieux entre les deux sources.

Le nom COLLECTION_JSON évite une collision de binding des variables d'environnement avec la map historique targets. Ne pas utiliser DYNORS_PAIEMENT_DELIVERY_TARGETS_JSON.

La validation vérifie la structure ; elle ne prouve ni l'existence d'une route, ni son admission SLY, ni l'autorité d'un destinataire. Les contrôles de transport et d'autorisation restent obligatoires. Les scopes sont provisionnés côté serveur ; cette option ne donne pas au client le droit de choisir son tenant ou son entité légale.

Adoption

1. Déployer Paiement 2.0.1 après qualification de son environnement ; ne pas injecter un SNAPSHOT dans une application livrée.
2. Choisir une seule source : table historique ou collection. Renseigner les identifiants réels autorisés, sans segment fonctionnel artificiel par quiz ou écran.
3. Vérifier les admissions et routes SLY exactes, les credentials et les éventuelles jonctions entre couloirs. Une valeur de configuration n'en crée aucun.
4. Recetter une émission réelle, sa réception authentifiée, les doublons, l'effet transactionnel et la relecture de statut par le consommateur lorsque son contrat l'exige.
5. Conserver image, révision figée et preuves de recette. Toute modification de raccordement passe par le circuit habituel de paramétrage, autorisation et exécution.

Qualification locale du candidat

Tests de propriétés : plusieurs portées/destinations, absence de contamination inter-portées, compatibilité historique, conflit des sources, entrées négatives et binding ENV. La chaîne SIRRAT/Ops/Compose/Spring est exercée séparément dans le banc applications/sirrat/backend/qualification/event-templates du candidat dynors-internal.

Ce banc instancie les propriétés depuis les classes du JAR candidat ; il ne qualifie pas une image applicative finale, un paiement PSP, un broker ou une route SLY réelle. Aucune publication ni activation n'est impliquée.