Hi @brajesh.shuklafil,

Even if you submit a batch request (one request for several RICs) EMA calls you back in the onRefreshMsg() methods several times for each individual RIC. For example if you request “TRI.N” and “IBM.N” (as done in the 370__MarketPrice__Batch example), EMA calls the onRefreshMsg() method twice, once for “TRI.N” and once for “IBM.N”. If you’re interested in the values of these two RICs (or all the currency RICs of your use case) you must wait for EMA to call the onRefreshMsg() method for all these instruments.

Beware that if there’s a problem with an instrument (e.g. if it doesn’t exist or if you do not have the proper permissions), for this instrument you will not be called in onRefreshMsg() but in onStatusMsg () only.

The onUpdateMsg() method is not called if you request the currency RICs in snapshot.

Hi Olivier, Thanks for your inputs. You know that is my problem onRefreshMsg is called for those instruments which have values. How onRefreshMsg is being called from OnstatusMsg();

I suspect that you want to retrieve the instruments values when EMA first calls you in onStatusMsg().This is not possible I’m afraid. Let me explain why:

If you run the 370__MarketPrice__Batch example, you’ll see that onStatusMsg() is called before any RefreshMsg is received. The item state onStatusMsg() sends you (“Closed / Ok / None / 'Batch request acknowledged.”) tells you that your batch request has been successfully received and acknowledged. It also tells you that the item stream associated to your batch request is closed. That is perfectly normal. Actually, the data of the instruments you requested (“TRI.N” and “IBM.N”) will come later in two separated item streams. This is what actually happens when onRefreshMsg() is called for “TRI.N” and then for “IBM.N” (or vice versa). When EMA calls onStatusMsg() the first time, it doesn’t have the “TRI.N” and “IBM.N” data yet. At this point there’s nothing you can do to retrieve this data. The only option is to wait for EMA to call you back in onRefreshMsg() for the two instruments.

Hi @Olivier

Let me tell what I am trying to achieve:

currently I am passing RICS from text file as an input like
Hide Copy Code

AUD=
AUDSW=
AUD2W=
AUD3W=
AED=
AEDSW=
AED2W=
AED3W=

and I need to write csv like this

1.AUD=, 'BID' value of AUD,'GEN_VAL1' of AUDSW=,'GEN_VAL1' of AUD1W=,'GEN_VAL1' of AUD2W=,'GEN_VAL1' of AUD3W=
2.AED=, 'BID' value of AED,'GEN_VAL1' of AEDSW=,'GEN_VAL1' of AED1W=,'GEN_VAL1' of AED2W=,'GEN_VAL1' of AED3W=

This I was able to achieve by running loops if onRefreshMsg was returning every currency RICS. Now I need to store input and output in a separate data structure and need to run compare between them and create the csv as per requirements. Any alternative approach you can suggest?

Hi @Olivier

Can you please explain how Batch snapshot request is getting terminated in main().

UInt64 handle = consumer.registerClient(ReqMsg()

.serviceName("ELEKTRON_DD").interestAfterRefresh(false)

.payload(ElementList().addArray(":ItemList",

ricArray).complete()), client);

sleep(1200000);

Right now I am able to store the RICS and its output from Decode Function in a Map but I am struggling to use this Map in main() function.

Hi @brajesh.shuklafil ,

I’m not sure to understand what you mean by “is getting terminated in main()”.

When you submit your batch snapshot request by calling registerClient(), an item stream is opened for this request. It is only used for sending the request, not for retrieving the values of the instruments you requested. These values will come in separated item streams via the onRefreshMsg() callback (This what I explained in my other answer above). Once your batch request is sent, it is automatically closed. You can just forget it. You do not even have to call unregister() with the handle you received from the registerClient() call.

Hi @brajseh.shuklafil

The non-deterministic behavior that you describe in the comment above makes me think of a multi-threading related issue. Because you call sleep just after you registered your client callback, I presume that your application relies on the API_DISPATCH operation model (that is the default EMA operation model). With this model your application receives events from an EMA background thread while (in your case) the main thread of the application is sleeping. This model looks simple in the examples, but it requires your application to be thread safe and to implement a synchronization mechanism between your main application thread and the EMA background thread. This is not always trivial and if it’s not done properly it may result in non-deterministic behaviors as the one you described.

To avoid this kind of issues and if you are not totally comfortable with multi-threading techniques, I recommend that you use the USER_DISPATCH EMA operation model instead. This model requires your application to implement a dispatching loop (that may seem more complicated), but at the end of the day your application will be single-threaded and this will make your programmer’s life much simpler.

I recommend you to have a look at the 130__MarketPrice__UserDisp example that demonstrates how to use the USER_DISPATCH operation model. For a better understanding of this operation model I recommend you to compare the main function of 130__MarketPrice__UserDisp to the one of the 100__MarketPrice__Streaming example that uses the API_DISPATCH operation model.

I hope this will help in you investigations