A few months ago, we began creating a small, but reasonably simple inhouse SharePoint Online Application using all the modern methods and products Microsoft had to offer. The Application was to help us log Support Calls in SharePoint and connect it with our ‘Customer List’ on another SharePoint Application.
Many who have created an app for SharePoint Online will already understand that when creating/ installing/running a new SharePoint Online Application, SharePoint creates its own unique URL for the app inside your Tenant. This is for security reasons and adheres to the same-origin policy used widely by all browsers. Same-origin_policy.
This is a great security feature, but it does limit the more ethical and honest users who would like to access information in another site or in this case another URL within SharePoint. Using vanilla JavaScript we can access information from Lists or access files and documents from within the App URL. However, some data may be required that is outside of the Application URL.
We had several lists which we wanted to access and have separate from the application, so we could preserve existing information when updating the application. We have several lists working as database entries with relationships between each using the ID column as the primary keys. All of our lists work outside of the application. This drastically reduces the risk of wiping lists as a new version of the application is installed or updated.
Currently the method for extracting data from a list using JavaScript is to ensure the SP.js file is loaded using the ExecutorDelayUntilScripLoaded method:
and then conducted a standard ajax request to the list, the one below, simply contacts the SendEmail URL and kindly sends an email to a colleague to tell them about a ticket, note it is identical to normal ‘internet’ ajax request (using regular JavaScript) :
In most cases of SharePoint Applications this ajax method would be enough to complete a query to the API URL and return some results. However, our lists are not inside the URL of SharePoint, so when we try to query a list with:
we may well get an error of:
This is likely down to the fact that we are trying to query a list that doesn’t really exist in the context of the SharePoint Application. To overcome this we have to use ‘executor.executeAsync’and attach the query paratmer ‘@target=’ to the end of the URL you are contacting.
The full initialization of ‘executor’ is included in the following example and the target parameter is just to inform SharePoint of the target that the return call is going to end up in:
Its essentially a regular ajax ‘GET’ call but using executor.executeAsync instead of a regular ajax. This piece of code returns the full list of items where the Created date is greater than midnight this morning, parses the JSON in something useable and then eventually inserts it in to a table on the page.
The real trick here is that the list ‘SupportList’ is a SharePoint List actually created and stored in the site outside of the Application, probably in a site called https://ourcompany.sharepoint.com rather than https://ourcompany-7402f5f0934dc8.sharepoint.com . The variable ‘hostweburl’ uses the first URL listed here, which is why it needs to be declared in the Target GET parameter. This ensures we are free to pass through some of restrictions set by most popular browsers and prevent any errors.