FieldEnty order guarantees

Is there any guarantees about field entries order?

Given response

    FieldList
    FieldEntry fid="25" name="ASK" dataType="Real" value="67.7"
    FieldEntry fid="31" name="ASKSIZE" dataType="Real" value="200.0"
    FieldEntry fid="3435" name="MMID" dataType="Rmtes" value="ARCA"
    FieldEntry fid="8464" name="ASK_TONE1" dataType="Rmtes" value="A"

Can I be 100% sure that 31 always comes after 25 or response can contain entries without any order?

   FieldList
   FieldEntry fid="8464" name="ASK_TONE1" dataType="Rmtes" value="A"
   FieldEntry fid="31" name="ASKSIZE" dataType="Real" value="200.0"
   FieldEntry fid="25" name="ASK" dataType="Real" value="67.7"
   FieldEntry fid="3435" name="MMID" dataType="Rmtes" value="ARCA"

Find more posts tagged with

elektron

elektron-sdk

refinitiv-realtime

rrt

elektron-message-api

ema-api

Accepted answers

umer.nalla

I have never an read or come across mention of a guarantee about field order entries.

I suspect it may depend on the behaviour of the provider you are connected to (remember that if your consumer app connects to the ADS, then the ADS is provider as far as your consumer is concerned)

I tried a quick test here with a Provider (connected to an ADH), using a simple record with 3 FIDs - publishing the initial image and then sending out an update.

I intentionally added the FIDs to the msg Payload in the following order:

22 (BID),
7 (TRDPRC_2)
8 (TRDPRC_3).

The consumer connected to an ADS received the initial Image with the data sorted by FID :

FieldList: standard data count = 3
        FieldEntry [     7] TRDPRC_2    120
        FieldEntry [     8] TRDPRC_3    310
        FieldEntry [    22] BID 250

But the Update was received in the order as published

FieldList: standard data count = 3
        FieldEntry [    22] BID 260
        FieldEntry [     7] TRDPRC_2    130
        FieldEntry [     8] TRDPRC_3    320

Therefore, I think it would be safer not to rely on a guaranteed order.

All comments

umer.nalla

I have never an read or come across mention of a guarantee about field order entries.

I suspect it may depend on the behaviour of the provider you are connected to (remember that if your consumer app connects to the ADS, then the ADS is provider as far as your consumer is concerned)

I tried a quick test here with a Provider (connected to an ADH), using a simple record with 3 FIDs - publishing the initial image and then sending out an update.

I intentionally added the FIDs to the msg Payload in the following order:

22 (BID),
7 (TRDPRC_2)
8 (TRDPRC_3).

The consumer connected to an ADS received the initial Image with the data sorted by FID :

FieldList: standard data count = 3
        FieldEntry [     7] TRDPRC_2    120
        FieldEntry [     8] TRDPRC_3    310
        FieldEntry [    22] BID 250

But the Update was received in the order as published

FieldList: standard data count = 3
        FieldEntry [    22] BID 260
        FieldEntry [     7] TRDPRC_2    130
        FieldEntry [     8] TRDPRC_3    320

Therefore, I think it would be safer not to rely on a guaranteed order.

Steven McCoy

A payload caching device such as TREP or the RSSL Value Add Cache will re-order the Field List to its internal optimal ordering strategy. This means with an item stream you may even see different orders between the initial refresh and subsequent updates, for example:

Received Source Directory Update

MSFT.O
DOMAIN: RSSL_DMT_MARKET_PRICE
State: Open/Ok/None - text: ""
        RDNDISPLAY          100
        TRDPRC_1            11

MSFT.O
DOMAIN: RSSL_DMT_MARKET_PRICE
State: Open/Ok/None - text: ""
        TRDPRC_1            12
        RDNDISPLAY          100


MSFT.O
DOMAIN: RSSL_DMT_MARKET_PRICE
State: Open/Ok/None - text: ""
        TRDPRC_1            13
        RDNDISPLAY          100

MSFT.O
DOMAIN: RSSL_DMT_MARKET_PRICE
State: Open/Ok/None - text: ""
        TRDPRC_1            14
        RDNDISPLAY          100

brian.sandri

I agree with the above answers. Per OMM specifications, the order of field entries is not guaranteed and you should not expect it to come in the order of the field IDs. The only container type that supports strict ordering is the OMM Vector, and even then the application is responsible for ensuring the order; the actions on each vector entry provide the details needed to order.

EXPLORE OUR SITES