Publishing a FID which has a dummy entry in the enumtype file

Hi
I want to know first of all if enumtype file is a must for Publishing in-house data to TREP.
Below is my RDMFieldDictionary.
!ACRONYM DDE ACRONYM FID RIPPLE FIELD TYPE LEN RWF TYPE RWF LEN
!------ ----------- --- ------ ---------- --- -------- -------
WEIGHT "" 1 NULL NONE 0 REAL64 7
EXECUTION_MS "" 2 NULL NONE 0 UINT 6
SIGNAL_MS "" 3 NULL NONE 0 UINT 6
YIELD "" 4 NULL NONE 0 UINT 6
For the above disctionary do I still need a enumtype file, if so I can create dummp file which looks like below.
! ACRONYM FID
! ------- ---
!
RDN_EXCHID 4
!
!
! VALUE DISPLAY MEANING
! ----- ------- -------
0 " " Not allocated
!
If I Publish data on FID 4 which is listed in the enumtypes, will it break something, where it doesn't know whether to parse it as an enum or not? Can you please clarify.
Answers
-
Thank you for reaching out to us.
Both files are required by RTDS (TREP) and real-time applications. To encode and decode data properly. all components must use the same data dictionary files.
It is not recommended to define your in-house fields with positive field IDs (FIDs). Instead, it is better to reuse the positive fields defined in the dictionary and define your own fields with negative FIDs if those positive fields don't meet the requirements.
Please check this Publish Custom Data via Refinitiv Real-Time Distribution System by EMA article for more information.
Under the hood, when the field entries are sent to the network, it contains only FID and data. For example:
<fieldEntry fieldId="1" data="020E"/>
<fieldEntry fieldId="2" data="99"/>
<fieldEntry fieldId="3" data="5241 424F 4241 4E4B 4746 4D20 204C 4F4E"/>
<fieldEntry fieldId="5" data="081B"/>
<fieldEntry fieldId="11" data="0C35"/>
<fieldEntry fieldId="12" data="0C37 D1"/>
<fieldEntry fieldId="13" data="0C37 89"/>
<fieldEntry fieldId="15" data="0188"/>
<fieldEntry fieldId="17" data="1E04 07E9"/>Therefore, the data dictionary files are required to get the fields' names and decode data.
RDNDISPLAY "DISPLAYTEMPLATE" 2 NULL INTEGER 3 UINT64 1
DSPLY_NAME "DISPLAY NAME" 3 NULL ALPHANUMERIC 16 RMTES_STRING 16
TIMACT "TIME OF UPDATE" 5 NULL TIME 5 TIME 5
CURRENCY "CURRENCY" 15 NULL ENUMERATED 5 ( 3 ) ENUM 2For example:
- The FID 3 is the DSPLY_NAME field and its data must be decoded as a string (RABOBANKGFM LON)
- The FID 5 is the TIMACT field and its data must be decoded as a time (08:27:00:000:000:000)
- The FID 15 is the CURRENCY field and its data must be decoded as an enumeration (392) which is equal to JPY in the enumtyp.def file
!
! ACRONYM FID
! ------- ---
!
CURRENCY 15
CURRENCY_2 1084
…
!
! VALUE DISPLAY MEANING
! ----- ------- -------
0 " " Not allocated
4 "AFA" Afghanistan afghani (from 1925 until 2003)
8 "ALL" Albanian lek
…
392 "JPY" Japanese yenTherefore, the provider, RTDS (TREP), and consumer must load and use the same data dictionary.
You can get the data dictionary files from here.
0 -
Hi @Jirapongse
I have the same question, which I'm not sure was actually answered.
Say I have a small custom dictionary (using the recommended FID range, as you suggest) that looks like:
!ACRONYM DDE ACRONYM FID RIPPLE FIELD TYPE LEN RWF TYPE RWF LEN
!------- ----------- --- ------ ---------- --- -------- -------
MY_CUSTOM_FID "" -4001 NULL NONE 0 REAL64 7This clearly has no enum types but I have to pass an enumtypes.def to the provider regardless.
Based on playing around, that file has to contain at least one "table".
Currently I am naming a FID at the edge of the usable range and giving it a nonsense name:
! ACRONYM FID
! ------- ---
!
A_NON_EXISTENT_FID -8000
!
! VALUE DISPLAY MEANING
! ----- ------- -------
0 "" undefinedThis seems neither clean nor a particularly foolproof way of avoiding collisions.
Is there a recommended solution to this?
0 -
You need to define the "A_NON_EXISTENT_FID -8000" in the dictionary file to.
For example:
!
!ACRONYM DDE ACRONYM FID RIPPLES TO FIELD TYPE LENGTH RWF TYPE RWF LEN
!------- ----------- --- ---------- ---------- ------ -------- -------
!
MY_CUSTOM_FID "" -4001 NULL PRICE 17 REAL64 7
A_NON_EXISTENT_FID "" -8000 NULL ENUMERATED 2 ( 1 ) ENUM 1!
! ACRONYM FID
! ------- ---
!
A_NON_EXISTENT_FID -8000
!
! VALUE DISPLAY MEANING
! ----- ------- -------
0 " " no value0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 684 Datastream
- 1.4K DSS
- 615 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 249 ETA
- 554 WebSocket API
- 37 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 275 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.9K Refinitiv Data Platform
- 643 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 26 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 192 TREP Infrastructure
- 228 TRKD
- 915 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 90 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