RFA Api : Multipart Refresh message with unexpected cache clearing instruction in between

mktdata
mktdata
in RFA

Hello, we use RFA 8.2 C++ api to consume market data in MBP domain. Please let us know if following message format is expected and if yes where it is documented?

<Refresh Message A>

Part <1> of Refresh Message <A> with clear cache instruction and summary fields

Part <2> of Refresh Message <A> with clear cache instruction and summary fields

Part <3> of Refresh Message <A> with RefreshComplete flag


The problem here is same summary fields are published twice in same Refresh Message. Is it expected?


Also is it allowed to publish same summary fields multiple times in same Refresh Message without any cache clearing instructions in between?

Tagged:

Answers

  • Jirapongse
    Jirapongse

    @mktdata

    Thank you for reaching out to us.

    Typically, the CLEAR_CACHE flag should only be set in the first part of the multipart refresh messages.

    1725594717343.png

    The summary data in a MAP is used to convey information that applies to every entry housed in the container. Using summary data ensures data is sent only once, instead of repetitively including data in each entry.

    I checked the RDM usage guide of Market By Price and found that the summaryData of the RsslMap needs to be present only for the first refresh part, which typically includes:

    • Permission information (PROD_PERM)
    • Currency of the orders (CURRENCY)
    • Trade Units for the precision with which order prices are set (TRD_UNITS)
    • Market State (MKT_ST_IND)
    • The identifier of the exchange on which the orders were placed (RDN_EXCHD2)
    • Price Ranking Rules (PR_RNK_RUL)
    • Quote Date (QUOTE_DATE)

    However, please contact the content support team directly via MyAccount to verify the content published on the Real-Time network.

  • mktdata
    mktdata

    @Jirapongse Thank you for your response.

    We have a use case from Milan Exchange (Sample RIC DIAS.MI) MBP domain where we are receiving messages that do not follow what you mentioned -

    1. As seen in my original post, we receive clear cache instruction(flag) in second part of the multipart refresh messages.

    2. We also receive summary fields such as INSTRUMENT_PHASE and TRD_STATUS are present in even second part of the Refresh message.


    I am not sure why only Milan stock exchange is exception as we have a client who trades globally and never faced this issue before.


    Do you think if Milan MBP data is not inline with protocol?


    Also can you tell me how is the end of Multi part refresh message is marked? I know it is marked using RefreshCompleteFlag but just wanted to confirm.

  • Jirapongse
    Jirapongse

    @mktdata

    You may need to enable tracing in API to verify the retrieved data. Then, please contact the content support team directly to verify this.

    Yes, you are correct. A flag value of COMPLETE indicates the final part of a multi-part message (or that the message is a single-part and no subsequent parts will be delivered).

  • mktdata
    mktdata

    @Jirapongse Alternatively I can also use consumer client and share it's log as well right?

  • Jirapongse
    Jirapongse

    @mktdata

    If you see the same behavior in the trace log, you need to contact the support team to verify it.

    The support team needs to check with the data feed team to confirm the behavior.

  • mktdata
    mktdata

    @Jirapongse Is it possible that application will receive same summary field twice in same refresh message <which is multi-part> without cache clear instruction separating them?


  • Jirapongse
    Jirapongse

    @mktdata

    Yes, it is possible. We need to check the trace file.


Categories