Elektron SDK - C/C++

API Family: Elektron

EMA Consumer - Posting data to Contribution Channel

Download tutorial source code

Click here to download

Last update Jun 2020
Environment Windows, Linux
Compilers Refer to the EMA Compiler Guides for a complete list
Prerequisite Downloaded, installed, compiled and ran an EMA consumer example

Posting Directly to Refinitiv Contribution Channel

Knowledge Prerequisite – Must have an understanding of an Elektron Message API and be familiar with consuming OMM Market Price data. You should also have a basic understanding of EMA Configuration  (see the end of this article for links to relevant tutorials)

Contributing Data to Refinitiv Elektron Feed

Currently, clients wishing to Contribute data to Refinitiv, typically do so using on-site contribution systems such as MarketLinkIP.

In order to meet the evolving needs of the market, Refinitiv has developed a new Contribution service - Refinitiv Contribution Channel (RCC). The Contributions Channel is provided through a cluster of virtual servers that can provide data optimization & conflation capabilities as well as a much higher rate of content onto Elektron.

Whilst it will be possible in the near future to contribute to RCC via the Refinitiv Enterprise Platform (TREP) system, some of our clients use 3rd party systems and will, therefore, need to contribute directly to RCC.

To contribute directly to RCC you will need to develop an OMM Consumer application using one of our Elektron APIs - i.e. Elektron Transport API (ETA) or Elektron Message API (EMA).

Now, EMA supports both Windows and Linux platforms. However, it must connect to an associated server OS host only. Otherwise, the application will encounter an "Initialization timed out" error message.

This article focuses on the process you will need to implement using EMA and is summarized as follows:

  1. Establish an Encrypted Connection to the server
  2. Open a Tunnel Stream
  3. Perform a Client Login
  4. Contribute data using Post Messages

For the purpose of this tutorial, I will use the EMA supplied example 341__MarketPrice__OffStreamPost as the starting point for tutorial code as I will also be using off-stream Post Messages to contribute data to RCC.

Establish Encrypted Connection to RCC server

As with any OMM Consumer application, one of the first things you would do is connect to and login to the server.

