Un signal peut-il créer plusieurs traces d'ordre?
Oui. Conservez la trace d'origine et créez des demandes de commande d'enfants liées lorsque le flux de travail approuvé se divise entre instruments, comptes ou jambes.
Systèmes de négociation
Tracer un flux automatisé du signal à l’ordre
Concevez une piste d’événements qui relie la réception du signal, la validation, la décision, les limites, la demande d’ordre, la réponse du courtier et le rapprochement.
Comment le flux de travail s’articule
- 1Créer une trace au signal ou à la évaluation planifiée
- 2Consigner les validations et les résultats des décisions
- 3Appliquer les limites configurées et la déduplication
- 4Enregistrer la demande d’ordre avant de la transmettre
- 5Relier les événements du courtier et les résultats du rapprochement
Un opérateur qui enquête sur une commande a besoin de plus que des journaux d’application. L'enregistrement utile commence par le signal entrant ou l'évaluation programmée et suit chaque validation, décision, contrôle, demande, réponse et mise à jour ultérieure de l'état. Un modèle de trace rend cette chaîne consultable sans confondre les journaux avec l’état métier faisant autorité.
Commencer la trace avant la décision stratégique
Créez un identifiant de trace lorsqu'un signal, un webhook, une évaluation programmée ou une demande d'opérateur entre dans le système. Entreposez l'identité de la source, le temps reçu, la version de charge utile, l'environnement et la clé de duplication. Les défaillances de validation devraient fermer la trace avec une raison plutôt que de disparaître dans un journal technique.
Enregistrer chaque décision en tant que données structurées
Persistez la version de la stratégie, les références d'entrée pertinentes, le résultat de la décision, les codes de raison, l'instrument et la quantité demandés, et toute limite qui a modifié ou supprimé l'action. Les journaux de texte libre peuvent ajouter du contexte, mais les champs structurés supportent la recherche et l'affichage cohérent du tableau de bord.
Relier les demandes locales aux identifiants du courtier
Créer un identificateur de commande local durable avant d'appeler le courtier. Envoyer un ID de commande client ou une clé d’idempotence lorsque soutiené. Entreposez chaque tentative et attachez ensuite les identifiants de commande et d'exécution sans remplacer l'identité locale.
- Identification des requêtes locales et des traces
- Commande client ou clé d’idempotence
- IDs d'ordre et d'exécution des courtiers
- État brut et situation normalisée
- Tentative, réponse et temps de mise à jour
Rendre la trace utile lors du rapprochement
Lorsque l'état local et courtier diffère, enregistrez la comparaison, la requête source, le résultat observé et la résolution dans la même trace. La vue finale peut montrer le calendrier des événements ordonnés et mettre en évidence des intervalles incertains sans prétendre que les événements manquants n'ont jamais eu lieu.
Relier l’identifiant de trace à chaque dossier d'entreprise
Un identifiant de trace relie le flux de travail sans remplacer les identifiants appartenant à chaque étape. Liez-la à la version de données du marché, à la version de stratégie et de configuration, au résultat d'admissibilité, aux vérifications de risque, à la demande de commande locale, au raccordement du courtier, à la tentative de soumission, à l'identification de commande du courtier et aux événements de commande ultérieurs. Préserver le statut de source de la plateforme à côté de tout statut normalisé.
Cette chaîne permet à un opérateur de distinguer deux signaux qui sont arrivés ensemble, de prouver quelle configuration a produit une décision, et de vérifier si une réessayer se réfère à la même commande prévue. Il permet également de rattacher un ordre observé par un courtier à la demande locale correcte sans s'appuyer uniquement sur le symbole et l'horodatage.
Repère visuel
Identificateurs qui connectent le signal, la décision, la requête et l'état de la plateforme
Chaque étape ajoute des preuves tout en conservant les identifiants nécessaires pour reconstruire le chemin plus tard.
- 1
Manifestation de signalisation
Trace ID, source ID, temps reçu, version d'entrée.
- 2
Décision
Version stratégique, configuration, résultats des règles, raisons de rejet.
- 3
Objectif de la commande
ID de commande client stable et conditions normalisées demandées.
- 4
Présentation
Connexion, tentative, demande de charge utile, réponse ou délai.
- 5
Cycle de vie du site
ID du courtier, événements sources, états normalisés, rapprochement.
Utiliser la trace lors de l'examen des défaillances
Lorsqu'une commande est signalée deux fois, déterminez d'abord si deux intentions ont été créées, si une intention a été présentée deux fois ou si une commande de courtier a été livrée par le biais d'événements en double. Ce sont des défauts différents. Une trace connectée expose là où l'identité diverge et quelle règle d’idempotence ou de transition aurait dû l'empêcher.
Conserver suffisamment de preuves sources pour enquêter sans enregistrer des secrets ou des renseignements personnels non contrôlés. Établir le maintien en fonction des exigences opérationnelles, contractuelles et juridiques. Fournissez une recherche par identifiant de trace, ID de commande client, ID de commande courtier, version de stratégie et plage de temps, et limitez l'accès aux charges utiles brutes séparément des vues normales du tableau de bord.
| Observation | Question | Preuves |
|---|---|---|
| Deux intentions locales | L'évaluation de la stratégie a-t-elle été menée deux fois? | Identification des signaux et dossiers de décision |
| Deux communications | Une intention a-t-elle fait l'objet d'une tentative dangereuse? | ID de commande client et historique de tentative |
| Manifestations en double lieu | Une mise à jour de courtier a-t-elle été livrée deux fois? | IDs d'événement de courtier et version d'état |
| L'état local diffère | Un événement a-t-il été raté ou rejeté? | Point de contrôle et enregistrement de rapprochement |
Questions pratiques
Questions fréquentes sur le sujet
Les réponses brutes des courtiers devraient-elles être conservées pour toujours?
La conservation dépend des exigences opérationnelles, légales, en matière de confidentialité et de stockage. Préserver suffisamment de preuves de source pour enquêter et se réconcilier tout en appliquant une politique de conservation explicite.
Poursuivre l’exploration
Projets et guides connexes
Collaborer avec Sun Cluster
Vous planifiez un système semblable pour votre organisation?
Sun Cluster construit un logiciel de négociation automatisé avec des décisions traçables, des flux de travail de commande, des contrôles opérationnels et un rapprochement entre courtiers et états.