CODEWITHSUNDEEP
c++quickfix
gearhead
gearhead

Reputation: 807

Questions about QuickFIX message cracking

VERY basic questions from a FIX newbie

Looking at the documentation at http://www.quickfixengine.org and reading posts here on stackoverflow I see lots of talk about message 'cracking'. I think I sort of get the idea, but feel like I'm still not totally clear.

Can some explain in general what exactly this is (why is it necessary? it sounds like a hack), why it only seems relates to received FIX messages, and is not used at all when using Python?

Thank you!

Upvotes: 15

Views: 10321

Answers (2)

Grant Birchmeier
Grant Birchmeier

Reputation: 18504

In practice, all you need to know is this:

Your fromApp() callback gets a Message object. That message is actually a NewOrderSingle or ExecutionReport or something. Rather than making you figure it out, QF lets you inherit from MessageCracker. To use it, call crack() in your fromApp(), as follows:

void fromApp( const FIX::Message& message, const FIX::SessionID& sessionID )
  throw( FIX::FieldNotFound&, FIX::IncorrectDataFormat&, FIX::IncorrectTagValue&, FIX::UnsupportedMessageType& )
{
  crack(message, sessionID);
}

What crack() does is this:

  1. Converts your Message into the proper subclass (e.g. NewOrderSingle, ExecutionReport, etc)
  2. Calls your user-defined onMessage(subtype) callback, if defined. If not defined, it throws an UnsupportedMessageType exception and your app will automatically send a BusinessMessageReject (35=j) to the counterparty.

So, do you want to handle NewOrderSingle messages? Great, just define an onMessage(NewOrderSingle) callback.

void onMessage( const FIX42::NewOrderSingle& message, const FIX::SessionID& )
{
  // Do whatever you want with your NewOrderSingle message's content.
  // Note that this message and the one passed to crack() are the same, content-wise.
}

Do you want to handle ExecutionReports? Define onMessage(ExecutionReport). And so on.

But what about those message types you don't want to handle? It would suck if you had to add handlers to reject all those other message types, but luckily, you don't have to. As I said earlier, if you don't define an onMessage(), QF will reject it for you. (If you want to swallow a particular message type and ignore it without rejection, then just define an onMessage() call with no body.)

Does that clear it up a bit? Perhaps now this page in the QF docs might read a little easier -- the bottom section talks about the MessageCracker.

Note: The MessageCracker does not handle session-level (aka "admin") messages. If you want to add custom handling for, say, Logon or Heartbeat messages, you must do it explicitly in fromAdmin() (see this question for more info).

Upvotes: 36

robthewolf
robthewolf

Reputation: 7624

I use quickfixj for Java. The cracking uses and interface to return the cracked message to the interface implementation. The implementor will over ride the interface's methods so that it can handle each message type individually.

Message cracker takes a plain message and returns the message as a specifically typed message. The advantage of this is that the dictionary will confine the fields of the message so that it is easier to look up each field.

Upvotes: 2

Related Questions