SQL Server Reporting Services 2012 SharePoint integrated mode Endpoints architecture (or how our services talk each other)
Recently I got interested in understanding how our Service works, so I started from at the entry point to Reporting Services.
As a final user you usually interact with Reporting Services through Web Pages that are hosted in SharePoint 2010, you use this pages to render reports or to accomplish management tasks like publishing reports, create subscription among many other tasks; all of these actions are performed using the old and reliable HTTP protocol sometimes with GET or POST methods, this is the User entry point (1).
Reporting Services also provides a set of SOAP APIs that allows developers to interact with Reporting Services from their own applications, this is the second entry point and is called Report Server Web Service Endpoints (2).
Each one of these entry points are available in the SharePoint Web Frond End, for HTTP you just navigate using the UI and for SOAP it is https://<Server Name>/_vti_bin/ReportServer/ReportService2010.asmx?wsdl, https://<Server Name>/_vti_bin/ReportServer/ReportExecution2005.asmx?wsdl and https://<Server Name>/_vti_bin/ReportServer/ReportServiceAuthentication.asmx?wsdl for the default site.
(those are the main endpoints there is also the ReportService2006 for backward compatibility you can see the documentation for all of them in Report Server Web Service Endpoints)
If you have created more sites the url changes a little adding the site for example https://<Server Name>/<yoursite>/_vti_bin/ReportServer/ReportService2010.asmx?wsdl
All the requests are received by the Reporting Services Proxy that is installed in the WFE boxes when you install the Microsoft SQL server 2012 RS Add-in for SharePoint, then the requests are balanced with the SharePoint Software Load Balancer then are sent using WCF to the Reporting Services Service application (all the communications between proxies and applications in SharePoint 2010 are done over WCF for more details see Building Customer Service Applications for the Right Situations (Real World SharePoint 2010))
The Proxy
The work of the Reporting Services Proxy in the WFE is to take any incoming request , convert it to WCF and use the Load Balancer and send it to any of the Mid Tier Servers, the proxy needs to be installed in all the WFEs in the Farm, that happens when the RS Add-In is installed.
The SOAP .NET Web Services files are deployed to in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\ReportServer
The ASPX pages and all the Reporting Services UI is deployed in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\ReportServer.
For the Reporting Services UI in SharePoint Central admin the pages are deployed in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\template\layouts\ReportServer.
Additional files are deployed to the GAC (look for the assemblies with name starting by Microsoft.ReportingServices)
Reporting Services Service Application
The RS Service application exposes three WCF contracts/endpoints which provides the following services.
ReportStreaming
It handles all the processing of streams to render reports and returning to the client, it is built in such way it can handle small or large reports.
ReportExecution
It have all the methods exposed by the SOAP API report execution API, which are used to execute reports programmatically , actions like LoadReport, SetExecutionParameters among others are invoked using this endpoint
ReportServiceManagement
It have all the management and SOAP API implementations, things like Publish a Report, Create a Subscription, list the existing reports, mange security etc are invoked using this endpoint.
ReportServiceBackgroundProcessing
It have all the methods to activate all background processing including subscriptions and catalog clean up etc, this one is called by the SharePoint timer job ( see The SQL Server Reporting Services 2012 Timer Job In SharePoint mode )
This WCF contracts are intended to work with the SharePoint Service Application architecture and I’m not aware of a way to use it directly, if you need to use RS programmatically the previous mentioned SOAP API are the way to go, those are well documented and supported, also the WCF could change at any moment.
The bits for this are located in the Mid Tier and are deployed when you install the Reporting Services – SharePoint using SQL Server Setup. The folder for those bits is C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\Reporting.
If you navigate to the folder you will see a .SVC file for each one of the the WCF endpoints we mentioned before, you will notice too there are some additional SVC files which are used by the Reporting Services Alerting feature which I plan to cover later in other post.
Identifying the process which is running the Reporting Bits
Sometimes I need to verify what account is running my Reporting Services bits to troubleshoot authorization issues or I need to attach a debugger or generate a dump, to do that I need to identify what is the process that is hosting the Reporting Assemblies.
As this is SharePoint mode the process will be hosted in IIS so it will be called W3wp.exe , anybody familiar with IIS and SharePoint would know that is very likely you will have multiple w3wp process in your box like this
The easiest way I found so far is using Process Explorer
Using Process Explorer switch to view DLLs (Ctrl+D), the w3wp.exe process that is running Reporting Services will have loaded many Microsoft.ReportingServices dlls
For the Proxy in the WFE you will see few of them and more important some that has the name Microsoft.ReportingServices.SharePoint.UI
For the Mid Tier with the Service Application you will see a lot more and not even one with SharePoint.UI
Identifying the IIS Application Pool running the Reporting Bits
For the WFE the bits run in the same pool as the SharePoint site (usually called SharePoint – 80)
For the Mid Tier it is a little more complicated
Go to SharePoint Web Services Site in IIS , you will see multiple sites with a GUID as a name, the easy way is to Switch to Content View and check quickly which one has the ReportingWebServices.svc file
If you have many, you can use the PowerShell cmdlet Get-SPRSServiceApplication
PS C:\> Get-SPRSServiceApplication
Name Id UEAccountName
---- -- -------------
Reporting Web Service 0ae65534-a5ba-47a7-85cd-340fc935af73
Now that you have identified the RS Site , you can use the advanced settings to check the application pool ID
Then in the Application Pools folder you can now identify the pool with the GUID you got before and you can check the settings like identity, .NET framework and others
Comments
Anonymous
September 20, 2012
Thanks, very useful information.Anonymous
May 11, 2013
Thank you. Very interesting. But I found more useful information here www.reportingsoftware.info/.../latch-on-the-secrets-of-business-efficiencyAnonymous
May 16, 2013
We are glad to receive such a informative write up. this is of good help. there are few write up floating over the web about the same concern. for more information you can look into: ccsglobaltech.com/blog.htmlAnonymous
June 24, 2013
Thanks - very useful