1. The core: QuickFix.dll
2. The message definitions for the FIX version(s) you’re using, which will be one or more of:

• QuickFix.FIX40.dll
• QuickFix.FIX41.dll
• QuickFix.FIX42.dll
• QuickFix.FIX43.dll
• QuickFix.FIX44.dll
• QuickFix.FIX50.dll
• QuickFix.FIX50SP1.dll
• QuickFix.FIX50SP2.dll

public class MyQuickFixApp: IApplication
{
    public void FromApp(Message msg, SessionID sessionID) { }
    public void OnCreate(SessionID sessionID) { } 
    public void OnLogout(SessionID sessionID) { }
    public void OnLogon(SessionID sessionID) { }
    public void FromAdmin(Message msg, SessionID sessionID) { }
    public void ToAdmin(Message msg, SessionID sessionID) { }
    public void ToApp(Message msg, SessionID sessionID) { }
}

Putting it all together, we implement the Application interface then instantiate an Acceptor:

using QuickFix;
using QuickFix.Logger;
using QuickFix.Store;

public class MyQuickFixApp : IApplication
{
    public void FromApp(Message msg, SessionID sessionID) { }
    public void OnCreate(SessionID sessionID) { }
    public void OnLogout(SessionID sessionID) { }
    public void OnLogon(SessionID sessionID) { }
    public void FromAdmin(Message msg, SessionID sessionID) { }
    public void ToAdmin(Message msg, SessionID sessionID) { }
    public void ToApp(Message msg, SessionID sessionID) { }
}

public class MyApp
{
    static void Main(string[] args)
    {
        SessionSettings settings = new SessionSettings(args[0]);
        IApplication myApp = new MyQuickFixApp();
        IMessageStoreFactory storeFactory = new FileStoreFactory(settings);
        ILogFactory logFactory = new FileLogFactory(settings);
        ThreadedSocketAcceptor acceptor = new ThreadedSocketAcceptor(
            myApp,
            storeFactory,
            settings,
            logFactory);

        acceptor.Start();
        while (true)
        {
            System.Console.WriteLine("o hai");
            System.Threading.Thread.Sleep(1000);
        }
        acceptor.Stop();
    }
}

Please view the Receiving Messages tutorial to see how to implement type safe message callbacks. This is highly recommended.

Switching this to an Initiator is as simple as swapping out the ThreadedSocketAcceptor class for the SocketInitiator class.

The IMessageStore keeps a record of all outgoing messages for FIX session level messaging. We could implement our own store by implementing the MessageStoreFactory interface.

There are a few options for logging, with file logger probably being the most useful. We could also implement our own logger by implementing the ILogFactory interface.

Sending FIX messages in QuickFIX/N is simple:

FIX44.NewOrderSingle order = new FIX44.NewOrderSingle(
    new ClOrdID("1234"),
    new Symbol("AAPL"),
    new Side(Side.BUY),
    new TransactTime(DateTime.Now),
    new OrdType(OrdType.MARKET));

Session.SendToTarget(order, sessionID);

First, we need to learn how to direct messages with Sessions.

When sending a message, we must tell QuickFIX which Session to send it to.

All QuickFIX Sessions are identified by fields in the header of a message, usually SenderCompID, TargetCompID, and BeginString. These are specified in the config file.

SenderCompID=CONNAMARA
TargetCompID=CBOE
BeginString=FIX.4.4

There are a few patterns to gather the session. We can grab the SessionID when it is created and cache it:

private SessionID MySessionID { get; set; }
public void OnCreate(SessionID sessionID)
{
    MySessionID = sessionID;
}

We can get the SessionID when responding to an incoming message:

public void OnMessage(FIX42.ExecutionReport execution, SessionID sessionID) 
{
    ProcessExecution(execution, sessionID);
}

Or, we can construct a SessionID by matching the values from our config file:

var mySessionID = new SessionID("FIX4.4", "CONNAMARA", "CBOE");

