Problem retrieving all the market prices for batch request.

Options
Gabriele.Casalinuovo
Gabriele.Casalinuovo Explorer
in RFA

I am composing a batch request to get the prices of several options of one underlying. The payload of the request contains 1191 option ticker in the form e.g. id1632097629324.

I received back the prices for several options, but for most of them the output message that is notified to the processEvent callback is not parsable. If I count the amount of correct output message and the amount of non parsable messages I get the original 1191 number of subscribed ticker.

In the attachment I show the type of request that I am sending and the un-parsable request that I receive for some of the subscribed ticker.

I would like to kindly ask you how I can avoid this and be sure to get data for each of the ticker I package in the request payload.

Thanks in advace

Best regards

requestresponsemsg.txt

Tagged:

Best Answer

  • umer.nalla
    umer.nalla LSEG
    Answer ✓

    Hi Gabriele,

    Just need to step back a bit and clarify a few basics.

    When you make a streaming request for a valid instrument, you initially receive a Refresh response, followed by any future Update response(s). If there is a change to the State/Status of the item you may also receive a Status response.

    For an Invalid / non permissioned instrument, you would expect to receive a Status response only. Note that the streamState will be Closed - i.e. the event stream has been closed and therefore you would not get any future events such as Updates etc.

    Therefore, regardless of single item request or Batch request, you should get back a Status response which would contain the symbol name for the Invalid request.

    e.g. the following is output from the StarterConsumer_BatchView example for the invalid instrument UMER.L

    Received MMT_MARKET_PRICE Status
        serviceName : ELEKTRON_DD
        symbolName  : UMER.L
        streamState : Closed
        dataState   : Suspect
        statusCode  : NotFound
        statusText  : The record could not be found
        itemName    : UMER.L
        itemHandle  : 0000000004564260
        itemFrom    : BatchItemList1.

    You should never receive an Update type response for an invalid Item.

    If you can output / log the Status response then this should provide additional information on why some of your instruments are failing. e.g. invalid instrument or permission denied etc.

Answers

  • zoya faberov
    zoya faberov ✭✭✭✭✭

    Hello Gabriele,

    Are you able to request the RICs that are not being returned as single subscription requests?

  • Gabriele.Casalinuovo
    Gabriele.Casalinuovo Explorer

    Hi, thanks for the quick answer.

    Yes, I am able to request the RICs as single subscription.

    The problem is that, in the context of a batch request, packaged with a lot of RICs, some of them are not retrieved and I cannot see which one, since the HAS_ATTRIB_INFO is false and so the messge.getAttribInfo().getName() returns null.

  • zoya faberov
    zoya faberov ✭✭✭✭✭

    There are two sub-questions:

    1. How to see in the update what item is being returned?

    What API are you using (are you using RFAJ 8)?

    If yes, try adding to request an indication flag:

    indicationFlags |= OMMMsg.Indication.ATTRIB_INFO_IN_UPDATES;

    You should see AttribInfo.

    2. Why more items are not being retuned?

    What infra are you connecting to? What is your permission (is your user permissioned for more items at a time than you are seeing returned)?

  • Thomas P. Fuller
    Thomas P. Fuller Explorer

    Are you handling events of type

    com.reuters.rfa.omm.OMMMsg$MsgType.STATUS_RESP

    ?

    In my experience when a user requests a RIC which doesn't exist, the message returned in this stream will indicate there's a problem -- for example:

    queryMarketPriceService("FOOO.N");

    results in:

    StatusResponse [code=NOT_FOUND, streamState=CLOSED, dataState=SUSPECT, text=The record could not be found]]

    Now granted this doesn't have the RIC but it's associated with the same handle that was returned when the query was made, so I can associate it directly with the same, in this case, market price.

    Tom

  • Gabriele.Casalinuovo
    Gabriele.Casalinuovo Explorer

    Hi,

    Thanks for your answers. I was able to figure out the issue I had. I am now able to get all the events and parse them; the ATTRIB_INFO_IN_UPDATES, gives me the evidence of the RICs I am subscribed to, so now it seems that I have all the prices.

    Thanks

    Best regards

Categories