EMA C++ RDM Usage Guide : 4 Source Directory Domain : 4.3 Data : 4.3.1 Source Directory Refresh and Update Payload : 4.3.1.1 Source Directory Info Filter Entry
 
4.3.1.1 Source Directory Info Filter Entry
The Info filter entry (SERVICE_INFO_FILTER, SERVICE_INFO_ID) conveys information that identifies a service and the content it can provide. This includes information about provided domain types (e.g., Market Price, Market By Order), available QoS, and the names of any dictionaries required to parse the published content.
The Info FilterEntry should be present when a service is first added, and should not be changed as long as the service remains in the list.
 
NOTE: The LSEG Real-Time Advanced Distribution Hub does not track services that are brought down. If you bring up a service after having brought it down, you must again include the Info filter entry.
If a FilterEntry element uses a default value, it is included in the element’s description.
 
Table 25: Source Directory Info Filter Entry Elements  
ELEMENT NAME
TYPE
RANGE/EXAMPLE
DESCRIPTION
Name
ASCII
e.g., IDN_RDF
Required. Specifies the service’s name. This will match the concrete service name or the service group name that is in the Map.Key.
Vendor
ASCII
e.g., LSEG
Specifies the name of the vendor that provides the data for this service.
IsSource
UInt
0 | 1
Specifies whether the service aggregates content from multiple sources. Available values are:
0: The service aggregates multiple sources into a single service. This is the default behavior.
1: The service is provided directly by the original publisher
Capabilities
Array of UInt
e.g., [5, 6]
Required. Lists the domains which this service can provide. Note that the UInt MesageModelType is extensible, using values defined in this guide (i.e., 1-255).
For example, a list containing MMT_DICTIONARY (5) and MMT_MARKET_PRICE (6) indicates a consumer can request dictionaries and Market Price data from this service.
DictionariesProvided
Array of ASCII
e.g., RWFFld
Lists the Dictionary names that this service can provide. A consumer can obtain these dictionaries by requesting them by name on the MMT_DICTIONARY domain.
For details, refer to Chapter 5, Dictionary Domain.
DictionariesUsed
Array of ASCII
e.g., RWFFld, RWFEnum
Conditional. Lists the Dictionary names that might be required to fully process data from this service. Whether or not the dictionary is required depends on the consumer’s needs. For example: if the consumer is not a display application, it might not need an Enumerated Types Dictionary.
For details, refer to Chapter 5, Dictionary Domain.
QoS
Array of QoS
e.g., Real-time, TickByTick
Specifies the available Qualities of Service (QoS).
If the data comes from one source, there will usually be only one QoS.
If there are multiple sources, more than one QoS may be available.
The default QoS is Realtime, Tick-By-Tick. Thus. if a QoS is not provided, the Transport API assumes the service provides a QoS of Realtime, Tick-By-Tick.
For more information about QoS use and handling, refer to the Enterprise Message API C++ Edition Reference Guide.
SupportsQoSRange
UInt
0 | 1
Indicates whether the provider supports a QoS range when requesting an item.
If supported, a consumer can indicate an acceptable range via ReqMsg.Qos.
0: The provider does not support QoS range requests. This is the default behavior.
1: The provider supports QoS range requests.
ItemList
ASCII
 
Specifies the name of a SymbolList (i.e., a specific item requested to get the names of all items available for this service). If it is not present, this feature is not supported. The consumer requests this item via the MMT_SYMBOL_LIST domain (See Chapter 11, Symbol List Domain).
SupportsOutOfBandSnapshots
UInt
0 | 1
Indicates whether Snapshot requests can still be made after reaching the OpenLimit (refer to Section 4.3.1.4).
0: Snapshot requests cannot be made if the OpenLimit is reached.
1: Snapshot requests can be made even when the OpenLimit is reached. This is the default behavior.
AcceptingConsumerStatus
UInt
0 | 1
Indicates whether a service can accept and process messages related to Source Mirroring (refer to Section 4.2.4).
0: The service cannot accept and process messages related to Source Mirroring.
1: The service can accept and process messages related to Source Mirroring. This is the default behavior.