HTTP ODPS requests
Hello
We configured ODPS on our TREP infra and we want to set up our entitlement application.
We are currently doing some tests to validate our developments and we need some help about the following :
- The first http request we test is to login :
- http://host:8088/command=userLogin&user=r_msa&position=1.1.1.1/net&application=185&closure=m_rsa1.1.1.1/net185&domainsearch=true
- The answer is : SUCCESS: that is good
- Second test is to run the following http request : we also did the test decoding the lock in base64 (lock=AwEBUmw=)
- We also tried into another way : (without lock parameter)
- http://host:8088/command=subscriptionTest&user=r_msa&position=1.1.1.1/net&application=185&closure=userpositionapplication&service=IDN_RDF&item=EUR=&ondemand=no&usage=denial&requesttype=normal&autope=true
- And we have : DENIED:DACSLOCK subscription infrastructure is DOWN
Is it expected ? is there something to fix at the odps config level ? to change to the http request level ?
Regards,
Henri
Hello Henri @Henri.GARDON,
If without dacs lock you are able to interact with ODPS correctly, we can next focus on the lock itself. To me, this lock does not seem exactly right, are you sure this is the lock?
For example, I just subscribed to EUR=, and it looks like this:
RefreshMsg streamId="5" domain="MarketPrice Domain" solicited RefreshComplete state="Open / Ok / None / ''" itemGroup="00 04" permissionData="03 01 01 52 6c" name="EUR=" nameType="1" serviceId="257" serviceName="ELEKTRON_DD" Payload dataType="FieldList"
The dacslocks are formed based on dacs lock structure requirements, and they all look similar, because they conform to the lock structure. Can you please try with the above lock for EUR=?
http://host:8088/command=subscriptionTest&user=r_msa&position=1.1.1.1/net&application=185&service=IDN_RDF&item=EUR=lock=030101526c
Can also test with the example from ODPS Developer Guide:
http://oaklx8637:8088/command=subscriptionTest&user=ted&position=1.1.1.1/ net&application=56&service=ROSIC_RDF&item=IBM.N&lock=03010163c0&closure=abcdefgh
Let's try to test, maybe it is a bad lock.
Hello Henri @Henri.GARDON,
To find out more about the cause, would suggest to go back to basics on the subscription test request, and then build up to what you require.
Can you please try:
How does this go?
Hello, @zoya.farberov,
We tested with your request and it worked.
We also tested with
http://host:8088/command=subscriptionTest&user=r_msa&position=1.1.1.1/net&application=185&closure=userpositionapplication&service=IDN_RDF&item=EUR=&ondemand=no&usage=denial&requesttype=normal&autope=false
and it works also. Actually this is the same than the one on my previous post but without lock option. We wonder why when we add the lock parameter it is not working. And in the documentation, it seems that the lock info is recommended.
"Thomson Reuters recommends a DACS lock if the data being
protected is from a TREP system and the source returned a DACS
lock as part of the initial image. This offers the maximum
functionality."
Is our lock parameter wrong ?
Thanks,
Henri