int main( int argc, char* argv[] )
	try {
		AppClient client;
		OmmConsumer consumer( OmmConsumerConfig().username( "rmds" ));
		client.setOmmConsumer( consumer );
		consumer.registerClient( ReqMsg().domainType( MMT_LOGIN ), client);

		sleep( 60000 );			// API calls onRefreshMsg(), onUpdateMsg(), or onStatusMsg()
	catch ( const OmmException& excp ) {
		cout << excp << endl;

	return 0;

In the snippet above I have removed some of the code from the 341 example which is not relevant for the purposes of this tutorial. The rest of the code remains much the same - except for specifying my username of 'test'.   

The above code results in the API loading the default configuration, attempting to establish a connection and performing a Device Login with the provided username.    

It also creates an instance of callback client class and registers it to receive any Device Login related events/messages.     

I mentioned earlier that I need to establish an encrypted connection - but there is no indication of this in the code above. This is because the connection type is specified in the configuration - and for this example, I will be using the EmaConfig.xml file (as opposed to programmatic config).    

    <DefaultConsumer value="Consumer_1"/>
            <Name value="Consumer_1"/>
            <Channel value="Channel_1"/>
            <Name value="Channel_1"/>
            <ChannelType value="ChannelType::RSSL_ENCRYPTED"/>
            <Host value="<RCC_SERVER_HOST_NAME>"/>
            <Port value="443"/>
            <EncryptedProtocolType value="EncryptedProtocolType::RSSL_SOCKET"/>

As you can see I have changed the Channel Type to RSSL_ENCRYPTED (from the default RSSL_SOCKET) and the Port to 443 (from the default 14002). I have also specified the hostname for my RCC server.

Also, note the EncryptedProtocolType setting which defaults to RSSL_HTTP on Windows, so needs to be changed to RSSL_SOCKET if you are using Windows. This encryption type requires OpenSSL libraries, which are not built by the Elektron SDK package. Please see chapter 4.3.3: Encrypted Connections in the EMA Developer's Guide for more information.

These are the minimum changes required for an encrypted connection to the RCC server. You will need to confirm the Host and Port value with your internal Market Data team or your Refinitiv Account manager.

Open a Tunnel Stream

I could also go ahead and attempt to open a Tunnel Stream in the main() method. However, I think it is better practice to wait for a successful Device Login response - no point attempting a Tunnel Stream if the Device Login fails.   

Earlier I created an instance of the callback client AppClient and registered it to receive the Device Login related events. Below is an example of Device Login response received by the onRefreshMsg() callback handler of this client:

AppClient::OnRefreshMsg :: RefreshMsg
    domain="Login Domain"
    state="Open / Ok / None / 'Refresh Completed'"
    Attrib dataType="ElementList"
            ElementEntry name="SingleOpen" dataType="UInt" value="1"
            ElementEntry name="AllowSuspectData" dataType="UInt" value="1"
            ElementEntry name="ApplicationId" dataType="Ascii" value="256"
            ElementEntry name="ApplicationName" dataType="Ascii" value="ema"
            ElementEntry name="Position" dataType="Ascii" value=""


The response shows that my Device Login request was accepted and the Stream is Open etc. 

A Tunnel Stream is a private stream that supports additional functionalities such as authentication, flow control, guaranteed delivery etc - which can be specified on a per stream basis.

So, I am going to modify my onRefreshMsg() handler method to create the Tunnel Stream once it receives a valid Device Login response:

void AppClient::onRefreshMsg(const RefreshMsg& refreshMsg, const OmmConsumerEvent& event)
	cout << "AppClient::OnRefreshMsg :: " 
	    << refreshMsg << endl; // defaults to refreshMsg.toString()
	// If Device Login accepted & stream Opened, then open Tunnel Stream 
	if (refreshMsg.getDomainType() == MMT_LOGIN &&
		refreshMsg.getState().getStreamState() == OmmState::OpenEnum &&
		refreshMsg.getState().getDataState() == OmmState::OkEnum &&
		_tunnelStreamHandle == 0)
		CosAuthentication cosAuthentication;

		CosDataIntegrity cosDataIntegrity;

		CosFlowControl cosFlowControl;

		CosGuarantee cosGuarantee;

		ClassOfService cos;

		TunnelStreamRequest tsr;

		_tunnelStreamHandle = _pOmmConsumer->registerClient(tsr,*this);

In the above code snippet, the first thing I check for is that I have received a successful MMT_LOGIN response. If this is the case then I define the Class of Service I require from my Tunnel Stream - in terms of Data Integrity, Authentication, Flow Control, and Guarantee. Exploration of these various properties is outside the scope of this document - suffice to say the above values are appropriate for this tutorial.

I then create a Tunnel Stream request, providing an arbitrary name of 'Seikan' for the Tunnel Stream and the service name of 'DDS_TRCC'. The service name will need to be obtained from your Market Data team or TR Account Manager. Note also, that I use a Domain type of MMT_SYSTEM - which as the name suggests is a System domain for content-neutral requests (i.e. non-data domains). 

Finally, I register this same AppClient instance as the callback client to receive events related to the Tunnel Stream and store the Tunnel Stream handle for later reference.

Perform a Client Login

When the Tunnel Stream has been established, I should get back a Status Message with a domain Type of MMT_SYSTEM and Stream State of Open - an example of which is shown below:   

AppClient::OnStatusMsg :: StatusMsg
    domain="System Domain"
    state="Open / Ok / None / ''"

The above response is handled and output by the onStatusMsg method of my AppClient class - since I registered this same instance to receive any Tunnel Stream related events. 

Once I get the above response, I can then perform a Client Login to the RCC server with my RCC Client credentials - which consist of a RCC username and a password - both of which will be supplied by your Market Data team or Refinitiv Account team. The password can be encrypted and locally stored in the configuration or Windows registry. Then, the password must be decrypted before using it in the login message.  The credentials are protected by the TLS encrypted connection. 

void AppClient::onStatusMsg(const StatusMsg& statusMsg, const OmmConsumerEvent& event)
	try {
		cout << "AppClient::OnStatusMsg :: " << statusMsg << endl;		
		// We should get a StatusMsg with Open Stream
		// once Tunnel Stream has been established
		if (!_bSubStreamOpen && 
		    event.getHandle() == _tunnelStreamHandle &&
	            statusMsg.hasState() &&
		    statusMsg.getState().getStreamState() == OmmState::OpenEnum)
			_bSubStreamOpen = true;
			cout << "Client Login to Private Stream : " 
			    << statusMsg.getStreamId() << endl;
			ElementList elmList;

			ReqMsg reqMsg;

			cout << endl << "Submit GenericMsg from onStatus" << endl;

			_subStreamHandle = _pOmmConsumer->registerClient(reqMsg,
			                *this, (void*)1, _tunnelStreamHandle);

In the code above, the first thing I do is check that the StatusMsg I have received is related to the Tunnel Stream request  (and not something else like the earlier Device Login) by comparing the events stream handle with the previously store Tunnel Stream Handle.

If the handles match, I then populate an ElementList with the Password which is then specified as an attribute of the Client Login request message which I create.   

Note the following for the Client Login request:

  • The domain type is MMT_LOGIN 
  • <RCC_USERNAME> must be changed according to your authentication information
  • Password is set as an attribute of the request
  • The StreamId is set to be the same as the received StatusMsg

Using the StreamId of the StatusMsg will ensure the Client Login request is sent using the Tunnel Stream -  I confirmed earlier that this StatusMsg was for the Tunnel Stream.

Finally, I register this AppClient instance as the callback client to receive events related to the Client Login and I store the new stream handle for later reference.

Contribute data using Post Messages

Once I received a successful Client Login response from RCC I can then go ahead and start contributing data using Post Messages. The client login’s response may include a maximum message rate in the refresh response and this message rate should be obeyed.  This message looks like:

<genericMsg domainType="RSSL_DMT_SYSTEM" streamId="3" containerType="RSSL_DT_MSG" flags="0x19 (RSSL_GNMF_HAS_EXTENDED_HEADER|RSSL_GNMF_HAS_SEQ_NUM|RSSL_GNMF_MESSAGE_COMPLETE)" seqNum="1" dataSize="127">
    <extendedHeader data="0100"/>
<!-- rwfMajorVer="14" rwfMinorVer="1" -->
        <refreshMsg domainType="RSSL_DMT_LOGIN" streamId="1" containerType="RSSL_DT_NO_DATA" flags="0x648 (RSSL_RFMF_HAS_MSG_KEY|RSSL_RFMF_REFRESH_COMPLETE|RSSL_RFMF_DO_NOT_CACHE|RSSL_RFMF_PRIVATE_STREAM)" groupId="0" dataState="RSSL_DATA_OK" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text="Login accepted by host HOSTNAME via HANDLERNAME"  dataSize="0">
            <key  flags="0x23 (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_ATTRIB)"  serviceId="10" name="USERNAME" attribContainerType="RSSL_DT_ELEMENT_LIST">
                    <elementList flags="0x8 (RSSL_ELF_HAS_STANDARD_DATA)">
                        <elementEntry name="TRCE:MaxMessagesPerSecond" dataType="RSSL_DT_UINT" data="300"/>

This feature is available in the cloud version so it will not be seen when logging in to the current On-Premises version. Therefore, if the TRCE:MaxMessagesPerSecond element presents, the message rate posted by the application should not exceed this number.  

Below is an example of a valid Client Login response which takes the form a RefreshMsg:

AppClient::OnRefreshMsg :: RefreshMsg
    domain="Login Domain"
    state="Open / Ok / None / 'Login accepted by host c905derdabc1'"
    itemGroup="00 00"
    Attrib dataType="ElementList"
            ElementEntry name="Password" 

The response shows that the Client Login was accepted and the stream is Open etc. As the response is handled by the onRefreshMsg handler I need to add another if statement to the onRefreshMsg() method to test for the valid Client Login response before I start Posting data to the server:

void AppClient::onRefreshMsg(const RefreshMsg& refreshMsg, const OmmConsumerEvent& event)
    //Start Posting messages once Client Login accepted
    if (refreshMsg.getDomainType() == MMT_SYSTEM &&
		event.getHandle() == _subStreamHandle &&
	    refreshMsg.getState().getStreamState() == OmmState::OpenEnum &&
	    refreshMsg.getState().getDataState() == OmmState::OkEnum)
	            cout<<"Send First PostMsg()....."<< endl;
		   _pOmmConsumer->submit( PostMsg()
			   .postId( _postID ).domainType(MMT_MARKET_PRICE)
			   .solicitAck( true ).complete()
		            .payload( FieldList()
			        .addReal(22, _BID-1, OmmReal::ExponentNeg2Enum)
			        .addReal(25, _ASK-1, OmmReal::ExponentNeg2Enum)
                                .complete() ))
			   _subStreamHandle );

A breakdown of the above code snippet:

  • Check if the RefreshMsg is for the Client Login - by checking the domain and comparing the handles
  • Ensure the stream is Open before proceeding to post
  • Extract the StreamId of the Client Login so I can Submit the Post on the same private stream
  • Create a PostMsg with the following properties and values
    • StreamId the same as the Client Login private stream
    • Domain Type of MarketPrice
    • Solicit an Ack (acknowledgment) from server
    • Unique ID for this Post (initialized to 1 in AppClient constructor)
    • PostMsg payload of an UpdateMsg - to update an existing record
    • <CONTRIBUTION_ITEM> must be changed according to an actual item in the RCC server.
    • UpdateMsg payload consisting of two fields - BID (22) and ASK (25)
  • Submit the PostMsg using the Stream Handle of the Client Login private stream
  • Increment the unique Post ID and my dummy BID and ASK values

A few things to note here:

  1. The unique Post ID can be retrieved from the Ack response you get back - so you can tie up the Ack to the Post and confirm that each Post has been acknowledged by the server
  2. RCC currently only allows the Update of existing records on the server via an API. New records can be defined manually by a RCC administrator.

Since I have solicited an Ack response from the server, the application should receive an AckMsg from the server shortly after the Post is submitted. This will result in the onAckMsg() method is invoked.   

Below is some example output from the onAckMsg() method when it receives an Acknowledgement to my first Post. Note the Ack Id=1, which matches the Post ID used in my first PostMsg above:

AppClient::onAckMsg :: AckMsg
    domain="MarketPrice Domain"

In a production application, you would submit further posts as and when your records field values change.

However, as this is a simple tutorial application, I am going to use the AckMsg response as a trigger to send further Updates.

void AppClient::onAckMsg(const AckMsg& ackMsg, const OmmConsumerEvent& event)
	cout << endl << "AppClient::onAckMsg :: " << ackMsg << endl;
	cout << "Posting Update....." << endl;
				.addReal(22, _BID, OmmReal::ExponentNeg2Enum)
				.addReal(25, _ASK, OmmReal::ExponentNeg2Enum)



In the above code snippet, when I receive an Ack response, I am pretty much just repeating the earlier code snippet to create a PostMsg with incrementing field values & Post ID and submitting it to the server.

Once I submit the above PostMsg, I should get back an Acknowledgement from the server, which will result onAckMsg() being invoked again, which will send out another PostMsg and so on.

Posting Update.....
AppClient::onAckMsg :: AckMsg
    domain="MarketPrice Domain"
Posting Update.....
AppClient::onAckMsg :: AckMsg
    domain="MarketPrice Domain"
Posting Update.....
AppClient::onAckMsg :: AckMsg
    domain="MarketPrice Domain"

This will continue until the sleep(60000) call in the main() method expires, the main thread resumes execution and the application terminates.

Note that it is possible to receive a Nack response if the Post is not accepted by the RCC server e.g. if you use an invalid RIC or try to update Fields that are not defined in the target RIC.   

Below is an example of a Nack response I received when I tried to post to an invalid RIC:

AppClient::onAckMsg :: AckMsg
    domain="MarketPrice Domain"
    text="Symbol unknown"

You can test for a Nack with the AckMsg::hasNackCode() method, for example, the following outputs the Nack Code in the string and numerical format:

    if ( ackMsg.hasNackCode() )
        cout    << "Nack Code: " << ackMsg.getNackCodeAsString() 
                << " : "         << ackMsg.getNackCode() << endl;


Closing summary

A few points worth noting here:   

  • I am only updating a single RIC, sending out my first Post once I get a valid Client Login Response and then Posting an update each time I receive an AckMsg back from the server. In reality, you will be most likely contributing data to several RICs and therefore, you can submit your multiple Posts at any time once you are connected and have received a successful Client Login response. The trigger for sending further updates out etc will be as and when your data needs updating.
  • As this is a simple tutorial I am not verifying that each of my Posts was acknowledged. In a Production application, you may well want to verify that you receive an AckMsg back for each PostMsg you submit. As mentioned, this can be done by comparing the AckId in the response to the PostId you set in your outgoing PostMsg.
  • I am updating the same two BID and ASK fields in all my Posts, however, you should only send out those Fields that have changed since your previous submission.
  • If the TRCE:MaxMessagesPerSecond element presents in the login response, the message rate posted by the application should not exceed this number.


Additional Resources

If you have any further questions I recommend you post them on our Developer

Forum or contact our Data Helpdesk

Existing Tutorials mentioned above:

Using The Tutorial Source Code

  • Windows

Elektron SDK build path and directory structure has changed, beginning with version 1.2.

For users with ESDK version 1.1.x, project files are provided for Visual Studio 2010, 2012 and 2013 in the ESDK 1.1 Build files subdirectory.

The users using ESDK 1.2, a project file is provided for Visual Studio 2013. Users also have an option to generate the project file for any compiler using the CMake process, described in the Quick Start guide.

The example has been built and tested with the EMA 3.5.0 development kit and can also work with older versions of SDK (that support the RSSL_ENCRYPTED channelType).

  • Linux

Extract the zip file and place the source folder: EMA_CPP_RCC_Tutorial in the EMA examples directory Ema/Examples/Training/Consumer/300_Series_Examples so that it is alongside the EMA example used as the starting point (i.e. 341__MarketPrice__OffStreamPost).

In the EMA_CPP_RCC_Tutorial directory, compile the code using ESDK Build System convention (from the Quick Start guide).


The resulting Consumer executable does not use any arguments.

Tutorial Group: 
EMA Consumer