| Table of Contents |
|---|
...
- Make sure you are properly setting content type and using HTTP POST method and setting up correct request body as XML while doing the request (i.e. not calling WS API as url directly from browser)
- Is the url of the API call correct? (e.g.: is it possible that you are accidentally using DataDelivery endpoint instead of PvPlanner or vice versa?)
- Is the provided key correct? (e.g.: in case you have multiple accounts, is the provided key correct for intended call? Didn't you accidentally use key from different account that was intended for different purpose?)
- Try to use the "proven to be working" / simplest / minimum XML requests adapted for you account. You can find minimum and working requests in our technical documentation here:
- For DataDelivery WS: request / response examples service (you may need to adjust lat/lng, dateFrom, dateTo, processing keys and summarization based on the access permissions of your account)
- For PvPlanner WS service (you may need to adjust lat/lng)
If the server answers with response: have you checked the detailed error message? Most of the times the response contains detailed message with hint why the request failed.
In case error happens the response is in JSON format instead of XML, so you may need to view the response in JSON or Raw view (if you are using third party applications for doing requests like SOAP UI),
here are examples how the error message may look like:Code Block language js {"message": "Error 403 Access is denied. dateFrom must be >= 2020-02-04"}Here (assuming that the request was made on 2020-02-04) the message is trying to tell us that we can not access data older then today - this could for example happen if your account has only access to forecast data and you are trying to access historic data. In such case you need to change the dateFrom of the failing request to accommodate this. In case you think you should have access (i.e. it is a configuration problem on our side and you should have access for historic data) please ask for technical support
Code Block language js {"message":"Error 403 Access is denied. Processing key DNI is not allowed"}So here the error messages are trying to tell that your account doesn't have access to use processingKey = DNI, so again you need remove the offending key from processingKyes of the request. In case you think you should have access (i.e. it is a configuration problem on our side) please ask for technical support
These were just examples but there are many more reasons why your requests may fail due to access restrictions (too many calls per day, summarization that is not allowed, requesting more than one month of data per single request and so on.)
...
- Download SOAP UI (standalone free application for sending HTTP requests) from here: https://www.soapui.org/
- Install SOAP UI and download following demo project provided by Solargis: ws-demo-soapui-project.xml
- Run SOAP UI and import the ws-demo-soapui-project.xml (File → Import Project)
- Depending on whether you have DataDelivery or PvPlanner license you should navigate to either DataDeliveryRest or PvPlannerRest Demo request
from the imported project. Rest of this guide shows steps for DataDelivery license, however the steps for PvPlanner are very similar. - Navigate to the DataDeliveryRest Demo request as seen on following image and submit the request with the "play" button:
- After the request is finished, you should see HTTP status 200 (OK) and following valid response - this should work immediately out of the box (no need for you to change / configure anything):
- Now that you have established that the demo is working correctly you can start adapting the demo request for your license. In order to do so,
you need to change key from "demo" to the one you were provided with your WS API account and also to adapt XML body of the request to the one that will work with your key,
therefore based on your account permissions you may need to change latitude / longitude of the request, dateFrom / dateTo etc. We strongly recommend that you start
with the simplest requests which are known to be working and build up from there. As already mentioned in "quick checklist" you can find working examples of simple
DataDelivery or PvPlanner requests here : DataDelivery WS: request / response examples and here: PvPlanner WS
- After you have made the necessary updates you should be able to successfully submit the request and receive correct XML response. If you do not see the expected correct XML response, then you might need to change the view to JSON or RAW.
Most of the times when the API call fails and you switch to JSON view you will see message like this which provides hint why the request has failed. E.g.: in the following case it suggests that you should remove "DNI" from the list of the processing keys.
- Once you get the simple XML requests working with your secret key then you can attempt to add more complex stuff (i.e. detailed configuration of your PV power plant etc.) We recommend that you proceed in incremental steps and after
each change you validate that the request is still working. That way if something breaks you know which change has caused it and you can work around it. - Afterwards: if some request is not working in your implementation, please first make sure that the same request is also not working in SOAP UI, this is to eliminate potential bugs in your implementation. If the request is not working in your implementation
but it is working in SOAP UI then you will need to review your implementation. As it's difficult for us to know what are the problems in your implementation we generally can't provide support regarding your implementation. But in order to solve
the issues we recommend to compare that everything in your implementation is 1:1 to the working SOAP UI request, mainly that:- the XML content of the request in your implementation is identical to the SOAP UI
- the url in your implementation matches the url in SOAP UI, including the correct key as the url parameter
- you are using HTTP header Content-Type set to "application/xml" in your implementation
- you are using POST method to do the HTTP call in your implementation
- you are also setting the request body (i.e. parameter of the POST method) to the intended XML request string in your implementation
- If after following these steps you are convinced that some request that is supposed to be working is failing then please ask for our technical support
...