Field length different between image data and update data

Hi folks,
I am using rfa8.1.0 C++ for encoding a field of RMTES_STRING with length of 255.
The length of this field with RespMsg::RefreshEnum (image data) is corresponding to 256 while with RespMsg::UpdateEnum this field can be sent with a length much more longer (1500).
Is there any explanation for this behavior ?
Thanks,
Best Answer
-
I couldn't find the setFromString method in the Buffer class.
Buffer bf;
bf.setFrom((unsigned char*)"TEST String", 11);Anyway, you may enable tracing in the API to verify the outgoing messages.
\Connections\<ConnectionName>\traceMsgToFile = true
\Connections\<ConnectionName>\traceMsgDomains = "all"
\Connections\<ConnectionName>\traceMsgMaxMsgSize = 5000000
\Connections\<ConnectionName>\traceMsgMultipleFiles = true
\Connections\<ConnectionName>\tracePing = truePlease change <ConnectionName> to the name of your connection. The RSSL tracing log would be created with the connection name, a process ID, and a ".xml" extension, such as <ConnectionName>_7648.xml in the same directory of the application.
If you find a string that is longer than 255 bytes in the trace file, it could be a problem in the application or RFA.
0
Answers
-
Thanks for reaching out to us.
How did you encode the data?
I modified the StarterProvider_Interactive example in the RFA C++ package to encode the SEG_TEXT field.
void Encoder::encodeMarketPriceFieldList(FieldList* pFieldList, bool bRefresh)
{
assert(pFieldList);
FieldListWriteIterator fieldListWIt;
...
field.clear();
Buffer bf;
bf.setFrom((unsigned char*)"TEST String", 11);
field.setFieldID(258);//SEG_TEXT
dataBuffer.setBuffer(bf, DataBuffer::StringAsciiEnum);
field.setData(dataBuffer);
fieldListWIt.bind(field);
fieldListWIt.complete();
}The following is the data retrieved by a consumer.
<updateMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="4" containerType="RSSL_DT_FIELD_LIST" flags="0x0" updateType="0 (RDM_UPD_EVENT_TYPE_UNSPECIFIED)" dataSize="26">
<dataBody>
<fieldList flags="0x8 (RSSL_FLF_HAS_STANDARD_DATA)">
<fieldEntry fieldId="2" data="64"/>
<fieldEntry fieldId="6" data="0C7A"/>
<fieldEntry fieldId="258" data="5445 5354 2053 7472 696E 67"/>
</fieldList>
</dataBody>
</updateMsg>
<!-- End Message (Channel IPC descriptor = 528) -->
UpdateMsg
streamId="5"
domain="MarketPrice Domain"
updateTypeNum="0"
name="IBM.N"
serviceId="1"
serviceName="DIRECT_FEED"
Payload dataType="FieldList"
FieldList
FieldEntry fid="2" name="RDNDISPLAY" dataType="UInt" value="100"
FieldEntry fid="6" name="TRDPRC_1" dataType="Real" value="1.22"
FieldEntry fid="258" name="SEG_TEXT" dataType="Rmtes" value="TEST String"
FieldListEnd
PayloadEnd
UpdateMsgEndI hope that this information is of help
0 -
Hi Jirapongse,
Thank you for your help.
My code based on the example below in RFA C++ packagevoid StarterProvider_NonInteractive::submitMsg()
{
/*
*/
RespStatus status;
if(!pTS->bSubmitted)
{
status.setStreamState(RespStatus::OpenEnum);
status.setDataState(RespStatus::OkEnum);
status.setStatusCode(RespStatus::NoneEnum);
status.setStatusText(RFA_String("UnSolicited Refresh Completed", 0, false));
setMarketPriceMsg(RespMsg::RefreshEnum, pTS->attribInfo, status, pCSH, true);
/*
*/
}
else
{
setMarketPriceMsg(RespMsg::UpdateEnum, pTS->attribInfo, status, pCSH, pTS->bAttribInfoInUpdates)
/*
*/
}
}
void StarterProvider_NonInteractive::setMarketPriceMsg(RespMsg::RespType respType, /**/)
{
/**/
bf.setFromString("veryLongString");
field.setFieldID(4281);//NEWSCODE05 with length : 255
dataBuffer.setBuffer(bf, DataBuffer::StringRMTESEnum);
field.setData(dataBuffer);
fieldListWIt.bind(field);
/*/
}
The point is when callingsetMarketPriceMsg(RespMsg::RefreshEnum, ...);
the data retrieved by a consumer is stripped to 255 charracters but
setMarketPriceMsg(RespMsg::UpdateEnum, ...);
the data retrived is totally fine (all the content is received with more than 1500 characters)
I can not explain this behavior.
0 -
Hi Jirapongse,
Thanks for your help.
Yes, I think that could be a problem in the RFA.
A string with more than 255 characters cannot be encoded/sent/decoded.
I should use a vector.
0
Categories
- All Categories
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 33 Data Model Discovery
- 682 Datastream
- 1.4K DSS
- 613 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 248 ETA
- 552 WebSocket API
- 37 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 275 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.8K Refinitiv Data Platform
- 622 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 26 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 191 TREP Infrastructure
- 228 TRKD
- 915 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 83 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