The top level SPS RIC points to provider SPS records, which shows individual venues within the same region. Each provider SPS record represents one venue.

• A line handler publishes venue data, and one venue may have multiple line handlers which contribute to the venue. A provider SPS RICs representing a venue, points to a subProvider SPS(s) which represents a CHE line handler.
• Subprovider SPS RIC shows the health of one CHE line handler of a venue. A line handler publishes the venues data, and one venue may be contributed to by multiple line handlers.
• By aggregating the subProvider SPS information, we can get the health of a venue

Solution

The application can consume Refinitiv Real-Time Infrastructure Health Status by the steps below:

1. Subscribe to snapshot of a top-level SPS RIC and get the list of Provider SPS in a refresh message.
2. Subscribe to snapshot of a Provider SPS and get the list of SubProvider SPS in a refresh message.
3. Make a streaming Subscribtion of a SubProvider SPS and get it's health status in real time.

Data content from subscribing top-level SPS and Provider SPS are linkage of records which the application does not need to monitor in real-time, because they do not change. Therefore, the application should subscribe to them as snapshot requests; only refresh message is returned with no update message.

An EMA Java application to consume Refinitiv Real-Time Infrastructure Health Status is designed as per the figure below:

2. Modify AppClient's Constructor to accept an OmmConsumer object and initialize the variables declared in the step 1. OmmConsumer provides the method for subscribing to Provider/SubProvider SPS.

3. Modify main(String[] args) to subscribe to a snapshot of a top level SPS domain(11) or EmaRdm.MMT_SERVICE_PROVIDER_STATUS

4. After subscribing to a top level SPS, the application receives a refresh message, of which the payload is a map container. Each map entry contains a Provider SPS info and the key is a Provider SPS RIC i.e. .[SPSCHE-EDX as shown below:

To get the list of Provider SPS RIC, we have to get the key from each map entry. Likewise, to get the list of SubProvider SPS RIC, we have to get the key in each map entry of a refresh message returned after subscribing to an input Provider SPS RIC e.g. .[SPSCHE-EDX as shown below:

The map entry above contains a SubProvider SPS info and the key is a SubProvider SPS RIC i.e. .[SPSEDXL1. Therefore, we have to add a method named getKeyString(..) in AppClient class. The method is used to get the key in each map entry of Provider SPS and SubProvider SPS as explained above. Then, we will be able to get the list of Provider SPS and SubProvider SPS RIC.

5. In the decode(..) method which decodes Map, call the method getKeyString(..) to get the keys from the map of a refresh message. Then, extract and add the keys which are the Provider/SubProvider SPS RICs/names to the SPS list.

6. Add a method named requestNextlevel() in AppClient class. The method is used to verify if it should print the list of Provider/SubProvider SPS and wait for the user input after it receives a refresh message or not, as detailed below:

• level 1 : print List of Provider SPS RICs and flag to subscribe an input RIC as a snapshot. Then, wait for a user input Provider SPS RIC and returns true to inform the application to subcribe the user input RIC.
• level 2 : print List of SubProvider SPS RICs and flag to subscribe to an input RIC streaming. Then, wait for a user input SubProvider SPS RIC and returns true to inform the application to subcribe to the user input RIC.
• level 3 or higher: returns false to inform the application not to subcribe to any RIC.

7. In onRefreshMsg(..) method, call the method requestNextlevel() after decoding a refresh message. The requestNextlevel() method prints the list of Provider/SubProvider SPS and wait for input. Finally, print the FieldList data which is the health status of the venue line handler(SubProvider SPS).

The application source code is available at Github. You can run the application using the following command line:

The example output when you run the application:

The application will show a refresh containing map of Provider SPS RICs in EMEA Top level SPS. Then, enter a Provider SPS RIC from the list e.g. .[SPSCHE-EDX

The application will show a list of SubProvider SPS RICs under .[SPSCHE-EDX. Next, enter a SubProvider SPS RIC from the list e.g. .[SPSEDXL1

The application will show the health status of a SubProvider. In this example, SubProvider .[SPSEDXL1 has SPS_PV_STS field(field id 6479) is 1 means Line Handler/Provider is UP and SPS_FD_STS field(field id 6474) is 5 means the input feed connection status is UP. Please refer to the next section for further details.

The data content in a SubProvider

Unlike the Top and Provider level SPS items which carry linkage of records, the data content in SubProvider level SPS item returns FieldLists that reflect the health status of the venue line handlers. In Refinitiv Real-Time, data of a venue is published by one or multiple line handlers, and data in each line handler should be discrete. Below is the extract of FIDs in the subProvider level item which client should be aware of.

Conclusion

If you are planning to develop an application to monitor/discover the health of Refinitiv Real-Time Infrastructure, you can use this article as a guide. EMA Java is one of the APIs(apart from ETA, RFA) which can be used to retrieve SPS messages. Implementing EMA Java to monitor the health of Refinitiv Real-Time is relatively quick and easy as shown in this article.

References

For further details, please check out the following resources:

• Elektron Pulse – Programmers Guide:  pulseprogrammersguidev2.5.pdf
• Refinitiv Real-time SDK - Java page.