How to get a list of items per request.

anton.filimonov.ext

Hello.

We are trying to transfer our code from RFA to EME (as adviced here: https://community.developers.refinitiv.com/questions/80627/after-switching-deployed-application-with-rfa-to-n.html?childToView=80967#answer-80967). But from totorial looks like we can get data only for a one item per request. So my question is this a usual situation or is it possible to get data for the list of items per request? And how we can inform our application what all data already requested and ready for use instead of waiting one or more minuts (Thread.sleep(60000);).

Could you please give me a piece of code or link to the suitable example.

Thank you in advance.

Find more posts tagged with

java

elektron

elektron-sdk

refinitiv-realtime

rrt

ema-api

Accepted answers

wasin.w

Hello @anton.filimonov.ext

You can request multiple items in one request message using the Batch feature. Please see more detail in the following resources:

EMA Java example: ex370_MP_Batch
Enterprise Messaging API (Java) - Batch and View features article

Could you please clarify the "how we can inform our application what all data already requested and ready for use instead" message? Basically, when the API receives item data from the Provider, it will dispatch to the onRefreshMsg and onUpdateMsg callback functions on the application side. If you want to know if all item data has been received, you can count the number of item refresh response messages in the onRefreshMsg callback function.

I suggest you check the following resources regarding the Refinitiv Real-Time behavior:

All comments

wasin.w

Hello @anton.filimonov.ext

You can request multiple items in one request message using the Batch feature. Please see more detail in the following resources:

EMA Java example: ex370_MP_Batch
Enterprise Messaging API (Java) - Batch and View features article

I suggest you check the following resources regarding the Refinitiv Real-Time behavior:

anton.filimonov.ext

Hello wasin.waeosri. Thank you for your response and your help. More or less your understand my question right. So, I will try to look on your links before. I hope they helps me fix my issue.

umer.nalla

Hi @anton.filimonov.ext

Note that for the examples you are looking at the Thread.sleep(60000) is just there to allow the example to run for a while before exiting. The data/event callbacks are on the API thread context and invoked asynchronously - please follow the advice above as provided by my colleague.

anton.filimonov.ext

umer.nalla wasin.waeosri

New question from my side.

In RFA was possible set the quality of request. For example Best/Worst rate and Best/Worst Timeliness. Is this attributes so critical and how we can set them in EMA api?

Tahnk you in advance.

umer.nalla

Hi @anton.filimonov.ext

Can you confirm if you have multiple source/services available on your infrastructure that provide different QOS in terms of rate and Timeliness - otherwise these QOS settings will have no impact?

With regards, how to set the QOS please see the Ema example 101_MP_QosPriority included with the RTSDK which shows how to set the best rates.

e.g. for EMA Java

consumer.registerClient(reqMsg.serviceName("DIRECT_FEED").name("IBM.N").qos(Timeliness.REALTIME, Rate.TICK_BY_TICK).priority(2,1), appClient);

anton.filimonov.ext

umer.nalla.

Thank you for your replay.

Yes, I have already seen this example. But looks like it is possible set only Best values and not Worst.

I am new in this API, and can't answer compleatly on your question. But looks like we have only one service for request. So, you can advice to us not use quality attributes, isn't it?

And only for more understanding of answear on my question "how we can inform our application what all data already requested and ready for use instead". wasin.waeosri advised store number of items which we requested and every time then onRefreshMsg or onUpdatehMsg calls we should calculate the namber of this call for the unique item and compare it with the stored value (number of requested items). But in real situation I can see that if I request data for the 40 items for example then I will receive may be 10 or a little bit more number of fresh data. So we finishing waiting data after one minute left instead to receiving all 40 (for example) responces (items). Overwise we should wait for the wole list of item wole day or may be more.

Sorry for my English. If this is not understandable, please tell me, I will try to parafrase it.

umer.nalla

Hi @anton.filimonov.ext

The Qos functionality is applicable where a customer has access to multiple services with differing QOS levels - so they can specify the rates they are prepared to accept. If you have only a single source then setting the QOs is not applicable.

With regards to your other question, when you registerclient() an instrument, you should always receive one of the following

an initial RefreshMsg for each valid instrument
a StatusMsg with Closed state for any invalid request (e.g. not licenced to the RIC, invalid RIC code or RIC not available for some other reason).

So, if you count the number of RefreshMsg + Status Msg with Close stream state - this should provide a way of confirming when all instrument requests have been processed and responded to by the server.

e.g.

statusMsg.getState().getStreamState() == StreamState::ClosedEnum

where StreamState::ClosedEnum indicates the Stream was closed.

For the RefreshMsg - you should also only count if it is a Solicited Refresh Msg

refreshMsg.getSolicited()

to ensure it is the initial Refresh for an instrument - not a subsequent one (e.g. received after data recovery scenario).

EXPLORE OUR SITES