Questions about QuickFIX message cracking

Question

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!

Contumely

Answer 1

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).

Padre

Thanks for the explanation @Grant. Regarding the last part of my question, how come in that very bottom section it says 'Python(Not Supported)' when discussing the message cracker. Do I not need to do the same thing in Python that needs to be done in C++ (that doesn't make sense)? Does it have to do with the way that python handles variable types as compared to C++? – Contumely

I've never used the Python version of QF, but the doc page does seem to imply that Python doesn't use the Cracker. I'd guess you may be correct in your guess at the reason why. Since Python is untyped, you can probably just slap a switch statement on field 35 in fromApp() and throw UnsupportedMessageType in the default case for any type you don't want to handle. You'd be better off asking other Python QF users. I know they're out there, but I don't know where they hang out. Maybe try the forums (see link on QF homepage)? – Padre

@GrantBirchmeier how do you handle 4= SequenceReset messages – Pragmatist

@Pragmatist - I don't. The engine handles it for me. – Padre

@GrantBirchmeier wow, what is its response, currently mine doesn't handle it correctly, calling Session.lookupSession(sessionId).reset(); results in a whole slew of messages sent – Pragmatist

Why are you calling Session.reset()? When engine gets a reset, it should figure out the proper response, send any appropriate resendRequests accordingly. You literally should not have to write any handling behavior for it. It sounds like you might want to make a new question for this, and include partial logs to show what's happening that you think is wrong. – Padre

Answer 2

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.

Aesir