Login Domain - Components and Elements in Login responses

Axe

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.

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.

Unknown

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.