question

Upvotes
Accepted
18 2 2 1

Migrating from sfc to EMA, NoDictionary errorcode.

We have a provider and consumer app developed with SFC. We are migrating to EMA.

I'm working on the EMA provider to replace the SFC provider.

When I send in an update request from the old SFC consumer, via the TREP servers, to the new EMA provider, I get the following postMsg with a NoDictionary error.

PostMsg

streamId="1"

domain="MarketPrice Domain"

Complete

Ack Requested

postId="65"

publisherIdUserId="0"

publisherIdUserAddress="0"

name="Record1"

serviceId="1"

Payload dataType="UpdateMsg"

UpdateMsg

streamId="0"

domain="MarketPrice Domain"

updateTypeNum="0"

name="Record1"

serviceId="9010"

Payload dataType="Error"

OmmError

ErrorCode="NoDictionary"

OmmErrorEnd


PayloadEnd

UpdateMsgEnd


PayloadEnd

PostMsgEnd


However, when I send an update via the sample EMA consumer app cons340, to my new EMA provider via the TREP servers, I do not get a NoDictionary error. I get the following postMsg with a correct field list.

PostMsg

streamId="3283"

domain="MarketPrice Domain"

Complete

Ack Requested

postId="66"

publisherIdUserId="0"

publisherIdUserAddress="0"

name="Record1"

serviceId="1"

Payload dataType="UpdateMsg"

UpdateMsg

streamId="0"

domain="MarketPrice Domain"

updateTypeNum="0"

name="Record1"

Payload dataType="FieldList"

FieldList

FieldEntry fid="25" name="ASK" dataType="Real" value="800"

FieldEntry fid="22" name="BID" dataType="Real" value="700"

FieldListEnd


PayloadEnd

UpdateMsgEnd


PayloadEnd

PostMsgEnd


Any ideas on how to fix this.

I'd like the old consumer to still work, is that possible?

elektronrefinitiv-realtimeelektron-sdkema-apirrtelektron-message-apierrorOMM
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
Accepted
25.3k 87 12 25

Hi @gproctor

My understanding from the above is that you are contributing data (Insert) from an SFC app to an EMA Provider via TREP.

SFC uses the legacy MarketFeed (MF) format and EMA uses the newer OMM/RWF data format.

The conversion should be handled by your TREP ADS+ADH components - so my first thought would be that there is something not right with the TREP config in terms of converting the MF Insert to an OMM PostMsg.

I am not a TREP expert so not familiar with the exact TREP config that would affect this behaviour. Therefore, I recommend that you speak to your Market Data team and ask them to confirm the related config. If they are unsure, they can create a ticket with the TREP support team for further guidance.

In the meantime, I will also check internally to see if there are any known issues with sending an Insert from an MF based app to an OMM based Provider and report back with any findings.

Also, I just noticed that the StreamID for the first post is StreamID 1 - which is usually reserved for a Login stream - which may be worth mentioning to the MarketData team / in the TREP Support ticket if they end up raising one.


icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
11.3k 25 9 14

@gproctor,

There is a known issue regarding "NoDictionary" error on EMA OmmProvider which could be related to the scenario you found. The issue occurs when EMA OmmProvider tries to decode payload of Off-Stream Posting (Posting on Login Stream). With On-Stream Posting, the provider works properly.

The issue has been fixed in the Refinitiv Real-Time SDK C/C++ 2.0.0.L1 version. Please try the 2.0.0.L1 version. You can download the version from https://developers.refinitiv.com/en/api-catalog/elektron/elektron-sdk-cc/downloads.


Below is the reference of the fix.

- [Case Number: 09179092] - [ESDK-4397] - EMA C++ offstream posting payload decode issue

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.