One can subscribe with a "dynamic view" that filters the response data set to the desired fields { BID, ASK, DAY HIGH, DAY LOW }. Then use the ValueAdd caching library to create a last value cache within the process. When an update arrives, apply it to cache and retrieve the full image from cache to process each and every field as required.

NB: Dynamic views require a premium TREP license.

Hi @Haseuser

When you make a streaming subscription request for an item, you receive the full list of fields in the Initial Image/Refresh event and then subsequent Update events only contain those fields that have changed since the last event - this is to reduce bandwidth by not sending those fields that have not changed.

You may occasionally receive an unsolicited refresh (with the full field list ) but this is usually an exceptional occurrence e.g. after a connection down is restored.

Therefore, the usual implementation of a consumer app is for the app to cache the field values locally and apply the updated fields to the cache as and when they arrive.

As far as dynamically updating your subscription list, you could unsubscribe / re-subscribe items in real time - as and when you need to. However, a more efficient alternative would be to Pause the item stream(s) and then Resume the item stream(s) as and when required.

Items can be paused / resumed individually, or as part of a Batch request or a PauseAll/ResumeAll request. .

You can Pause individual items by making a reissueClient call on the handle(s) of the item(s) concerned with the InteractionType PauseFlag set.

To Resume items you repeat the above but with the InterestAfterRefreshFlag set.

For Batch operations you would populate a RFA_Vector of Handles to pause/resume and pass that to the reissueClient call.

To Pause All / Resume All items you would use the Login handle (rather than individual item handles) with the reissueClient call.

The above Pause and Resume featrues are covered in detail in the RFA Developers Guide pdf file.

Regards,

Umer