Xml versus binary record replay

Hello,

We are currently using the record replay tool provided by
Reuters :

https://developers.refinitiv.com/article/quick-start-guide-recording-and-playback-elektron-data#Instrument%20List%20File%20Format

As described there are two formats for the record/replay :

Xml
Binary

In our side, the binary file is well replayed. However, we
got some troubles with Xml file.

After some investigations we managed to make it works, but
it requires to manually update the recorded Xml file.

So we think this is not something expected and this is why
we would like to get your advises.

Our detailed test case :

Prerequisites :

Trrt : hostname where
our Reuters server is deployed
14002 : the port to
connect to the server

Record
1. Xml
2. ```
rmdstestclient -S IDN_RDF -h trrt -p 14002-ct rssl -u r_msa -ef RIC.lst -rf 8-of idn_rdf.xml
```
3. Binary
```
rmdstestclient -S IDN_RDF -h trrt -p 14002-ct rssl -u r_msa -ef RIC.lst -rf 8-of idn_rdf.xml
```
We followed the documentation :
1. Replay
1. Xml
2. ./sink_driven_src -S IDN_RDF -Q idn_rdf.xml -U 1-N 14001-K -ik
3. Binary
4. ./sink_driven_src -S IDN_RDF -bdf idn_rdf.dat -U 1-N 14001-K -ik
We followed the documentation :
1. Final result :
1. Xml
- i.We get this error :
```
./sink_driven_src -S IDN_RDF -bdf idn_rdf.dat -U 1-N 14001-K -ik
Initialized RSSL library
Failed: rsslEncodeFieldEntry ,return value = "RSSL_RET_UNSUPPORTED_DATA_TYPE: Failure: The data type is unsupported. (-24)"...
```
- ii.Finally after all the following modifications in
  the recorded file idn_rdf.xml (you will find attached the two files the
  original and the manually fixed one) : it works fine :
- Xml file reformatting
  We noticed that the recorded Xml file is currently corrupted.
  After some additional investigations, it seems that the root cause of this issue is the bad-formatted XML file generated from the "record" script.
  Narrowing down to two eligible fields which might cause this, We have managed to replay successfully an XML file by changing the following :
  - initially to be able to load the entire XML file without losing data, add the missing dataType="RSSL_DT_TIME" for fields between 13404 - 14208 under the XML element <refreshMsg domainType="RSSL_DMT_MARKET_PRICE".
  - qosRate="2" ---> should be changed from 2 to 1 in all occurrences
  - <mapEntry flags="0x0" action="RSSL_MPEA_ADD_ENTRY" key="257" > --->key should be changed from 257 to 1 under the XML element <refreshMsg domainType="RSSL_DMT_SOURCE"
1. Binary
- i.It works fine
Is that expected ?
How can we record a correct Xml file ?
Thanks,

Find more posts tagged with

trep

xml

data

elektron

dss-rest-api

refinitiv-realtime

replay-tool

Accepted answers

pimchaya.wongrukun01

Hello @guillaume.chatel

You may contact TREP support team who is expert in rmdstestclient and sink_driven_src which are TREP's tool. To raise this problem to them, please submit the query via Get Product Support in MyRefinitiv . Select Product "Thomson Reuters Enterprise Platform". If you face any difficulties submitting the query, please contact Refinitiv Account team.

All comments

umer.nalla

Hi @guillaume.chatel

I have come across this error once before when the local Data dictionary file used by sink_driven_src was outdated, compared to the one used by rmdstestclient - which by default requests the dictionary from the server it connects to.

Can you confirm if the local RDMFieldDictionary and enumtype.def are the same as the ones deployed on your 'trrt' server?

pimchaya.wongrukun01

Hello @guillaume.chatel

guillaume.chatel

Hello, @umer.nalla,

Thank you for you feedback,

We already tested with several local Data dictionary files, and each time we ensured that they are the same between sink_driven_src and rmdstestclient and it did not work.

@pimchaya.wongrukun01, thanks for the advice. I submitted the ticket.

EXPLORE OUR SITES