REST API

Which user account is running the ODX Service? 

How is OAuthSettingsLocation property defined in the data source connection?

By default, the Access Token is saved to disk via the OAuthSettingsLocation property. This file is unique per user / credentials.

Verify the ODX service user has access to the file directory. 

CData Providers - Performance Optimization and Troubleshooting

Hi Sowjanya

A 400 bad request error is not about authentication, but about what it recieves when attempting to connect to the source.
This is commonly because the response you get from the JSON source is in HTTP format.

Try to set the data source setup to not be JSON, but CSV instead.

Also set up a log with verbosity level 3, then it will show what data it returns in the log.

ODX service is running on the TimeXtender user account.  I am getting an authentication error If I change OAuth setting file Location to my account. 

Authentication was successful If I use the below location. 

C:\Users\timextender\AppData\Roaming\CData\REST Data Provider\OAuthSettings.txt\sguntupalliadmin\AppData\Roaming\CData\REST Data Provider\OAuthSettings.txt 

Which one is best to use?

So, ODX uses a Service user account.  Where do I need to set SCHEMA files for pagination?

Hi Sowjanya

I would specify a fixed location.

Like C:\OAuth\REST\OAuthSettings.txt

Then all users who uses this data source will point at the same location for a file. If you used the C:\Users\timextender\AppData\Roaming\CData\… path you can experience that other users cannot see the file due to the location of the file.

I changed the OAuth location to

C:\OAuth\REST\OAuthSettings.txt

Schema file location to

C:\SCHEMAS\ER_Schema

Test connection getting an error:  RSSBus.RSBException.HTTP Protocol error. 400 bad requests

1. Please verify that the user account for ODX service has read/ write access to the above folder paths.

2. Try to set the data source setup Format to CSV (not JSON)

3.  

   Also set up CData log with verbosity level 3, then it may show error details in the log.

I made all those changes still the same. 

I am attaching a log file for reference.

Please use an external tool (like Postman) to verify all the connection strings are correct.

Normally, The server cannot or will not perform the request because of what is thought to be a client problem, according to the 400 (Bad Request) status code. To cross-check whether the connection string details are working fine or not, could you please make the same request with the URL and Header by using Postman and let us know if you are seeing any result or not with all the authentication methods which are shown in the log file?

If you are able to see the result in Postman, then please try to test again with CData provider in TimeXtender, and generate a logfile in order to troubleshoot.

 

My URL contains Offset parameters.https://data.emergencyreporting.com/agencyincidents/incidents?orderby=08/31/2022%2008:00%20ASC&limit=100000&filter=isReviewed%20eq%201&offset=0I did try the below pagination as well.<api:set  attr="pageoffsetparam"                      value="offset" /> <api:set  attr="pagesizeparam"                        value="limit" /> <api:set  attr="pagesize"                             value="100" />

Since the Synchronize and Transfer tasks ran OK, preview the tables in ODX, ER (Fire) data source, to verify the incoming data rows look OK, then map those tables to MDW.

Hi @sguntupalli does the incoming data look OK? Are you able to map the tables to MDW?