The preferred constructor to use includes the specific FIX version and message type. We also pass in the required fields:

import QuickFix;
import QuickFix.Fields;

var order = new QuickFix.FIX44.NewOrderSingle(
    new ClOrdID("1234"),
    new Symbol("AAPL"),
    new Side(Side.BUY),
    new TransactTime(DateTime.Now),
    new OrdType(OrdType.LIMIT));

To set fields, use the message’s field properties:

order.Price = new Price(new decimal(22.4));
order.Account = new Account("18861112");

Putting it all together - creating the message, setting its required fields, setting two additional fields, using SessionID from the section above, we send the message on its way:

var order = new QuickFix.FIX44.NewOrderSingle(
    new ClOrdID("1234"),
    new Symbol("AAPL"),
    new Side(Side.BUY),
    new TransactTime(DateTime.Now),
    new OrdType(OrdType.LIMIT));

order.Price = new Price(new decimal(22.4));
order.Account = new Account("18861112");

Session.SendToTarget(order, sessionID);

The type safe way – the best way – was demonstrated above, but there are a few other ways to create messages and set fields.

Each message type has a default constructor:

var order = new QuickFix.FIX44.NewOrderSingle();
order.ClOrdID =  new ClOrdID("1234");
order.Symbol = new Symbol("AAPL");
order.Side = new Side(Side.BUY);

We have the QuickFIX C++ and QuickFIX/J style get/set methods available, which are also type safe:

order.Set(new TransactTime(DateTime.Now));
order.Set(new OrdType(OrdType.LIMIT));

For setting a field that isn’t a property of a message, use setField:

order.SetField(new Account("18861112"));

Here we create base Message class; it has no properties so SetField must be used everywhere. This style is not recommended:

var order = new QuickFix.Message();
order.Header.SetField(new MsgType("D"));
order.SetField(new ClOrdID("1234"));
order.SetField(new Symbol("AAPL"));
order.SetField(new Side(Side.BUY));
order.SetField(new TransactTime(DateTime.Now));
order.SetField(new OrdType(OrdType.LIMIT));

Receiving messages in QuickFIX/N is type safe and simple:

public void OnMessage(
    QuickFix.FIX44.NewOrderSingle order, 
    SessionID sessionID)
{
    ProcessOrder(order.Price, order.OrderQty, order.Account);
}

The best way to write an app is with the specific, strongly typed Message and Field classes, which we’ll mixin with MessageCracker. We import the MessageCracker class, inherit from it, then call Crack inside FromApp:

using QuickFix;

public class MyApplication : MessageCracker, IApplication
{
    public void FromApp(Message msg, SessionID sessionID)
    {
        Crack(msg, sessionID);
    }
    //...
}

Crack will then call the appropriate overloaded OnMessage callback. This example receives orders and security definitions:

public void OnMessage(
    QuickFix.FIX44.NewOrderSingle ord, 
    SessionID sessionID)
{
    ProcessOrder(ord.Price, ord.OrderQty, ord.Account);
}

public void OnMessage(
    QuickFix.FIX44.SecurityDefinition secDef, 
    SessionID sessionID)
{
    GotSecDef(secDef);
}

Putting it all together, a full application with type safe orders looks like this:

public class MyApplication : MessageCracker, IApplication
{
    public void OnMessage(
        QuickFix.FIX42.NewOrderSingle ord,
        SessionID sessionID)
    {
        ProcessOrder(ord.Price, ord.OrderQty, ord.Account);
    }

    protected void ProcessOrder(
        Price price,
        OrderQty quantity,
        Account account)
    {
        //...
    }

    #region Application Methods

    public void FromApp(Message msg, SessionID sessionID)
    {
        Crack(msg, sessionID);
    }
    public void OnCreate(SessionID sessionID) { }
    public void OnLogout(SessionID sessionID) { }
    public void OnLogon(SessionID sessionID) { }
    public void FromAdmin(Message msg, SessionID sessionID)
    { }
    public void ToAdmin(Message msg, SessionID sessionID)
    { }
    public void ToApp(Message msg, SessionID sessionID)
    { }

