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