Most of the messages you will be interested in looking at will be arriving in your overloaded fromApp function of your application. You can get fields out of messages with different degrees of type safety. The type in question here is the FIX message type. When the application passes you a Message class, the Java type checker has no idea what specific FIX message it is, you must determine that dynamically. There is, however, a way we can make Java aware of this type information. First we will cover how to dynamically retreive fields from a message, then we will show you the prefered type safe way. Keep in mind that all messages have a header and a trailer. If you want to see fields in them, you must first call getHeader() or getTrailer() to get access to them. Otherwise you access them just like in the message body.
This method of retreiving data from messages is strongly discouraged and is generally only useful for writing more low level interfaces for other languages and middleware.
import quickfix.*;
public void fromApp(Message message, SessionID sessionID)
throws FieldNotFound, UnsupportedMessageType, IncorrectTagValue {
StringField field = new StringField(44);
message.getField(field);
}
A way to add some type safety to this is by using field classes that represent all the FIX defined fields. This is sometimes useful in an application, but is generally only used within code segments that need to be version independent (meaning versions of FIX). For example, our Session class is implemented using mostly these. It is generally not recomended for most applications. This will also get fields as their appropriate type, not just as strings.
import quickfix.*;
import quickfix.field.*;
public void fromApp(Message message, SessionID sessionID)
throws FieldNotFound, UnsupportedMessageType, IncorrectTagValue {
Price price = new Price();
message.getField(price);
ClOrdID = new ClOrdID();
message.getField(clOrdID);
}
Here is the most type safe and highly encouraged method for retreiving data from a message. QuickFIX has message classes that correlate to all the messages defined in the spec. They are, just like the field classes, generated directly off of the FIX specifications. To take advantage of this, you must break the messages out with the supplied MessageCracker. Also notice we are no longer using a generic Message class and we are now using get instead of getField. Keep in mind you can still use getField as all of these classes derive from Message
import quickfix.*;
import quickfix.field.*;
public void fromApp(Message message, SessionID sessionID)
throws FieldNotFound, UnsupportedMessageType, IncorrectTagValue {
crack(message, sessionID);
}
public void onMessage( quickfix.fix42.NewOrderSingle message, SessionID sessionID )
throws FieldNotFound, UnsupportedMessageType, IncorrectTagValue {
ClOrdID clOrdID = new ClOrdID();
message.get(clOrdID);
ClearingAccount clearingAccount = new ClearingAccount();
message.get(clearingAccount);
}
public void onMessage( quickfix.fix42.OrderCancelRequest message, SessionID sessionID )
throws FieldNotFound, UnsupportedMessageType, IncorrectTagValue {
ClOrdID clOrdID = new ClOrdID();
message.get(clOrdID);
// compile time error!! field not defined for OrderCancelRequest
ClearingAccount clearingAccount = new ClearingAccount();
message.get(clearingAccount);
}
In order to use this you must use the MessageCracker as a mixin to your application. This will provide you with the crack function and allow you to overload specific message functions. Any function you do not overload will by default throw an UnsupportedMessageType exception
Define your application like this:
import quickfix.Application;
import quickfix.MessageCracker;
public class MyApplication
extends MessageCracker implements quickfix.Application