    #endregion
}

It is possible to receive message callbacks with only the base class Message.

This is not recommended - we lose the typesafe Group and Field properties and extra boilerplate logic is required:

// NOT RECOMMENDED
public class MyApplication : IApplication
{
    public void FromApp(Message msg, SessionID sessionID)
    {
        string msgType = msg.Header.GetString(Tags.MsgType);
        if (msgType.Equals(MsgType.EXECUTION_REPORT))
        {
          string account = msg.GetString(Tags.Account);
          decimal price = msg.GetDecimal(Tags.Price);
        }
    }
    // ...same Application callbacks as above
}

QuickFIX/N creates and reads repeating groups in FIX messages.

Creating groups is straightforward - instantiate the specific group class then add it to the message:

var tcr = new QuickfiFix.FIX44.TradeCaptureReport();
var sidesGrp1 = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup();
sidesGrp1.Account = new Account("Silvio");
sidesGrp1.OrderID = new OrderID("09011900");
sidesGrp1.Side = new Side(Side.BUY);

var sidesGrp2 = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup();
sidesGrp2.Account = new Account("Sven");
sidesGrp2.OrderID = new OrderID("2000");
sidesGrp2.Side = new Side(Side.BUY);

tcr.AddGroup(sidesGrp1);
tcr.AddGroup(sidesGrp2);

We can create groups inside of groups, too:

var tcr = new QuickFix.FIX44.TradeCaptureReport();
var sidesGrp = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup();
sidesGrp.Side = new Side(Side.BUY);
sidesGrp.Account = new Account("Piola");
sidesGrp.OrderID = new OrderID("09011900");
var partyIdsGrp = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup.NoPartyIDsGroup();
partyIdsGrp.PartyID = new PartyID("Nesta13");
sidesGrp.AddGroup(partyIdsGrp);
tcr.AddGroup(sidesGrp);

To read a group from a message, we use GetGroup() and supply a reference to a new group object of the appropriate type. The extracted group gets assigned to this parameter.

var sidesGrp1 = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup();
tcr.GetGroup(1, sidesGrp1);
// sidesGrp1 now has all fields populated
var sidesGrp2 = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup();
tcr.GetGroup(2, sidesGrp2);

Group indexes start at 1.

To iterate the groups, we can use a for loop with the value of the group field:

var noSidesGrp = new QuickFix.FIX44.TradeCaptureReport.NoSidesGroup();
for(int grpIndex = 1; grpIndex<= message.GetInt(Tags.NoSides); grpIndex += 1)
{
    message.GetGroup(grpIndex, noSidesGrp);
    // ...do stuff with noSidesGrp...
}

An acceptor or initiator can maintain as many FIX sessions as you would like. A FIX session is defined in QuickFix/N as a unique combination of a BeginString (the FIX version number), a SenderCompID (your ID), and a TargetCompID (the ID of your counterparty). A SessionQualifier can also be used to disambiguate otherwise identical sessions.

Each session can have several settings associated with them. Some of these settings may not be known at compile time and are therefore passed via a class called SessionSettings. SessionSettings behaves as a data dictionary that can be set and queried.

The SessionSettings class has the ability to parse settings out of any System.IO.TextReader. You can also simply pass it a filename. If you decide to write your own components (eg, storage for a particular database) you may also use this to store settings.

A settings file is set up with two types of heading; [DEFAULT] and [SESSION]. [SESSION] tells QuickFIX/N that a new Session is being defined. [DEFAULT] is a section to define settings which will be associated with sessions that don’t explicitly define them. QuickFIX/N itself will not define default values for all required settings. If you do not provide a setting that QuickFIX/N needs, it will throw a ConfigError telling you what setting is missing or improperly formatted.

Below are the settings that can be associated with a session based on the default functionality provided with QuickFIX/N, followed by an example.

