I am using the EMA to develop an application posting data to contribution channel. During the test, I got an error saying the encoded data length exceeds RWF length for Fid HST_CLOSE.
HST_CLOSE "HISTORIC CLOSE" 21 NULL PRICE 17 REAL64 7
1. In the RDM dictionary, that fid has RWF len = 7. How should I interpret the len so that I can avoid the error?
2. The DeniedBySource code means the whole message will be denied by the source, right?
3. For the field length (e.g. 17 for fid HST_CLOSE), does it mean the field should have no more than 17 digits in it? Does the decimal point counted in the length?
The value sent out in PostId=9, HST_CLOSE=29979.9
[WARN] 2020-11-22 07:18:02.032896 EST (1610610432):Application::PostMsg Error: AckId: 9, NackCode: DeniedBySource
[WARN] 2020-11-22 07:18:02.032948 EST (1610610432):Application::PostMsg Error: AckId: 9, Text: Encoded data length exceeds RWF length Fid Id  [Failed to apply update. Cache build failed]
Another example is the following:
addRealFromDouble(22,100000000000000.9, ExponentNeg1Enum) [WARN] 2020-12-07 10:58:54.354297 EST (3345233664):Application::PostMsg Error: AckId: 74106, Text: Encoded data length exceeds RWF length Fid Id  [Failed to apply update. Cache build failed]
In this example we cannot use a better hint to represent the value.
The value can be represented as a Real using the EMA API, why is it rejected when contributing?
The value you are posting should not exceed the length of REAL64.
To enable the tracing, please add the XmlTraceToFile parameter for the Channel that you wish to enable XML Trace for. The file will be in "emaLog_<pid>.log" format.
Yes, I am using EMA C++ to post into the Contribution Channel.
Here is the code i use. The upstream data is in a different price type. Price precision will tell us how many digits after the decimal point we need to keep. we then map it to the corresponding OmmReal Exponent Enum.
mamaPricePrecision pp = mPrice.getPrecision();
if( _precisionMap.find(pp) != _precisionMap.end() )
fList.addRealFromDouble( it->getOutputTag(), mPrice.getValue(), _precisionMap[pp] );
px << mPrice.getValue();
I can't find the message "Encoded data length exceeds RWF length" from EMA source codes so that I believe that it comes from the infra backend; in this case, it should be the RCC or Contribution Channel. The problem seems to relate to the double value and exponent enum you set in the post message. Therefore I need to see the RSSL Trace log generated by the app when you found the issue. It should help us verify what data the application publishes to the RCC at the time problem occurs.
I also did a quick test with the RCC example we provided on the Dev Portal.
I change the codes to use .addRealFromDouble to send the Real64 data with the sample double vale 29979.9 and below are my snippet codes.
.addRealFromDouble(22, 29979.9, OmmReal::ExponentNeg1Enum)
I test the app, and it can post data to the server without the issue. And below is the raw data EMA send to the server.
<fieldEntry fieldId="22" data="0D04 9317"/>
0D = 13 = ExponentNeg1Enum
and 049317 = 299799.
We can compare it with the raw data from the RSSL Trace. What I can help is to verify the data which send from the app. If it's the correct value, that should be the problem on the RCC server-side, and you might need to contact the support team who takes care of the Contribution Channel server to further investigate the issue.
The following is the TRACE log we get when sending out HST_CLOSE.
[Message] feed=refinitivsource=PB-NAMR-DEVsymbol=MSTEST001.PUBHSTCLSDATE=04 DEC 2020HST_CLOSE=29979.9TRDPRC_1=12345publish_time=2020-12-04 09:58:03.475806 ESTcontrib_sym=TEST0009=JPMLmapSource=EMEA_EDG_INDEX_CHAIN_REUTERShash=15222191812757905843PostID=290796 <!-- Outgoing Message (Channel IPC descriptor = 15) --> <!-- Time: 9:58:03:476 --> <!-- rwfMajorVer="14" rwfMinorVer="1" --> <genericMsg domainType="RSSL_DMT_SYSTEM" streamId="4" containerType="RSSL_DT_MSG" flags="0x19 (RSSL_GNMF_HAS_EXTENDED_HEADER|RSSL_GNMF_HAS_SEQ_NUM|RSSL_GNMF_MESSAGE_COMPLETE)" seqNum="290797" dataSize="79"> <extendedHeader data="0100"/> <dataBody> <!-- rwfMajorVer="14" rwfMinorVer="1" --> <postMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="6" containerType="RSSL_DT_MSG" flags="0x62 (RSSL_PSMF_HAS_POST_ID|RSSL_PSMF_POST_COMPLETE|RSSL_PSMF_ACK)" postId="290796" postUserId="0" postUserAddr="0.0.0.0" dataSize="57"> <dataBody> <!-- rwfMajorVer="14" rwfMinorVer="1" --> <updateMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="6" containerType="RSSL_DT_FIELD_LIST" flags="0x8 (RSSL_UPMF_HAS_MSG_KEY)" updateType="0 (RDM_UPD_EVENT_TYPE_UNSPECIFIED)" dataSize="29"> <key flags="0x2 (RSSL_MKF_HAS_NAME)" name="TEST0009=JPML"/> <dataBody> <fieldList flags="0x8 (RSSL_FLF_HAS_STANDARD_DATA)"> <fieldEntry fieldId="79" data="040C 07E4"/> <fieldEntry fieldId="21" data="0401 10AA 64E6 2600"/> <fieldEntry fieldId="6" data="0B00 BC5E A9"/> </fieldList> </dataBody> </updateMsg> </dataBody> </postMsg> </dataBody> </genericMsg> <!-- End Message (Channel IPC descriptor = 15) -->
This results in the following application log:
[WARN] 2020-12-04 09:58:03.531388 EST (3143907072):Application::PostMsg Error: AckId: 290796, Text: Encoded data length exceeds RWF length Fid Id  [Failed to apply update. Cache build failed]
Code (substituting tag,value,and hint variables):
addRealFromDouble( 21, 29979.9, OmmReal::ExponentNeg10Enum);
It looks like the problem comes from the MagnitudeType you set in the addRealFromDouble function. It should be ExponentNeg1Enum rather than ExponentNeg10Enum.
Not sure why you set it to ExponentNeg10Enum in this case?
The value you set in EMA seems to not over 8 bytes and still covered by the Real data type. I think it should be the problem from the caching feature on the infra side. I also try the value, and it looks like the status text was generated by the infra. Basically, EMA provides a method for the user to set value and its magnitude type and then pass it to the back end, so it does not know a limitation on the specific back end.
I would suggest you contact the RCC team directly to verify the issue on the infra side and confirm its cause.
You can open a new support ticket via https://my.refinitiv.com/content/mytr/en/productsupport.html
And select the following product