Imported from previous forum
Hi All,
Recently I encountered some query about TAG 122 which is a header message and will be included during resend messages session. I noticed that this TAG might not be in sequence like from the beginning of the message, starting after the SenderCompID/TargetCompID etc. The TAG seem to appear in the middle of the body message or at the end of the messages. Is there any way we can recognise which is a header TAG or body TAGs etc?
Do we have any FIX protocol info that will indicate which TAG should come first or before? Thanks in advance!
Only the first few fields of the header must be in sequence, see FIX Spec Volume 1. “The first three fields in the standard header are BeginString (tag #8) followed by BodyLength (tag #9) followed by MsgType (tag #35).”
Also “General message format is composed of the standard header followed by the body followed by the standard trailer.”
Fields of the header thus must not appear in the body. The standard header fields are identified in the respository as MsgID 1024 in MsgContents.xml. It is also defined in FIXimate as component 1024 which you can find in Comp1024.html.
Regards,
Hanno.
Hi All,
Recently I encountered some query about TAG 122 which is a header
message and will be included during resend messages session. I noticed
that this TAG might not be in sequence like from the beginning of the
message, starting after the SenderCompID/TargetCompID etc. The TAG seem
to appear in the middle of the body message or at the end of the
messages. Is there any way we can recognise which is a header TAG or
body TAGs etc? Do we have any FIX protocol info that will indicate which
TAG should come first or before? Thanks in advance!
Hanno,
After the first three fields of a FIX.4.4 message
8=FIX.4.4^9=BodyLength^35=MessageType^
there is no mention of positional field requirements for any other tags. Isnt the remaining FIX message a “bag of Tags” ?
Regards,
K. Mahesh
Only the first few fields of the header must be in sequence, see FIX
Spec Volume 1. “The first three fields in the standard header are
BeginString (tag #8) followed by BodyLength (tag #9) followed by MsgType
(tag #35).”Also “General message format is composed of the standard header followed
by the body followed by the standard trailer.”Fields of the header thus must not appear in the body.
No, all fields within a message are either in the header, the body or the trailer, i.e. you have 3 groups of fields that have to come in this sequence. Within these main groups, only the header and trailer prescribes the sequencing of a subset of the fields as mentioned below (and Checksum has to be last field of trailer).
You are right in that the tags in the body do not have to follow a sequence but I would see it as best practice to follow the sequence defined in the spec. That sequence follows a semantic and FIX users should adhere to FIX semantics. Technically, it does not matter but I find it helpful when reading an interface specification. A programmer has to come up with some sequence so why not just take the standard one. After all, it is available in the FIX repository (MsgContents.html, tag ).
With FIX 5, I believe another field (ApplVerID) becomes required in position four if application versioning is being used.
Repeating groups also have sequencing rules for the tag=value syntax which are actually quite strict to enable parsing. First field is required and the rest have to appear in the pre-defined sequence.
Regards,
Hanno.
Hanno,
After the first three fields of a FIX.4.4 message
8=FIX.4.4^9=BodyLength^35=MessageType^
there is no mention of positional field requirements for any other tags.
Isnt the remaining FIX message a “bag of Tags” ?Regards,
K. MaheshOnly the first few fields of the header must be in sequence, see FIX
Spec Volume 1. “The first three fields in the standard header are
BeginString (tag #8) followed by BodyLength (tag #9) followed by
MsgType (tag #35).”Also “General message format is composed of the standard header
followed by the body followed by the standard trailer.”Fields of the header thus must not appear in the body.
[ original email was from John Prewett - jprewett@lavatrading.com ]
Also not forgetting the “length” fields that must immediately precede the tags whose contents are binary data.
Example: SecureDataLen(tag 90) must be immediately followed by SecureData(tag 91).
Hanno, John,
As of FIX.5.0, the following Standard Header fields must be ordered as:
BeingString (8) - 1st position (Mandatory)
BodyLength (9) - 2nd position (Mandatory)
MessageType (35) - 3rd position (Mandatory)
SenderCompID(49) - 4th position (Mandatory)
TargetCompID(56) - 5th position (Mandatory)
ApplVerID (1128) - must be 6th position if used
You are right regarding repeating groups and Length fields.
But still my question is if the following message is received
8=FIX.4.4^9=123^35=D^55=MAX^48=ABCD12345678^22=1^11=98765^54=1^60=20090305-11:02:03^49=MAHESH^34=123^38=100^52=20090305-11:03:04^40=1^56=FPL^10=123^
Would it be treated as a malformed FIX.4.4 message because the header tags (49, 34, 56, 52) are intermixed with body tags? I fully agree “A programmer has to come up with some sequence so why not just take the standard one.”
Regards,
K. Mahesh
Hanno, John,
As of FIX.5.0, the following Standard Header fields must be ordered as:
BeingString (8) - 1st position (Mandatory) BodyLength (9) - 2nd position
(Mandatory) MessageType (35) - 3rd position (Mandatory) SenderCompID(49)
- 4th position (Mandatory) TargetCompID(56) - 5th position (Mandatory)
ApplVerID (1128) - must be 6th position if usedYou are right regarding repeating groups and Length fields.
But still my question is if the following message is received
IX.4.4^9=123^35=D^55=MAX^48=ABCD12345678^22=1^11=98765^54=1^60=20090305-
11:02:03^49=MAHESH^34=123^38=100^52=20090305-
11:03:04^40=1^56=FPL^10=123^Would it be treated as a malformed FIX.4.4 message because the header
tags (49, 34, 56, 52) are intermixed with body tags? I fully agree “A
programmer has to come up with some sequence so why not just take the
standard one.”Regards,
K. Mahesh
I can say with certainty that QuickFIX will complain.
Practically speaking, I remember reading in the FIX documentation where it stated that header and body tags should not be intermixed.
Regards.
Jay
[ original email was from John Prewett - jprewett@lavatrading.com ]
I believe that is spelled out very clearly in the FIX.4.4 specification volume 1:
Except where noted, fields within a message can be defined in any sequence (Relative position of a field within a message is inconsequential.) The exceptions to this rule are:
- General message format is composed of the standard header followed by the body followed by the standard trailer.
<other rules omitted for brevity as they aren’t pertinent to this issue>
JohnP
Jay,
Could you point me to the FIX documentation which stated “header and body tags should not be intermixed.”
I have written a FIX broker simulator in Java which tests three different Buy side systems (two of them in FIX.4.2 and one in FIX.4.0) and none of them reject messages with intermixed header and body tags as incorrect.
John,
Since FIX.4.0 “The general format of a FIX message is a standard header followed by the message body fields and terminated with a standard trailer.
Each message is constructed of a stream of = fields.
Except where noted, fields within a message can be defined in any sequence (i.e. relative position of a field within a record is inconsequential); exceptions are explicitly defined otherwise (certain header fields and fields within repeating data groups).”
So FIX.4.4 introduced no new Field ordering requirements compared to FIX.4.0. Upto FIX.4.4 for 8, 9 and 35, there is explicit mention as first, second and third fields of “every” FIX message, but there is no such mention for any other fields.
Regards,
K. Mahesh
Jay,
Could you point me to the FIX documentation which stated “header and
body tags should not be intermixed.”I have written a FIX broker simulator in Java which tests three
different Buy side systems (two of them in FIX.4.2 and one in FIX.4.0)
and none of them reject messages with intermixed header and body tags as
incorrect.John,
Since FIX.4.0 “The general format of a FIX message is a standard header
followed by the message body fields and terminated with a standard
trailer. Each message is constructed of a stream of =
fields. Except where noted, fields within a message can be defined in
any sequence (i.e. relative position of a field within a record is
inconsequential); exceptions are explicitly defined otherwise (certain
header fields and fields within repeating data groups).”So FIX.4.4 introduced no new Field ordering requirements compared to
FIX.4.0. Upto FIX.4.4 for 8, 9 and 35, there is explicit mention as
first, second and third fields of “every” FIX message, but there is no
such mention for any other fields.Regards,
K. Mahesh
I don’t think there’s an explicit mention that the tags shouldn’t be mixed, but you can derive it from these three points:
-
Standard header definition fields (for example, FIX 4.2 with Errata 20010501, pp 22-23)
-
The quote you gave to John above (“The general format of a FIX message is a standard header followed by the message body fields and terminated with a standard trailer”).
-
A field is either a header field or a body field. I don’t have a reference for this - you can either find the reference or check each message type in the spec
Thus if I was writing a really pedantic fix engine, I could impose the following ordering:
8, 9, 35, {other header fields - CompIDs, etc}
{body fields}
{trailer fields}
So whilst there is no requirement to order the remaining header fields after tag 35, the first one that I encounter that is a non-header field implies that the header has been completely read. Any subsequent header fields will cause me to reject the message.
As mentioned previously, the most sensible approach seems to be to adhere to the above when sending messages and allow non-conformance on receiving messages (repeating groups notwithstanding).
Could you point me to the FIX documentation which stated “header and
body tags should not be intermixed.”
“FIX Session-level Test Cases and Expected Behaviors” dated July 10, 2001 is available via http://fixprotocol.org/specifications/TechDoc-FIXSession and is part of Volume 2 within FIX specs >= 4.3. Test Case 14-g:
"g. Receive a message in which the following is not true: Standard Header fields appear before Body fields which appear before Standard Trailer fields.
- Send Reject (session-level) message referencing incorrect message structure header+body+trailer
- Increment inbound MsgSeqNum
- Generate an “error” condition in test output.
"
Note also for the discussion that the spec has clearly stated that CheckSum must be the last field in the message.
[ original email was from John Prewett - jprewett@lavatrading.com ]
> I have written a FIX broker simulator in Java which tests three
different Buy side systems (two of them in FIX.4.2 and one in FIX.4.0)
and none of them reject messages with intermixed header and body tags
as incorrect.
You have been lucky then.
The systems I preside over will actually accept messages where the fields are not in header/body/trailer order because we operate under the concept of:
“Be tolerant when receiving and strictly in conformance when sending”.
I’m sure our liberal policy has nothing to do with the “order flow = revenue” equation 
Nonetheless, I definitely would not recommend that anyone relies on the other end of a FIX session being anything other than in strict conformance with the standards.
If everyone follows the “Be tolerant when receiving and strictly in conformance when sending” concept, we will all be sending out strictly conforming messages and therefore not needing to be tolerant when receiving. I presume this will all come to pass shortly after I have posted this message.
Standards are a great thing.
Have a wonderful day.
JohnP
Hi All,
Recently I encountered some query about TAG 122 which is a header
message and will be included during resend messages session. I noticed
that this TAG might not be in sequence like from the beginning of the
message, starting after the SenderCompID/TargetCompID etc. The TAG seem
to appear in the middle of the body message or at the end of the
messages. Is there any way we can recognise which is a header TAG or
body TAGs etc? Do we have any FIX protocol info that will indicate which
TAG should come first or before? Thanks in advance!
BeginString(8) and Bodylength(9) have to come first in sequence. Because some implementation may read them in first without verify other message contents. With whole FIX message read in buffer, any tag message can be found by a string scanning. For a faster approach, the whole FixMessage can be read in by two socket read.
FixExpress finds message header first, the read in who Fix message.
FixExpress is at A Person to Person Business Site.
Good luck,
peng