@yongguang.wang

Thanks for the log.

Based on your log, it seems to be the issue on the server-side rather than EMA. I’m not sure why the server replies with the invalid_grant because EMA already sends a new request to get a new Access Token with grant_type = refresh_token, and it also sends a valid refresh_token with the request message.

--- REST REQUEST ---

<!-- Time: 22:31:01:808 -->

URL: https://api.refinitiv.com/auth/oauth2/v1/token

HTTP method POST

HTTP header data:

Accept : application/json

Content-Type : application/x-www-form-urlencoded

HTTP body data: grant_type=refresh_token&username=GE-XXXXXXXXXXXXXXXXX&client_id=XXXXXXXXXXXXXXXXXXXXXXXXXXX&refresh_token=XXXXXXXXXXXXXXXXXXXX

Request timeout: 90

--- REST RESPONSE ---

<!-- Time: 22:31:04:547 -->

HTTP header data:

Date : Thu, 14 Jan 2021 03:31:04 GMT

Content-Type : application/json

Content-Length : 29

Connection : keep-alive

X-Amzn-Trace-Id : Root=1-5fffbaf5-31xxxxxxxxxxxxxx498c58c3

X-Served-By : region=us-east-1; cid=43a92xxxxxxxxxxxxxxxxxxxb3205a29

X-Tr-Requestid : xxxxxxxxxxxxxxxx84-3f45af9e7bfe

HTTP body data: {"error":"invalid_grant" }

Protocol version: HTTP/1.1

HTTP status code: 400

--- REST REQUEST ---

<!-- Time: 22:31:09:552 -->

URL: https://api.refinitiv.com/auth/oauth2/v1/token

HTTP method POST

HTTP header data:

Accept : application/json

Content-Type : application/x-www-form-urlencoded

HTTP body data: grant_type=password&username=GE-XXXXXXX&client_id=1fc3b1f559e44d2381c5ffa004909af9c47fb12f&scope=trapi.streaming.pricing.read&takeExclusiveSignOnControl=true

Request timeout: 90

--- REST RESPONSE ---

<!-- Time: 22:31:09:969 -->

HTTP header data:

Date : Thu, 14 Jan 2021 03:31:09 GMT

Content-Type : application/json

Transfer-Encoding : chunked

Connection : keep-alive

Content-Encoding : gzip

X-Amzn-Trace-Id : Root=1-5fffbafd-395d75a2277d9a6417d43767

X-Served-By : region=us-east-1; cid=73ef8666607743fca9aec424574aba15

X-Tr-Requestid : b9395c54-cf7d-479b-b0a7-aa92d476c011

HTTP body data: { "access_token":"eyJ0eXAiOXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-hj2Uiaerqyg8GVvUdOSGzLJ4bunAZCnURln2kozY6Q", "refresh_token":"653XXXXXXXXXXXXXXXXXX", "expires_in":"300" , "scope":"trapi.streaming.pricing.read", "token_type":"Bearer" }

Protocol version: HTTP/1.1

HTTP status code: 200

--- REST REQUEST ---

<!-- Time: 22:35:10:079 -->

URL: https://api.refinitiv.com/auth/oauth2/v1/token

HTTP method POST

HTTP header data:

Accept : application/json

Content-Type : application/x-www-form-urlencoded

HTTP body data: grant_type=refresh_token&username=GE-XXXXXXXXXXXXXXXXX&client_id=1fc3bXXXXXXXXXXXXXXXXXXXXXb12f&refresh_token=65372b05-436b-48c3-9fe2-275e996c03b0

Request timeout: 90

Anyway, after it gets the error, EMA immediately sends a new request with a grant_type password to get a new Access Token instead; therefore, this should not cause a delay in your application. I think that is the reason that EMA treats this kind of message as a warning.

I would suggest you open a case with the RDP server support team and provide them the log to contact the RDP Gateway team to verify what happens at the time reported in the log. As you said previously, this works without warning before, so it is clearly the server-side change.

Hi @yongguang.wang,

The error indicates that you likely do not have valid OAuth grant credentials. When you registered for this service, did you receive a Welcome email that provided you a username and password? If so, did you go through the Quick Start Guide to ensure you have proper access?

thanks.

@yongguang.wang

Are you testing with the EMA C++ example from the RTSDK package?

If it's one of our examples, Can you let me know the command-line arguments you use to run the example?

