RTO - Service Discovery via Delivery Direct

Hi LSEG,

in a client environment it is required to connect a EMA based application to RTO via Delivery Direct.

As a temporary solution to test a successful connection, the EMA application was using hardcoded values for host and port (EmaConfig-host-port.xml inside the attached zip). Thought not optimal, this configuration was working fine.

To enable Service Discovery, the configuration has been changed to use Location instead (EmaConfig-location.xml inside the attached zip).

However, after the change, the application is no longer able to connect to RTO.

From the logs, we can see that the application now tries to connect to refinitiv.com instead of refinitiv.biz.

*   Trying 75.2.0.254:443...
* connect to 75.2.0.254 port 443 from 0.0.0.0 port 53137 failed: Timed out
*   Trying 99.83.242.11:443...
* connect to 99.83.242.11 port 443 from 0.0.0.0 port 53143 failed: Timed out
* Failed to connect to api.refinitiv.com port 443 after 42082 ms: Couldn't connect to server
* Closing connection

From the "The Real-Time - Optimized Install and Config Guide", we understand that to use .biz endpoints, Service Discovery bypass should be used, but we're not sure to be in the right direction.

Could you please help us clarifying how the configuration should be changed to achieve this?

Thanks,

Paolo

EmaConfig.zip

Find more posts tagged with

connection

ema-api

refinitiv-realtime-optimised

#technology

#product

Accepted answers

Jirapongse

@Paolo Parlapiano

Thank you for reaching out to us.

Did you chage the tokenServiceUrlV2 and serviceDiscoveryUrl in OmmConsumerConfig to refinitiv.biz?

You may verify the connected server from the REST log.

All comments

Jirapongse

@Paolo Parlapiano

Thank you for reaching out to us.

Did you chage the tokenServiceUrlV2 and serviceDiscoveryUrl in OmmConsumerConfig to refinitiv.biz?

You may verify the connected server from the REST log.

Paolo Parlapiano

Hello @Jirapongse,

the tokenServiceURL (V2) is set to https://us-east-1-api.refinitiv.biz/auth/oauth2/v2/token and it's working fine: authentication is successful.

We are not overriding the serviceDiscoveryURL instead.

As a matter of fact, what value should we use for serviceDiscoveryURL in this scenario?

Thanks,

Paolo

Jirapongse

https://us-east-1-api.refinitiv.biz/streaming/pricing/v1/

wasin.w

Hello @Paolo Parlapiano

It should be https://us-east-1-api.refinitiv.biz/streaming/pricing/v1/ endpoint.

us-east-1-api.refinitiv.biz: DNS for the Delivery Direct AMER connection
/streaming/pricing/v1/: the RDP Service Discovery API endpoint.

Paolo Parlapiano

Hi @Jirapongse , @wasin.w ,

thanks for the hints. We've applied the suggested change, and we can see that the applications is downloading the list of services, but after that, the application gets an error.

Both the applications are now using https://us-east-1-api.refinitiv.biz/streaming/pricing/v1/ as Service Discovery URL.

In attachment you can find the logs generated by a EMA java test application and by a EMA C++ application.

In the java case, we get:

Error - exceeded initialization timeout (5 s)

In the c++ case, we get:

Exception Type='OmmInvalidUsageException', Text='login failed (timed out after waiting 45000 milliseconds)', ErrorCode='-4052'

What can be the cause of this new failure?

Thanks,

Paolo

service-discovery.zip
service-discovery-cpp.zip

Paolo Parlapiano

From the documentation, I understand that this paragraph is relevant:

5.3.2.3 Service Discovery

The service discovery API will always return refinitiv.net domain endpoints in the response object. For RTDS and RTSDK Reactor components to leverage service discovery via Delivery Direct, selective forwarding of the optimized-pricing-api.refinitiv.net domain must be configured on client site DNS and/or proxies to direct queries to Delivery Direct eDNS. If it is not possible and/or practical to configure client site local DNS as described the service discovery feature can be bypassed to explicitly use Delivery Direct (.biz) endpoints as a workaround.

Does this mean that to make Service Discovery work, the client must apply some changes to their networking configuration?

Thanks,

Paolo

Jirapongse

@Paolo Parlapiano

Thank you for sharing,

According to that paragraph, you are correct. Please contact the RTO support team directly via MyAccount for more information.

EXPLORE OUR SITES