Le protocole FIX permet-il de réutiliser la même balise dans un message et dans des groupes répétitifs? Ie pourrais-je avoir quelque chose comme ça
<message name='Quote' msgtype='S' msgcat='app'>
<field name='Price' required='Y'/><!-- i.e. total price for the whole quote-->
...
<group name='NumLegs' required='Y'>
<field name='Price' required='Y'/><!-- i.e. leg price -->
...
<group name='NumLegDetails' required='Y'>
<field name='Price' required='Y'/><!-- i.e. leg component price -->
...
</group>
...
</group>
</message>
3 Réponses :
Vous ne pouvez pas réutiliser une balise de groupe répétitif en dehors d'un groupe extensible.
La déclaration d'une balise en tant que balise de groupe répétitif lui impose des contraintes, telles que son ordre dans un groupe et la manière dont une occurrence est traitée différemment d'une occurrence ultérieure. Les balises de groupe non répétitives n'ont pas une telle contrainte.
J'ai essayé avec QuickfixJ et cela fonctionne très bien. Y a-t-il une spécification qui l'interdit? Parce que du point de vue technique, il n'y a aucun problème à le faire.
Avez-vous seulement essayé de créer un tel dictionnaire de données ou également d'analyser ces messages?
@ChristophJohn Oui, j'ai construit un dictionnaire, généré des classes java, créé un message FIX et l'ai analysé. Cela fonctionnait bien pour moi.
Non, ce n'est pas autorisé. Je vous suggère d'obtenir un gros dictionnaire de données sur http://www.quickfixengine.org , de l'enregistrer sur votre ordinateur au format XML, puis d'exécuter une commande comme celle-ci:
grep Price FIX.xml | grep number
Cela vous montrera les définitions de tous les champs liés au prix. Si vous recherchez chacun de ces noms de champ dans les messages / composants, vous verrez que chacun est utilisé à un endroit différent. Le résultat global est que chaque champ n'est répertorié qu'une seule fois dans un message.
Je demande comment créer mon propre dictionnaire de données. Je pourrais créer un champ défini par l'utilisateur comme MyPrice pour cela. Donc, ma question ne concerne pas spécifiquement le champ Price , mais la conception du protocole FIX et le type de structure de message que je pourrais avoir.
@kan Malheureusement, de nombreux compilateurs de dictionnaire de données FIX effectuent une vérification de validation incomplète, ce qui signifie que si votre dictionnaire de données contient une erreur, l'erreur peut ne pas être détectée.
Il n'est pas autorisé dans le codage de la valeur de balise .
(mais dans FIXML c'est le cas)
Mon malentendu initial est venu de cette déclaration dans la spécification de valeur de balise FIX: voir ici, rechercher "Présence sur le terrain"
Une balise (champ) doit apparaître au plus une fois dans un message, sauf lorsque la balise apparaît dans un groupe répétitif.
Mais comme je l'ai appris, cela fait référence au format filaire du message, pas à la définition du message.
Alors que la spécification FIX5.0SP2 Volume 1 fait référence à la définition du message et déclare:
Un numéro de tag (champ) ne doit apparaître qu'une seule fois dans un message. S'il apparaît plus d'une fois dans le message, il doit être considéré comme une erreur avec le document de spécification.
En attendant, je l'ai même trouvé mentionné dans FIXimate en regardant le composant NestedParties (c'est moi qui souligne): ( lien vers le composant NestedParties dans FIXimate )
Le bloc de composants NestedParties est identique au bloc Parties. Il est utilisé dans d'autres blocs de composants et des groupes répétés lorsque l'imbrication aura lieu, ce qui entraînera plusieurs occurrences du bloc Parties dans un seul message FIX. L' utilisation de NestedParties dans ces conditions évite de multiples références au bloc Parties dans le même message qui n'est pas autorisé dans la syntaxe de balise / valeur FIX.
BTW, il existe également des composants NestedParties2 , NestedParties3 , NestedParties4 pour contourner ce NestedParties4 .
Le fil de discussion est accessible ici, mais pour autant que je sache, vous ne pouvez y accéder que si vous êtes membre de FIX TC: forum FIX TC
L'expert FIX Hanno Klein a donné les informations suivantes:
La citation de la spécification en ligne refactorisée fait référence au format filaire de toute instance d'un message codé dans la syntaxe de valeur de balise. Cela signifie qu'à l' intérieur du format filaire d'un seul groupe répétitif, une étiquette (champ) peut apparaître plusieurs fois.
FIXML n'a pas cette restriction:
La restriction est en fait limitée au codage tagvalue. Par exemple, le composant parties est «Pty» pour toutes les instances de FIXML, la syntaxe / encodage XML de FIX. Cela est dû au fait que la syntaxe XML a une structure sans ambiguïté avec un chemin distinct vers chaque occurrence d'un composant ou d'un champ. Les noms XML doivent uniquement être uniques au sein du même élément.
La valeur de la balise fait:
Pour tagvalue, un analyseur doit savoir quand un groupe répétitif commence et se termine. Le champ NoXXX marque le point de départ et un champ qui ne fait pas partie du groupe marque le point de fin. Il n'y a pas de délimiteurs explicites pour les groupes répétés dans tagvalue et les composants (non répétitifs) ne sont pas du tout visibles dans le format filaire. Techniquement, vous avez probablement raison de dire qu'une étiquette de prix pourrait exister dans deux groupes répétés distincts sans causer de problème d'analyseur, mais je ne vois pas l'intérêt d'autoriser cette exception à la règle. Vous ne pouvez pas l'autoriser pour deux niveaux adjacents, par exemple racine + niveau d'imbrication 1 ou niveau d'imbrication x + niveau d'imbrication y.
Sur une autre note, lors de la définition de vos propres groupes répétitifs, veuillez utiliser la notation NoXXX pour les groupes répétitifs car c'est la recommandation officielle. voir ici, recherchez "Champ NumInGroup"
Il est recommandé que les champs NumInGroup soient nommés NoXXX, par exemple NoContraBrokers (382).
Cependant, en suivant votre exemple avec 44/Price vous verrez normalement 566/LegPrice utilisé comme prix pour une jambe individuelle puisque les deux sont utilisés différemment. Le premier est le prix utilisé pour l'exécution d'un ordre, le second est utilisé lors de la définition d'une jambe d'une stratégie.
Donc, en bref, lors de la définition de la structure de votre message et des groupes de répétition, vous devez vraiment vous demander si la signification de la balise est la même pour toutes les occurrences de la balise dans le message et s'il est vraiment logique d'utiliser la même balise dans le corps. et en groupes répétitifs. La clarté doit être la première priorité.
Au début, j'ai pensé que cela ne pouvait pas être autorisé mais principalement parce que je ne l'ai jamais vu apparaître quelque part dans un vrai message. Mais en fait, je n'ai pas pu trouver une raison pour laquelle cela ne devrait pas être autorisé. La spécification dit seulement: voir ici, rechercher "Présence sur le terrain"
Une balise (champ) doit apparaître au plus une fois dans un message, sauf lorsque la balise apparaît dans un groupe répétitif.
Une balise (champ) doit apparaître au plus une fois par instance de groupe répétitif.
Donc ... la conclusion est ... C'est permis par la norme, mais il y a des implémentations cassées qui nous obligent à éviter d'utiliser une fonctionnalité intéressante ... :( Non?
@kan Je ne suis pas d'accord avec Christoph John. Voir ma réponse dans cette autre question: stackoverflow.com/questions/56524842/...
N'avez-vous pas dit que cela fonctionnait dans QFJ? Je ne vois cependant pas la grande amélioration que cela aurait.
@CiaranMcHale la spécification à laquelle je fais référence remplace en fait la spécification FIX4.4 et 5.0 et je ne trouve pas le paragraphe que vous avez mentionné dans la dernière spécification que j'ai liée. Je ne sais pas si la rétro-ingénierie des dictionnaires de données est la bonne façon de prouver votre point de vue. ;)
@Christoph John: Essentiellement, la dernière spécification à laquelle vous liez est incompatible avec les spécifications précédentes. Étant donné qu'au moins certaines implémentations de FIX seront basées sur les spécifications antérieures les plus restrictives, il semble prudent pour quelqu'un qui rédige un dictionnaire de données de respecter ces spécifications antérieures plus restrictives, car cela offrira une meilleure portabilité entre les implémentations de FIX.
@Christoph John: Une lecture plus approfondie de la dernière spécification que vous avez liée me laisse penser qu'elle est simplement mal formulée mais conforme aux spécifications précédentes. En particulier, la spécification indique ce qui suit (en plus de ce que vous avez cité): "Chaque champ est identifié de manière unique par un entier, appelé balise. Les balises doivent être uniques dans les champs de message de session et d'application. (Champs dans l'en-tête standard et les composants de fin standard sont partagés par les messages de session et d'application.) "Le libellé pertinent est" Les balises doivent être uniques [...] parmi les champs de message. "
@CiaranMcHale en fait, le document dit "Les balises doivent être uniques parmi les champs de message de session et d'application" et les points de suspension "Les balises doivent être uniques parmi les [...] champs de message." est à mon avis pas correct. L'intention réelle est d'interdire qu'une étiquette soit à la fois définie comme faisant partie du corps ainsi que l'en-tête / la remorque. Pour parler en termes de dictionnaire de données: vous ne devez pas avoir de balise n dans la section <header> / <trailer> ainsi que dans la section <messages> .
Je pense que nous pouvons convenir que le libellé prête à confusion. Cependant, si vous recherchez des occurrences de session dans la spécification, vous verrez que «session = champ d'en-tête / de fin» n'est pas la signification voulue. Un message de session est plutôt un message dans lequel msgcat="admin" , et un message d' application en est un dans lequel msgcat="app" . En tant que tel, je pense que mon utilisation des points de suspension est correcte.
Les balises doivent être uniques [...] parmi les champs de message. - semble bizarre dans le contexte de la répétition de scénario de groupe.
@CiaranMcHale bien, que dois-je dire. Les spécifications sont constamment remplacées et modifiées, en particulier dans le domaine informatique. Donc, soit vous avez raison et ils ont oublié de mentionner cette exception dans la nouvelle spécification, soit j'ai raison et c'est en effet un changement qui a été fait intentionnellement. Quoi qu'il en soit, je clarifierai cela avec FIX Trading Community et vous ferai rapport. BTW, le vote négatif parce que vous n'êtes pas d'accord avec la réponse me semble un peu étrange car ma réponse contient des références aux spécifications officielles et, comme l'OP l'a signalé, cela fonctionne même avec QuickFIX / J.
@kan je suis d'accord. Le libellé est horriblement déroutant / incohérent, et j'attends avec impatience que Christoph John obtienne des éclaircissements à ce sujet.
@Christoph John J'ai décliné votre réponse parce que je pense qu'elle est incorrecte. Si vous obtenez des éclaircissements de la communauté commerciale FIX qui prend en charge votre réponse, veuillez mettre à jour votre réponse avec les informations pertinentes, et je changerai mon vote négatif en un vote positif (en supposant que StackOverflow le permette). QuickFIX / J n'est qu'une des nombreuses implémentations de FIX; Je connais deux autres implémentations avec lesquelles le dictionnaire de données de kan ne fonctionnerait pas (l'une est un moteur FIX interne qui génère un mauvais code C ++ invalide, et l'autre est un compilateur de dictionnaire de données FIX non encore publié que j'ai développé).
@CiaranMcHale, j'ai finalement trouvé le temps de mettre à jour ma réponse. Il s'est avéré que vous aviez raison et j'ai mal compris le paragraphe du document de spécification de la valeur de balise. Cependant, j'ai compilé quelques informations et j'espère qu'elles seront néanmoins utiles.
Merci d'avoir fourni cette mise à jour. StackOverflow m'a permis de changer mon vote défavorable en vote positif. @kan Je vous suggère d'accepter la réponse mise à jour de Christoph John, car elle fournit un raisonnement utile pour expliquer la restriction et la formulation confuse dans la spécification.
Merci @CiaranMcHale, je l'apprécie vraiment.