Suggestions for how to use UPA/TREP for complex snapshot queries?

Jonathan Haruni - Refinitiv

Any suggestions for using TREP for a request/response application
where the requests are too complex to encapsulate in a RIC? IE the request should carry arbitrarily large
structured payload.

The idea is to build a publisher that can be deployed and operated like any other TREP publisher to handle parameterized analytical queries. Mostly snapshot but streaming may be used for some purposes.

Idea 1: Can an OMM
REQUEST message field msgKey.name contain arbitrary content? Is there a size limit?

Idea 2: Can an OMM REQUEST message field “Payload” be used
for arbitrary purposes? I see in documentation
how to use this for specific purposes such as Batch Request under various
RDMs. But with existing domains or if you build your own can you load up the Payload of an RSSL_MC_REQUEST with whatever you want? Any examples?

Idea 3: Are private streams with Generic messages a good way
to do this? If used, can the ADH’s load
balancing features be used to dole out private stream requests to several
identical publishers? Does this
effectively provide load balancing?
Does it do failover too, i.e. if a consumer is connected to a private
stream provider that fails will ADH reconnect it to a different one? This
would allow the consumers and infrastructure/operations to be handled in familiar ways.

Any different suggestions?

Jirapongse

MsgKey.name type is an RsslBuffer type that allows for a name of up to 255 bytes. Its content should comply with the rule associated with the MsgKey.nameType member, such as RIC.

Another option is using MsgKey.attribContainerType and MsgKey.encAttrib. MsgKey.attribContainerType identifies the content type of the MsgKey.encAttrib information.

This attribute typically allows for further uniqueness in the identification of a stream. It is also an RSSLBuffer that can represent up to 32,767 bytes of information.

david.mazeska

Jirapongse's answer is correct. By setting this payload in the encAttrib, it guarantees stream uniqueness.

You can put this in the request payload as well. However, when that happens if two users request the stream with the same msgKey but different payloads, they will get merged into one. Only way to prevent that is to use private streams.

I prefer recommending use of the encAttrib to solve this problem.

You could use GenericMsg too but that is an extra level of complexity that is best to be avoided if you can convey all the necessary information in the request. A GenericMsg should only be used when establishing a private stream to the service. Private streams are really only used for either targeted posting of data OR the need of line of sight from consumer to publisher application whereby source app must then do the fanout and TREP is just a conduit.