Let’s assume that the data service (or static file) is located at https://apps.zoomcharts.com/spreadsheet-analytics/SampleData.json.
To instruct SA app to automatically load this service upon opening,
you have to add it to the SA URL: sa_url + "#load=" + urlencode(service_url)
The result should be: https://apps.zoomcharts.com/spreadsheet-analytics/#load=https%3A%2F%2Fapps.zoomcharts.com%2Fspreadsheet-analytics%2FSampleData.json
On the server side the only configuration needed is that it returns
an additional HTTP header: Access-Control-Allow-Origin: https://apps.zoomcharts.com
Since the data is processed in the browser, the service does not have to be reachable from the internet, as long as it can be opened from the user’s browser.
If the data service would rely on user being authenticated in the
system where the authentication is stored in a cookie (or uses
Basic/Digest/NTLM/Kerberos authentication), you have to add additional
parameter to the URL: sa_url+"#load=…" + "&withCredentials=1"
.
This will instruct the browser to send the cookies to the service
(by default no authentication information is sent).
For example, the URL could be: https://apps.zoomcharts.com/spreadsheet-analytics/#load=https%3A%2F%2Fapps.zoomcharts.com%2Fspreadsheet-analytics%2FSampleData.json&withCredentials=1
To support this mechanism on the server, the service has to return an
additional HTTP header: Access-Control-Allow-Credentials: true
The both cases above require the end user to have a subscription in the Spreadsheet Analytics app and be logged in. However there is an option to avoid this requirement.
The process for creating and using the signature:
api_key
parameter is optional.#load=…&sign=b0b0b0b0…
X-Spreadsheet-Analytics-Signature: b0b0b0b0…
The signature does not have an expiry date, so it can be used to store the generated JSON as a static data source and publish reports based on it publicly.
It is also possible to request a domain name to be whitelisted in the Spreadsheet analytics application so that any data coming from this domain is treated as it would be signed.
This is subject to additional cost.
If the application is deployed on-premise, the default configuration simplifies the requirements as it does not require the user to be logged in and neither does it require the signature service.