1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<title>Validation</title>
<H1>Validation</H1>
</head>
<body>
<p>
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.
</p>
<p>
QuickFIX comes with several definition files. These are <B>FIX40.xml</B>, <B>FIX41.xml</B>,
<B>FIX42.xml</B>, <B>FIX43.xml</B> and <B>FIX44.xml</B>. 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.
<p>
<p>
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 <B>defining</B> and not just reflecting reality.
</p>
<p>
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.
</p>
<p>
The skeleton of a definition file looks like this.
</p>
<PRE><B>
<fix type="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" />
<value enum="X" description="CROSS" />
<value enum="T" description="TRADE" />
</field>
...
</fields>
</fix>
</PRE></B>
<p>
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 <B>fromApp</B> function if you try to get a field that is not there.
</body>
</html>
|
