Implementation for WebServiceDataSource Component for Telerik Reporting

[Nikhil]

I'm facing some issues while connecting my SQL Server using 2 Step Authentication WebServiceDataSource in Telerik Reporting. I have referred the following official documents - Document 1  Document 2

Currently, I'm stuck on a few things:

1. On Configure Data Retrieval window, Can I leave the Data Selector Field Blank? Is it required to specify JSONPath?
2. In Postman I don't have to manually add any Headers to my current Authentication and Data Retrieval Endpoint (content type, accept, authorization, etc. these are automatically added by Postman). In Config Request/Authentication Parameters,  do I need to add any of these headers?
3. In Configure 2 Step Authentication window;
   a. What is the role of Token Path? If it is to retrieve the access_token, as per the documentation is this regex (?:"access_token":")(.?)(?:")* correct? I came up with another regex "access_token":"(.*?)". Let me know which one is correct and why.
   b. What is the Request Body Type? Text or JSON?
4. Due to the above configuration issues I am getting the following error on the Preview DataSource Results window.
   a. Error- Could not get preview.. An error has occurred. Value cannot be null. Parameter name: content

 

[Momchil]

Hi Nikhil,

Let me try to address your questions in order.

1. Is the Data selector field mandatory?

No, if you do not need to bind to an inner object or filter the JSON data returned from your web service, you do not need to specify a data selector.

2. Do I need to add additional headers to the request/authentication parameters?

This depends on the web service used. Generally, there should be no need to add miscellaneous headers to the requests but you can try adding the ones from Postman just in case.

3a. Token path

Indeed, the Token path is used to retrieve the access token or the session key from the response to the login request.

Regarding the regular expressions, the expression from the documentation screenshot (?:"access_token":")(.?)(?:")* is actually incorrect but we have since updated it with a better version (?:"access_token"\s*:\s*")([^"]*)(?:")* that should work (see Token Path). Is it possible that you are viewing an older version of the documentation, perhaps from the PDF files that we distribute?

That said, the expression you have come up with looks correct. The only major difference I see from the one I shared above is that it does not account for possible white spaces in the JSON response.

Still, I would suggest checking the response from the login request using Postman and creating an expression specifically for your web service as there could be differences (make sure that the actual token is within the first capturing group of the expression). You can use a site like regex101 for this purpose.

3b. What is the request body type?

Usually, the parameters passed in the body of the POST request have a content type of application/x-www-form-urlencoded but this also depends on what your web service expects. If the body you have specified in the screenshot works using Postman, I would assume that it is correct.

4. "Value cannot be null. Parameter name: content" error.

This error generally occurs when a POST request is configured but no content is provided in the request body field. From the screenshots, I see that you have configured the body of the 2-step authentication request but I do not see the configuration of the data retrieval request.

Please, check whether the data retrieval request has the correct type and if anything is missing from its body. The Using Parameters with WebServiceDataSource article might be of help if you need to add any specific parameters to this request.

 

I hope this information helps you get the web service data source working.

If you need further assistance and do not mind sharing your report, you can attach it to this thread along with an example of how the requests to the web service should be made in Postman.

Best Regards,
Momchil
Progress Telerik

[Nikhil]

Hey Momchil,

Thank you for getting back. The issue was resolved after adding the request header "content-type" and using the token path you provided. I really appreciate you updating the report documentation (Token Path - Regex).

 

Thanks again!