Login Domain - Components and Elements in Login responses

The below question is related to sections 3.2.4 and 3.2.5 of EMA30_RMD Usage Guide;

The
Login Refresh and Login Status messages of the Login Domain consist of a
number of components and attributes E.g. AllowSuspectData, SingleOpen.

a) Out of these what components and attributes should mandatorily be consumed by the consuming application?

b)
Is it acceptable for the consuming application to not process (i.e.
ignore) non-mandatory fields available in the Login Refresh or Login
Status messages.

c) Is it possible for consuming application to
receive values that are out of range for a particular element; e.g.
Expected values for the element AllowSuspectData are either 0 or 1. Is
it possible that the consumer application to receive any value other
than 1 or 0 (invalid values), may be due to a defect of omm provider.

Find more posts tagged with

elektron

status

refresh

elektron-sdk

refinitiv-realtime

rrt

elektron-message-api

ema-api

log-in

Accepted answers

veerapath.rungruengrayubkul

Please see the following answers to your questions.

a) The Login domain is one of the Reuters Domain Models
(RDMs) which typically are provided or consumed by a Thomson Reuters product, such
as the Enterprise Platform Real-Time, Data Feed Direct, or Elektron. If the
consuming application connects to one of Thomson Reuters product, there should
be no other components and attributes received.

b) The Login is administrative
domain which is generally handled by EMA. Application doesn’t need to process
the Login domain message. However, Login message processing provides additional information about the connected provider.

For example, if an OMM provider
doesn’t support Dynamic View feature, it will send SupportViewRequests = 0 in
the Login refresh message. Once EMA applcation tries to use Dynamic Views
feature by specifying field ID Element List in ReqMsg’s payload, EMA will
process the request depended on received value of the SupportViewRequests. If
SupportViewRequests is 0, EMA will send the request message without views so
that the application receives refresh with all available fields. In this case,
Login refresh processing will provide the reason why Dynamic Views request
doesn’t take effect.

c) If OMM provider actually sends
the out of range values, EMA application will also receive the values. This is
because EMA pass the values received from network to application as is.

All comments

veerapath.rungruengrayubkul

Please see the following answers to your questions.

c) If OMM provider actually sends
the out of range values, EMA application will also receive the values. This is
because EMA pass the values received from network to application as is.

nextersen

Please tell me this will work in conjunction with domain catcher? The fact that I recently bought, it helps my work, but I'm not sure whether it will work with your service, decided to find out in advance.

EXPLORE OUR SITES