What are the advantages/disadvantages for Web Socket Json Request ID per RIC vs Request ID per mu...

Nana
Nana Explorer
in WebSocket API

...lttple Rics?

When using a web socket connection to the Refinitive API what are the advantages and disadvantages of using 1 RIC per Request ID vs using multple RICs per Request ID?

I'm referring to the following function "sendRequest(WebSocket websocket)" which makes use of the following Json string section [websocket.sendText(requestJsonString);)] which can use a single RIC per request ID or an array of RIC.

What are advantages and disadvantages of these approaches?

Tagged:

Best Answer

  • wasin.w
    wasin.w admin
    Answer ✓

    Hello @Nana

    When you send a JSON request message with single ID and array of RICs, it is a Batch request message. You can find more detail regarding the Batch feature in Elektron WebSocket API: Make a Batch Request for Multiple Items tutorial.


    The benefit of Batch request message is it lets you subscribes multiple RIC codes in a single request message.

    Once the ADS receives a Batch Request, it will respond on the same ID of the Request with a Status message that acknowledges receipt of the Batch by indicating a State object with a "Data":"Ok" and "State":"Closed". Then the ADS will send each item refresh response message in separate ID (beginning with the ID of the original Batch Request message + 1). The application needs to manage subscription ID from each Refresh response message.


    Example:

    Request message:

    "ID":2,
      "Key":{
        "Name":
        [
           'VOD.L',
           'BT.L'
        ],
      }    

    ADS Receives a Batch request:

     {
        "ID":2,
        "State":{
          "Data":"Ok",
          "Stream":"Closed",
          "Text":"Processed 2 total items from Batch Request.  2 Ok."
        },
        "Type":"Status"
    }

    Refresh response messages:

    {
       "Fields":{
          "52WK_HIGH":214.6,
          "52WK_LOW":133.48,
    ...
    ...  
          "YRLOW":133.48,
          "YRLO_IND":"15M.Yr.L"
        },
        "ID":3,
        "Key":{
          "Name":"VOD.L",
          "Service":"ELEKTRON_DD"
        },
    ...
    ...  
        "Type":"Refresh"
      }
      {
       "Fields":{
          "52WK_HIGH":268.6,
          "52WK_LOW":201.25,
    ...
    ...  
          "YRLOW":201.25,
          "YRLO_IND":"15M.Yr.L"
        },
        "ID":4,
        "Key":{
          "Name":"BT.L",
          "Service":"ELEKTRON_DD"
        },
    ...

Answers

  • wasin.w
    wasin.w admin

    Hello @Nana

    In summary:

    Single Request message:

    Pro:

    • You can manage the mapping between the stream ID and RIC name after you have sent a request message

    Cons:

    • If you want to subscribe multiple items from Elektron, you need to send multiple request messages

    Batch Request message:

    Pro:

    • You can subscribe multiple items with a single request message

    Cons:

    • The application needs extra process to mapping the stream ID and RIC name from the Refresh Response message instead.
  • umer.nalla
    umer.nalla LSEG

    Hi @Nana

    In addition to everything my colleague said, there is slightly better efficiency with Batch request - saving a few bytes per RIC in the outgoing message as you don't have to repeat the 'ID', 'Key', 'Name' value labels for each RIC you request. Also, less calls to Send the Json to the server.

    However, one thing to bear in mind is that there is a 64K limit on the size of a JSON message so if you are requesting several thousand RICs in a Batch request, you will need to do the additional math to ensure your JSON Request does not exceed the 64k limit - and split your request into multiple smaller batches.

    Having said all that, I personally prefer Single request as I am in control of the StreamID to RIC mapping - rather than having to map later by extracting the StreamID and RIC from the Refresh message etc - unless I was to do hundreds or thousands of RICs where the reduced number of Send calls and smaller message size outweighs the mapping effort (IMHO).


  • Nana
    Nana Explorer

    @umer.nalla @wasin.w


    Guys,

    Thank you for your responses they were very helpful. This got me the information I needed.


    Regards


Categories