Empty Data packet received from reuters

Hi @tsss

Are you able to advise which RIC you were consuming and which field was being processed when the above isBlank check was triggered?

It is indeed possible for a blank field to be sent out by the server and thereby to be received by your application.

A Blank field would indicate there is no value available for that particular field at that point in time. The Blank field is there to differentiate from say a 0 value which could be a valid price or quantity in the context of a particular instrument.

A field that previously contained a non blank value could be updated with a blank if the data source / provider decides to blank that value for whatever reason - e.g. for example if I subscribe to say an LSE equity instrument outside of trading hours, the TRDPRC_1 field would be blanked as there is no current trade activity for that instrument.

In theory, it is possible to get a blank field list. I have modified the provider to publish this update.

<updateMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="3" containerType="RSSL_DT_FIELD_LIST" flags="0x0" updateType="0 (RDM_UPD_EVENT_TYPE_UNSPECIFIED)" dataSize="0">
    <dataBody>
    </dataBody>
</updateMsg>

Then, I added the code in the consumer to print the data type of data when the data is blank.

if (data.isBlank()) {
            printf("### Data is blank: 0x%x, %d\n", data.getDataType(), data.getDataType());            
        }

The consumer prints this message when decoding the update message with no payload.

2020 Jul  3 13:42:22.096 ST GMT+07:00 1AE4 33C4   611 TRACE <- Received MMT_MARKET_PRICE Update.
### Data is blank: 0x84, 132

However, the server shouldn't send the kind of update to the application.

To verify the problem, you need to print the raw hex data of the response message.

The code looks like:

void Decoder::printHexString(const unsigned char* data, int len) {
    char hexmap[] = { '0', '1', '2', '3', '4', '5', '6', '7',
                           '8', '9', 'a', 'b', 'c', 'd', 'e', 'f' };
    std::string s(len * 2, ' ');
    for (int i = 0; i < len; ++i) {
        s[2 * i] = hexmap[(data[i] & 0xF0) >> 4];
        s[2 * i + 1] = hexmap[data[i] & 0x0F];
    }
    printf("\n%s\n", s.c_str());

}

Then, call the printHexString method with the encoded buffer inside the response message.

    _pDecoder->printHexString(respMsg.getEncodedBuffer().c_buf(), respMsg.getEncodedBuffer().capacity());

With this information, we can verify the data retrieved by the application.

H i@tss,

You are welcome.

Once you do capture the details of blank data instances, you can raise a Content type ticket for the Elektron Rrealtime product -at My.Refinitiv

They can investigate Elektron content issues and hopefully will be able to explain the blank data instances.

Hi @tss,

Thanks for getting back but, apologies, I don't fully understand your response?

In the above check, you are checking if the payload flag is not present you return - but in our examples, it checks if the payload flag exists and if the payload isBlank() then it returns.

If the Payload or any contained Data isBlank()==true then you would not need to process/extract any fields etc from that Payload or Data.