• Session
• Validation
• Initiator
• Acceptor
• Socket Configuration
• Storage
• File Storage
• Logging
• SSL
• Sample Settings File

Here is a typical initiator settings file you might find in a firm that wants to connect to several ECNs.

# default settings for sessions
[DEFAULT]
FileStorePath=store
FileLogPath=log
ConnectionType=initiator
ReconnectInterval=60
SenderCompID=TW

# session definition
[SESSION]
# inherit FileStorePath, FileLogPath, ConnectionType, 
#    ReconnectInterval and SenderCompID from default
BeginString=FIX.4.1
TargetCompID=ARCA
StartTime=12:30:00
EndTime=23:30:00
HeartBtInt=20
SocketConnectPort=9823
SocketConnectHost=123.123.123.123
DataDictionary=somewhere/FIX41.xml

[SESSION]
BeginString=FIX.4.0
TargetCompID=ISLD
StartTime=12:00:00
EndTime=23:00:00
HeartBtInt=30
SocketConnectPort=8323
SocketConnectHost=23.23.23.23
DataDictionary=somewhere/FIX40.xml

[SESSION]
BeginString=FIX.4.2
TargetCompID=INCA
StartTime=12:30:00
EndTime=21:30:00
# overide default setting for RecconnectInterval
ReconnectInterval=30
HeartBtInt=30
SocketConnectPort=6523
SocketConnectHost=3.3.3.3
# (optional) alternate connection ports 
#  and hosts to cycle through on failover
SocketConnectPort1=8392
SocketConnectHost1=8.8.8.8
SocketConnectPort2=2932
SocketConnectHost2=12.12.12.12
DataDictionary=somewhere/FIX42.xml

Here is a typical acceptor settings file.

# default settings for sessions
[DEFAULT]
FileStorePath=store
FileLogPath=log
ConnectionType=acceptor
ReconnectInterval=60
SenderCompID=ARCA

# session definition
[SESSION]
# inherit FileStorePath, FileLogPath, ConnectionType, 
#  ReconnectInterval and SenderCompID from default
BeginString=FIX.4.1
TargetCompID=TW
StartTime=12:30:00
EndTime=23:30:00
HeartBtInt=20
SocketAcceptPort=9823
DataDictionary=somewhere/FIX41.xml

[SESSION]
BeginString=FIX.4.0
TargetCompID=TW
StartTime=12:00:00
EndTime=23:00:00
HeartBtInt=30
SocketAcceptPort=8323
DataDictionary=somewhere/FIX40.xml

[SESSION]
BeginString=FIX.4.2
TargetCompID=TW
StartTime=12:30:00
EndTime=21:30:00
# overide default setting for RecconnectInterval
ReconnectInterval=30
HeartBtInt=30
SocketAcceptPort=6523
# (optional) only listen for incoming connections on a specific host
SocketAcceptHost=127.0.0.1
DataDictionary=somewhere/FIX42.xml

We’ve made three QuickFIX/N example applications:

The Simple Acceptor is a barebones acceptor that prints any message it receives to the console.

The Trade Client is a command-line client that sends order messages.

The Executor listens for order messages and responds with mock execution responses.

The Trade Client and Executor can be configured to send and execute orders with each other.

Have your own app you’d like to share? Contact us!

We often connect to parties who have modified or customized the FIX protocol to fit their needs. QuickFIX/N provides us some powerful ways to deal with this problem, the easiest of which is through the Data Dictionary.

A Data Dictionary documents the protocol for a QuickFIX/N Session. When a field, group, or message is custom for a session versus the FIX specification, we change this document.

We specify data dictionary for a session in the config file:

[Session]
SenderCompID=CONNAMARA
TargetCompID=CBOE
BeginString=FIX4.2
UseDataDictionary=Y
DataDictionary=./spec/FIX4.2.xml

The XML-based document is fairly straightforoward.

A Data Dictionary defines all FIX Fields:

<fields>
  <field number="1" name="Account" type="STRING"/>
  <field number="2" name="AdvId" type="STRING"/>
  <field number="3" name="AdvRefID" type="STRING"/>
