question

Upvotes
Accepted
1 0 0 1

MapEntry Action -> DELTE [ ORDER_ID] -> 1668520581231622381_1481511_1

Hi team,

Need help for this query. thanks in advance

We are using RFA 8.1 C++ API to consume depth data using MBP domain [Market By Price].

When we receive DELETE instruction we receive only OrderID. Side is not mentioned.
Order ID are received in given format

MapEntry Action -> DELTE [ ORDER_ID] -> 1668520581231622381_1481511_1
MapEntry Action -> DELTE [ ORDER_ID] -> 1668521395460227680_1481511_1

from these we cannot decide which side we have received it for Ask or Bid.
Are the Order ID's guarantied to be unique across both Bid and Ask Side?
So that we can search for OrderID in both our local Ask Levels and Bid Levels and delete level corresponding to that order ID.

rfa-api#contentmarket-by-price
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 @ryan.roxas

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

Thanks team all good it solved the issue.

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
79.1k 250 52 74

@ryan.roxas

Thanks for reaching out to us.

I think it is a key in the map entry.

I checked the domain model specification and found the following data definition of MBP.

The payload of a Market By Price Refresh or Update is an RsslMap. Each price point is contained in an RsslMapEntry which uses the price point and side (buy or sell) as the entry key.

1671589522685.png

According to the definition, the key contains one price point along with the buy/sell side. The data could look like this.

<mapEntry flags="0x0" action="RSSL_MPEA_ADD_ENTRY" key="77.580000a" >
<fieldList flags="0x7" fieldListNum="0" dictionaryId="1" setId="0">
<fieldEntry fieldId="3430" dataType="RSSL_DT_UINT" data="9368"/>
<fieldEntry fieldId="3428" dataType="RSSL_DT_ENUM" data="2"/>
<fieldEntry fieldId="3429" dataType="RSSL_DT_REAL" data="2100"/>
<fieldEntry fieldId="3427" dataType="RSSL_DT_REAL" data="77.58"/>
<fieldEntry fieldId="3855" dataType="RSSL_DT_UINT" data="72985174"/>
</fieldList>
</mapEntry>

However, the format may depend on the data provider who provides the data. Therefore, it is better to contact the content team directly to verify the data.

A Map uses keys to identify its entries so keys must be unique in each Map.




1671589522685.png (31.5 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.

Thanks for your update.

The domain is actually Market by Order and not MBP as mistakenly mentioned in query.

#RIC Domain Date-Time [GMT]


NAVYA.PA Market By Order 2022-11-15T14:06:17.810976404Z


MapEntry DELETE 1668520581231622381_1481511_1


#RIC Domain Date-Time


NAVYA.PA Market By Order 2022-11-15T14:10:14.051650506Z



MapEntry DELETE 1668521395460227680_1481511_



Another question is “Is it guaranteed to receive key in insert,update,delete actions in the format price+side, e.g. “105.55A” for MBP domain for all venues?”

Upvotes
79.1k 250 52 74

@ryan.roxas

I found the MapEntry ADD action for this key at 2022-11-15T14:56:21.286928283+01.

NAVYA.PA,Market By Order,2022-11-15T14:56:21.286928283+01,Raw,UPDATE,UNSPECIFIED,,,,6508,,46560,,0
,,,Summary,,,,,,,,,,3
,,,FID,17,,ACTIV_DATE,2022-11-15,
,,,FID,4148,,TIMACT_MS,50181231,
,,,FID,6952,,TIMACT_MSP,50181231622381,
,,,MapEntry,,ADD,,,,,,1668520581231622381_1481511_1,,10
,,,FID,3426,,ORDER_ID,1668520581231622381,
,,,FID,3427,,ORDER_PRC,0.1631,
,,,FID,3429,,ORDER_SIZE,3000,
,,,FID,6520,,PR_TIM_MS,50181231,
,,,FID,14275,,PR_TIM_NS,13:56:21.231622381,
,,,FID,3428,,ORDER_SIDE,1,BID
,,,FID,6521,,PR_TIM_MSP,50181231622381,
,,,FID,6522,,PR_DATE,2022-11-15,
,,,FID,3886,,ORDER_TONE,2,
,,,FID,8591,,ORD_TONE,2,

Then, it was deleted at 2022-11-15T15:06:17.810976404+01.

NAVYA.PA,Market By Order,2022-11-15T15:06:17.810976404+01,Raw,UPDATE,UNSPECIFIED,,,,6508,,47200,,0
,,,Summary,,,,,,,,,,3
,,,FID,17,,ACTIV_DATE,2022-11-15,
,,,FID,4148,,TIMACT_MS,50777754,
,,,FID,6952,,TIMACT_MSP,50777754737265,
,,,MapEntry,,DELETE,,,,,,1668520581231622381_1481511_1,,0

According to this data, the key was not sent in the price+side format. However, you need to contact the content team directly to verify it. The side is in the ORDER_SIDE field.

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.

@Jirapongse thanks, just would like to know if this is something that you can assist below: Thank you in advance again for your usual support.

One more small query which is still open specifically for MBP [Market By Price] domain ,
Is it guaranteed to receive UNIQUE order id in insert, update, delete actions ?
Is it guaranteed to receive key in insert,update,delete actions in the format price+side, e.g. “105.55A” for MBP domain for all venues?”
We cannot specify a RIC here as we want to know this for MBP domain in general and not for specific RIC.

Upvotes
79.1k 250 52 74

@ryan.roxas

From the API perspective, the keys in map entries must be unique. If it uses an order id as a key, yes the order id in the key must be unique.

A key in a map entry can be anything, such as a string, buffer, or number. According to the RDM usage guide, the key in a map entry of MBP is the buffer.

1671702241405.png

However, because it is a buffer, it can contain anything. You need to contact the content team to confirm the format in the key. It may be different among venues.


1671702241405.png (88.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.

Hi @Jirapongse Thanks for your prompt response and help.

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.