FIX Parser

The FIX Parser transforms a raw message stream (bytes or string) into a FixMessage data structure which is suitable for querying the required information from the message.

An object of the FixParser class does not need a FIX Data Dictionary for parsing simple messages. However, a FIX Data Dictionary is essential for parsing:

• Custom messages.
• Messages having custom fields or custom enumerations.
• Messages having Repeating Group fields.
• Messages having data type fields.

FF.FIX Engine also allows to create FixParserHint objects which:

• Provide the relevant information for successful parsing of messages and enable parsing in the presence or absence of a FIX Data Dictionary.
• Force the FixParser object to ignore certain default validations. It is useful to deal with specific needs.

::FAQ::

1. What is the role of the FixParser class? How do I parse a simple FIX Message?
2. How do I specify a FIX Data Dictionary in FixParser objects?
3. How do I specify FixParserHint objects for parsing complex FIX Messages?
4. Which important public methods are available on FixParser objects?
5. How I parse a FIX Message with Repeating Groups?
6. How do I parse a FIX Message having data type fields?
7. How do I parse a FIX Message string that includes a binary or encoded data as field values?

The FixParser class in the FF.Fix.Core.Message namespace offers fast and powerful parsing of a FIX Message stream resulting into a FixMessage object.

The FixParser object can parse simple FIX Messages. However, it requires more inputs like FixDataDictionary and FixParserHint objects to deal with complexities like:

• Custom fields.
• Custom messages.
• Repeating Groups.
• Data type fields.

For example, the code for parsing a simple FIX Message string is:

The FixParser constructor in the above example represents a default FixParser object constructor. It takes only the Raw Message string (rawFIXMessage) as input.

The FixParser object created using the default constructor:

• Checks the presence and correct order of the mandatory fields BeginString (tag 8), BodyLength (tag 9) and MsgType (tag 35).
• Validates the value of the BodyLength field.
• Checks the presence of the CheckSum field (tag 10) as the last field of the FIX Message and validates its value.
• Checks the presence of the mandatory header fields SenderCompID (tag 49), TargetCompID (tag 56), and MsgSeqNum (tag 34).

The FixParser object throws an error on violation of any of the above conditions.

For parsing complex messages, a constructor for FixParser objects should include a FIX Data Dictionary as inputs. Such constructor is given below:

For example:

The FixParserHint class in the FF.Fix.Core.Message namespace includes useful hints and information about Repeating Groups fields, Data type fields and custom Header fields. You can also override certain default validations through these objects, as required. Different constructors for FixParserHint objects are:

• Constructor 1: For declaring Header fields.

  FixParserHint(int[] headerFields)

  It initializes a new instance of FixParserHint with the specified FIX Message Header tags. For example, to create a FixParserHint object that informs the parser about custom Header fields at tag 5001 and 5002, the code is:

  //Create a FixParserHint object for new Header fields.
  FixParserHint fixParserHint = new FixParserHint(new int[]{5001, 5002});

  //Create a new FixParser object.
  FixParser fixParser = new FixParser(originalRawFixMessage, fixDataDictionary, fixParserHint);

• Constructor 2: For declaring Header fields, Data type fields and Repeating Group fields.

  FixParserHint(int[] headerFields, MsgDataTypeFieldInfo msgDataTypeFieldInfo, MsgRepeatingGroupFieldInfo msgRepeatingGroupFieldInfo)

  It initializes a new instance of FixParserHint object with the following information:

  • Header fields: All custom fields expected to appear in message Headers.
  • Data type fields: All Data type fields that may appear in the Body parts of different messages. The MsgDataTypeFieldInfo class includes the information about Data type fields in different message types.
  • Repeating Group fields: All the Repeating Group fields that may appear in the Body parts of different messages. The MsgRepeatingGroupFieldInfo class provides the information about Repeating Group fields in different message types.

  For example, create a FixParserHint object to inform the parser that:

  • The News message (MsgType = B) shall contain the Data type fields RawData (tag 96), EncodedText (tag 355) and EncodedHeadline (tag 359).
  • The MarketDataIncrementalRefresh message (MsgType = X) shall include the Repeating Group field NoMDEntries (tag 268) and the tag numbers of fields under it would be 79, 69, 6, 70 and 71 respectively.

  The code for this requirement is:

  /*Create the msgDataTypeFieldInfo object, which contains the information that tags 96, 355 and 359 are the Data type fields in the message type B. The AddDataTypeFieldInfo method enables you to add information on Data type fields across several message types into the same MsgDataTypeFieldInfo object.*/
  MsgDataTypeFieldInfo msgDataTypeFieldInfo = new MsgDataTypeFieldInfo();
  msgDataTypeFieldInfo.AddDataTypeFieldInfo(FixMessageTypes.News_B, new int[]{359, 355, 96});

  /*Create the repeatingGroupFieldInfo object, which contains the information that:
  [1] Tags 79, 69, 5, 70 and 71 occur as a group of fields.
  [2] These fields occur in each group and in the same order.
  [3] The NumInGroup field at tag 268 specifies the number of group of fields that repeat after it. */
  RepeatingGroupFieldInfo repeatingGroupFieldInfo = new RepeatingGroupFieldInfo(268, new int[]{79, 69, 5, 70, 71});

  /*Create a msgRepeatingGroupFieldInfo object that shall contain information about Repeating Group fields in a specific message type. */
  MsgRepeatingGroupFieldInfo msgRepeatingGroupFieldInfo = new MsgRepeatingGroupFieldInfo();

  /*Specify that the msgRepeatingGroupFieldInfo object shall contain Repeating Group fields under Tag 268 in message type X. The AddMsgRepeatingGroupInfo method enables you to add information on Repeating Group fields across several message types into the same MsgRepeatingGroupFieldInfo object. */
  msgRepeatingGroupFieldInfo.AddMsgRepeatingGroupInfo(FixMessageTypes.MarketData_IncrementalRefresh_X, repeatingGroupFieldInfo);

  /*Create a FixParserHint object for Data type fields and Repeating Group fields in several message types. Note that the null value for headerFields array indicates that there are no declarations for the same.*/
  FixParserHint fixParserHint = new FixParserHint(null, msgDataTypeFieldInfo, msgRepeatingGroupFieldInfo);

  //Create a new FixParser object.
  FixParser fixParser = new FixParser(originalRawFixMessage, fixDataDictionary, fixParserHint);

