Papa's Got A Brand New Bag...
Because CRM 3.0 was an Intranet only application, we could make certain assumption that users would have direct access to SQL server for a number of features including:
With CRM 4.0 we have to make sure the product is deployable and secure in an Internet facing environment such as http://www.crmlive.com/. This required a re-think of our architecture, removing the need for direct database or report server access by end-users. To acheive this we made several high-level architectural changes:
In order to understand what this means, I'll explain the steps involved in viewing and running reports in CRM 3.0 and then compare with with the new architecture in CRM 4.0
Viewing The Report List in CRM 3.0
Viewing The Report List In CRM 4.0
Reports in CRM 4.0 are now just a standard entity and can be secured using the role-based security. The upshot of this is that reports are now shareable, assignable, workflow enabled, advanced find enabled and can also be taken offline.
Another benefit is that when navigating to the list of reports, no web service call is made to the SRS web service, which means that no Kerberos Trust For Delegation is required when viewing a list of reports. Setting up Kerberos Service Principal Name (SPN) & Trust For Delegation (TFD) is one of the most common mis-configuration issues in CRM 3.0.
There is also another advantage in that the new architecture can significantly improve the responsiveness of the system. In CRM 3.0 whenever an entity grid view in CRM is rendered, the page makes a synchronous call to SRS in order to populate the list of contextual reports. If the connection to the SRS is particularly slow, the page can be blocked, which will have a knock-on effect on the overall page-load times. In CRM 4.0 we don't need to query SRS to obtain this information, thus eliminating this bottleneck.
Running A Report In CRM 3.0
Running A Report In CRM 4.0
In CRM 4.0 we added a new CRM Data Connector to the SRS server. This is a component that is installed on the SRS server itself and substitutes for a direct connection to the database. Think of the component as a proxy that takes requests and sends them to the transactional server. The CRM server requests the report from the SRS, passing in the identity of the user as a parameter. The CRM Data Connector then takes the user ID and executes the query against the filtered views using that user’s ID as a filter on the data. The benefit of this architecture is that no Kerberos Trust For Delegation is required when running reports.
We also moved the report viewer control – an ASP.Net control – from the SRS server to the CRM application server, keeping users in the context of the CRM IIS web site, and eliminating cross web-site authentication issues that arise when using forms authentication in an Internet facing deployment.
This posting is provided "AS IS" with no warranties, and confers no rights.
PingBack from http://www.artofbam.com/wordpress/?p=7212
White Wedding... To make sure I didn't duplicate any information in my blog, I have been compiling a
Here is a nice blog article on how CRM 4.0 reporting feature are different from the 3.0 ones. Really