Erreurs, idempotence et reprises
Les erreurs du cœur utilisent des problèmes HTTP de type RFC 7807, avec notamment status, title et detail. Une validation de corps peut également fournir une liste errors avec le champ refusé et son message.
Réagir au refus
| Réponse | Réaction |
|---|---|
400 | Vérifier le corps, les types, les champs et les paramètres signalés |
401 / 403 | Vérifier le jeton, le royaume, le rôle et le participant ciblé |
404 | Vérifier l’identifiant et le contexte participant ; ne pas supposer une absence d’effet financier sur ce seul signal |
409 | Lire le conflit métier ; retrouver l’opération existante avant une nouvelle action |
422 | Corriger la règle métier signalée, notamment une recherche préalable absente ou incohérente |
429 | Respecter la limitation ; tenir compte de Retry-After lorsqu’il est fourni |
503 | Examiner l’état du participant et des dépendances ; une reprise financière exige de connaître l’issue de l’appel précédent |
Les statuts et motifs précis dépendent de la route ; la table ne promet pas une erreur identique pour toutes les opérations.
Idempotence des transferts
La route directe accepte Idempotency-Key facultatif, de 1 à 128 caractères. Pour une même opération, conservez la clé et les mêmes données. Le rejeu identique restitue la demande initiale ; Idempotent-Replayed l’indique. Une clé réutilisée avec d’autres données reçoit 422. Une référence métier déjà utilisée peut recevoir 409.
La clé protège les routes qui la déclarent. D’autres routes utilisent un identifiant métier, par exemple l’EndToEndId ou la référence de lot : ne supposez pas qu’un en-tête ajouté à une route suffit à la rendre rejouable.
Distinguer échec et incertitude
Après un timeout réseau, consultez l’opération existante. Une réponse perdue ne signifie pas que le serveur n’a rien exécuté. Les effets CBS ambigus se résolvent par leur suivi d’opération ; ils ne sont pas rejoués automatiquement.
Les messages PI sont signés avec des octets et un MsgId figés. Les exceptions de renvoi à l’identique prévues par les décisions du projet sont gérées par le cœur. Le client ne reconstruit pas de message XML pour « relancer » un paiement.
Pour les files mortes, utilisez la procédure opérateur après diagnostic. Un rejeu technique n’autorise pas à recréer un effet financier dont le résultat reste inconnu.