OnixS::FIX::Message class represents a generic model of any FIX message, in order to manipulate such a message, you need to check the message type and know what fields exist in this message, all of this is not safe and creates some development complexity, so to simplify the FIX message handling and make this more safe you can use strongly typed message classes instead of the generic Message class. Such typed message classes can be generated by the generator tool.
There are two modes in the typed messages generator.
In the first one, the messages are generated based on the FIX Dictionary file provided. This mode is enabled by specifying the
In the second one, the generation performed based on the standard FIX Dictionary for the provided FIX versions, which must be specified. This mode is enabled by specifying the
It is possible to provide the generator with a filter for messages to be dispatched as incoming ones. It reduces the generated code size and achieves performance benefits for message dispatching. To do so,
message-types argument can be used. If no filter provided, all the messages are treated as incoming ones.
Below are the description for the Generator arguments:
|dictionary||Y||A path to the FIX dictionary file, the first mode|
|versions||Y||A comma-separated list of FIX versions, the second mode|
|out-name||N||A name to the files, where typed messages classes are saved|
|std||N||The C++ standatd version (Cxx03, Cxx11, Cxx14, Cxx17, Cxx20, universal (use macros))|
|message-types||N||A comma-separated list of messages to be dispatched as incoming|
--versions=FIX40,FIX50sp1 --out-dir=Generated --std=Cxx17 --message-types=D,8: generate messages based on standard FIX Dictionary for FIX versions 4.0 and 5.0 SP1, use C++17, put generated classes in files named
Generated, treat messages with types
8 as incoming.
It is very similar to the standard interface, but the listener object must be inherited from TypedMessageListener, instead of OnixS::FIX::ISessionListener.
It is very similar to the standard interface. The strongly-typed message object is created, and the fields are set with the corresponding setters.
To receive an incoming messages, it is necessary to override the corresponding method of TypedMessageListener class. The incoming messages are delivered via these callbacks.
The strongly-typed message getters provide a type specified in the FIX Dictionary during the generation; no type conversion is required.
For non-required fields, the getter's return a boolean value that indicates the field's presence, and the value itself is returned by reference.
If a message with an unexpected type is received, it is delivered to the user via TypedMessageListener::onUnrecognizedMessage callback.
Every group and its entry are exposed as a nested class of a correspondent owner (message or another group).
To add a new repeating group or modify the number of instances of the existing one, a method named after the group name must be used as in the following example. The method accepts a new number of repeating group entries as a parameter and returns an instance of a newly created or modified repeating group.
To allow traversing group entries, every typed group entry class is a descendant of OnixS::FIX::TypedGroup class, which contains correspondent methods: querying groups size, accessing the group's entries, etc. The index operator (or OnixS::FIX::TypedGroup::at member) returns an entry that allows fields access in the very same manner the message does. The indexing entry starts from zero.
The following example demonstrates how to traverse over the repeating group entries:
A group can also be traversed using an iterator:
The Strongly Typed Messages are implemented as a very thin wrapper, which incurs almost no additional overhead. Moreover, because of the highly optimized message dispatching, there could be some performance benefits.