For a deeper look into our Elektron API, look into:
Overview | Quickstart | Documentation | Downloads | Tutorials | Articles
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",
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.
@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" } ]
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.
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:
Hi @Xiao.Xiao
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.
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" } ]
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.