Requesting dictionary from RDF-D server using UPA/ETA

My application can retrieve the dictionary from the Elektron Edge server without a problem but when it connects to an RDF-D server and issues the same request,

the Dictionary response on the
RDM_DC_MT_REFRESH message has the type field in the dictionary refresh message
set to 0. (DictionaryMsgEvent->pRDMDictionaryMsg->refresh->type)

The valid values in the ETA API
are shown here:

typedef enum {
  RDM_DICTIONARY_FIELD_DEFINITIONS      = 1
  RDM_DICTIONARY_ENUM_TABLES            = 2
  RDM_DICTIONARY_RECORD_TEMPLATES       = 3
  RDM_DICTIONARY_DISPLAY_TEMPLATES      = 4
  RDM_DICTIONARY_DATA_DEFINITIONS       = 5
  RDM_DICTIONARY_STYLE_SHEET            = 6
  RDM_DICTIONARY_REFERENCE              = 7
  RDM_DICTIONARY_FIELD_SET_DEFINITION   = 8
  RDM_DICTIONARY_ELEMENT_SET_DEFINITION = 9
} RDMDictionaryTypes;

The enum does not contain a 0 value.

Fortunately I've been able to work around the problem by specifying the path to the static dictionary files RDMFieldDictionary and enumtype.def in calls to rsslLoadFieldDictionary and rsslLoadEnumTypeDictionary.

Is it possible to get the dictionaries from an RDF-D server or must they be loaded locally from files on the disk

Find more posts tagged with

elektron

rdf

elektron-sdk

refinitiv-realtime

elektron-transport-api

eta-api

rrt

elektron-data-dictionary

Accepted answers

All comments

Jirapongse

When the consumer sends the dictionary request, it specifies the dictionary name (RWFFld or RWFEnum) in the request message. Then, the provider will send the refresh message with the corresponding dictionary name. The dictionary name is defined in the message key attribute.

<requestMsg domainType="RSSL_DMT_DICTIONARY" streamId="3" containerType="RSSL_DT_NO_DATA" flags="0x4 (RSSL_RQMF_STREAMING)" dataSize="0">
    <key  flags="0xB (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_FILTER)"  serviceId="267" name="RWFFld" filter="7"/>
    <dataBody>
    </dataBody>
</requestMsg>

<requestMsg domainType="RSSL_DMT_DICTIONARY" streamId="4" containerType="RSSL_DT_NO_DATA" flags="0x4 (RSSL_RQMF_STREAMING)" dataSize="0">
    <key  flags="0xB (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_FILTER)"  serviceId="267" name="RWFEnum" filter="7"/>
    <dataBody>
    </dataBody>
</requestMsg>

<refreshMsg domainType="RSSL_DMT_DICTIONARY" streamId="3" containerType="RSSL_DT_SERIES" flags="0x168 (RSSL_RFMF_HAS_MSG_KEY|RSSL_RFMF_SOLICITED|RSSL_RFMF_REFRESH_COMPLETE|RSSL_RFMF_CLEAR_CACHE)" groupId="0" dataState="RSSL_DATA_OK" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text=""  dataSize="615880">
    <key  flags="0xB (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_FILTER)"  serviceId="267" name="RWFFld" filter="7"/>

...

<refreshMsg domainType="RSSL_DMT_DICTIONARY" streamId="4" containerType="RSSL_DT_SERIES" flags="0x168 (RSSL_RFMF_HAS_MSG_KEY|RSSL_RFMF_SOLICITED|RSSL_RFMF_REFRESH_COMPLETE|RSSL_RFMF_CLEAR_CACHE)" groupId="0" dataState="RSSL_DATA_OK" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text=""  dataSize="102159">
    <key  flags="0xB (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_FILTER)"  serviceId="267" name="RWFEnum" filter="7"/>
    <dataBody>

RsslRDMDictionaryRefresh::type is populated from the summary data in the payload of dictionary refresh message.

It is a required field. To verify the problem, please enable XML tracing in the application. Therefore, we can verify the value of Type sent in the summary data.

You can use the below code to enable XML tracing or run rsslVAConsumer in the package with -x option.

RsslTraceOptions traceOptions;
RsslErrorInfo rsslErrorInfo;

rsslClearTraceOptions(&traceOptions);
traceOptions.traceMsgFileName = traceOutputFile;
traceOptions.traceFlags |= RSSL_TRACE_TO_FILE_ENABLE |  RSSL_TRACE_TO_MULTIPLE_FILES | RSSL_TRACE_WRITE | RSSL_TRACE_READ;
traceOptions.traceMsgMaxFileSize = 100000000;

