We are wondering how streamID generated when some of requested of RIC are not found/no permissioned on provider (TREP). Are the counted as one of streamID?
Hi @danai.ongvuttivate
When you make a batch request, the batch request itself is allocated a stream ID - but the batch stream is closed once the server has process the batch.
All valid requests should then have their own stream ID allocated - since each item can update individually.
For the invalid or not permissioned RICs you should receive a status msg type event ?
Each status msg should have a streamID assigned - but since the stream will be closed off, the stream ID may be re-used at some point in the future.
If I have misunderstood your question please clarify.
Thanks.
Thanks. So, when there are 10 RICs (RIC#1 to #10 in sequence) and initial streamID = 20 then, assigned ID will be as below, right?
RIC#1 (Valid): 20+1
RIC#2 (No Permission): 20+2
RIC#3 : 20+3
RIC#4 (RIC Not Found): 20+4
RIC#5 : 20+5
RIC#6 : 20+6
RIC#7 : 20+7
RIC#8 : 20+8
RIC#9 : 20+9
RIC#10 : 20+10
When you say about the reused streamID, it should be on different batch, right?
Is it correct if we can mapping the send RIC directly with streamID by our application without concerning status msg type event returning.
That looks about right - please note that it is the responsibility of the provider application to allocate the stream ID correctly. If you are connecting to a Refinitiv component such at ADS or ERT in Cloud, that should be fine - but for internal providers or 3rd party - you will need to check with the developers of the provider.
For a detailed description please refer to section 13.7.1 Batch Request of the ETA Developer guide.
Thanks. We use TREP here.
can you clarify what you mean by 'Is it correct if we can mapping the send RIC directly with streamID by our application without concerning status msg type event returning'?
You can expect to get status msgs for the Batch request itself and also if one or more of the items in the batch is invalid or not permission, or some other problem scenario.These can be in response to the initial request, or at some later point in time as and when there is a change to an items stream or data state.
Please refer to the developer guide and the examples supplied with the ElektronSDK e.g. rsslMarketPriceHandler.c in the Cpp-C\Eta\Applications\Examples\Consumer folder or similar example for ETA Java
Hello @danai.ongvuttivate
Regarding the "Is it correct if we can mapping the send RIC directly with streamID by our application without concerning status msg type event returning." message, do you mean the application wants to automatic mapping the requested RIC with streamID based on the #RIC1 to #RIC10 logic above?Like @umer.nalla has mention, the streamID of each item in the Bath request is assigned by the provider application. The application should mapping the RIC with the streamID from the Refresh or Status response messages return from the API.
