question

Upvotes
Accepted
1 0 2 4

OMMDataBuffer.horizontalPosition() returns -1

Hi,

I am looking at the RIC LP62009689. Its DSPLY_NMLL field is a RMTES_STRING and its OMMDataBuffer.hasPartialUpdates() returns true. When I tried to iterate its partial updates, I got the following result:

(1) Horizontal offset -1, Data 0xEF 0xBE 0x86 0xEF 0xBD 0xAF 0xEF 0xBD 0xBE 0xEF 0xBD 0xB2 0x20 0xE5 0xA4 0x96 0xE5

(2) Horizontal offset 0, Data 0x20 0xE8 0xB3 0xBC 0xE5 0x85 0xA5

The RFA JavaDoc says offset -1 means "full buffer", then how come there is a second partial update whose offset is 0?

Do anyone has any idea how to interpret the result?

Regards,

CM


treprfarfa-api
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Hello @CM Wong

Thank you for your participation in the forum. Is the reply below satisfactory in resolving your query?


If so please can you click the 'Accept' text next to the appropriate reply? This will guide all community members who have a similar question.

Thanks,


AHS

Hello @CM Wong,

Please be informed that a reply has been verified as correct in answering the question, and has been marked as such.

Thanks,

-AHS

Upvotes
Accepted
24.7k 54 17 14

Hello @CM Wong

Thank you for your confirmation. I have checked the FID 1352 (Field DSPLY_NMLL) from the trace file:


The API received a blank value FID 1352 from Refresh message on 2020-12-02T04:24:29

FIELD_ENTRY 1352:


Then the API received data from Update message on 2020-12-02T19:58:56

FIELD_ENTRY 1352: efbe86efbdafefbdbeefbdb220e5a496e59bbde6a0aa49647820e8b3bce585a5


Based on the RMTES/Partial Update definition, it should not be the “Partial Update” because the update message contains an entire new message, not just some part of the position of update characters.


The Partial Update message should also have the following pattern as shown below:

Example Partial Update message from FXFX RIC:

FIELD_ENTRY 220: 1b5b33316020302e373539332f3 35

Which means: <CSI> n=31 <HPA> data = 0.7593/95 (20 30 2e 37 35 39 33 2f 39 35).


However, your incoming DSPLY_NMLL message is

FIELD_ENTRY 220: efbe86efbdafefbdbeefbdb220e5a496e59bbde6a0aa49647820e8b3bce585a5


The message does not look like Partial Update at all. It does not have any control and infra-field position characters. It looks like the Full update.


You can find more detail regarding the page-based data and partial update behavior from this article (the article is based on RTSDK Java, but the data concept is the same as RFA).



partial-update.png (84.0 KiB)
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

@CM Wong

I have sent you a private email in case you want this API behavior to be investigated by the API support team. Please contact your colleague(s) that I listed in the email to submit the ticket on your behalf.

Upvotes
24.7k 54 17 14

Hello @CM Wong

I have checked the RIC LP62009689 (Nissay Foreign EQ Index). The RIC seems to provide Quote data for consumer, not the Page-based data which application needs to check the partial update.

Basically, the Page-based data contains text or numbers for over-the-counter traded instruments and emerging markets. The data are delivered through Real-time feed row by row, each row is identified by a unique field. The Page-based data contains field names in the "ROWx_x" pattern (example: ROW64_1, ROW80_1, ROW99_1, etc ). Refinitiv Real-Time can send updates for Page-based data as "partial update" which is an intra-field positioning sequence within the data field so that the minimum number of characters are transmitted to effect a change.

However, this LP62009689 seems to be the Quote RIC that the application should update an entire field data from the Update message as usual.

How often the problem occurs in your environment? Can you replicate the issue on demand? If so, could you enable the RFA trace file and share the file when the issue occur?

You can configure the following RFA Java configurations to enable the XML log file

<namespace>/Connections/<Connection Name>/ipcTraceFlags = 23
<namespace>/Connections/<Connection Name>/mountTrace = True
<namespace>/Connections/<Connection Name>/logFileName=<path to log file>

### Example RFA Java Configurations for the trace file ###


<node name="rsslConnection">
   <map>
      <entry key="connectionType" value="RSSL"/>
      <entry key="serverList" value="localhost"/>
      <entry key="portNumber" value="14002"/>
<entry key="ipcTraceFlags" value="23"/>
      <entry key="mountTrace" value="True"/>
      <entry key="logFileName" value=".\logs\RSSL_%U.log"/>
   </map>
</node>

Additionally, could you please give me the versions of RFA Java and Java SDK that you are using?


icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
1 0 2 4

Hi @wasin.waeosri

Thanks for your reply. As far as I know, many Japanese instruments do have RMTES string fields with partial updates.

I am using Java RFA v8.1.0.L1 and JDK 8

Trace log attached. Please see update at 2020-12-02 13:20:10

Regards,

CM

trace.txt


trace.txt (306.9 KiB)
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

@wasin.waeosri

Can you take a look and review the trace log?

Upvotes
24.7k 54 17 14

Hello @CM Wong

Sorry for the late reply, I have checked the trace file at 2020-12-02 13:20:10 (<date>2020-12-02T13:20:10</date>). The only RMTES string field that was updated is FID 1667 (field GN_TX20_3)

GN_TX20_3  "GN TXT20 3"          1667  NULL        ALPHANUMERIC       20  RMTES_STRING    20

Could you please confirm if you encounter the problem with this FID?

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
1 0 2 4

Hi @wasin.waeosri

Sorry, I copied the wrong time. The update should be at 2020-12-02 19:58:56, field name is DSPLY_NMLL

Regards,

CM


icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
1 0 2 4

Hello @wasin.waeosri

Thanks for your update.

If you compare the captured FID raw data with those returned from the JRFA (in my original question), they are very similar:

(1) Horizontal offset -1, Data 0xEF 0xBE 0x86 0xEF 0xBD 0xAF 0xEF 0xBD 0xBE 0xEF 0xBD 0xB2 0x20 0xE5 0xA4 0x96 0xE5
(2) Horizontal offset 0, Data 0x20 0xE8 0xB3 0xBC 0xE5 0x85 0xA5
FIELD_ENTRY 220: efbe86efbdafefbdbeefbdb220e5a496e59bbde6a0aa49647820e8b3bce585a5

But somehow JRFA divides them into 2 parts and returns them as partial updates.

My program has no problem processing other partial update fields except this one.

I will try JRFA 8.2 and see if there is any improvement.

Regards,

CM

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.