How to set ConflationInfo?

Xiao.Xiao

The updates we received doesn’t seem to respect the ConflationInfo requested. For the request below:

SENT:

{

"ConflationInfo":{

"Count":1,

"Time":1000

"ID":2,

"Key":{

"Name":"/IBM.N" (I am using this for now as I am waiting for real-time feed entitlement)

}, …}

The consecutive updates we received has timestamps:

"SALTIM":"14:13:54",

"SALTIM":"14:14:57",

"SALTIM":"14:15:53",

Another example:

"SALTIM":"16:16:45",

"SALTIM":"16:17:12",

"SALTIM":"16:18:58",

"SALTIM":"16:19:27",

Find more posts tagged with

elektron

conflation

elektron-sdk

refinitiv-realtime

rdp-api

update-message

Accepted answers

umer.nalla

Hi @Xiao.Xiao

You cannot specify a Conflation time in your Request Msg, you can only specify the following Conflation related attribute in your Request Msg

ConfInfoInUpdates

boolean

Specifies whether the consumer wants ConflationInfo in updates. ConfInfoInUpdates defaults to false.

If you set the above in your Request Message, you can receive the following in your Update responses:

ConflationInfo

object

When requested, provides the information about any conflation logic that may have been applied to this event.

If you want to receive data with different conflation rates, you need to ask your Market Data team if they can create a Conflated service for you which meets your requirements.

All comments

umer.nalla

Hi @Xiao.Xiao

You cannot specify a Conflation time in your Request Msg, you can only specify the following Conflation related attribute in your Request Msg

ConfInfoInUpdates

boolean

Specifies whether the consumer wants ConflationInfo in updates. ConfInfoInUpdates defaults to false.

If you set the above in your Request Message, you can receive the following in your Update responses:

ConflationInfo

object

When requested, provides the information about any conflation logic that may have been applied to this event.

If you want to receive data with different conflation rates, you need to ask your Market Data team if they can create a Conflated service for you which meets your requirements.

Xiao.Xiao

@umer.nalla I set this variable but I don't think I get what the conflation logic. Something wrong with my request?

SENT:
{
"ConfInfoInUpdates":true,
"ID":2,
"Key":{
"Name":"/IBM.N"
},
"View":[
"TRDPRC_1",
"TRDTIM_1",
"SALTIM",
"EXCHTIM",
"TRADE_DATE",
"ACVOL_UNS",
"BID",
"ASK",
"CURRENCY",
"ASK_TM_NS",
"BID_TM_NS"
]
}

RECEIVED:
[
{
"DoNotConflate":true,
"Fields":{
"ACVOL_UNS":212538,
"ASK":138.63,
"BID":138.6,
"EXCHTIM":"16:23:04",
"SALTIM":"16:23:04",
"TRDPRC_1":138.61,
"TRDTIM_1":"16:23:00"
},
"ID":2,
"Key":{
"Name":"/IBM.N",
"Service":"ELEKTRON_DD"
},
"SeqNumber":3518,
"Type":"Update",
"UpdateType":"Multiple"
}
]

umer.nalla

Hi @Xiao.Xiao

Can you confirm if the service you are consuming from is actually a truly Conflated service?

I do not have an ADS with a Conflated service to test with at this point in time - so cannot confirm this, but I suspect that the service you are consuming from is not conflated and therefore you do not receive any Conflation information in the Updates.

In the Refresh Message what do you see for Qos - Timeliness and Rate ?

You included an example update with the "DoNotConflate" attribute - which indicates that the update includes Trade data and therefore should not be conflated. This may also indicate that you are consuming from a JitConflated service i.e. Just-in-time conflated, meaning that quality is typically tick-by-tick, but if burst data occurs (or if a component cannot keep up with tick-by-tick delivery), multiple updates are combined into a single update to reduce traffic. This value is usually considered a lower quality than TickByTick

If you were consuming from a truly conflated service, then the Rate would be indicated as TimeConflated along with a RateInfo value indicating the Conflation interval.

Xiao.Xiao

Hi @umer.nalla

thanks for the explanation, here is the Qos:

"Qos":{ "Rate":"JitConflated", "Timeliness":"Realtime" }

as you suspected...

So just to confirm my understanding:

the gaps between consecutive timestamps in my original post, where the updates are around 30 seconds, are due to "burst data occurs" (?) Is it possible for users to control the update interval in some way?
the behavior we see here indicates that I don't have conflated service to start with
even if I had, the conflation cannot be configured by users but the Market Data team

umer.nalla

Hi @Xiao.Xiao

The gaps could be because you are using a View and the updates to the fields in your view are not occuring more often and / or that particular RIC is not that active. It could also be because Msg Packing is enabled on the ADS you are connecting. I am not a TREP expert and you have not provided enough data - so cannot confirm if this is the cause.
You are most likely connecting to a Bandwidth optimised Trade Safe feed which is i.e. upto 3 (non-trade) Updates a second + all Trade updates
If you are connecting to ERT in Cloud, then the Trade Safe BoN feed is all that is currently available. If you are connecting to a TREP, you can ask your Market Data team to configured a different conflation rate service for you.

A user cannot configure the conflation rate from his application - since it can require considerable processing power for the TREP components to Conflate data - and so it left in the hands of the Market Data team to configure, so they can access the potential impact on performance etc before adding a conflated service.

Xiao.Xiao

thanks @umer.nalla, may I have one more follow up on the first point? I really appreciate that!

The gaps has been there regardless of the variation of query I sent. For the example, these gaps were observed without using VIEW and the RIC I was looking at is IBM.N durning market hours - I was surprised that a constantly traded big cap like IBM only have a few updates...

Please let me know how to check the enabled MsgPacking, but this is the response from the authentication step:

RECEIVED: [ { "Domain":"Login", "Elements":{ "MaxMsgSize":61430, "PingTimeout":30 }, "ID":1, "Key":{ "Elements":{ "AllowSuspectData":1, "ApplicationId":"256", "ApplicationName":"ADS", "AuthenticationErrorCode":0, "AuthenticationErrorText":{ "Data":null, "Type":"AsciiString" }, "AuthenticationTTReissue":1561480846, "Position":"10.194.238.132/u6065010-tpm-a.ten.thomsonreuters.com", "ProvidePermissionExpressions":1, "ProvidePermissionProfile":0, "SingleOpen":1, "SupportBatchRequests":7, "SupportEnhancedSymbolList":1, "SupportOMMPost":1, "SupportOptimizedPauseResume":0, "SupportPauseResume":0, "SupportStandby":0, "SupportViewRequests":1 }, "Name":"AQIC5wM2LY4SfcxRdBbl%2B8dgyd%2BWx0aChwHOX0vyMMQa05E%3D%40AAJTSQACNDAAAlNLABQtODAwODE1MjU3ODgzODY3MDg1MAACUzEAAjM4%23" }, "State":{ "Data":"Ok", "Stream":"Open", "Text":"Login accepted by host ads-premium-az2-blue-9-main-prd.use1-az2." }, "Type":"Refresh" } ]

umer.nalla

Hi @Xiao.Xiao

Based on the most recent bit of information you have provided, you are connecting to ERT in Cloud and this operates a Bandwidth optimized Tradesafe conflation as I described earlier i.e. a upto 3 Updates a second - but it wont conflate Trade type updates - so you will receive all Trades even if that exceeds the 3 update limit.

If you believe you are missing information, you should raise a ticket with the Content helpdesk and ask them to confirm the tick history for your instrument.

EXPLORE OUR SITES