OnixS C++ FIX Engine  4.10.1
API Documentation
FlatMessage Mode

Sometimes it is more convenient to work with FIX messages just as sequences of tag=value pairs. For example, an application needs to receive a message, access a few fields, and use the value of these fields to route the message to one of the counterparties (so-called "FIX to FIX routing"). In this scenario, it could be impractical to maintain the FIX Dictionary - especially if messages are received from venues that use different FIX Dictionaries.

To support this scenario, the Engine exposes the Flat FIX Message class.

Receiving Flat Messages

To receive Flat Messages, set OnixS::FIX::Session::messageMode setting to FlatMessage. In this mode, the overloaded inbound callbacks with OnixS::FIX::FlatMessage objects are called:

class Listener : public ISessionListener
{
public:
void onInboundApplicationMsg(Message & message, Session *) ONIXS_FIXENGINE_OVERRIDE
{
// This callback is called when the `Message` mode is used (by default).
std::clog
<< "Incoming application-level message: "
<< message.toString()
<< std::endl;
}
void onInboundApplicationMsg(FlatMessage & message, Session *) ONIXS_FIXENGINE_OVERRIDE
{
// This callback is called when the `FlatMessage` mode is used.
std::clog
<< "Incoming application-level message: "
<< message.toString()
<< std::endl;
}
};
Listener listener;
Session session("SenderCompId", "TargetCompId", ProtocolVersion::FIX_42, &listener);
// In this mode, the overloaded inbound callbacks with `FlatMessage` objects are called.
session.messageMode(MessageMode::FlatMessage);
// Work with the session as usual.
Note
All OnixS::FIX::FlatFieldKey and OnixS::FIX::FieldValueRef objects become invalid after receiving a new message, therefore one should use them only in the context of the same OnixS::FIX::FlatMessage object passed to the inbound callback.

Sending Flat Messages

To send Flat Messages, use the corresponding OnixS::FIX::Session::send(OnixS::FIX::FlatMessage*) method.

FlatMessage versus Message

Class Advantages Disadvantages
Message Supports validation. Fields order is defined by the FIX Dictionary.
Tag-based field access takes constant time. FIX Repeating Groups are lost without the complete FIX Dictionary.
The message type and FIX protocol version cannot be changed.
FlatMessage FIX Repeating Groups are always preserved and can be accessed without the corresponding FIX Dictionary. Tag-based field access requires the finding of the tag offset that takes linear time.
Keeps the field order. Does not support validation.
Any field can be changed.