UPDATE (11/13/2012): Additional modification needed to provide ability to manage the parameters in SharePoint (see the bottom of the post for the updates)
If you are using Reporting Services (SSRS) in SharePoint Integrated Mode (I saw this issue with SSRS 2008 R2 SP2 & SSRS 2012 with SharePoint 2010 running with SP1 CU Aug 2012), then something you might want to be aware of. If you ever have to load a parameter list with lots of records (say 35K+) then you might end up receiving a message like this:
An error (Unable to read data from the transport connection: The connection was closed.) occurred while transmitting data over the HTTP channel.
An error (Unable to read data from the transport connection: The connection was closed.) occurred while transmitting data over the HTTP channel.
Unable to read data from the transport connection: The connection was closed.
If you are running the report in BIDS or SSDT or Reporting Services Native Mode you will be fine, just an issue with SharePoint Integrated Mode. I also noticed this with a report that had approximately nine parameters (four were hidden) and two of them had approximately 10K records. So I think it was the combination of the parameters along with some default values getting set that caused the issue.
REPRO: For a quick example of this issue you can easily replicate this with populating a parameter with the FactFinanceKey from the AdventureWorksDW2012 database. Deploy the report to SharePoint and try and run it:)
I have filed a Microsoft Connect Bug for this here – Reporting Services (SSRS) SharePoint Large Parameter Issue
Well after a bunch of searching and digging through the forums, blogs, BOL, and additional documentation (and even tried an old ProClarity fix) I found the fix for the issue – MaxItemsInObjectGraph….yes, that was a setting that I had to incorporate into a couple of the configuration files for Reporting in SharePoint:S
The first forum posting that pointed me to the web.config and client.config files was Issue Exporting SSRS 2012 Report to CSV file in SharePoint 2010 (MaxReceivedMessageSize property exceeded) and then after doing some additional research running live log tracing on SharePoint I tracked down that it was really related to the WCF and I came across this additional MaxItemsInObjectGraph setting in quit a few posts such as this one MaxItemsInObjectGraph and keeping references when serializing in WCF.
Now I didn’t find the magic post that just told me what to do, but with some trial-and-error I came up with the following steps to fix this:
1. Edit the web.config file in the following location C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\Reporting
NOTE: prior to modifying a config file, always make a backup of the file first and use a text editor like notepad, notepad++ to modify the file, do not use a rich text editor.
2. In the web.config file find the <behaviors> section and make the following addition:
<behaviors>
<serviceBehaviors>
<!–
Notes:
1) maxConcurrentCalls is set to 16(default value in .Net3.5)*Processor Count(assuming 32)
2) maxConcurrentInstances is set to 512 since InstanceContextMode is PerCall
3) These settings can be removed after upgrading to .Net 4.0
–>
<behavior name=”RSExecutionBehavior”>
<serviceThrottling maxConcurrentCalls=”512″ maxConcurrentInstances=”512″ />
<serviceMetadata httpGetEnabled=”true” />
<serviceDebug includeExceptionDetailInFaults=”true” />
<dataContractSerializer maxItemsInObjectGraph=”2147483647″ />
</behavior>
</serviceBehaviors>
</behaviors>
3. Save the file and then go and edit the client.config file, remember to make a backup copy prior to modifying it. This file is located in the following location C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebClients\Reporting\
4. In the client.config file add the following section below the <System.ServiceModel> tag and before the <client> tag
<system.serviceModel>
<behaviors>
<endpointBehaviors>
<behavior name=”RSExecutionBehavior”>
<dataContractSerializer maxItemsInObjectGraph=”2147483647″ />
</behavior>
</endpointBehaviors>
</behaviors>
<client>
5. Now I also modified four of the endpoint settings in the <client> section to reference the new behavior that I added (IReportExecution and IReportStreamingAsyncClient):
<endpoint name=”https” contract=”Microsoft.ReportingServices.ServiceContract.IReportExecution” binding=”customBinding” bindingConfiguration=”https” behaviorConfiguration=”RSExecutionBehavior”/>
<endpoint name=”http” contract=”Microsoft.ReportingServices.ServiceContract.IReportExecution” binding=”customBinding” bindingConfiguration=”http” behaviorConfiguration=”RSExecutionBehavior”/>
…
<endpoint name=”https” contract=”Microsoft.ReportingServices.ServiceContract.IReportStreamingAsyncClient” binding=”customBinding” bindingConfiguration=”httpsStreaming” behaviorConfiguration=”RSExecutionBehavior”/>
<endpoint name=”http” contract=”Microsoft.ReportingServices.ServiceContract.IReportStreamingAsyncClient” binding=”customBinding” bindingConfiguration=”httpStreaming” behaviorConfiguration=”RSExecutionBehavior”/>
6. Once that was done I had to restart the server where the Reporting Services application was running. The web.config settings seemed to work right away, but not the client.config settings. Once it restarted I warmed up SharePoint and got SSRS running again. I tested out my report and it started up just fine, no error message:)
And that is the fix, can’t believe this is the first time I have come across this issue, but now there is a fix and it is documented:D Just a word of caution, this still does not perform as well as it does in SSRS Native Mode, but at least it does work now. It appears that it takes maybe twice as long to load in SharePoint as it does through the Report Manger (your mileage may vary though).
I have filed a Microsoft Connect Bug for this here – Reporting Services (SSRS) SharePoint Large Parameter Issue
UPDATE (11/13/2012): Additional modification needed to provide ability to manage the parameters in SharePoint –
One quick update on this – there is one more additional service & endpoint that needs to be updated in the config files as well. The reason is so that you can manage the parameters in SharePoint if needed.
Web: <service name=”Microsoft.ReportingServices.ServiceRuntime.ReportServiceManagement” behaviorConfiguration=”RSExecutionBehavior”>
Client: <endpoint name=”https” contract=”Microsoft.ReportingServices.ServiceContract.IReportServiceManagement” binding=”customBinding” bindingConfiguration=”https” behaviorConfiguration=”RSExecutionBehavior”/>
I added the behaviorConfiguration reference. Not only did I update this in the web.config file, I also updated the endpoints in the client.config file as well. It seems like it picked up on the change without a reboot this time as well, so the web.config setting seemed to work, but wanted to keep things in synch so I updated the client.config as well. This time though I did receive a valid SharePoint error message and was able to look it up in the logs to pinpoint the additional service being referenced for this operation. There are two other items in the config file – ReportServiceBackgroundProcessing and AlertManagement – and I have not had to alter these ones yet.
NOTE: Also, in a multi-server environment I had to update the client.config file on the WFE server (web.config did not exist since it wasn’t the application server) and restart that one to get the reports to behave consistently.
Subscribe to Blog feed
Dan English's BI Blog 