Got “Invalid encrypted protocol type(2) for requesting RDP service discovery, ErrorCode=-22” when running EMA application consumer example cons113. What's the root cause? Is that due to TLS version?
Hello @Frederic
My colleague, @Jirapongse can replicate the issue by setting the wrong value to the EmaConfig.xml's EncryptedProtocolType property.
Could you share and recheck your EmaConfig.xml file? The supported value of the EncryptedProtocolType for the encrypted RSSL connection (RTO) is as follows:
I never experience this kind of error message. Could you please give me more detail as follows?
Can you try the following cURL commands in the same machine that encounters the issue?
Step 1: Authentication
If you are using the Version 1 Authentication (Machine-ID type)
curl -X POST \ 'https://api.refinitiv.com:443/auth/oauth2/v1/token' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'username=<Machine-ID>' \ --data-urlencode 'password=<Password>' \ --data-urlencode 'client_id=<App Key>' \ --data-urlencode 'grant_type=password' \ --data-urlencode 'takeExclusiveSignOnControl=true' \ --data-urlencode 'scope=trapi'
If you are using the Version 2 Authentication (Service Account/CIAM type)
curl -X POST \ 'https://api.refinitiv.com:443/auth/oauth2/v2/token'; \ --header 'Accept: */*' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'client_secret={client secret}' \ --data-urlencode 'client_id={client id}' \ --data-urlencode 'grant_type=client_credentials' \ --data-urlencode 'scope=trapi'
Then copy the return access token.
Step 2: Test Service Discovery
curl -X GET \ 'https://api.refinitiv.com:443/streaming/pricing/v1/' \ --header 'Accept: application/json' \ --header 'Authorization: Bearer <Access Token from Step 1>'
The RTSDK C/C++ uses the OpenSSL, zlib, and cURL libraries to connect to the encrypted server RTO. You may check if you have set up those libraries on your machine correctly from the following articles
Additionally, did the same HTTP error returns for an authentication request (the first request from the API to the platform)?