Oct
23

QuickFIX Introduction

adminUncategorizedComments (86)

Technorati Tags:

QuickFIX Introduction Tutorial

v 1.0

A developer sideview

by

Julián Mendiola | PSF Developer Leader

http://www.prosoftwarefactory.com.ar

Content:

Introduction

What is FIX?

What is QuickFIX?

What do I want to do?

What is a session?

How to establish a FIX session with a server?

What should the Application class do?

How do I identify each incoming message?

How do I create/edit a FIX message?

Using And understanding the LogFile

Common errors

Usfull links

Introduction:

First of all, this is a non supported tutorial of QuickFIX, it’s just the explanation of what a QuickFIX user (me) would had needed to avoid losing weeks of searching and studding. I had to dig the web for several days, subscribe to forums, read plenty of material and almost get Google crazy in order to have a decent QuickFIX application. So I decided that it’d be correct to share what I’d learn and post it in a simple, clear and compact tutorial.

I’ve also must apologize because English is my second language so the paper won’t be litararily rich, but if we are honest is the language of universal programmers. As I said, I just want it to be useful not nice. You can write me in Spanish if you want.

This tutorial is oriented to a Initiator ICE FIX client which needed to obtain information of his Trades by a Windows C# application, that was shortly what PSF had to do. Perhaps users that need other functionality of QuickFIX will have to write theirs own papers(:P), but this will help them as an introduction. I’ll suppose that you have basic knowledge of object programming, C# language and xml; anyhow there is not purpose of reading this if you don’t.

I’ve “steel” parts of this papers from other similar but not completed fix approximation, I’ll

list them below; I guess there won’t be problem… this is written with the best intentions.

What is FIX?

The “Financial Information eXchange” is a protocol to send/receive information concerning the market and any buy/sell performed. It is just a definition of how the messages between to counterparts (server – client ) must be formated. It is not an application, not a software, not a socket, direction or organization…. just a protocol. It doesn’t specify how you will send or receive the message, it just tell you how to write it and some other exchanging protocols.

Several Market companies use FIX to move information about the trades an leave the possibility to theirs client to develop theirs own application to connect to them. The popularity of FIX has grown since its birth and the application that use it had became more expensive… here is were we came up…

link: http://www.fixprotocol.org/

What is QuickFIX?

QuickFIX is an open Source application developed in C++ and extended to Java, C# Python and Ruby. Although it is not the only one, it is the most used but despite that it has very few documentation, examples and support (especially in languages beside C++).

This application will generate - after compiling - the .dll files so that you add them to your project and use several functions that make FIX easier to use. The most important thing is that QuickFIX will manage all the sockets/ports/sessions/connections between the two parts leaving to the developer only the responsibility of the application itself. It also automatically manage the logic of the FIX(4.0 , 4.2 and 4.4) protocol and has support for every message defined in them as well as other that you might want to create.

Link: http://www.quickfixengine.org/

What do I want to do?

The first you should have to define and have clear is what your application must do. There are to basic possibilities. Are you going to be a client or a server in the exchange process. The difference is quit important, one will have the service running continuously and the other one will connect to it and ask for responses. QuickFIX implement this with the “Acceptor” and “Initiator” class. The names are quite graphic, an Initiator(client) initiate a session connecting by socket to the Acceptor(host) that listen the incoming message and response conform to that.

Once you have decide your side (or both) you might have to ask the other part for the information to perform the connection or in the other case, give it to them. Suppose you are a client, the basic necessary information to start a session would be:

FIX Version to use: FIX.4.0, FIX.4.2 or FIX.4.4

Conection Protocol: (ej: TCP/IP)

SenderCompID: This will identify you with all the other clients (ej: 4515)

SenderSubID: given by you Server

TargetCompID: This is specific for each server.

SocketConnectPort: given by you Server(ej: 1024)

SocketConnectHost: given by you Server (ej: 12.129.91.121 )

