@gemaangela.vicente

I am not sure if I reading between the lines, but I just want to make sure that the client realises that just adding those Connection_RSSL entries to their config file wont suddenly make the app start working with OMM data. I mention this because I have had clients who were under this mistaken impression.

They will off course need to re-write considerable part of their application to migrate it from SSL connection (and MarketFeed data) to RSSL connection (and OMM Data).

If they do need to rewrite their application and it in only Consumes data (rather than publish/provide data), then it may be seriously worth considering using EMA C++ rather RFA C++.

EMA C++ is a much higher level programming interface - works with OMM/RSSL data and requires far less coding to achieve similar results. For example, the basic RFA C++ OMM StarterConsumer example uses a 700 line source code file to consume some MarketPrice data and output to screen.

The most basic EMA C++ example that consumes some data and outputs to screen uses approx 30 lines source file e.g.

void AppClient::onRefreshMsg( const RefreshMsg& refreshMsg, const OmmConsumerEvent& ) 
{
	cout << refreshMsg << endl;		// defaults to refreshMsg.toString()
}
void AppClient::onUpdateMsg( const UpdateMsg& updateMsg, const OmmConsumerEvent& ) 
{
	cout << updateMsg << endl;		// defaults to updateMsg.toString()
}
void AppClient::onStatusMsg( const StatusMsg& statusMsg, const OmmConsumerEvent& ) 
{
	cout << statusMsg << endl;		// defaults to statusMsg.toString()
}
int main( int argc, char* argv[] )
{ 
	try { 
		AppClient client;
		OmmConsumer consumer( OmmConsumerConfig().host( "localhost:14002" ).username( "user" ) );
		consumer.registerClient( ReqMsg().serviceName( "DIRECT_FEED" ).name( "IBM.N" ), client );
		sleep( 60000 );				// API calls onRefreshMsg(), onUpdateMsg(), or onStatusMsg()
	} catch ( const OmmException& excp ) {
		cout << excp << endl;
	}
	return 0;
}

Granted, the above is an extremely simple example, but it does result in a Login, Item request and output of received data to the screen. The equivalent RFA C++ example would take a few hundred lines of code to implement.

EMA defaults many of the required administrative activities -e.g. Login, Dictionary download - and performs them behind the scenes on the developers behalf. For key functionalities, it is possible to override this default behaviour if / when required - which would require the developer to write some additional code - but even this would typically require far less effort than the RFA equivalent.

Please refer your client to the following Introductory tutorial to EMA C++ EMA Consumer - Introduction.

If they wish they can contrast this with a similar RFA C++ tutorial Tutorial 1 - Creating a barebones RFA application

As mentioned earlier, EMA currently only supports Consuming of and Posting (contribution) of data, so if the client app is a Provider - then presently they would still have to use RFA C++. Although, I understand the Provider functionality may be added to EMA in the future.

@gemaangela.vicente

The APIs that support RSSL transport are RFA (C++, .NET, Java), UPA (C, Java) and Elektron Message API (EMA C++). The latest version of RFA and UPA are 8.x.

However, the current version of EMA C++ (3.0.1) only supports consumer side.

You can check API Compatibility Matrix for more information.

About the RFA configuration, basically it requires connection type, server list and port as you mentioned. However, you may need to check the API Configuration Guide for the full list of parameters.

@gemaangela.vicente

From the configurations, you may be using RFA C++ or RFA.NET.

For RFA OMM interface, RFA supports the following types of connections: RSSL, RSSL_CONS_MCAST, RSSL_PROV, RSSL_NIPROV, and RSSL_NIPROV_MCAST.

• RSSL connection type is for the RSSL consumer application that uses TCP/IP connection to connect to TREP
• RSSL_CONS_MCAST connection type is for the RSSL consumer application that uses multicast connection to connect to TREP
• RSSL_PROV connection type is for the RSSL interactive provider application that uses TCP/IP connection waiting for the connection from the RSSL consumer application
• RSSL_NIPROV connection type is for the RSSL non-interactive provider application that uses TCP/IP connection to connect to TREP for publishing the data
• RSSL_NIPROV_MCAST connection type is for the RSSL non-interactive provider application that uses multicast connection to connect to TREP for publishing the data

Therefore the above configuration means that RFA session that uses the "Connection_RSSL" connection will create a TCP/IP connection to 14002 TCP port on p2ps1 server in order to consumer OMM data from p2ps1 server.

RFA is actually two APIs: RFA/SSL and RFA/RSSL, to migrate from SSL/Marketfeed to RSSL/OMM is a significant rewrite. This rewrite may actually be more effort than migrating to the Elektron SDK.

Consider this non-scientific comparison of API examples:

Please be aware there have been many changes to RSSL/OMM and that older versions (7.0 and earlier) may have interoperability problems with newer TREP versions (2.6, 3.0) due to changes in the service dictionary enumeration.