question

Upvotes
Accepted
3 0 0 3

How to get FID before creating view and ommit duplicate response

Hello,

I'm trying to change current working OmmConsumer Client to Client with payload, where View is added.

During this I found 2 problems:

1. I need to add to OmmArray int value of field. But how to know FID before creating client, not after msg receiving? Is there any dictionary or something else which I can use to fetch actual FID list to create view?

2. After creating client with view, I get regular stream, which is great. I receive only fields, which are defined in view. But now i have many situations, where data comes as updated, but there is not any change between current and previous values. When I used client without view, updateMsg had only changed fields. Now I have all fields defined in view, even without changed values. So is it possible to ignore duplicates by client configuration or is it a bug, or bad implementation?

I'm using Elektron SDK - Java, libraries:

ema, upa, upaValueAdd and ansipage in version: 3.2.2.0

elektronrefinitiv-realtimeelektron-sdkrrtema-apielektron-message-api
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
12.5k 59 39 63

Hi @rafal.wroblewski,

The dictionary and enumtype files data is made available by requesting for a dictionary, i.e.:

consumer.registerClient(reqMsg.clear().domainType(EmaRdm.MMT_DICTIONARY).name("RWFEnum").filter(EmaRdm.DICTIONARY_NORMAL),appClient);

By doing this, you can use the EMA API to retrieve details from the response to gather details about FIDs and enum values. Refer to the example332__Dictionary__Streaming within the Examples folder for more details.

The ADS server manages the list of FIDs and can change periodically. Using the above example, you can subscribe to the Dictionary to monitor changes. Changes to the dictionary are almost always the result of adding new FIDs/Enum values - I don't recall changes such as deleting FIDs or changing their types to occur - to protect against applications breaking.

I'm not entirely sure I understand what you mean by "...we still receive all data even outside of view". When you specify a View within the API call, you are instructing the server to send only those fields defined within the View. For example, if you only specify quote fields such as BID/BIDSIZE,ASK/ASKSIZE, you will receive those fields upon a refresh. If a quote occurs, you will receive those fields affected by the quote. If you receive a trade, you won't receive any event at all - assuming the trade doesn't affect the quote fields.

Hope this helps.

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
24.7k 86 10 22

Hi @rafal.wroblewski

If you have downloaded and unzipped our Elektron SDK Java edition package - please refer to the 'Java\etc' sub folder.
There you will find the RDMFieldDictionary and enumtype.def files.

The RDMFieldDictionary file contains definitions and brief descriptions of the fields.
The enumtype.def file contains the enumeration values for any ENUMERATED field types

With regards receiving 'duplicate' updates please see the following post which explains that this is expected behaviour and why it happens - Duplicate update messages - the particular question was raised by a Websocket developer - but the explanation remains the same as it is related to ADS / TREP behaviour.

When you are using Views - you are asking the server to filter the fields for you and it does just that. It is not going to filter out the actual Updates it receives from the exchange or feed because the particular fields you are interested in have not changed since the previous update.

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
3 0 0 3

Thank you @Umer Nalla!

enumtype.def file is what i'm looking for :)

Is it possible to get this file in more readable format i.e. java enum or class? I must say that this file is really hard to parse in current format.

Another question: is it possible that FIDs in file can change or append new? Is it possible to get information about changes without refreshing page to find there is new SDK version with changes within?

About duplicates, that answer my question too, thank you!

But if I understand correctly, views are described in documentation as a great way to minimize stream and network usage. If this doesn't happen we still receive all data even outside of view, so it's really confusing.

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
24.7k 86 10 22

Hi @rafal.wroblewski

You add a API to your watchlist so that you can receive email notifications when a new version of the API is released. To do this, go to the Elektron SDK Java page and click the 'Add My Watchlist' link:

You can then amend the Notification settings to ensure you receive the desired notifications

My Notifications-Settings


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
3 0 0 3

@nick.zincone.1

Thank you for your explaination!

I'll check this dictionary requesting and in case any troubles, i'll create another post :)

About my view misunderstood, I'm really sorry. I red again post mentioned by @Umer Nalla and I see now my previous thoughts was wrong, because i missed this sentence:

When TREP receives the above update messages from Feed/Exchange, TREP will send just BID, ASK and MID_PRICE fields for the View consumer

Thank you @Umer Nalla I'll use that watchlist option :)

Now everything seems clear for me, so thank you very much for your responses!

I must say there is the fastest and the best support in my life :)

I can't check all answers as Accept, but all your answers are very valuable for me :)

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.