How to check whether Rmtes string contains partial update

Sergei Nazarov
Sergei Nazarov Newcomer
in EMA

We are implementing Rmtes string partial updates in our application and facing problems with testing it on rics ICAB[1-5]. Initial data snapshot contains proper data and looks like this (e.g. from fid ROW80_5):

1 Yr -07.25/-17.25  +13.50/+07.50  +15.25/+09.25  +09.25/+03.25   -20.75/-30.75

but in refresh message we are receiving update on the same fid and string replaced with something like this

09:02 1.00020 6.0000¥¥6.50/-25.50  .25.25¥¥36.25¥¥¥20.50¥¥¥4.50¥¥¥¥¥0.75¥¥¥0.75

We are using Ema library 1.2.0 and applying updates like this

    const FieldEntry& fe = fieldList.getEntry();
    rmtesBuffer.apply( fe.getRmtes() );

Initially we were storing char array from obtained string with getAsUTF8().c_buf(), it had the same effect.

So we would like to check whether updated rmtes string contains proper update sequence 0x1B 0x5B <offset position> 0x60, but we were wondering what is the proper way to translate Rmtes string into hex? Also does translation of Rmtes string into EmaBuffer removes any sequences like the one showed above?

Tagged:

Best Answer

  • Sergei Nazarov
    Sergei Nazarov Newcomer
    Answer ✓

    So what was found out:

    • the corruption of underlying on transformation to EmaBuffer is present in 1.2.0 version of ema library, but was fixed somewhere before 1.4.0.
    • transformation to EmaBuffer will return wrong data anyway, so it's not usable even in later versions
    • as a solution we've decided to copy field as Data and store it as hex in EmaBuffer
    const FieldEntry& fe = fl.getEntry();
    const thomsonreuters::ema::access::Data& data = fe.getLoad();
    const thomsonreuters::ema::access::EmaBuffer buffer = data.getAsHex();
    rmtesBuffer.apply(buffer.c_buf(), buffer.length());

Answers

  • zoya faberov
    zoya faberov ✭✭✭✭✭

    Hello @Sergei Nazarov,

    EMA would differentiate between refreshes and updates on the application's behalf, and trigger the appropriate registered callback.

    I would try testing with example 310_MarketPrice_RMTES that comes with SDK.

    The example is geared toward news RMTES, so in order to test with ICAB1-5, you would:

    Modify on register:

    UInt64 handle = consumer.registerClient( ReqMsg().serviceName( "ELEKTRON_EDGE" ).name( "ICAB1"/*"N2_UBMS"*/ ), client, closure

    And modify on decode:

    void AppClient::decode( const FieldList& fl )
    {
        while ( fl.forth("ROW80_5" /* "BCAST_TEXT"*/ ) )
        {
            const FieldEntry& fe = fl.getEntry();

            cout << "Name: " << fe.getName() << " Value: ";

            rmtesBuffer.apply( fe.getRmtes() );
            cout << rmtesBuffer.toString() << endl;
        }
    }

    I am unable to test an update on this now, as the instrument is not active.

    For more information, if you would like to learn more about the RMTES refresh and update, as Transport tier handles RMTES for Message tier in ETA Developer Guide, lookup section "RMTES Decoding" and "rsslHasPartialRMTESUpdate".

  • Sergei Nazarov
    Sergei Nazarov Newcomer

    Hi, @zoya.farberov! Thanks for the suggestion with 310 example. It works as expected and I've noticed what was different in our app. Since creating RmtesBuffer copy with update is restricted and throws exception, we were getting EmaBuffer(EmaBufferU16 has the same effect), but turns out that this exact action is corrupting data in RmtesBuffer and we see gibberish I've shown as example in first question in buffer. Could you please tell what is the proper way to store a copy of rmtes update? Due to our design it's not really possible to apply it immediately after obtaining.

  • zoya faberov
    zoya faberov ✭✭✭✭✭

    Hi @Sergei Nazarov,

    For me, the simpler approach is to copy the message, rather then the buffer, if you are on one of the later versions of EMA that supports the feature.

    In Reference Guide see

    :UpdateMsg::UpdateMsg    (    const UpdateMsg &     other    )    
    Copy constructor.

    This will save you processing time in main thread callback which is very important, and potentially allow to offload heavy processing to worker threads as design choice.

Categories