New posts are disabled while we improve the user experience.

You can browse the site, or for urgent issues, raise a query at MyAccount.

question

Upvotes
Accepted
mithun3 avatar image
1 ●1 ●1 ●1

Trailing zeroes seem to be dropped from BID and ASK

Hi All,

We seem to be receiving BID and ASK fields with the trailing zeroes dropped.

We are currently using RFA Version: 7.5.0.L1.all.rrg

We notice that the upstream TREP system seems to be sending valid data but when we receive it we seem to be loosing the Trailing 0s (hence loosing the decimal precision).

This was sent from TREP:

Sipc message Sent:  Len: 84 HdrLen: 6 Flags: 0 ProtId: 2 FD: 183
 Tue Jun 22  04:07:35.307811 2021
  SSL Update:   srvcId: 18  ItemName: AUDGBP=TEST1  DataLen: 59
Data(59):
<FS>316<US>XX<GS>AUDGBP=TEST1<US><RS>
16<US>22 JUN 2021<RS>
5<US>04:07<RS>
22<US>+1.5490<FS>
Sipc message Sent:  Len: 84 HdrLen: 6 Flags: 0 ProtId: 2 FD: 183
 Tue Jun 22  04:07:42.316894 2021
  SSL Update:   srvcId: 18  ItemName: AUDGBP=TEST1  DataLen: 59
Data(59):
<FS>316<US>XX<GS>AUDGBP=TEST1<US><RS>
16<US>22 JUN 2021<RS>
5<US>04:07<RS>
25<US>+1.5500<FS>

However this is what we are receiving from our service (as per logs):

2021-07-01 14:35:42.813 +1000 pool-2-thread-1 TRACE MarketDataClient Processing:  BID
2021-07-01 14:35:42.434 +1000 pool-2-thread-1 DEBUG MarketDataClient Received MARKET_DATA_ITEM_EVENT (data), value = 1.549, name = BID
2021-07-01 14:35:42.813 +1000 pool-2-thread-1 TRACE MarketDataClient Processing:  ASK
2021-07-01 14:36:58.806 +1000 pool-2-thread-1 DEBUG MarketDataClient Received MARKET_DATA_ITEM_EVENT (data), value = 1.55, name = ASK

We have set downloadDataDictionary=true
Which means we receive the RDMFieldDictionary file from TREP
BID and ASK have the following configuration in the above file:
LENGTH: 17
RWF TYPE: REAL64
RWF LEN: 7

The following was suggested by @adam.centofanti, https://community.developers.refinitiv.com/questions/27828/rfa-8-java-api-market-price-decimal-precision.html
but sadly I could not go anywhere with it as my knowledge is very limited when it comes to RFA library.

Please let me know how we can best resolve this issue.

Regards,
Mithun.

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.

3 Answers

· Write an Answer
Upvotes
Accepted
Jirapongse avatar image
87.8k ●294 ●53 ●79

@mithun3

You can try RawData() and convert it to a string. 

 byte[] test =    field.RawData();
 if(test != null) {
          System.out.println("Raw: "+ new String(test));
                 }

The output looks like this:

Raw: 0.7470
HIGH_1: 0.747 --> Hint Type:6, Hint Size:1, Hint Data:20
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.

mithun3 avatar image mithun3

@jirapongse.phuriphanvichai

Thank you for that!

Looks like the raw data is able to return the trailing zeroes:

Processing:  BID Received MARKET_DATA_ITEM_EVENT (data), value = 1.55, name = BID, Hint Type = 6, Hint Size = 1, Hint Data = 20, Raw Data = +1.5500
Processing:  ASK Received MARKET_DATA_ITEM_EVENT (data), value = 1.555, name = ASK, Hint Type = 6, Hint Size = 1, Hint Data = 20, Raw Data = +1.5550

Is there an elegant solution to do this using RFA library itself rather than this (hacky) way, i.e., convert into byte array, check if null or empty and then convert to string?

Since we receive thousands of updates in a minute adding this logic may not be efficient in the long run, is there somewhere we can instruct not to remove trailing zeroes within the RFA framework itself?


Alex Putkov.1 avatar image Alex Putkov.1 mithun3

RDC team provided the following response:
RFA truncates the prevailing zeros off the end of the BID/ASK fields. This is by design.
The MDSubDemo application gets 6 digit value from RFA as we can see this by printing field.rawData().
The application can use the same instead of using field.StringData(). This method is from TIB implementation and we don’t have control over it.
So it is suggested to use rawData and there wont be any fix from RFA.

Upvotes
Jirapongse avatar image
87.8k ●294 ●53 ●79

@mithun3

You can use Hint to determine the decimal places. 

 System.out.print(field.Name());
 System.out.print(": ");
 System.out.println(field.StringData()+" --> Hint Type:"+field.HintType()+", Hint Size:"+field.HintSize()+", Hint Data:"+field.HintData());
             

The output is:

HIGH_1: 0.747 --> Hint Type:6, Hint Size:1, Hint Data:20
LOW_1: 0.7456 --> Hint Type:6, Hint Size:1, Hint Data:20
CURRENCY: 840 --> Hint Type:6, Hint Size:2, Hint Data:261
ACTIV_DATE: 02 JUL 2021 --> Hint Type:6, Hint Size:2, Hint Data:258
OPEN_PRC: 0.7467 --> Hint Type:6, Hint Size:1, Hint Data:20
HST_CLOSE: 0.7469 --> Hint Type:6, Hint Size:1, Hint Data:20
BID: 0.7456 --> Hint Type:6, Hint Size:1, Hint Data:20
BID_1: 0.7456 --> Hint Type:6, Hint Size:1, Hint Data:20
BID_2: 0.7455 --> Hint Type:6, Hint Size:1, Hint Data:20

Hint Type: 6 represents TIBMSG_UINT. Hint Data:20 represents HINT_DECIMAL_4.

1625211165348.png


1625211165348.png (17.7 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.

Upvotes
mithun3 avatar image
1 ●1 ●1 ●1

Thank you for the reply @jirapongse.phuriphanvichai.

After applying the above changes, I get the following logs in the console:

Processing:  BID
Received MARKET_DATA_ITEM_EVENT (data), value = 1.55, name = BID, Hint Type = 6, Hint Size = 1, Hint Data = 20
Processing:  ASK
Received MARKET_DATA_ITEM_EVENT (data), value = 1.555, name = ASK, Hint Type = 6, Hint Size = 1, Hint Data = 20

The issue here is we are loosing the zero's, i.e., we are receiving 1.55 instead of 1.5500 similar case with ask wherein we are receiving 1.555 instead of 1.5550.

Is there anything else we have to do to retain the trailing 0s?

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.