Password: given by you Server (if required)

UserName: given by you Server (if required)

Often you have to fill a extend registration form and if your are accepted they’ll email you with all the information above. If not… fight the technical support to gather it.

Advise: Before start developing your application make your own server/client example. Create two Console Application, run the host(acceptor) first and then the client(initiator) and print by console when the connection is successful, messages are being sending and nay other information that could help you understand what’s going on.

What is a session?

A FIX session is defined as a bi-directional stream of order messages between the FIX host and FIX clients within continues sequence number series. A FIX client can connect and disconnect multiple times while maintaining a single FIX session.

Having an active session doesn’t mean you are log in, you just have an open port where you can send and receive messages. You’ll need to send a log in message later (actually, QuickFix will handle this ).

How to establish a FIX session with a server?

There are several ways of setting the sessions information given by the Server to the QuickFIX engine; the simplest, quickest and most use way is by a text file as follows:

Write a text file like : “C:\Setting.txt” 

#default settings for sessions ——-> This are commentaries (#…)

[DEFAULT]     ——-> This will applies to all sessions

ConnectionType=initiator —-> Notes I created an Initiator Session

LogonTimeout=30

ReconnectInterval=30

ResetOnLogon=Y

# ICE Session

[SESSION] ————–> A single session

BeginString=FIX.4.4 ————–> I’ll use FIX.4.4 (the last one)

SenderCompID=4514

SenderSubID=1

TargetCompID=ICE

StartDay=sunday

EndDay=friday

StartTime=09:00:00

EndTime=21:00:00

HeartBtInt=30

CheckLatency=Y

MaxLatency=240

SocketConnectPort=1024

SocketConnectHost=12.129.91.121

Password=1234

UserName=user_name

EncryptMethod=0

SessionQualifier=ICE

UseDataDictionary=Y

DataDictionary=C:\DD\FIX44.xml —————> This specifies FIX4.4 message’s fields

FileStorePath=C:\Projects\ICE —————> Here the session Info will be stored

Don’t panic if you do not understand any of this lines, as you continues reading you’ll get them. If you want to go deeper later, you can read the SessionSettings breakdown post. Now that we have the setting file done we have to load it. A Simple C# application to create an Initiator from this file could be:

using System;
using System.Collections.Generic;
using System.Text;
using QuickFix;

namespace ConsoleApplication1{
   class Program {
      static void Main(string[] args){
         SessionSettings settings = new SessionSettings
(“C:\\Setting.txt”); 
         Application application = new Application(settings);
         FileStoreFactory storeFactory = new FileStoreFactory(settings);
         FileLogFactory logFactory = new FileLogFactory(”C:\\LogInfo”);
         MessageFactory messageFactory = new     DefaultMessageFactory();
         Sender my_sender = new Sender(settings);
         SocketInitiator initiator = new SocketInitiator(application,  storeFactory, settings, logFactory, messageFactory);
         initiator.start();
         while (!initiator.isLoggedOn());
          // Do something
         initiator.stop();
      }
   }
}

Lets interpret each line so that we can understand the problem from the root. The first one is very simple, just a class where all the info of the session setting is loaded; see that we pass as parameter the setting file path:

SessionSettings settings = new SessionSettings                     
(“C:\\Setting.txt”);

The next line define an Application object instance, this class is perhaps the most important and I’ll say that it implement the methods that would listen to the outgoing and incoming messages because we’ll treat carefully ahead.

Application application = new Application(settings);

This factories will create files were to write the information about the sessions and the messages sent and received, to have a record and history of the communication. Notice that the Setting file has a line that says “FileStorePath=C:\Projects\ICE” and the second line receives “C:\\LogInfo”, those are the files where the info is going to write in. Be sure that the “C:\Projects” folder do exist.

FileStoreFactory storeFactory = new FileStoreFactory(settings);

FileLogFactory logFactory = new FileLogFactory(”C:\\LogInfo”);