...

A Data Dictionary defines all FIX Messages:

<messages>
  <message name="Heartbeat" msgtype="0" msgcat="admin">
    <field name="TestReqID" required="N"/>
  </message>
  <message name="Logon" msgtype="A" msgcat="admin">
    <field name="EncryptMethod" required="Y"/>
    <field name="HeartBtInt" required="Y"/>
...

And a Data Dictionary defines all FIX within a Message:

<message name="Logon" msgtype="A" msgcat="admin">
  <field name="EncryptMethod" required="Y"/>
  <field name="HeartBtInt" required="Y"/>
  <field name="RawDataLength" required="N"/>
  <field name="RawData" required="N"/>
  <field name="ResetSeqNumFlag" required="N"/>
  <field name="MaxMessageSize" required="N"/>
  <group name="NoMsgTypes" required="N">
    <field name="RefMsgType" required="N"/>
    <field name="MsgDirection" required="N"/>
  </group>
</message>

Adding custom fields to existing messages

Many counterparties’ customizations are limited to only adding custom fields to existing FIX messages.

Create the field:

If your counterparty is adding a already-existing field to a message that doesn’t normally use it, then your field should already be defined, and you can skip this step.

If the counterparty has created this field, then you must define it. Here, we’ll add a new string field called AwesomeField as tag 9006.

Note: your new field must have a name and tag unique from all other fields in your Data Dictionary.

To do this, we would go to the fields section of the Data Dictionary, and add a new field entry for the new AwesomeField field.

<fields>
  <field number="1" name="Account" type="STRING"/>
  <field number="2" name="AdvId" type="STRING"/>
  <field number="3" name="AdvRefID" type="STRING"/>
...
  <field number="9006" name="AwesomeField" type="STRING"/>
</fields>

That’s it! Your field can now be used in other messages.

Add the field to a message:

If the field is not being added in a repeating group, then your altered message will look like this:

<message name="ExecutionReport" msgtype="8" msgcat="app">
  <field name="OrderID" required="Y"/>
  <field name="SecondaryOrderID" required="N"/>
  <field name="ClOrdID" required="N"/>
  <field name="OrigClOrdID" required="N"/>
  <field name="TestReqID" required="N"/>
...
  <field name="AwesomeField" required="N"/>
</message>

If the field is being added to a repeating group, then you must add it inside the appropriate group tag. In the following excerpt, we add it to the NoContraBrokers group.

• Note 1: If your group is not specified correctly, your message will be rejected or interpreted incorrectly.
• Note 2: For FIX 4.0-4.4, the order of fields inside a repeating group is important. Make sure the position of your field matches that of the actual message to be received, or your message will be rejected.

<message name="ExecutionReport" msgtype="8" msgcat="app">
  <field name="OrderID" required="Y"/>
...
  <field name="ExecBroker" required="N"/>
  <group name="NoContraBrokers" required="N">
    <field name="ContraBroker" required="N"/>
    <field name="ContraTrader" required="N"/>
    <field name="ContraTradeQty" required="N"/>
    <field name="ContraTradeTime" required="N"/>
    <field name="AwesomeField" required="N"/>
  </group>
...

Some counterparies add entirely new message types to FIX.

To add a new message type to the Data Dictionary, there are two steps:

1. Add a new message definition to the messages section.
2. Add a new corresponding entry to the MsgType field within the fields section

For example, here is how you’d add a new message type called CoolMessage that contains 3 fields (1 of which is required, the others mandatory):

Note: The msgtype and name (both are strings) must be unique from all other messages.

<messages>
  ...
  <message name="CoolMessage" msgcat="app" msgtype="xCM">
    <field name="Currency" required="N"/>
    <field name="Text" required="N"/>
    <field name="Account" required="Y"/>
  </message>
  ...
</messages>
...
<fields>
  ...
  <field number='35' name='MsgType' type='STRING'>
    ...
    <value enum='xCM' description='COOLMESSAGE'/>
  </field>
  ...