You can also try your account with the 113_MP_SessionMgmt example; it is an OMM Consumer application example that demonstrates the basic usage of the EMA library in accessing

and parsing OMM market price data from Refinitiv Real-Time - Optimized.

@yongguang.wang

Have you modified any codes before running the app? Or you just build it and then run the app with -username <RDP Username> -password <RDP Password> -clientId <appkey>

Can you try the below curl command with your account on the Linux box? It can help confirm that your login is valid.

curl --location --request POST 'https://api.refinitiv.com/auth/oauth2/v1/token' --header 'authorization: ' --header 'content-type: application/x-www-form-urlencoded' --header 'accept: application/json' --data 'grant_type=password&username=<RDP Username>&scope=trapi&takeExclusiveSignOnControl=true&client_id=<Your App Key>&password=<RDP Password>'

@yongguang.wang

-What version of RTSDK you currently use?

-Did you found the issue after running the application for a while? or you found the error immediately after starting the app?

As far as I understand, the error message is related to the token management that the Reactor fails to use the refresh token grant type to renew the access token, and the Reactor tries to use the password grant type instead. The 240 seconds is the default token reissue interval and 10 seconds is the default retry internal using the password grant type.

Anyway, I can't replicate the issue with the latest version of RTSDK 2.x. I leave it running for a while, and it can run and get the refresh token as usual.

To verify the issue at the application level, please turn on the REST API log. There is the message log for the REST API call that EMA interacts with the RDP Authentication service.

Please add the following log to EmaConfig.xml; if you are using example 113, it should be added under the Consumer_4 section.

<Consumer>

<Name value="Consumer_4"/>

<ChannelSet value="Channel_4"/>

<Logger value="Logger_1"/>

<Dictionary value="Dictionary_1"/>

<XmlTraceToStdout value="0"/>

<RestEnableLog value="1"/>

<RestLogFileName value="Restlog.txt"/>

</Consumer>

You can find additional config from EMACPP_ConfigGuide.pdf provided under folder Docs from RTSDK package.

Ema will generate Restlog.txt under the running directory; it contains the REST API messages EMA sends and receive from the server. We can review the parameters from the log. If it appears to be an incorrect message from EMA, you can directly open a case to the EMA development team.

@yongguang.wang

Version 1.5 still supports, but the error message seems to generate when setting the wrong ChannelType. Actually, I want you to test using the setup explained in Quick Start Guide and then add the following config to the Consumer config you currently use.

<RestEnableLog value="1"/>
<RestLogFileName value="Restlog.txt"/>

If you currently use RTSDK 1.5 and example 113 use Consumer_3, you must add it to Consumer_3.

The original error shows that you are using Consumer_3, but the latest message you provided seems to be Consumer_4 instead. This causes incorrect Channel settings in this case. Note that I use Consumer_4 because the codes in Consumer.cpp from RTSDK 2.0 use Consumer_4 by default.

You can find the following codes to see the difference between the codes from different versions of Consumer.cpp(RTSDK2.0 vs. 1.5). Note that the structure of the EmaConfig.xml has been changed in the latest version.

From RTSDK 2.0 package

// use the "Consumer_4" to select EncryptedProtocolType::RSSL_SOCKET predefined in EmaConfig.xml
        EmaString consumerName = "Consumer_4
        if (connectWebSocket)
        {
// use the "Consumer_5" to select EncryptedProtocolType::RSSL_WEBSOCKET predefined in EmaConfig.xml
            consumerName.set( "Consumer_5" );
        }

From 1.5 package

    // use the "Consumer_3" to select EncryptedProtocolType::RSSL_SOCKET predefined in EmaConfig.xml
        EmaString consumerName = "Consumer_3";

        if (connectWebSocket)
        {
            // use the "Consumer_4" to select EncryptedProtocolType::RSSL_WEBSOCKET predefined in EmaConfig.xml
            consumerName.set( "Consumer_4" );
        }

The original problem you found is that the application found an invalid_grant error when the application re-requests the access token. It’s not the first time the app tries to get a token, so I suspect that EMA might send incorrect grant_type with some invalid parameter to the Authentication Server, there is the reason we need to turn on the REST log file. Also, I suggest you update to the latest version of RTSDK or test it with the latest version because if the problem does not occur with the latest version, it could be some bug, and it is already fixed in the latest build.