question

Upvotes
Accepted
43 1 0 1

ETA: request a view, but get an error: State: Open/Ok/Invalid view - text: "All is well"

Not sure which FID triggered this error.

If I add add 2 FIDs(22 and 25), the same as the sample, it works fine

elektronrefinitiv-realtimeelektron-sdkrrteta-apielektron-transport-apifields
icon clock
10 |1500

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

10 Answers

Upvotes
Accepted
23k 22 9 14
@ayan@jump

To me, what you describe in the follow-up is not an intended usage of the view request. Which is why expect you see this response. It does not reduce the traffic by much, but introduces lots of unnecessary overhead. I would not use view for this use case.

I have only mentioned the service filtering for completeness of the discussion. Deployed TREP, prevalent in the past, is replaced by convenient Elektron Hosted, EaaS, Elektron Connect, if your org were using hosted you would have known. Therefore it will not be possible to effect.

I think the right approach to design for your use case is not to use view, to use streaming subscription as described in the documentation and examples and to process updates as per your requirement when they arrive.

icon clock
10 |1500

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

Upvotes
9.5k 10 5 7

Hello @ayan@jump

Could you share the application source code when the application creates the view request?

icon clock
10 |1500

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

Upvotes
9.5k 10 5 7

Hello @ayan@jump

Invalid view indicates that the requested view is invalid, possibly due to bad formatting. Please refer to the section 13.8 Dynamic View Use in Developers Guide of Transport API Java Edition or Transport API C Edition. The section explains how to create a view request and example source code.

icon clock
10 |1500

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

Upvotes
43 1 0 1

Yes, I am referring to 13.8 in Developer's guide. It works fine when the view contains only BID and ASK. But fails if I add a lot of fields(>100 fields). The relevant code is attached.fids.txt


fids.txt (2.8 KiB)
icon clock
10 |1500

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

Upvotes
43 1 0 1

Is there a limit on the number of fields for a view? Actually we are planning to add more fields in the future.

icon clock
10 |1500

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

Upvotes
23k 22 9 14

Hello @ayan@jump,

To explain a little about the nature of the view requests, the more fields you are looking to receive, the less sense it makes to use view feature, but more sense to process or not to process on the client tier depending if required.

Because on every update, and most of them are significantly smaller then 100 fields, a provider that supports view, instead of publishing update as is, will have to first check on every field specified within the view request. I.e. overhead introduced should be considered. The reduction of the data flow from provider to consumer should be weighted against the overhead, it makes most sense with significant bandwidth reduction and lesser overhead.

Also, for fields that do not update often, such as TRADE_DATE, it does not make sense to check for it in every update by including it in view, it will very likely not be in the update, but if specified in view it will have to be checked. Such fields are better retrieved when needed, for example, as snapshot/non-streaming request.

Additionally, may be relevant, if you are connecting to a deployed TREP within your organization, you may be able to request from your market data team to enable service-level filtering, i.e. service will only publish fields that are required.

Therefore, to me, 100+ field view is way too fat, not a good use.

icon clock
10 |1500

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

Upvotes
43 1 0 1

Thanks for the explanation, Zoya. But what's the reason it reports an invalid view?

We are only interested in a subset of fields. So hope to reduce the traffic via view.

Also we may update the subset of interested fields occasionally. View seems provide us such a capability.

As for service-level filtering, it's done on the server/provider side, right? If we send such a request to Thomson Reuters, how long does it take to be effective for our session?

icon clock
10 |1500

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

Upvotes
43 1 0 1

Our top priority is to reduce the traffic, since we are going to subscribe to thousands of symbols.

Could you give more details on streaming subscription, please? Is it just a request without view?

icon clock
10 |1500

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

Upvotes
23k 22 9 14

@ayan@jump

Yes. It's the request without view. The requests can be streaming (image = complete set of fields, followed by the updates) or snapshot ( image = complete set of fields, once-off).

To subscribe 1000s of symbols the feature you would like for efficiency is Batch, please see in developer guide and in Consumer example within Elektron SDK->ETA.

icon clock
10 |1500

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

Upvotes
43 1 0 1

yes, I am doing several batch requests, since I believe one single batch request may not be able to include 10k symbols.

icon clock
10 |1500

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

Click below to post an Idea Post Idea