Re: field ordering
Mahesh Kumaraguru <>
10 Apr 2008 11:09PM ET
FIX Messages are
1) 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^
2) 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 <header fields>
<trailer fields> 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.