• Constructor 3: For declaring Header fields, Data type fields and Repeating Group fields and ignoring certain validations.

  FixParserHint(int[] headerFields, MsgDataTypeFieldInfo msgDataTypeFieldInfo, MsgRepeatingGroupFieldInfo msgRepeatingGroupFieldInfo, bool ignoreBodyLengthValidation, bool ignoreCheckSumValidation, bool ignoreHeaderRequiredFldValidation)

  It initializes a new instance of FixParserHint object with the following information:

  • Header fields: All custom fields expected to appear in message Headers.
  • Data type fields: All Data type fields that may appear in the Body part of different messages. The MsgDataTypeFieldInfo class includes the information about Data type fields in different message types.
  • Repeating Group fields: All the Repeating Group fields that may appear in the Body part of different messages. The MsgRepeatingGroupFieldInfo class provides the information about Repeating Group fields in different message types.
  • ignoreBodyLengthValidation: A boolean parameter that tells the parser whether to validate or ignore the BodyLength field (tag 9) during parsing.
  • ignoreCheckSumValidation: A boolean parameter that tells the parser whether to validate or ignore the CheckSum field (tag 10) during parsing.
  • ignoreHeaderRequiredFldValidation: A boolean parameter that tells the parser whether the validation of the required (mandatory) Header fields shall be ignored during parsing.

  For example, refer to Example for the Constructor 2 above. In addition to the cited requirements, assume that your application is creating and validating the message before sending. It is then essential to ignore the validation of tag 10 because it is inserted automatically before sending the message. You may wish to ignore the validation of the BodyLength field as the message is not yet final. Further you wish to validate the presence of all mandatory Header fields. The required code for this purpose would be:

  /* The code for creating msgRepeatingGroupFieldInfo and msgDataTypeFieldInfo objects is same as in Example for the Constructor 2.*/

  /*Create a FixParserHint object for Data type fields and Repeating Group fields in several message types. Note that the null value for headerFields array indicates that there are no declarations for the same.*/
  FixParserHint fixParserHint = new FixParserHint(null, msgDataTypeFieldInfo, msgRepeatingGroupFieldInfo, true, true, false);

  //Create a new FixParser object.
  FixParser fixParser = new FixParser(originalRawFixMessage, fixDataDictionary, fixParserHint);

To parse a FIX Message stream having a Repeating Group, you require to provide an appropriate FixParserHint object containing the details about the Repeating Group field. For example:

To parse a FIX Message stream having Data type fields, you have to provide an appropriate FixParserHint object containing the details about the Data type fields.

For example: A FIX Message contains the Body field RawData (tag 96). It is a Data type field with value Hello|World. The two words Hello and World are separated by a <SOH> character, shown by '|'.

To parse this message successfully, the code would be as follows:

If a FIX Message stream contains a binary or encoded data, the FixParser object takes a stream of byte data for successful parsing.

See the following steps for verification:

1. Take some rawFixMessage string, parse it and obtain a FixMessage structure from it with the name fixMessage1.
2. The fields at tag 89, 91 and 96 contain encoded data. Tag 89 is the Signature field in the Trailer. Tag 91 is the Header field SecureData. Tag 96 is the Body field RawData. Include these fields in the message structure fixMessage1.
3. After this, extract the modified message in the fixMessage1 structure as a byte array having the name bFixMessage1.
4. Parse bFixMessage1 and obtain another FixMessage structure from it with the name fixMessage2.
5. The fixMessage2 structure is obtained after parsing a message having encoded fields. Get the FIX Message as a byte array with name bFixMessage2 from the fixMessage2 structure.
6. Compare bFixMessage1 with bFixMessage2. The comparison of the two byte arrays should return a true value, as they must be identical. This is a test that verifies that the encoded messages are successfully parsed.

The code for these steps is:

The identifier result returns the TRUE value. It means bFixMessage1 = bFixMessage2. This confirms the successful parsing of encoded fields.