When are these "Updates" of domain "Source" triggered ?

piotr.wroblewski

Client has upgraded and switched to Websocket API this week.

We sometimes receive the following message

[

{

"ID": 2,

"Type": "Update",

"Domain": "Source",

"UpdateType": "Unspecified",

"DoNotConflate": true,

"Key": {

"Service": "BLOOMBERG",

"Filter": 3

"Map": {

"KeyType": "UInt",

"Entries": [

{

"Action": "Update",

"Key": 129,

"FilterList": {

"Entries": [

{

"ID": 1,

"Action": "Set",

"Elements": {

"Name": "BLOOMBERG",

"SupportsQoSRange": 0,

"Capabilities": {

"Type": "Array",

"Data": {

"Type": "UInt",

"Data": [

]

}

"QoS": {

"Type": "Array",

"Data": {

"Type": "Qos",

"Data": [

{

"Timeliness": "Realtime",

"Rate": "TimeConflated",

"RateInfo": 300

}

]

}

"DictionariesProvided": {

"Type": "Array",

"Data": {

"Type": "AsciiString",

"Data": [

"RWFFld",

"RWFEnum"

]

}

"DictionariesUsed": {

"Type": "Array",

"Data": {

"Type": "AsciiString",

"Data": [

"RWFFld",

"RWFEnum"

]

}

"Vendor": "BloombergLP",

"IsSource": 1,

"SupportsOutOfBandSnapshots": 0,

"AcceptingConsumerStatus": 1

}

]

}

]

}

]

Whereas, we always expect to have at the end this section (which is missing above):

{

"ID": 2,

"Action": "Set",

"Elements": {

"ServiceState": 1,

"AcceptingRequests": 1

}

We understood that this message (with ID:2) only appears in "Refresh" message all the time and in "Update" message when the "filter" is at least "4".

We actually use this second section (ID:2) to determiner whether the service is still up or not. In case the Service is not UP (or the message is missing), we deduce that the service is not operational and we stop the connection (which is why the client is having issues).

By the way, the client is not reproducing the issue in their UAT environment, in which no "Update" with domain "Source" is seen from the logs.

My questions are the following:

When are these "Updates" of domain "Source" triggered ? If we can find a way to not trigger these actions, this could be a temporary workaround to unblock the client production ?
What is the guideline from LSEG regarding these messages ?
- Should we assume the second section of the message (status update) will always be present ?
- What should we do when the message is not present ? Stopping the connection like we do today ? Or just do nothing ?
- Should we increase the filter level (currently set to 3) to 4 to get the status update everytime ? What is the recommendation for that ?

Find more posts tagged with

trep

websockets

source-directory

#technology

#product

Accepted answers

All comments

wasin.w V3

Hello @piotr.wroblewski

I checked the given WebSocket Source Directory Update message. The update message contains the information about:

the Service Name is BLOOMBERG
SupportsOutOfBandSnapshots = 0 means the Snapshot requests cannot be made if the OpenLimit is reached (the OpenLimit should be available in a Refresh message)
AcceptingConsumerStatus = 1 means the service can accept and process messages related to Source Mirroring. This is the default behavior.

The BLOOMBERG service changed may be related to these properties changed.

I did a quick test on my local ADS. I sent the following source directory request message:

{

  "Domain":"Source",

  "ID":3,

  "Key":{

    "Filter":3

  }

}

The Refresh message contains the following State information:

{

                "Action":"Set",

                "Elements":{

                  "AcceptingRequests":1,

                  "ServiceState":1

},

It is possible that the Service changed that made the backend server sent the status message to the client application is not related to the ServiceState and AcceptingRequest or the Service availability status.

Question 1: When are these "Updates" of domain "Source" triggered ? If we can find a way to not trigger these actions, this could be a temporary workaround to unblock the client production?

Answer:

The https://developers.lseg.com/en/api-catalog/real-time-opnsrc/websocket-api is a Server-Side API. All incoming messages are generated from the LSEG Real-Time Platform. The Source Directory message (messages with "Domain": "Source") is about the Services on the RTDS/RTO server side.

I am assuming that the client is connecting to their local ADS server, so the issue needs to be investigated on the ADS server to verify why it sent this status message to a consumer side.

Question 2: What is the guideline from LSEG regarding these messages?

Answer:

My suggestion is the client should contact the ADS server team to verify the meaning of this Update message first. The server team should be able to tell what the consumer side should do when receive this kind of message.

In my opinion, if the Update messages do not contain the Service availability status information (ServiceState and AcceptingRequest). It means those properties values remain the same from the Refresh message. If the Refresh message contains ServiceState 1 (Up) and AcceptingRequest 1 (Yes), it means new requests and reissue requests can be successfully processed. A consumer application should not stop a connection.

Regarding the Filter Information. The value 4 means the Group Filter only as follows. I do not think it helps the client.

I have tried on my side. The ADS returns the following Source Directory Refresh message.

RECEIVED: 

[

  {

    "Domain":"Source",

    "ID":3,

    "Key":{

      "Filter":4

    },

    "Map":{

      "Entries":[

        {

          "Action":"Add",

          "FilterList":{},

          "Key":10004

        }

      ],

      "KeyType":"UInt"

    },

    "State":{

      "Data":"Ok",

      "Stream":"Open"

    },

    "Type":"Refresh"

  }

]

Jirapongse

@piotr.wroblewski

I checked the RDM usage found and found the following statement.

NOTE: If an application does not subscribe to the Source Directory’s group filter, it will not receive group status messages. This can result in potentially incorrect item state information, as relevant status information may be missed

The application should register to retrieve INFO, STATE, and GROUP filter.

Richard_Wilson761382

@Jirapongse and @wasin.w V3 Thank you for your responses. The client has responded and asked:

I've seen some answers on the dev community, 2 devs answered, but they are a bit contradicting each other.

The first dev says it wouldn't help increasing the filter, the second dev says we should increase the filter to get status updates.

Is there someone from product side that could confirm what we should implement ? Despite the fact we still don't know why we receive these source updates, I believe there is a guideline on this.

Jirapongse

@Richard_Wilson761382

This is just a recommendation found in the RDM Usage Guide.

However, I found that the GroupId is optional in the WebSocket API Specification. The client may need to contact the API support team directly via Contact Premium Support to verify the group status usage in the WebSocket API.

If client is not a RDC (Developer Connect) user, the client raise this question on GitHub.

For the question about "why we receive these source updates", the message has been published from the server or the service provide, the client needs to contact the server team to verify this.

For the document regarding the source directory message, please refer to the RDM Usage Guide.

EXPLORE OUR SITES