Imported from previous forum
Hi,
I’m trying to write the FIXatdl specification for a strategy that takes values from a repeating group.
The name of the repeating group is not TotNoOrders[68] or NoLegs[555], but the specification states that FIXatdl only supports one repeating group with either of these two names or the repeating group NoStrategyParameters[957].
To use FIXatdl to construct FIX messages, I would need to define such a repeating group and possibly more than one.
Is this possible?
Thanks, David
I’m trying to write the FIXatdl specification for a strategy that takes values from a repeating group.
The name of the repeating group is not TotNoOrders[68] or NoLegs[555], but the specification states that FIXatdl only supports one repeating group with either of these two names or the repeating group NoStrategyParameters[957].
To use FIXatdl to construct FIX messages, I would need to define such a repeating group and possibly more than one.
Can you elaborate with an example of the repeating group content you’re describing (and why it needs to be part of a user-defined repeating group)?
I think that David is facing a case where the parameter’s type is an array (correct if I’m wrong David). In that case we need a user-defined repeating group to hold all values that the client may send or the other solution is to use a complex syntax of the parameter value (something like JASON) which could be a little bit tricky to be held by both parties.
I’m trying to write the FIXatdl specification for a strategy that takes values from a repeating group.
The name of the repeating group is not TotNoOrders[68] or NoLegs[555], but the specification states that FIXatdl only supports one repeating group with either of these two names or the repeating group NoStrategyParameters[957].
To use FIXatdl to construct FIX messages, I would need to define such a repeating group and possibly more than one.
Can you elaborate with an example of the repeating group content you’re describing (and why it needs to be part of a user-defined repeating group)?
Yes, it is a repeating group just like NoStrategyParameters but with fixtag 11002. I would need to sepcify 11004=3 for example, but within the repeating group.
11002=2{11003=1|11004=1|11005=1|11006=55.6}
I think that David is facing a case where the parameter’s type is an array (correct if I’m wrong David). In that case we need a user-defined repeating group to hold all values that the client may send or the other solution is to use a complex syntax of the parameter value (something like JASON) which could be a little bit tricky to be held by both parties.
I’m trying to write the FIXatdl specification for a strategy that takes values from a repeating group.
The name of the repeating group is not TotNoOrders[68] or NoLegs[555], but the specification states that FIXatdl only supports one repeating group with either of these two names or the repeating group NoStrategyParameters[957].
To use FIXatdl to construct FIX messages, I would need to define such a repeating group and possibly more than one.
Can you elaborate with an example of the repeating group content you’re describing (and why it needs to be part of a user-defined repeating group)?
Yes, it is a repeating group just like NoStrategyParameters but with fixtag 11002. I would need to sepcify 11004=3 for example, but within the repeating group.
11002=2{11003=1|11004=1|11005=1|11006=55.6}
I meant:
11002=1{11003=1|11004=1|11005=1|11006=55.6}
I think that David is facing a case where the parameter’s type is an array (correct if I’m wrong David). In that case we need a user-defined repeating group to hold all values that the client may send or the other solution is to use a complex syntax of the parameter value (something like JASON) which could be a little bit tricky to be held by both parties.
I’m trying to write the FIXatdl specification for a strategy that takes values from a repeating group.
The name of the repeating group is not TotNoOrders[68] or NoLegs[555], but the specification states that FIXatdl only supports one repeating group with either of these two names or the repeating group NoStrategyParameters[957].
To use FIXatdl to construct FIX messages, I would need to define such a repeating group and possibly more than one.
Can you elaborate with an example of the repeating group content you’re describing (and why it needs to be part of a user-defined repeating group)?
Yes, it is a repeating group just like NoStrategyParameters but with fixtag 11002. I would need to sepcify 11004=3 for example, but within the repeating group.
I meant:
11002=1{11003=1|11004=1|11005=1|11006=55.6}
You say “just like NoStrategyParameters but with fixtag 11002”. You provided a fragment of a repeating group (albeit having only one repeating instance) but without any elaboration regarding what its tags are or why you need a repeating group. At first I thought you were mapping ‘an alternative’ set of tags to 957, {958, 959, 960}, but that does not appear to be the case. Also, a tag in the 11000 range is defined by the spec as inter-firm only (eg used internally). If this is one internal system communicating with another, then perhaps you could ‘enhance’ the internal systems involved.
Yes, it is a repeating group just like NoStrategyParameters but with fixtag 11002. I would need to sepcify 11004=3 for example, but within the repeating group.
I meant:
11002=1{11003=1|11004=1|11005=1|11006=55.6}You say “just like NoStrategyParameters but with fixtag 11002”. You provided a fragment of a repeating group (albeit having only one repeating instance) but without any elaboration regarding what its tags are or why you need a repeating group. At first I thought you were mapping ‘an alternative’ set of tags to 957, {958, 959, 960}, but that does not appear to be the case. Also, a tag in the 11000 range is defined by the spec as inter-firm only (eg used internally). If this is one internal system communicating with another, then perhaps you could ‘enhance’ the internal systems involved.
As far as I can tell, User Defined Fields in FIX can be implemented as repeating groups. It is possible that a strategy therefore would need a parameter supplied in such a repeating group UDF.
This parameter may need to be validated within fixatdl or if fixatdl was used to construct a fix message for the strategy, it would need to know to construct a repeating group for this parameter.
This however does not seem possible within the fixatdl specification.
Is this true?
This requirement has never been considered for FIXatdl. User-defined repeating groups are always discouraged when communicating with an outside entity since many FIX engines don’t provide adequate support for them. However, I can see how user-defined repeating groups (UDRGs?) can be useful for internal communications. Although I don’t think FIX was ever intended to be a generic data-encoding mechanism. (Isn’t that best left for XML, JSON, etc?)
So I’m not sure it can be done in FIXatld 1.1. If you can find a way using the schema files (as they now exist!) then please let those in this forum know how you plan on going about it - you’ll be breaking new ground.
As far as the requirements go… When adding support for repeating groups in FIXatdl we focused on: (1) multi-leg orders where custom tags are defined within the LegOrdGrp ; (2) List orders where custom tags are defined within the ListOrdGrp; and (3) Basket orders where custom tags are defined at the root level and the orders are delivered as multiple NewOrderSingle messages linked by a common basket ID. (Many pairs algos do this.)
For each of these cases we sought to support sub-cases where:
a) the number of legs/ orders is established prior to order entry
b) the number of legs/orders can be unbounded and is defined at the time of order entry
c) a custom tag must have the same value in each group in which it appears (Think of the user being presented with one GUI control and the value entered in that control gets propagated to all leg orders or list orders.)
d) a custom tag can have different values within each group it appears. (In this case the user would be presented with a GUI control for each leg/order.)
This comes to 12 use cases. I would be great if we had 12 examples to provide. We are scheduled to revisit repeating group support when we discuss the next release of FIXatdl. We’ll add UDRGs to the list of things to consider.
If you have any toughts on how a UDRG could be defined
-Greg