The follow line is very graphic, is own to the QuickFIX implementation and does not receive any parameter, we shouldn’t stop in it.

MessageFactory messageFactory = new DefaultMessageFactory();

Now we’ll create the initiator itself and start it. If you want to be the Acceptor side you’ll need to create a SocketAcceptor class. This object will automatically create the FIX session and try to connect by the settings specifications you had entered. The session status can be followed by the logfiles information or simple print screen as I’ll detail above.

SocketInitiator initiator = new SocketInitiator(application,    
              storeFactory, settings, logFactory, messageFactory);
initiator.start();

The connection process can delay some time so we have to wait before we performed some action with the session, that’s why I’ve enter the line:

                initiator.start();
                int i = 0;
                do
                {
                    // wait 30 second to connect
                    Thread.Sleep(1000);
                    i++;
                }
                while ((!initiator.isLoggedOn()) && (i < 30));

This will wait 30 seconds to get a confirmation we are logged in. Once we’re, we can manage the session as pleased and after all, we should log out:

initiator.stop(true);
initiator.Dispose();

With the “true” we are forcing QuickFix to free all the resources it has taken. And by dispose, we avoid waiting for the garbage collector to call the destructors (they can also might have to free some resources). With this you will be able to inmediatly restart the fix application without problem.

What should the Application class do?

One of the main critics I should make to QuickFIX, furthermore the poor documentation, is the fact that it makes much things automatically leaving behind not info beside the one in the logFile. The Application owns that responsibility, it implements all the methods than will be call in most of the FIX activities. The problem is that “most” is different to “all”…

It is important to understand that FIX is a bidirectional asynchronous protocol. Messages are flowing in both directions.  An incoming message can arrive at any time.  The methods following methods are the ones that QuickFIX uses to report to the application that some action has taken place based on an incoming. message.

Lets see the methods headers  

we should override and you’ll intermediately see this class functionality:

public void onCreate(SessionID);

public void onLogon(SessionID);

public void onLogout(SessionID);

public void toAdmin(Message, SessionID);

public void toApp(Message, SessionID);

public void fromAdmin(Message, SessionID);

public void fromApp(Message, SessionID);

As you might deduce, each of this methods are called when the session is create/logon/logout, when a message is send to administrator (toAdmin), when a message is send to the application (toApp), when a message is received from Administrator(fromAdmin) and when a message is received from Application(fromApp).

Surely, you would like to perform different actions when some of this methods are called and interpret every incoming messages. All the Fix communication logic will be manage from this methods, if you are in C# it would be practical to fire events for incoming messages for preventing soiling this methods with busyness layer.

One of the main problems you are probably thinking in, is how do I identify every different FIX protocol message. I’ll explain one practical and easy way of doing this taking advantage of one QuickFIX function.

How do I identify each incoming message?

One useful tool of QuickFIX is the message cracker, a class interface that has a method that will automatically recognize the type of message (tag 35) received and call the corresponding method. If you inherit your Application class from MessageCracker and call the crack function as follows:

public class myApplication: QuickFix.MessageCracker, QuickFix.Application

{

…

public void fromApp(Message message, SessionID sessionID)

	{
  		crack(message, sessionID);
	} 

	public override void onMessage(QuickFix44.TradeCaptureReport order, 
						  SessionID sessionID)
	{
		// Do what you want with the TradeCaptureReport
  	}
	public override void onMessage(QuickFix44.SecurityDefinition order, 								  SessionID sessionID)
	{
		// Do what ever you want with the SecurityDefinition
	}
}

Now, for example, when a TradeCaptureReport message (tag 35=AE) is send to as from the Application (FIX host) and fromApp is invoked, the crack(…) method will automatically identify the tag 35 and create a QuickFix44.TradeCaptureReport message calling the onMessage(QuickFix44.TradeCaptureReport …).