rsslReactorChannelIoctl(pReactorChannel, (RsslIoctlCodes)RSSL_TRACE, (void *)&traceOptions, &rsslErrorInfo);

Please attach the tracing file in your response.

Joe.Ferraro

Attaching the xml trace per request:
trace.zip

Joe.Ferraro

my comments attached as text, clearly showing that

pRsslRDMDictionaryMsgEvent->pRDMDictionaryMsg->refresh.type is 0
NOT one of the values in the table in the message above.

Note that the application logic works perfectly when connecting to an Elektron Edge server. If only has a problem when communicating with an RDF-D server.

comments and related data structure dumps from gdb:
my-comments.txt

Jirapongse

Thank you so much for your analysis.

For your concern about flag's values, the RsslRDMDictionaryRefreshFlags in the value added library and RsslRefreshFlags in the UPA library use the different enum for flags.

The following is RsslRefreshFlags enum defined in rsslRefreshMsg.h.

typedef enum {
	RSSL_RFMF_NONE					= 0x0000,
	RSSL_RFMF_HAS_EXTENDED_HEADER	= 0x0001,
	RSSL_RFMF_HAS_PERM_DATA			= 0x0002,
	RSSL_RFMF_HAS_MSG_KEY			= 0x0008,
	RSSL_RFMF_HAS_SEQ_NUM			= 0x0010,
	RSSL_RFMF_SOLICITED				= 0x0020,
	RSSL_RFMF_REFRESH_COMPLETE		= 0x0040,
	RSSL_RFMF_HAS_QOS				= 0x0080,
	RSSL_RFMF_CLEAR_CACHE			= 0x0100,
	RSSL_RFMF_DO_NOT_CACHE	   		= 0x0200,
	RSSL_RFMF_PRIVATE_STREAM		= 0x0400,
	RSSL_RFMF_HAS_POST_USER_INFO	= 0x0800,
	RSSL_RFMF_HAS_PART_NUM			= 0x1000,
	RSSL_RFMF_HAS_REQ_MSG_KEY		= 0x2000,
	RSSL_RFMF_QUALIFIED_STREAM		= 0x4000
} RsslRefreshFlags;

The flag's value (0x168) in the XML is RsslRefreshFlags which means:

RSSL_RFMF_CLEAR_CACHE (0x0100) is equivalent to RDM_DC_RFF_CLEAR_CACHE (0x10)
RSSL_RFMF_REFRESH_COMPLETE (0x0040) is equivalent to RDM_DC_RFF_IS_COMPLETE (0x02)
RSSL_RFMF_SOLICITED (0x0020) is equivalent to RDM_RFF_SOLICITED (0x04)
RSSL_RFMF_HAS_MSG_KEY (0x0008) is equivalent to RDM_DC_RFF_HAS_INFO (0x01)

Therefore, the flag's values in RsslRDMDictionaryRefresh::flags and the XML file represent the same meaning.

Next, for the dictionary's type issue, the XML file indicates that the type's value in the summary data sent by RDFD is zero.

<refreshMsg domainType="RSSL_DMT_DICTIONARY" streamId="3" containerType="RSSL_DT_SERIES" flags="0x168 (RSSL_RFMF_HAS_MSG_KEY|RSSL_RFMF_SOLICITED|RSSL_RFMF_REFRESH_COMPLETE|RSSL_RFMF_CLEAR_CACHE)" groupId="0" dataState="RSSL_DATA_OK" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text=""  dataSize="238134">
    <key  flags="0xB (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_FILTER)"  serviceId="74" name="RWFFld" filter="7"/>
    <dataBody>
        <series  flags="0x7 (RSSL_SRF_HAS_SET_DEFS|RSSL_SRF_HAS_SUMMARY_DATA|RSSL_SRF_HAS_TOTAL_COUNT_HINT)" countHint="6009" containerType="RSSL_DT_ELEMENT_LIST">
 ...
    <summaryData>
       <elementList flags="0x8 (RSSL_ELF_HAS_STANDARD_DATA)">
         <elementEntry name="Type" dataType="RSSL_DT_UINT" data="0"/>
         <elementEntry name="DictionaryId" dataType="RSSL_DT_INT" data="1"/>
         <elementEntry name="Version" dataType="RSSL_DT_ASCII_STRING" data="4.00.2"/>
       </elementList>
    </summaryData>

This could be the problem in RDFD so I have created a case to RDFD team on your behalf to verify the problem. The case number is 05106623.

EXPLORE OUR SITES