Systèmes de négociation
Définissez les conditions qui autorisent le démarrage, la pause, la reprise, l’arrêt et la récupération d’un système de négociation automatisée.
Comment le flux de travail s’articule
Les états en cours, en pause et arrêté sont faciles à afficher. Le travail d'ingénierie consiste à décider quand une transition est permise et ce qui doit se passer autour. Les garde-fous de transition empêchent une reprise avec des données périmées, un démarrage en direct accidentel ou une commande d'arrêt qui cache les ordres de courtiers non résolus.
Pour commencer, arrêtez, recommencez, arrêtez et récupérez, listez le rôle demandé, les états sources valides, la configuration requise, la connectivité, la fraîcheur des données, le travail en attente, l'état résultant, les effets secondaires et l'événement d'audit. Une demande peut entrer en démarrage ou s'arrêter pendant que le travail asynchrone s'achève.
Sélection d'environnement séparée de l'état d'exécution. Un système peut être arrêté mais configuré pour une utilisation en direct. Commencer l'opération en direct peut nécessiter une activation explicite, une version de configuration approuvée, des identifiants disponibles, des connexions saines, aucun incident de blocage, et un résultat de rapprochement récent.
Pause peut empêcher de nouvelles décisions tout en laissant le suivi et commander des mises à jour actives. Arrêt peut mettre fin aux travailleurs après l'état persistant. Aucune action n'annule automatiquement les commandes ouvertes ou ferme les positions à moins que la politique d'exploitation définie par le client n'exige et n'autorise explicitement ces actions.
Un état défaillant devrait enregistrer la cause, les composants touchés, le dernier état de courtier connu et exiger des vérifications de récupération. Effacer la condition sous-jacente, réconcilier les ordres ou positions incertains, obtenir toute autorisation requise, et créer un nouvel événement de transition plutôt que de modifier l'échec hors de l'historique.
Une transition de prêt à activer peut exiger une configuration valide, un environnement approuvé, une session de courtier saine, un nouveau compte instantané, une horloge synchronisée, une file d'attente de rapprochement vide et un opérateur ayant l'autorité requise. Chaque condition doit renvoyer un résultat nommé afin que l'interface puisse expliquer pourquoi l'activation est bloquée.
Ne comprimez pas chaque dépendance en bonne santé. Un flux de courtiers peut être connecté pendant que les données de compte sont inexistantes, et un processus de stratégie peut être exécuté pendant que la soumission en direct est désactivée. Les états des composantes et le mode d'exploitation global répondent à différentes questions et doivent rester visibles séparément.
| Transition | Preuves requises | Résultat bloqué |
|---|---|---|
| Idle → prêt | Configuration valide; dépendances initiales | Rester inactif avec des erreurs de validation |
| Prêt → activé | Mode autorisé; nouveau compte; connexion saine | Restez prêt et identifiez les gardes échoués |
| Activer → pause | Demande de pause enregistrée | Arrêter les nouvelles requêtes; définir la politique d'ouverture d'ordre |
| En pause → activé | La cause de la rupture a été réglée; rapprochement terminé | Reste en suspens en attendant l’examen |
| Tout → arrêté | Arrêter la raison et le flux de travail d'arrêt | Préserver les preuves terminales et la porte de redémarrage |
Après un crash ou une interruption de réseau, la mémoire locale ne peut pas établir l'état actuel du courtier. Récupérer la configuration et l'historique des événements durables, interroger le courtier pour les commandes et positions ouvertes pertinentes, les comparer avec les enregistrements locaux et placer les différences non résolues dans un état visible. La soumission automatique devrait rester désactivée jusqu'à ce que le contrat de récupération passe.
Tester les transitions invalides aussi délibérément que valides: reprendre pendant l'expiration des identificateurs, activer avec des données caduques, arrêter pendant une soumission incertaine, ou redémarrer avec un ordre ouvert non assorti. Le résultat attendu devrait être un état sûr avec des preuves utiles, et pas seulement une exception dans un journal.
Repère visuel
Les transitions dépendent de la preuve et de l'autorité; un processus ne peut pas se déplacer en toute sécurité parce qu'un minuteur s'est écoulé ou qu'un bouton a été cliqué.
Idée
La configuration peut être éditée; les dépendances d'exécution ne sont pas supposées prêtes.
Prêt
Validation passée, mais la soumission de l'ordre reste désactivée.
Activé
Les flux de travail définis peuvent être soumis sous les contrôles actuels.
Paus
Les nouvelles présentations s'arrêtent alors que la surveillance et le traitement défini par les politiques se poursuivent.
Récupération
L'état local et l'état de la plateforme sont comparés après interruption.
Arrêts
Le flux de travail est fermé avec une raison et une porte de redémarrage explicite.
Questions pratiques
Non. En pause décrit la permission de lancer de nouvelles actions de flux de travail. Les connexions peuvent rester actives pour que les données, les mises à jour de commande et la surveillance se poursuivent.
Seulement pour les cas récupérables explicitement approuvés avec des contrôles rigoureux. L'état d'ordre ou de compte incertain nécessite généralement la rapprochement et peut nécessiter une autorisation humaine.
Poursuivre l’exploration
Collaborer avec Sun Cluster
Les ingénieurs Sun Cluster ont automatisé les systèmes de négociation avec des contrôles d'exécution persistants, des environnements explicites, la surveillance et des flux de travail de récupération.
