question

Upvotes
Accepted
1 1 2 1

Not recieving Timestamps in Update messages

Using RFA API C++ I am requesting some data using View functionality. But I am frequently not receiving the QUOTIM_MS in the update messages.

treprfarfa-apic++quoteupdate-message
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
Accepted
25.3k 87 12 25

Hi @hamza.khalid

The RFA API is 'content-agnostic' and will just pass on whatever data it receives from the server.

If you are getting updates without a particular field, then the most likely cause is there was no such field present in that update as sent out by the server.

For example, if you received an update containing something other than a Quote - you would not get a QUOTIM_MS - as the update did not represent Quote type activity.

However, if you feel the above is not a valid explanation for your particular incidents, then please raise Content incorrect/incomplete type ticket at MyRefinitiv - with examples of dates + times, price values etc where you believe data to be missing.


icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Hi, So in the update messages if I don't receive timestamp, does is it mean that the Timestamp is the same as it was in the previously received message of that particular Symbol. For example :

First update Message : BidPrice 12.00, BidSize: 3000, QUOTIM_MS: 3456700

Second update Message : BidPrice 12.50, BidSize: 1000

Now, there was no QUOTIM_MS in the second message, does that mean for the second BID event the QUOTIM_MS is the same as the first because the definition of 'update messages' promise to send only those attributes which are changed.

Hi @hamza.khalid

I am not a content expert so cannot provide definitive advice on the scenario described above. However, if I received the 2nd update without a timestamp field I would assume the previous timestamp still applied. However, if this did not make sense based on the fields present in the 2nd update, I would query with a Content specialist via MyRefinitiv as described as above.

As you are using a view it may be possible that the timestamp is in a different field for the 2nd update but is being filtered out by the server due to your View request. Again the Content specialist could advise on this.

I would also enable the Trace as described by my colleague and confirm which fields are definitely being received on the wire from the server - i.e. just to be sure it is not an application-level issue.

Also, one more thing sometimes I only receive BIDSIZE in the update message without any BIDPrice, does that mean the new price is same as the price of the previous Bid event of a particular instrument?


I have tried using the configs that your colleague has suggested and it seems that it is not an application level issue.

Hi @hamza.khalid

As mentioned, I am not a content expert - most of us on these forums are on the API side - that is why we recommend you raise content queries with the content helpdesk.

Logically speaking, if you receive only a BIDSIZE in an update then yes it would indicate that only the number of orders has changed but the BID Price remains the same.

Upvotes
24.4k 53 17 14

Hello @hamza.khalid

You may enable the RFA trace file to check if the API receives the QUOTIM_MS field from the your server (if that field is updated).

You can enable the RFA RSSL trace with the following paremters:

\Connections\<ConnectionName>\traceMsgToFile = true
\Connections\<ConnectionName>\traceMsgDomains = "all"
\Connections\<ConnectionName>\traceMsgMaxMsgSize = 5000000
\Connections\<ConnectionName>\traceMsgMultipleFiles = true
\Connections\<ConnectionName>\tracePing = true
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.