OnixS C++ CME MDP Premium Market Data Handler  5.8.9
API Documentation
Inner Contents
Getting Started

Inner Contents

 Adjusting Handler's settings
 
 Setting up Feed Engine
 
 Event listeners
 
 Errors and warnings
 
 Trade summary and order details
 
 Selecting securities of interest
 
 TCP Recovery
 
 Logging services
 

Detailed Description

The Handle API is enclosed in the OnixS::CME::MDH namespace. The master OnixS/CME/MDH.h header file collects all header files.

The following sections show how to receive and process CME MDP 3.0 market data:

Constructing and configuring the handler

The OnixS::CME::MDH::Handler class encapsulates the market data processing logic in the bounds of a CME MDP 3.0 channel. The OnixS::CME::MDH::HandlerSettings class contains parameters controlling various aspects of market data processing.

Default values configure the likely behaviour of the handler instance. However, some parameters must be set explicitly before starting market data processing:

Handler handler;
// Selects the CME MDP 3.0 channel and specifies the configuration file's location.
handler.settings().channel(310).connectivityConfigurationFile("config.xml");
#if !defined(_WIN32)
// Specifies network interfaces.
handler.settings().feeds().feedANetworkInterfaces(NETWORK_INTERFACE_FOR_FEEDS_A)
.feedBNetworkInterfaces(NETWORK_INTERFACE_FOR_FEEDS_B);
#endif
See also
Adjusting Handler's settings

Licensing

The SDK needs a valid license for successful execution. If the licensing subsystem is not able to find a valid license, it throws an exception when the OnixS::CME::MDH::Handler::start is called.

By default, the handler looks for a license in the application’s current directory. To instruct the handler where to look for a valid license, use the OnixS::CME::MDH::LicenseSettings::licenseStore method.

Note
The licensing subsystem looks for a valid license in the specified folder and selects the best one. If multiple licenses are available, it selects the most significant one (for example, a production license is selected instead of a trial one if both are available).

The following example shows how to specify the license location:

// The folder in which the license is stored.
handler.settings().licenseSettings().licenseStore("license");

Binding a Feed Engine

The Feed Engine abstractions encapsulate market data sources. It is necessary to construct a Feed Engine implementation instance and bind it to the OnixS::CME::MDH::Handler instance:

// Using the Socket Feed Engine to receive live market data.
SocketFeedEngine feedEngine;
handler.settings().feeds().engine(&feedEngine);
Note
An OnixS::CME::MDH::Handler instance does not manage the lifetime of the associated OnixS::CME::MDH::NetFeedEngine instance. The user is responsible for keeping an OnixS::CME::MDH::NetFeedEngine instance alive while bound to an OnixS::CME::MDH::Handler instance.
See also
Setting up Feed Engine

Subscribing to market data events

Once an OnixS::CME::MDH::Handler instance is constructed and bound to an instance of the OnixS::CME::MDH::NetFeedEngine, market data processing can be started. To get the results of market data processing, subscribe to the corresponding events (e.g., order book updates).

See also
Event listeners

Starting market data processing

To start market data processing, call the OnixS::CME::MDH::Handler::start method.

handler.start();
Note
The OnixS::CME::MDH::Handler::start method switches the handler to the market data processing state. However, the Feed Engine logic must be executed to make market data come into the handler instance. It is necessary to explicitly run the Feed Engine logic either by invoking the OnixS::CME::MDH::NetFeedEngine::process method repeatedly or by using additional services like one offered by the OnixS::CME::MDH::FeedEngineThreadPool class.

To stop market data processing, call the OnixS::CME::MDH::Handler::stop method.

handler.stop();

Configuring logging (optional)

The handler can log market data it processes and other events that may occur during market data processing.

The OnixS::CME::MDH::Logger abstract class encapsulates the logging subsystem. The handler provides a few logging implementations. File-based logging is a good choice for most cases.

Below is an example of how the file-based logging is configured:

FileLoggerSettings loggerSettings;
// Sets filename of the log file.
loggerSettings.filename(makeLogFilename(310));
// Defines which events are to be logged.
loggerSettings.severityLevel(LogSeverity::Debug);
// Initializes the logger instance.
FileLogger logger(loggerSettings);
// Binds the logger to the Handler.
handler.settings().logging().logger(&logger);
Note
An OnixS::CME::MDH::Handler instance does not manage the lifetime of the associated OnixS::CME::MDH::Logger instance. Therefore, the user must keep the OnixS::CME::MDH::Logger instance alive while it is bound to the handler.
See also
Logging services