Issue with TR UPA Java Consumer APIs - DecodeMapEntry failed UNSUPPORTED_DATA_TYPE

I am developing a Consumer application using the TR UPA Java APIs. The Consumer application connects to UCDP system and - after Login, Source and Directory requests - makes a STORY domain request. While trying to handle the STORY domain response I am running into following error:

DecodeMapEntry() failed:

For reference I am using the "Example" classes, mostly unchanged, provided with the UPA Java API and demo distribution and here is the actual API information as it dumps to the screen upon startup:

Ultra Performance API (UPA), Java Edition, LibraryVersionInfo
productVersion: upaj7.4.0.L1.all.rrg
productInternalVersion: upaj7.4.F9
productDate: Fri May 16 12:00:00 CST 2014 Thomson Reuters

I duplicated the code for MarketPriceHandler for handling STORY response and from what I can see the exception/error is coming from base UPA libraries - or more likely - because of incorrect use of UPA APIs in my application.

I would appreciate any help.

Find more posts tagged with

consumer

refinitiv-internal

elektron-sdk

Accepted answers

All comments

piyasak.chansaengsai

According to the UPA Java Developer's guide, the error code UNSUPPORTED_DATA_TYPE indicates that the type is not supported for the operation being performed. This might indicate a primitiveType is used where a containerType is expected or the opposite.

However, I don't have a feed providing STORY domain, please let me know if there is a test feed available so that I can run a test app to check what would be wrong.

Thanks,
Piyasak

Kamalesh Patil

hi Piyasak, thanks for your reply. Here are the parameters I am using to connect to the UCDP system - host: 10.51.13.16, port: 50001, service: NEWS.
Currently user name is optional.
Is there anything else you need from me?

piyasak.chansaengsai

Unfortunately, I could not connect my application to the host 10.51.13.16, port 50001. The telnet command "telnet 10.51.13.16 50001 indicated that it could not connect to this address.

However, there was an issue with similar to this one, as follows:
---------------------------------------
upaj7.1.0.E1.all
---------------------------------------
upaj1282; Codec: UPA Java cannot decode a MapEntry that has a key with
datatype of INT
MapEntries with keys of primitive type INT cannot be properly decoded.
A change was made to make sure that MapEntries with keys of any primitive type
can be properly decoded.

It might be the same issue in case that the decoder still does not support the primitive data type used by STORY domain. Would you mind if I create a case (in service cloud) to perform further investigation on this case?

Note that we also would like to know the RIC and structure of STORY domain as it is not currently avaiable in our RDM usage guide.

Thanks & regards,
Piyasak

Kamalesh Patil

Brian Sandri helped resolve the issue for me. As I suspected the issue was incorrect use of the APIs.
In Brian's own words
"This looks like your code is written to decode a Map, but the content being sent is a Field List. I am not sure how the Story domain content should be encoded as I have not been involved in those discussions, and since it has not been published in our RDM Usage Guide customer facing document, I have no reference here.

Looking at the XML trace you provide, this is an Update message on the STORY domain type, and the container type says it is a Field List (this means the message’s top level container in its content is Field List.

Your code and your StoryHandler is structured to invoke the Map decoder at the top level – if you are receiving the content that is being sent as a Field List, this is what is causing your problem. Your code should be invoking the Field List decoder instead of the Map decoder. You/your application can determine this by looking at the container type specified by the message.

In general, OMM applications are coded up in two ways:

Way 1) content handlers are written specifically for the content they are consuming based on a well known and agreed upon definition. The handlers we provide in our example applications are coded specifically for the domain models that they are handling (e.g. MarketPriceHandler strictly follows the domain model of MarketPrice as seen in the RDMUsageGuide document that TR provides – this is on the customer zone and is shipped with all API releases).
Way 2) a content handler can be written to generically interpret content based on the information provided on the wire. In this pattern, you would have a switch statement at each level that can invoke the correct decoder based on the containerType specified for that level. For instance, when processing message payload, the switch would handle all container types and would go into the case based on what is present on msg.containerType. This would basically follow the same behavior all the way down the stack.

Since you are trying to specifically handle the Story domain, you can likely follow Way 1, but you need to make sure your code is structured properly to handle the actual content being sent to you. In your case, the MarketPrice handler is likely a better starting point since it is invoking the field list decoder at the top level."

EXPLORE OUR SITES