Fields order

, ,
1

Imported from previous forum

2

Hi,
I wonder if the order of the fields in each FIX message, which is specified in the specifications
of FIX must be kept the same in the implementation? or the FIX doesn’t care about the
order? in other words, how, the FIX engines receive the messages? the fields must keep their
order or not, to be accepted by a FIX engine ?
Thank you.
Najla.

3

Najla,

The only ordering that I am aware of is that you need to put the header before the body and the trailer after the body. The field order within those parts of the message should not matter. Hope this helps.

-Will

> Hi,
> I wonder if the order of the fields in each FIX message, which is specified in the specifications
> of FIX must be kept the same in the implementation? or the FIX doesn’t care about the
> order? in other words, how, the FIX engines receive the messages? the fields must keep their
> order or not, to be accepted by a FIX engine ?
> Thank you.
> Najla.
>

4

[ original email was from Ian Orford - ian.orford@dresdnerkb.com ]
But as previously discussed (See thread "Message format"), this has only been made clear in version 4.2. Prior to that, it was rather ambiguous.

If you are writing a FIX engine, the general advice is to try to create messages with tags in header-body-trailer order, but to be able to receive messages with tags in any order (with the exception of tgs 8, 9, 35 and 10)

Ian

> Najla,
>
> The only ordering that I am aware of is that you need to put the header before the body and the trailer after the body. The field order within those parts of the message should not matter. Hope this helps.
>
> -Will
>
> > Hi,
> > I wonder if the order of the fields in each FIX message, which is specified in the specifications
> > of FIX must be kept the same in the implementation? or the FIX doesn’t care about the
> > order? in other words, how, the FIX engines receive the messages? the fields must keep their
> > order or not, to be accepted by a FIX engine ?
> > Thank you.
> > Najla.
> >
>

5

Hi

A quick query about repeating fields, if a block is repeated.

Assume there is a repeating block like:

numSymbols
Symbol
SymbolType

Do the fields in the repeating block have to be in the order in the spec. ie is the following valid?

numSymbols=2
SymbolType=FUT
Symbol=GSK
Symbol=RTR
SymbolType=OPT

Thanks

6

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Assume there is a repeating block like:
>
> numSymbols
> Symbol
> SymbolType
>
> Do the fields in the repeating block have to be in the order in the spec. ie is the following valid?
>
> numSymbols=2
> SymbolType=FUT
> Symbol=GSK
> Symbol=RTR
> SymbolType=OPT

That is invalid.

One of the exceptions to the ordering rule is that repeating groups must appear in the order which they are defined in the spec.

Further, most if not all repeating groups are constructed such that one field is going to be conditionally required for all repetitions, and that field is required to be first in the repeating group. This allows you to use it as a delimiter for parsing.

7

[ original email was from John Hardman - yiq12@dial.pipex.com ]
Most aspects of field ordering are clearly described in the 4.2 specification (I have copied the main bit below). However, there are two requirements not listed in the current 4.2 specification that should appear in the forthcoming errata, namely;

(a) "Length" fields must appear before the related "data" fields. I believe the errata will state that each "length" field must IMMEDIATELY precede the related "data" field.
(b) Where repeating groups are used the "count" or "number" field specifying how many repeats occur will IMMEDIATELY precede the first instance of the group.

The following is the excerpt from the 4.2 specification.

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:

  1. General message format is composed of the standard header followed by the body followed by the standard trailer.
  2. The first three fields in the standard header are BeginString (tag #8) followed by BodyLength (tag #9) followed by MsgType (tag #35).
  3. The last field in the standard trailer is the CheckSum (tag #10).
  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.
    If the repeating group is used, the first field of the repeating group is required. This allows implementations of the protocol to use the first field as a "delimiter" indicating a new repeating group entry.

Regards,

John Hardman.

> Hi,
> I wonder if the order of the fields in each FIX message, which is specified in the specifications
> of FIX must be kept the same in the implementation? or the FIX doesn’t care about the
> order? in other words, how, the FIX engines receive the messages? the fields must keep their
> order or not, to be accepted by a FIX engine ?
> Thank you.
> Najla.
>