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.

Find more posts tagged with

market-by-price

rfa-api

#content

Accepted answers

Jirapongse

@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.

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.

All comments

Jirapongse

@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.

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.

ryan.roxas

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?”

Jirapongse

@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.

ryan.roxas

@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.

Jirapongse

@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.

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.

ryan.roxas

Hi @Jirapongse Thanks for your prompt response and help.

EXPLORE OUR SITES