Lucian Pricop said:

However all URLs I found in the sage documentation return error, ApplicationNotFound

That error would happen if the accounts50 provider were not registered or not enabled on the PC. Querying the $system/registry/-/endpoints URL is the right thing to do to determine if a provider is available and registered, but even if it is none of the URLs returned are directly 'browsable'. Rather they are stems of what would be a valid URL. You would need to include further detail on the URL to actually retrieve any information. This page shows an example https://sage.github.io/SData-2.0/pages/core/0201/ but if you are sending a request of the form http://<server name>:<port>/sdata/accounts50/GCRM/{<some sort of UID>} the key thing you are missing is the resource kind which would go after the UUID (which is actually the unique identifier of a dataset). The specific resources that can be requested are 'self documented' via a $schema request so you can simply issue a request to http://<server name>:<port>/sdata/accounts50/GCRM/{<some sort of UID>}/$schema to see what is available. Note that the dataset Id provided in that URL must be a valid one for an existing and available dataset for the request to complete successfully.

Lucian Pricop said:

there are only 2 /accounts50 and /accounts50/GCRM and accessing with CURL returns a different error: ResourceKindNotFound, Unable to locate the specified object 'accounts50'

So what that is saying is that the accounts50 application is registered and that it supports the GCRM contract, so the Sdata adpater is available and can deal with requests adhering to that schema. However if there are only those 2 entries it means there are no datasets registered, or that any that were are currently unavailable/inaccessible. Specifically the error means Sdata could not find the appropriate resource kind to be requested (supported resource kinds can be discovered via the $schema request as noted above).

A couple of things to look at here. First of all if you open the Accounts application on the same PC you are issuing the requests to do you have any available datasets to open (not including demo data or practice data), and are you able to open and access that data in the Accounts application? If you can then the 2nd thing to look at is where is the data located i.e. is it on a local drive or a remote path (UNC or mapped drive)? 'Local' being local to the PC that is running the Sdata service you are trying to query. If the data is on a remote path then Sdata will not be able to access this by default so you would need to either reconfigure things to allow the service to access data on the network, or move the data to be local.

It may be best to start simple and create a new test dataset (company) in Accounts ensuring you use a path to a local drive (the default path should be fine normally) and then query the endpoints URL again via localhost i.e. http://localhost:5495/sdata/$system/registry/-/endpoints . If things are working correctly you should see an additional entry in the response that will be the dataset and include the dataset Id. Armed with the dataset Id you can then issue a schema request http://localhost:5495/sdata/accounts50/GCRM/{<your dataset Id>}/$schema and that will tell you all of the available resource kinds and what operations they support. With this information you could issue a simple request to actually return some data e.g. localhost:5495/.../{<your dataset Id>}/taxCodes

Lucian Pricop said:

I am sending the Basic Authorization header with my sage user account, thought without it, I get the same errors.

You will need to provide authentication for a valid URL to be processed, but the errors you are getting are happening before any authentication occurs which is why it currently makes no difference. The above errors are all endpoint routing issues where the Sdata service is unable to determine an appropriate handler for the request. Authentication will only kick in once a valid handler has been determined and the request is passed on to it. Also worth noting that authentication is applied within the context of the dataset you are connecting to so the the account details you need to send are the username/password for the dataset you are connecting to.

Hope that helps.

Thank you Darron, that was very informative, I've learned a lot from your reply.

I should add that the machine I want to access the API from is not running Windows so I can't run the Accounts application on it to test. I did a call to http://<server name>:<port>/sdata/accounts50/GCRM/{<UUID>}/$schema as you suggested and I get a different error, ApplicationDiagnosis, Unable to locate the specified company '{UUID}'. So I guess I'm in the scenario where the dataset is currently unavailable/inaccessible. I can access the data on the Accounts application running on a different PC, the data is on a remote path, it's running at the IP I am accessing the API at <server name>

I will look further to find how I can make the dataset available. Any idea how I can reconfigure things to make the data available on the network?

Thank you again for the help!

Lucian Pricop said:

I get a different error, ApplicationDiagnosis, Unable to locate the specified company '{UUID}'. So I guess I'm in the scenario where the dataset is currently unavailable/inaccessible.

Sorry, it may not have been obvious in my reply but '{UUID}' was not meant as a literal value but rather it is a place holder for the value of the actual identifier for your dataset. Unfortunately I cannot tell you what the literal value would be on your system as it a unique value generated when your data is initially created and is 'universally unique' and not predictable. The only place you can find the actual value is from the endpoints request.

Lucian Pricop said:

I can access the data on the Accounts application running on a different PC, the data is on a remote path, it's running at the IP I am accessing the API at <server name>

When you say that the data is on a remote path do you mean remote from the PC that is running Accounts and the Sdata service or simply remote from the machine you are issuing the request from? If it is remote from the PC that is running Accounts, is Accounts and/or the Sdata service not available on the machine that hosts the data? If it is then its best to issue requests to that machine rather than a one where the data needs to be accessed over the network. Whilst you can make changes so the Sdata service so it can access data over the network, doing so does come with a performance overhead Vs accessing local data so I would always recommend local data access whenever possible.

Lucian Pricop said:

Any idea how I can reconfigure things to make the data available on the network?

Yes. The first thing you need to check is if the remote path used to access the data in Accounts is using a mapped network drive or a UNC path. If it is a mapped drive you would need to convert it to use a UNC path instead. Easiest wat to do this is from the select company screen in Accounts where you can remove the existing entry and then add it back in again but browse to the UNC path instead of the mapped drive.

Next you will need to change the Windows user that the Sdata service runs as. By default it runs as the 'Local System' account which has no network access. To change the Windows user that the service runs as open the services app (Start -> Run -> services.msc). Right click on the 'Sage SData Service 2.0' service and select properties. In the properties dialog select the Log on tab, and then select the 'this account' option. Enter the username and password of the Windows account that you want to run Sdata as and click OK. You will then need to restart the service for the changes to be applied.

Note that the user you change the service to run as will need to be one with access to the network share that the Accounts data is hosted. I would recommend that you create a special user specifically for the service rather than using your own user account.

With that done the Sdata service should be able to access the data on the network and you should then see the dataset show up in the endpoints request.

It was very obvious you meant my data source's UUID. The machine hosting the data is remote to both the PC running Accounts software and to the machine I'm trying to access the API from, so yes, I need to access the data over the network, performance overhead accounted for.

I will follow the steps suggested to try and make the dataset available on the network.

Thank you again

So I created a special user with access to the network resources and had 'Sage SData Service 2.0' run with this user's details. It's a network user, not a local Windows one.

When I restart 'Sage SData Service 2.0' it doesn't work anymore, it starts, but Accounts Software doesn't find it in "SData Settings" anymore. 

Any ideas what I did wrong?

If it's not found in Sdata settings it would normally suggest that the service isn't running. Worth checking the service is indeed still running and didn't start but then stop/crash for some reason. If the service is starting but then stopping/crashing out there should be an entry in the Windows event log indicating what the issue was. If you could share the details of that log entry I can advise further.

You are right. The Event log lists "Exception caught during Integration Server startup: Requested registry access is not allowed." when I attempt to start the service with this other user.

I gave permissions to the Sage registry and it starts now, and I get a reply for the company $schema. Now digging deeper. Fingers crossed.

Thank you very much! I can now talk to the API. You've been of tremendous help :)