QuickFIX/J User Manual


QuickFIX will validate and reject any messages that do not conform to the FIX specifications. This means that it will reject any poorly formed messages without bothering you at the application level. But there is an extra piece to validation. QuickFIX can also dynamically load an XML definition file for each session which it will use to validate if a message is of the right type, if it contains unsupported fields, if required fields are missing etc... And it will do this all without you needing to do any extra work at the application level.

QuickFIX comes with several definition files. These are FIX40.xml, FIX41.xml, FIX42.xml, FIX43.xml and FIX44.xml. These are directly generated off their respected fix specification documents. But the power comes in modifying these documents or creating new ones for your specific needs.

If, for instance, you need to define a FIX spec for a sell side application. Why not define the spec in XML and then just publish the XML file to your clients! Not only is your FIX spec fully documented in a machine and human readable format, but you can guarantee that the documentation is 100% accurate because it is actually defining and not just reflecting reality.

And if XYZ corp needs some special fields added to their session but you don't want to expose them to anyone else, fine. Create XYZ.xml, load it up with the session and keep everyone else using the normal definintion file. Now XYZ can send their user defined fields but they will be rejected for anyone else.

The skeleton of a definition file looks like this.

  <fix major="4" minor="1">
      <field name="BeginString" required="Y"/>
      <field name="CheckSum" required="Y"/>
      <message name="Heartbeat" msgtype="0" msgcat="admin">
        <field name="TestReqID" required="N"/>
      <message name="NewOrderSingle" msgtype="D" msgcat="app">
        <field name="ClOrdID" required="Y"/>
      <field number="1" name="Account" type="CHAR" />
      <field number="4" name="AdvSide" type="CHAR">
       <value enum="B" description="BUY" />
       <value enum="S" description="SELL" />
       <value enum="X" description="CROSS" />
       <value enum="T" description="TRADE" />

The validator will not reject conditionally required fields because the rules for them are not clearly defined and are often debatable. QuickFIX will reject a conditonally required field when you try to pull it out in your fromApp function if you try to get a field that is not there.