</fields>

Groups are a little more nuanced than other parts of the Data Dictionary.

A group is defined within a message, with the group tag. The first child element of the group tag is the group-counter tag, followed by the other fields in the group in the order in which they should appear in the message.

Don’t forget to define the group counter field in the fields section! By convention, the field usually starts with “No”, e.g. if the group is called “NeatGroup”, the counter field would be called “NoNeatGroups” (though this is not mandatory).

• Note 1: If your group is not specified correctly, your message will be rejected or interpreted incorrectly.
• Note 2: For FIX 4.0-4.4, the order of fields inside a repeating group is important. Make sure the position of your field matches that of the actual message to be received, or your message will be rejected.

Here is how you would add a new group ‘BrandNewGroup’ to the message ‘CoolMessage’ that created in the previous section:

<messages>
  ...
  <message name="CoolMessage" msgcat="app" msgtype="CM">
    <field name="Currency" required="N"/>
    <field name="Text" required="N"/>
    <field name="Account" required="Y"/>
    <group name="NoBrandNewGroups" required="N">
      <field name="ExecID" required="Y"/>
      <field name="OrderID" required="N"/>
      <!-- ... maybe other fields ... -->
    </group>
  </message>
  ...
</messages>
...
<fields>
  ...
  <field number='9876' name='NoBrandNewGroups' type='NUMINGROUP'/>
</fields>

The easiest way to get a custom field from a message or group is to call the typed getter:

const int AWESOME_FIELD = 9006;
string awsmFld = message.GetString(AWESOME_FIELD);

const int AWESOME_FIELD = 9006;
string awsmFld = contraBrokersGrp.GetString(AWESOME_FIELD);

For setting a custom field, we use one of the generic Field type classes:

const int AWESOME_FIELD = 9006;
message.SetField(new StringField(AWESOME_FIELD, "ohai"));

const int AWESOME_FIELD = 9006;
contraBrokersGrp.SetField(new StringField(AWESOME_FIELD, "ohai"));

QuickFIX/n is not compatible with the QuickFIX C++ .NET wrapper. This means you cannot simply replace the .NET wrapper DLLs with the QuickFIX/n DLL, and expect your existing code to compile.

The QuickFIX programming style is unchanged, so the top level interfaces you wrote code against are still the same. Creating an application is still the same as before. Your application needs to implement the standard application callbacks (FromApp, ToApp, etc…). MessageCracker is still the recommended way to receive messages, and you write your code in the OnMessage callbacks. Sending a message to a counterparty is the same method call.

Most of the changes you need to make to an existing application are minor, such as changing a method or namespace name. Below is a list of known compatibility issues:

• Method names are now upper camel case.

  
  

  For example: Session.logout() is now Session.Logout() and Application.fromApp() is now Application.FromApp()

  
  

• Getter and setter methods no longer exist and have been (or will eventually be) replaced with .NET properties.

  
  

  Previously, you would call order.getClOrdID() to get the ClOrdID value from a NewOrderSingle message. Now, just use order.ClOrdID

  
  

  For a setter: exec.setField(order.getClOrdID()); is now exec.ClOrdID = order.ClOrdID;

  
  

• Interface classes now start with I, per .NET convention. For instance, where you’d implement an Application in QuickFIX/C++, you’ll now implement an IApplication.

  
  

• FIX Message classes used to be part of the QuickFix## namespace, where ## is the FIX version. Now they are part of the QuickFix.FIX## namespace.

  
  

  For example: QuickFix42.NewOrderSingle is now QuickFix.FIX42.NewOrderSingle

  
  

• Socket acceptor and initiator classes are different.

  
  

  QuickFIX/n’s default initiator is QuickFix.Transport.SocketInitiator and the default acceptor is QuickFix.ThreadedSocketAcceptor

  
  

• There may be new or different QuickFIX settings. Please look at the configuration page to determine if you need to update your configuration files.

  
  

If we missed anything, let us know