Systèmes de négociation
Séparez les commandes internes des requêtes propres au courtier et normalisez les événements sans perdre les données sources utiles.
Comment le flux de travail s’articule
Un connecteur devient difficile à remplacer lorsque les noms de champs de la plateforme et les hypothèses de réponse se propagent dans la stratégie, le tableau de bord et le code de base de données. Un contrat de commande et d'événement conserve la traduction propre au courtier dans cette couche tout en préservant les identifiants bruts et les états nécessaires à l'enquête.
Une commande de placement d’ordre peut inclure l'ID de requête locale, connexion de compte, identité d'instrument, côté, quantité avec des unités, type de commande, valeurs limites ou arrêts, temps en vigueur, environnement, et identifiant de trace. Valider les invariants internes avant d'appeler l'adaptateur courtier.
L'adaptateur doit signaler les types de commande pris en charge, les valeurs de temps en vigueur, les quantités fractionnées, le comportement en heures prolongées, l'environnement d'essai et les limites pertinentes. Un flux de travail peut alors rejeter les commandes non prises en charge avec une raison structurée avant la soumission du réseau.
Reconnaissances, refus, statut ouvert, remplissages partiels, remplissages, annulations et remplacements dans des événements internes. Conservez les ID de commande du courtier, les ID d'exécution, l'état de la source, l'horodatage de la source, l'horodatage reçu et une référence à la charge utile brute autorisée.
Utiliser les réponses désinfectées enregistrées et les tests de bac à sable pour les événements acceptés, rejetés, partiels, annulés, retardés, dupliqués et hors-commande. Confirmer qu'un délai d’attente crée un état incertain plutôt qu'une commande automatique dupliquée. Les installations contractuelles doivent être mises en version lorsque le courtier API change.
Une commande de soumission de commande exprime une action prévue avec l'ID de commande client, instrument, côté, type, quantité, termes de prix, compte, et contexte de contrôle. Le résultat immédiat ne peut que confirmer que l'adaptateur a accepté la commande de traitement. Les événements des courtiers rapportent plus tard des faits de source tels que acceptés, rejetés, ouverts, partiellement remplis, remplis, annulés ou expirés.
Conservez ensemble l'événement normalisé et la charge utile du courtier ou les champs source autorisés. Lorsqu'un courtier ne prend pas en charge une fonctionnalité demandée, retourner une erreur de capacité explicite avant la soumission au lieu de se rapprocher silencieusement. Lorsqu'un délai d’attente rend le résultat inconnu, émet un état incertain qui déclenche la recherche ou la rapprochement plutôt que de signaler un rejet définitif.
Repère visuel
L'adaptateur isole l'authentification spécifique à la plateforme, les identifiants, les capacités et les réponses du flux de négociation plus large.
Commande
Une demande interne stable avec identité et termes définis.
Contrôle des capacités
Valider la connexion, le marché, le type de commande et le soutien de compte.
Requête à la plateforme
Traduire les unités, les identifiants, les paramètres et l'authentification.
Réponse des sources
Conserver les cartes d'identité, les codes, la charge utile et l'heure.
Manifestation normalisée
Publier un fait cohérent sur le cycle de vie avec les preuves de la source.
Conservez les appareils approuvés pour chaque forme de réponse prise en charge et comparez à la fois le résultat normalisé et la preuve de source conservée après un changement d'adaptateur. Un champ rebaptisé, un nouveau statut, un corps d'erreur modifié ou un format d'identificateur différent devrait échouer visiblement au lieu de devenir une erreur de mappage silencieuse.
Utilisez le bac à sable ou l'environnement de démonstration permis par le courtier pour vérifier la compatibilité actuelle, tout en conservant les appareils déterministes pour les défaillances difficiles à déclencher sur demande. Enregistrez les versions de documentation et la découverte de la capacité de répétition lorsque le courtier change de produits, de permissions de compte ou de comportement API.
| État du fournisseur | Réponse normalisée | Suivant action du logiciel |
|---|---|---|
| Type d'ordre non pris en charge | Erreur de capacité | Rejet avant présentation |
| Taux limité | Erreur réutilisable du fournisseur | Retour dans la politique de demande |
| Délai de soumission | Résultat inconnu | Demander ou réconcilier avant de réessayer |
| Autorisation refusée | Erreur de configuration de connexion | Désactiver l'action affectée et le propriétaire de l'alerte |
| Dupliquer l'ID client | Conflit d'intention existant | Charger la requête liée et comparer les termes |
Questions pratiques
Non. Normaliser les concepts partagés et exposer les capacités ou les extensions pour de véritables différences. Faire semblant que chaque courtier se comporte de façon identique crée des hypothèses dangereuses.
Il devrait normalement avoir un comportement de traduction et de connexion. La stratégie et les règles d'exploitation définies par le client appartiennent à des couches qui peuvent être testées indépendamment d’une plateforme.
Poursuivre l’exploration
Collaborer avec Sun Cluster
Sun Cluster construit des adaptateurs de courtage API et des intégrations de système de négociation avec des capacités explicites, la gestion des commandes et des garanties opérationnelles.
