can we alter the request message?

Hello @Aalim

Can you please clarify "We want to reduce the network calls" message?

Please be informed that that the nature of the Real-Time platform and the Real-Time APIs (like EMA) is, a connection between the API and Server (ADS) is a long-live connection in order to receive streaming data (Refresh, Update, Status). If you unregister RIC (that you are not interest anymore) using the handle, the API just closed the RIC stream, the rest of other streams remain opened and be able to receive data (Refresh, Update, Status)

If you want to reduce the data volume on the network, there is a View feature that mention by my colleague above. Basically, the default subscription gives you all fields' data of that RIC. With the View feature, it lets you specify only interested FIDs which can reduce network bandwidth between the API and Sever.

Another feature is the "CompressionType" in the EmaConfig.xml configuration file. Please note that the setting must be matched to the ADS setting, so I strongly suggest you contact your Market Data team before try this one.

All comments

Hi @Aalim,

The batch request cannot be modified. You will need to unsubscribe the previous items and re-subscribe to the new batch.

If you are pricing a bucket of instruments and just need to get the initial images for them - its better to use the snapshot feature instead.

@Gurpreet Thanks, then at which scenario this consumer.request() fits in do you think? I can also see it accepts the batch parameter though! Even the documentation of reissue says that "ReqMsg attributes that may change are Priority(), InitialImage(), InterestAfterRefresh(),
* Pause() and Payload ViewData()" these attributes can be altered? Do we have any examples or detailed documentation/tutorials to read more about this feature?

Do you mean Unsubscribe is completely unregister the client and reregister? Because I feel unsubscribing is something different from unregistering? Unregistering and registering often incurres more network calls? Do we really need un registration only to alter the batch of items?

Hello @Aalim

Basically, the Batch request lets the consumer application sends multiple items request in a single request message.

When the Server receives a Batch request message, the Server will send a status message back to the API/Consumer and close that Batch request stream as follows:

Item Name: <not set>
Service Name: ELEKTRON_DD
Item State: Closed / Ok / None / 'Stream closed for batch'

Then the Server will create individual streams for each of the RICs and send data via each stream like the following diagram.

That is the reason you cannot modify (reissue) the Batch stream because the Batch stream is already closed.

However, you can modify those individual RICs streams with reissue() to:

Change request priority.
Pause stream.
Resume stream.
Change View.

I hope this information helps.

Thanks @wasin.w for explaining with pics. So, Do you think we need to unregister the client and then register a new client with new batch with updated item? Or do you feel any other option in EMA? I'm trying to mitigate the server calls overall.

Hello
@Aalim

Can you give me more detail about what kind of "updated items" you want to change in the request?

You want to request entirely new set of RICs and do not interest in previous subscriptions anymore?
Or you just want to add new RICs subscription and keeps existing previous subscription RICs?
Or you want to change fields of the previous subscription?
etc (please explain your scenario).

Hello @Aalim

Thank you for the information.

If you want to remove existing subscription, you need to unsubscribe that item stream handle individually.

Since the Batch request stream is always closed, so you cannot use the Batch request's handle to unsubscribe items directly. However, the Server creates individual streams for each of the RICs and send data via each stream to the API including a new handle information. You can get the items handlers from Batch via the OmmConsumerEvent.handle() method in the OnRefreshMsg callback method as follows:

public void onRefreshMsg(RefreshMsg refreshMsg, OmmConsumerEvent event){
    System.out.println("Item Name: " + (refreshMsg.hasName() ? refreshMsg.name() : "<not set>"));
    ...
    System.out.println("Item Handle: " + event.handle());
}

Then you can use this incoming handle to unsubscribe or modify the stream (pause, resume, change fields subscription, change priority).

I recommend you store the handle for each item when they receive the initial RefreshMsg - in some application-level map etc. Then you can look up and access the handle when you need to close the stream.

Note: The API does not have batch unsubscribe feature.

About adding new items subscription, the consumer application can just send a new batch subscription with the array of new items.

long l = event.handle()) is a long data type. With this method, what API a developer can use to unsubscribe an RIC? Could you shed some light with technical or API level documentation please?

Do you mean to say we can mange all of the above operations with the same consumer and without unregistering the client but with a new batch request? Is my understanding right? Any tiny code example would be really great!

Hi @Aalim,

Yes, the same original consumer object can be used to manage all the streams. Use the handle from the event to unregister (unsubscribe) an item.

ommConsumer.unregister(event.handle());

See the Example 300 MP Close from the RTSDK to see how unregister is used.

We dont want to stop the streaming flow. unregistration will stop the flow!
We want to reduce the network calls in fact!

Hi @Aalim,

Unregister will unsubscribe (stop) that one particular instrument not the whole batch. Isn't that what you are asking?

If you want to reduce the data volume on the network, then please look into the View feature of the SDK - whereby you can limit the number of FIDs that are received in the refresh and update messages.

I would also recommend that you speak with your LSEG account manager to get one of us on the call, so that we can understand and recommend best practice guidelines for your application.

@Gurpreet Thanks for directing me to the LSEG account manager. Before, as community a of developer why do you think I shouldn't ask refinitiv tech queries here as a developer? We're asked to investigate and learn more about refinitiv to build an application around that. If you think you have different opinion, let me know what's this forum for and for types of discussion or clarification should I post my queries here? Have a great day!