SSL and RSSL connection in EMAConfig.xml

gaurav.mahajan

Hi,

We are in process of migrating from RFA 7.6.0.E1, to EMA Api. In RFA we were connecting using reuters_config.xml, where we are having 2 types of connection SSL and RSSL. SSL was primarily used for Streaming and NonStreaming subscription. On the other hand RSSL was used for getting data using Real time snapshot request.

In Documentation, it was mentioned that EMA uses RSSL_SOCKET and i was able to setup this configuration and connect successfully. Can you please share if EMA supports SSL connection by any chance and if not is there a way we can setup two different ports for two different RSSL connection. OR Can the single connection will be able to serve both Streaming\Non-Streaming subscription and adhoc requests. Request your valuable inputs.

umer.nalla

Hi @gaurav.mahajan

EMA does not support the legacy SSL connection.

You can use RSSL for both Streaming and Snapshot(non-streaming) realtime data.

Any data you previously subscribed to using SSL connection would have been delivered to your app in MarketFeed format - whereas RSSL data is delivered in OMM format.

Since you are already consuming OMM data from an RSSL connection, then you should be familiar decoding OMM data (and therefore the difference between MF and OMM data).

A single Consumer instance in EMA (using an RSSL connection) can consumer both streaming and non-streaming data.

If you refer to the examples that come with the EMA package, you will see that example102 shows how to make a snapshot request:

consumer.registerClient(reqMsg.serviceName("DIRECT_FEED").name("IBM.N").interestAfterRefresh(false), appClient);

In the above code snippet, the interestAfterRefresh attribute is explicitly set to false - to make a non-streaming Snapshot request. The default value for this attribute is true - i.e. streaming request.

As you can see the attribute is set on a per instrument basis when you register the callback handler client for each instrument. Therefore you can make multiple requests with a single Consumer instance - for a mixture of streaming and non-streaming requests.

When you call registerClient you provide the callback client as the 2nd parameter - appClient - in the above example. Therefore, if you wanted, you could use different Callback client implementation classes for Snapshot request and for streaming requests - or you could just use the same client class for both - depending on your application design.

Just to be clear here that you can use a single instance of AppClient for multiple instruments. You can retrieve the RIC code in the callback handlers using the name() method of the Refresh/Update/StatusMsg that you are passed in the callback handler.

Alternatively, you can pass in a Closure when calling registerClient and then retrieve the closure value from the OmmConsumerEvent that is passed to you in the callback handler.

See this post for more details on closures.