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.

Hello @ayan@jump

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

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.

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

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

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.

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?

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?

@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.

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