For a deeper look into our Elektron API, look into:

Overview |  Quickstart |  Documentation |  Downloads |  Tutorials |  Articles

question

Upvotes
Accepted
duncan_kerr avatar image
26 ●1 ●5 ●4

MBO L2 data : can I truncate keys?

Im looking at MBO L2 data and I can see that the "action" keys can be printed, and look like:

'3339 6563*******************************39ec'

'3330*************************30'

'1****************************1'

(where * are spaces and pad key to 50 chars wide)

however, when I look at the keys in Refinitiv app OMMViewer, you truncate the keys and only seem to use the right hand end of the keys.

My question is - can you explain how the keys work, and what the significance of the lft and right hand bit of the keys is? Can I make any assumptions with spaces in the gap in the middle of the key?

elektronrefinitiv-realtimeelektron-sdkequitieslevel-2market-by-order
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.

2 Answers

Upvotes
Accepted
Jirapongse avatar image
45.2k ●103 ●43 ●60

@duncan_kerr

Refer the RDM usage guide, the data type of the MBO key is buffer.

The data in the buffer is a byte array. When printing to a screen, the byte array can be represented as a hexadecimal string, such as '3339 6563'. Moreover, this data can also be represented as an ASCII string.

For example, from the ASCII table, '3339 6563' represents '39ec' in an ASCII string.

Therefore, the left-hand side should be a hexadecimal string while the right-hand side is an ASCII string.

Hexadecimal string => ASCII string

'3339 6563' => '39ec'
'3330'      => '30'

It depends on what methods or libraries that the application uses to print the buffer. Some methods can display the buffer in this format.

'3339 6563*******************************39ec'
'3330*************************30'

Then, OMM Viewer uses ASCII strings for display. This is my assumption.

However, I am not sure about the last example.

'1****************************1'

What RICs are you using to retrieve that data?


1593164973356.png (33.9 KiB)
1593165815321.png (126.2 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.

duncan_kerr avatar image duncan_kerr

I see, the last example was from memory, and wrong. What I was thinking of, was:

KEY ADD "31 1"

If my understanding is correct I can extract the key from the ascii representation of the buffer by disgarding everything up to and including the last space in the string, so:


31****1 => 1

'3339 6563*******************************39ec' => 39ec

Upvotes
duncan_kerr avatar image
26 ●1 ●5 ●4

OMM VIewer seems to truncate away some of the key:


1593162457478.png (20.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.