Probably your are thinking, what happens if I want to create and use my own message type? How does QuickFIX can identify messages that are not defined in neither the FIX4.0, FIX4.2 or FIX4.4 specifications. To do this we’ll have to go back to the setting file…

How do I create/edit the FIX messages ?

The problem with FIX is that many apps use custom fields and sometimes even require variations of the official spec to work seemlessly together. Most companies will provide you with their official FIX specification and you might have to tweak your data dictionary according to accept or reject certain flags required by your counter party.

Focus to the line in the Setting.txt file that says:

DataDictionary=C:\DD\FIX44.xml

This file (FIX44.xml) is an xml definition of the FIX4.4 protocol; the header, trailer, a definition of every field and message specification. It (and the others versions) can be download from the QuickFIX page

        http://www.quickfixengine.org/xml.html

And could be edited as pleased. Lets see some sections of it to clarify concepts:

<fix major=”4″ minor=”4″>

   <header> ... </header>

   <trailer> ... </trailer>

   <messages>

      ...

      <message name=”TradeCaptureReport” msgtype=”AE” msgcat=”app”>

         …

         <field name=”LastQty” required=”Y” />

         <field name=”LastPx” required=”Y” />

         …

      </message>  
...

   </messages>

   <components> ... </components>

   <fields>

      …

      <field number=”31″ name=”LastPx” type=”PRICE” />

      <field number=”32″ name=”LastQty” type=”QTY” />

      ...

   </fields>

</fix>

As you see, there is a fields section where every field with his tag number associated is defined. There is also a messages section where every message with his type is specified, as well as all the fields it contains. You should add, remove and edit this xml in order to make your application work!!!. I my case, I had to do this lots of times, mostly because the message format that the original xml had define was different from the one my server send me.

Using and understanding the LogFile

As I had mention before, one of the main problems (in my opinion) of the QuickFix implementations is the automatic responses behind the administrator (you) “knowledge”, specially the ones related to format problems and errors. How does it work? Ok, lets see it with an example.

Suppose you receive this “imaginary” message from your server:

8=FIX.4.4#9=676#35=AAA#49=THEM#56=ME#34=4#2000=a costume field value#10=161

And in your FIXML44 specification this message does not have the field 2000:

<message name=”Test” msgtype=”AAA” msgcat=”app”>

</message>

Naturally, QuickFix can’t parse it because, for him, it doesn’t have a valid format. The problem is that QF engine does not throw an exception or notification, non of the Application overridden methods are called. It automatically assumed the responsibility and send a response message to your server (What do they care if you can’t interpret their message???), this message will said something like this:

8=FIX.4.4#9=134#35=3#34=5#49=ME#56=THEM#45=4#50=1#58=Invalid message format#371=2000#372=AAA#10=235#

Here is were the LogFile gets in scene, as all this automatic message are unseen by your application whenever something went wrong you should check the LogFile to be shore non of this is happening. Each line of the “ … .messages.log.txt” file has a fix message, all of them, sent and received, in chronological order. With some practice, you would be able to understand all the application progress by reading this file.

Once you have identify the problem you can edit the XML (as explained before) file so that the message turns to be valid or communicate to your service to ask them to change the message format (if you have the possibility).

Common errors:

  • QuickFix reject a message:

Is quite probable that once your application starts a session with a server, not every messages will be accepted right away. Strictly speaking, this shouldn’t happens, cause FIX doesn’t leave spaces to doubts in his definition. But each platform frequently customize his messages making them unreachable to quickFix. Luckily, quickFix set up the message format on the fly by the xml Data Dictionary. So you can edit it in order the message to fit. Sometimes, the reject reason wont be accurate. For example: it says missing field x and you see x define for that message. The problem is not indeed in this field, probably there is other field that doesn't match and quickFix misunderstood the error. In this cases, I recommend you to make an exhaustive compare between message fields and your dictionary to find the difference.

Usfull Links:

vvvvvvv