@luxiangyuan

• The original case you post is an error when you try to print updateMsg and get Illegible contents. It could be an issue from method toString inside UpdateMsg class when the content of fieldEntry contains RMTES encoded with a partial update. I just want to show you that I don't have the error when using the latest version. Actually, the recommended way to decode data is that the user has to decode field list and then check field type and decode it accordingly. Also Below special character, you see from my console output is a result when UpdateMsg class call toString to return value of fieldEntry inside the message. Typically, the class does not check the type of the field and it just returns value from toString method when you call cout << updateMsg <<endl;

value="ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ3440 2425ÍÍÍÍ98 4086"

You can see a similar value when calling fe.toString from the partial update message. See below sample codes to demonstrate the usage. Note that my sample just decodes only fid ROW80_4.

cout << "Name: " << fe.getName() << endl;
cout << "fe.toString:" << fe.toString() << endl;
rmtesBuffer.apply( fe.getRmtes() );
cout << "after call rmtestBuffer.apply()"<<rmtesBuffer.toString() << endl;

Sample console output

Item Name: 0874bk.HKd
Service Name: ELEKTRON_DD
Name: ROW80_4
fe.toString:FieldEntry fid="318" name="ROW80_4" dataType="Rmtes" value="ร5337รร1194 1193 -11s"
after call rmtestBuffer.apply() 5337 1194 1193 -11s | 5469 6825 9025 6999

The junk characters you see in original value is just the data encoded with RMTES partial update so when we call rmtestBuffer.apply() it will return the actual string which apply the change from partial field update.

• Regarding duplicate value from your screenshot, your codes seem to re-use the same rmtestBuffer object with any fields, therefore, it causes a duplicate data or redundant character. This should be incorrect usage.

Please note that the RMTES example just shows the way to catch RMTES data for one specific field which is BCAST_TEXT. If you want to apply the same approach to decode the HK page which contains multiple fields for Page rows, you have to catch data for each row in the PAGE to your data structure such as Array of string or array of RmtestBuffer class it depending on your design.

• Regarding the bug I mentioned, It’s the issue happen when you have codes that call fe.getRmtes().toString() before calling rmtestBuffer.apply(). You will get incorrect result from rmtesBuffer.toString(). That is the case I mentioned. If the application does not have the implementation like this, you don’t need to upgrade it.

@luxiangyuan

It looks like the screenshot you uploaded is corrupted so I can't see the error.
What version of EMA you are using?

I did a quick test the RIC but there is no update for the RIC now. The field is RMTES and the update message may contain a partial page update which you might need to catch the field data for each row from the first refresh and then call RmtesBuffer.apply() to apply the buffer from the update message like the sample codes from 310__MarketPrice__Rmtes.

Anyway, I would suggest you turn on XML Trace log to see actual data EMA receive.

hello @moragodkrit

1、HKSE is closed, so you can not get 0874bk.HKd updateMsg;

2 、how can I turn on trace log in emaconfig.txt shown as appendix?

2、what is the different between "100__MarketPrice__Streaming" and “310_MarketPrice_Rmtes"？ I develop my progrem refer to "100__MarketPrice__Streaming";

Hello @luxiangyuan

I find the concept of HK broker queue to be a bit complex, and it is usually necessary for a developer to understand how the queue is formed by the exchange, in order to parse it's meaning. Perhaps How to read the Hong Kong Broker Queue on My Refinitiv will be of help to better understand the content of HK broker queue.

To add a little to the answer by @moragodkrit

Do you see:

<XmlTraceToStdout value="0"/>

Change tracing to 1, to be able to better understand what data is received by the consumer.

The broker queue is partitioned into rows. An update contains the updated content for a specific row(s).

The ROW80_X info is defined as RMTES type. RMTES example 310 shows how to process the update to RMTES field (BCAST_TEXT).

Same as in this example, one would store the initial content of ROW80_X and when an update to ROW80_X is received, apply the update content to the stored ROW80_X content, and store the current, resulting content of ROW80_X.

@luxiangyuanoutput.txt

I did test the issue this morning and not found the error. Please find attached console output (output.txt) generated by ESDK1.3 example. It just prints the refresh and updates message like your codes.

The reason I asked you about the version you are using because there is a problem with RMTES in the old version of ESDK and development already add a built-in RMTES decoder to EMA internal decoder therefore if you are using the new version, you should get the same result as my test.

I would suggest you test the issue with the latest version of ESDK to confirm the issue.

@luxiangyuan

It seems to relate with this case which fixed in EMA 3.3.0. You can find the information from CHANGELOG file.

EMA C++ 3.3.0.L1 Issues Resolved 
-------------------------------- 
[ESDK-619] - RMTES Partial updates are not processed correctly if OmmRmtes.toString() is called before OmmRmtes.apply() is called [Case Number: 05533464, GitHub #74] 

hello @moragodkrit

1、my sdk is 1.2.1

2、do you test refer to "100__MarketPrice__Streaming"？

3、I decode brokers updateMsg refer to "310__MarketPrice__Rmtes", there is no Exception, the updateMsg is shown as follows:

4、what is the ”effect“ of the code "rmtesBuffer.apply( fe.getRmtes() );"?

5、what is the difference between "100__MarketPrice__Streaming" and "rmtesBuffer.apply( fe.getRmtes() );"

6、it semms there are some redundance charaters in updateMsg of brokers, what is the use of these charaters?

@luxiangyuan

The version you currently use has a bug in RMTES decoder, you should upgrade to the latest version of 1.3.1. The problem is reproducible with HK ric like your sample RIC.

EMA C++ 3.3.0.L1 Issues Resolved 
-------------------------------- 
[ESDK-619] - RMTES Partial updates are not processed correctly if OmmRmtes.toString() is called before OmmRmtes.apply() is called [Case Number: 05533464, GitHub #74] 

@moragodkrit

thanks for your replay.

if I use 1.3.1, I will not recv "redundance chars" such as follows???

hello @moragodkrit:

I update ems sdk to 1.3.1

but I still can not get correct updateMsg.

some updateMsg seems ok,

but some updateMsg seems error, because I can note decode brokers form the msg.

the fun and result is shown as following: