Documentation for QuickFIX/C++ (with Python and Ruby)

Getting Started

Creating Your Application

Creating a FIX application is as easy as implementing the QuickFIX Application interface. The C++ interface is defined in the following code segment:

C++

namespace FIX
{
  class Application
  {
  public:
    virtual ~Application() {};
    virtual void onCreate( const SessionID& ) = 0;
    virtual void onLogon( const SessionID& ) = 0;
    virtual void onLogout( const SessionID& ) = 0;
    virtual void toAdmin( Message&, const SessionID& ) = 0;
    virtual void toApp( Message&, const SessionID& )
      throw( DoNotSend ) = 0;
    virtual void fromAdmin( const Message&, const SessionID& )
      throw( FieldNotFound, IncorrectDataFormat, IncorrectTagValue, RejectLogon ) = 0;
    virtual void fromApp( const Message&, const SessionID& )
      throw( FieldNotFound, IncorrectDataFormat, IncorrectTagValue, UnsupportedMessageType ) = 0;
  };
}

Python

class Application(_object):
        def onCreate(self, sessionID): return
        def onLogon(self, sessionID): return
        def onLogout(self, sessionID): return
        def toAdmin(self, message, sessionID): return
        def toApp(self, message, sessionID): return
        def fromAdmin(self, message, sessionID): return
        def fromApp(self, message, sessionID): return

Ruby

class Application < Quickfix::Application

  def onCreate(sessionID)
  end

  def onLogon(sessionID)
  end

  def onLogout(sessionID)
  end

  def toAdmin(sessionID, message)
  end

  def toApp(sessionID, message)
  end

  def fromAdmin(sessionID, message)
  end

  def fromApp(sessionID, message)
  end
end

These methods act as callbacks from your FIX sessions.

• onCreate is called when quickfix creates a new session. A session comes into and remains in existence for the life of the application. Sessions exist whether or not a counter party is connected to it. As soon as a session is created, you can begin sending messages to it. If no one is logged on, the messages will be sent at the time a connection is established with the counterparty.
• onLogon notifies you when a valid logon has been established with a counter party. This is called when a connection has been established and the FIX logon process has completed with both parties exchanging valid logon messages.
• onLogout notifies you when an FIX session is no longer online. This could happen during a normal logout exchange or because of a forced termination or a loss of network connection.
• toAdmin provides you with a peak at the administrative messages that are being sent from your FIX engine to the counter party. This is normally not useful for an application however it is provided for any logging you may wish to do. Notice that the FIX::Message is not const. This allows you to add fields to an adminstrative message before it is sent out.
• toApp is a callback for application messages that you are being sent to a counterparty. If you throw a DoNotSend exception in this function, the application will not send the message. This is mostly useful if the application has been asked to resend a message such as an order that is no longer relevant for the current market. Messages that are being resent are marked with the PossDupFlag in the header set to true; if a DoNotSend exception is thrown and the flag is set to true, a sequence reset will be sent in place of the message. If it is set to false, the message will simply not be sent. Notice that the FIX::Message is not const. This allows you to add fields to an application message before it is sent out.
• fromAdmin notifies you when an administrative message is sent from a counterparty to your FIX engine. This can be usefull for doing extra validation on logon messages like validating passwords. Throwing a RejectLogon exception will disconnect the counterparty.
• fromApp receives application level request. If your application is a sell-side OMS, this is where you will get your new order requests. If you were a buy side, you would get your execution reports here. If a FieldNotFound exception is thrown, the counterparty will receive a reject indicating a conditionally required field is missing. The Message class will throw this exception when trying to retrieve a missing field, so you will rarely need the throw this explicitly. You can also throw an UnsupportedMessageType exception. This will result in the counterparty getting a reject informing them your application cannot process those types of messages. An IncorrectTagValue can also be thrown if a field contains a value you do not support.