Validation
QuickFIX/J can validate messages that do not conform to the FIX specifications. This means that it will reject poorly formed messages without bothering your application-level code.
QuickFIX/J dynamically loads an XML definition file for each session, which it uses to validate if a message is of the right type, if it contains unsupported fields, or if required fields are missing.
QuickFIX/J comes with several default definition files: FIX40.xml, FIX41.xml, FIX42.xml, FIX43.xml, FIX44.xml, and FIXT11.xml. These are generated directly from the respected FIX specification documents.
Customizing Validation
The true power comes in modifying these documents or creating new ones for your specific needs. If you need to define a FIX spec for a sell-side application, you define the spec in XML and publish it to your clients.
If a specific counterparty (e.g., XYZ corp) needs special fields added to their session but you don't want to expose them to anyone else, you create XYZ.xml, load it into their specific session configuration, and keep everyone else using the normal definition file.
Skeleton of a Definition File
<fix major="4" minor="1">
<header>
<field name="BeginString" required="Y"/>
...
</header>
<trailer>
<field name="CheckSum" required="Y"/>
...
</trailer>
<messages>
<message name="Heartbeat" msgtype="0" msgcat="admin">
<field name="TestReqID" required="N"/>
</message>
...
<message name="NewOrderSingle" msgtype="D" msgcat="app">
<field name="ClOrdID" required="Y"/>
...
</message>
...
</messages>
<fields>
<field number="1" name="Account" type="CHAR" />
...
<field number="4" name="AdvSide" type="CHAR">
<value enum="B" description="BUY" />
<value enum="S" description="SELL" />
</field>
...
</fields>
</fix>
Note: The validator will not reject conditionally required fields because the rules for them are not clearly defined and are often debatable. QuickFIX/J will reject a conditionally required field when you try to pull it out in your fromApp function if you attempt to get a field that isn't present.