Imported from previous forum
[ original email was from Colin Cullen - colin.cullen@us.icap.com ]
I wonder if someone could enlighten me regarding field ordering requirements within FIX messages? The FIX Protocol 5.0 docs (what I am currently using) speaks to field order only in regard to the detailed documentation for Repeating Groups (VOL.1), where it says little about field ordering except for the fact that the first field in the repeating group is always required (because it is used as the repeating group delimiter).
I have also found a number of documents that state a FIX message must be of the form with BeginString-8, BodyLength-9, and MsgType-35, being specified as the first three fields in the header section.
Neither our FIX engine vendor nor our application depend on field order.
I think it makes sense that field order requirements would be minimal given the name=value construction of the message protocol at the field level. The field name is what is needed to parse the message (including any Repeating Groups).
What is definitive with regard to this issue, and where is it stated in the specification? If there is nothing definitive then what is the prevailing consensus out there in the FIX community. Thanks to all.
FIX Messages are
- Physically divided into three sections
First Part + Second Part + Trailer
First part = FIX Version^Message Length^Message Type^
Sample : 8=FIX.X.Y^9=123^35=X^
Second Part = Series of Tag=Values^ of all other fields depending on Message type
Note :- Message type = X is MarketDataIncrementalRefresh
http://fixprotocol.org/FIXimate3.0/en/FIX.5.0SP1/body_514988.html
Trailer = CheckSum^
Sample : 10=001^
- Logically divided into three sections
Header Tags + Application Tags + Trailer
for Header and Application tag definitions refer appropriate spec at
http://fixprotocol.org/specifications/
Trailer is same in both.
Sample FIX.4.0 : Message Header topic showing as Page 10 / 72 on WordPerfect reading .doc file under heading “Session Protocol”, Thoese Tags listed below
49 SenderCompID
56 TargetCompID
115 OnBehalfOfCompID
128 DeliverToCompID
90 SecureDataLen
91 SecureData
34 MsgSeqNum
50 SenderSubID
57 TargetSubID
116 OnBehalfOfSubID
129 DeliverToSubID
43 PossDupFlag
97 PossResend
52 SendingTime
122 OrigSendingTime
I have used two - a physical division and a logical division because as per FIXProtocol other than first three tags are 8,9,35 and last tag is 10, there is no other restriction on ordering of the tags other as noted by you regarding repeating groups.
As an example of FIX Message parsing and handling, refer below for a slightly modified FIX Message (just a “little” shuffle of the tags - nothing big to worry about 
http://fixprotocol.org/discuss/read/94232f30
Another discussion thread regarding handling FIXML Message transfprmation:-
http://fixprotocol.org/discuss/read/0c88025f
MQ FIX Engine architecture:-
http://fixprotocol.org/discuss/read/6759c8ec
Some “layman” / Non FIX examples of Transport :-
http://fixprotocol.org/discuss/read/165569a1
http://fixprotocol.org/discuss/read/d5962a4b
Please feel free to post any further queries.
Regards,
K, Mahesh
I wonder if someone could enlighten me regarding field ordering
requirements within FIX messages? The FIX Protocol 5.0 docs (what I am
currently using) speaks to field order only in regard to the detailed
documentation for Repeating Groups (VOL.1), where it says little about
field ordering except for the fact that the first field in the repeating
group is always required (because it is used as the repeating group
delimiter).I have also found a number of documents that state a FIX message must be
of the form with BeginString-
8, BodyLength-9, and MsgType-35, being specified as the first three
fields in the header section.Neither our FIX engine vendor nor our application depend on field order.
I think it makes sense that field order requirements would be minimal
given the name=value construction of the message protocol at the field
level. The field name is what is needed to parse the message (including
any Repeating Groups).What is definitive with regard to this issue, and where is it stated in
the specification? If there is nothing definitive then what is the
prevailing consensus out there in the FIX community. Thanks to all.
[ original email was from Ian Richardson - ian.richardson@nyfix.com ]
The Message Format section in volume 1 of the 5.0 spec contains
“4. Fields within repeating data groups must be specified in the order that the fields are specified in the message definition within the FIX specification document. The NoXXX field where XXX is the field being counted specifies the number of repeating group instances that must immediately precede the repeating group contents.”
This has been in the fix spec since the 4.2 errata.
It should noted that many fix implementations dont implement/force this and engines often have validation/rule settings which allow support of repeating group fields in the correct or a mixed order. It is however imperative that the first repeating group element is the correct mandatory tag stated within the protocol message spec.
I wonder if someone could enlighten me regarding field ordering
requirements within FIX messages? The FIX Protocol 5.0 docs (what I am
currently using) speaks to field order only in regard to the detailed
documentation for Repeating Groups (VOL.1), where it says little about
field ordering except for the fact that the first field in the repeating
group is always required (because it is used as the repeating group
delimiter).I have also found a number of documents that state a FIX message must be
of the form with BeginString-
8, BodyLength-9, and MsgType-35, being specified as the first three
fields in the header section.Neither our FIX engine vendor nor our application depend on field order.
I think it makes sense that field order requirements would be minimal
given the name=value construction of the message protocol at the field
level. The field name is what is needed to parse the message (including
any Repeating Groups).What is definitive with regard to this issue, and where is it stated in
the specification? If there is nothing definitive then what is the
prevailing consensus out there in the FIX community. Thanks to all.