on 10-27-2015 4:43 PM
Dear omniscient SCN
I have the situation that I have to integrate an external webservice using REST where the webservice requires registration using an api key.
Now the SDK documentation, chapter "Integrate an External Web Service Using REST" wrote:
If the service you are calling requires authentication, you can define the required identifiers as API keys. The values of the API keys are maintained in the communication arrangement. You cannot use API keys with non-secure URLs (HTTP). To define an API key, do the following:
- Enter the key in the API Key field.
- Click the Placeholder for API Key in Script File field to the right of the API Key field.
The placeholder is generated, which you can use in the script file to build the Web service request.
So, according to SDK documenation, I can use a placeholder somewhere inside the script file to build the Web service request.
Now my question:
How does one use this placeholder using a REST webservice?
My current code is:
// Communication details
var scenarioName = "RESTWebServiceTest";
var serviceName = "RESTWebServiceIntegrationTEST";
var urlPath;
urlPath = "api?apiKey=&RESTWebServiceTest_ApiKey&";
// Execute webservice call
var ws_result = WebServiceUtilities.ExecuteRESTService(this.ScenarioName, this.ServiceName, "POST", urlPath, this.UrlParameter, this.HeaderParameter, "text/plain", this.Content);
If I replace the place holder with the actual api key, everything is working fine.
However the purpose of the placeholder is be able to set an api key individually in the communication arrangement.
So how do I use the placeholder correctly?
With SOAP webservices I do have a fair understanding how this is supposed to work since I do have a webservice object where I am building the webservice request and set the api key.
However with REST webservices there is no such thing as a webservice request object, execution is triggered using a Library call.
So, Horst, Fred, etc:
Any ideas?
Thanks a lot,
Ludger
--
Custom development with all4cloud.de
Hi,
You can generate API Key in the communiation arrangement and it should work automatically, that is because WebServiceUtilities.ExecuteRESTService implementation would get it from the communication arrangement
Thanks, Pradeep.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Ludger,
Were you able to find the solution?
Best regards,
Victor Silva
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Ludger,
Just to clarify. I have used the approach suggested by Kumar below and it works.
We included the API token placeholder as a header parameter. During debug, you never is able to see the placeholder converted, but once the REST service is triggered you can see the API Key converted.
Thanks a lot for the support guys!
Fernando
No-one has any experience yet?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Ludger,
I hope you would have sorted out the above issue.I too have a similar requirement to pass API key and User Key in the URL of the REST service itself to get the Output.
Below is the REST URL which am going to use for my scenario.
https://aiaas.pandorabots.com/talk/APP_ID/BOTNAME?user_key=USER_KEY&input=INPUT
When I give extract parameters REST Service will look like this:
My Question here is :
1.Do I need to create a Communication scenario and Communication arrangement to consume this REST service in ABSL code or I can directly REST Mashup Webservice like this in Front End and I can use the Service ID while executing the webservice call.
2.What is the difference between selecting JSON or XML in the service protocol drop down.
I need your views also on this Hanumath.
Thanks in advance.
Please help me with the approach.
Regards,
Navin
User | Count |
---|---|
84 | |
10 | |
10 | |
9 | |
7 | |
6 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.