Today we will learn the steps to integrate SharePoint in the SQL Server Reporting services. We will create a Reporting Services SharePoint application, and set it up in a way that we are able to view reports when they are uploaded to SharePoint.
For this, all you’ll need is a SharePoint instance you can work with. Do make sure you have an administrative access to the SharePoint site. If you have an Azure account, free or paid, you could set up a test instance of SharePoint and use it to follow the instructions in this article. Note the setup of such an Azure instance is outside the scope of this article. In this article, we assume you are using an on premise SharePoint installation.
How to do it…
- Open the SharePoint 2016 Central Administration web page.
- Click on Manage service applications under the Application Management area:
3. The Service Applications tab now appears at the top of the page. Click on the New menu:
4. In the menu, find and click on the option for SQL Server Reporting Services Service Application:
5. You’ll now need to fill out the information for the service application. Start at the top by giving it a good name, here we are using SSRS_SharePoint.
6. Presumably this is a new install, so you’ll have to take the Create new application pool option. Give it an appropriate name; in this example, we used SSRS_SharePoint_Pool.
7. Select a security account to run under. Here we selected an account set up by our Active Directory administrator, which has permissions to SQL Server where SSRS is installed.
8. Enter the name of the server which has SQL Server 2016 Reporting Services installed. In this example, our machine is ACSrv.
9. By default, SharePoint will create a name for the database that includes a GUID (a long string of letters and numbers). You should absolutely rename this to eliminate the GUID, but ensure the database name will be unique. In this example, we used ReportingService_SharePoint.
10. Review the information so that it resembles the following figure, but don’t hit OK quite yet as there are few more pieces of information to fill out. Scroll down in the dialog to continue:
11. After the database name, you’ll need to indicate the authentication method. Assuming the credentials you entered for the security account came from your Active Directory administrator, you can take the default of Windows authentication.
12. Place a check mark beside the instance of SharePoint to associate this SSRS application with. Here there is only one, SharePoint – 80.
13. Click OK to continue. Assuming all goes well, you should see the following confirmation dialog. If so, click OK to proceed:
14. Now that SharePoint is configured, you’ll now need to provide additional information to SQL Server. That is the purpose of this final screen, Provision Subscriptions and Alerts. Select the Download Script button, and save the generated SQL file:
15. Pass the SQL file to a database administrator to execute, or open it in SSMS and execute it yourself, assuming you have administrative rights on the SQL Server.
SharePoint uses the concept of Service Applications to manage items which run under the hood of SharePoint. SQL Server Reporting Services is one such service application. By integrating it as a service application, end users can upload, modify, and view SSRS reports right within SharePoint.
We began by generating a new Service Application, and picking Reporting Services from the list. We then needed to let SharePoint know where the SQL Server would be used to host both the database, as well as have a copy of Reporting Services for SharePoint installed. In addition, we also needed to provide security credentials for SharePoint to use to communicate with SQL Server.
As the final step, we needed to configure SQL Server to now work with SharePoint. This was the purpose of the Provision Subscriptions and Alerts screen. Note there is an option to fill out a user name and credential; clicking OK would then have immediately executed scripts against the target SQL Server.
In most mid-to large-size corporations, however, there will be controls in place to prevent this type of thing. Most companies will require a DBA to review scripts, or at the very least you’ll want to keep a copy of the script in your source control system to be able to track what changes were made to a SQL Server.
Hence, we suggest taking the action laid out in this article, namely downloading the script and executing it manually in the SQL Server Management Studio.
To test your setup, we suggest creating a new report with embedded data sources and datasets. Upload that report to the server, and attempt to execute; it should display correctly if your install went well.
If you enjoyed this excerpt, check out the book SQL Server 2016 Reporting Services Cookbook to know more about handling security and configuring email with SharePoint using Reporting Services.