|
General Q/A
< Previous Next >
Re: field ordering
Colin Cullen / ICAP <>
11 Apr 2008 1:30PM ET Mahesh,
Thanks for your lucid ecplaination and for the links to your detailed treatment on this subject. I recommend the discussions you point to anybody interested in field ordering and/or message construction.
Thanks.
Colin
> 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.
Re: field ordering
Colin Cullen / ICAP 11 Apr 2008 1:30PM ET
|
