Sdílet prostřednictvím

How hard is it to write Reporting Services extensions?

  • Článek

Obviously the answer to this question is fraught with conditions and dependencies. In general terms, this would be my answer (from easiest to most difficult):

 

Data Processing Extensions: Built on the same framework as ADO.NET, a Reporting Services data processing extension models .NET data providers in many ways. They are fairly straight forward to build and because they are based on .NET data providers, there is ample documentation and resources to support them. Obviously, you can make it as complex and powerful as you want, but as a rule, they are not hard to build. The documentation for Reporting Services includes a sample, however, that sample does not cover the use of data extensions that handle parameters. This is the only area where it gets confusing. Hopefully we will include a more comprehensive sample in the future. Developers with some experience with ADO.NET and .NET data providers should be well on their way to implementing a data processing extension.

 

Delivery Extensions: Unique to Reporting Services, delivery extensions can appear a bit overwhelming at first, but they really are simple once you get down to it. A delivery extension supports extension settings, which are used to drive subscriptions to reports. In addition, developers must implement the Deliver method which actually handles delivering the notification. Once again, there is a sample available with the Reporting Services documentation which should give you an idea of what they are all about. If you follow the sample and its logic, you should be able to write a delivery extension of your choosing with little or no problem. Once again, it can be as complex and feature-rich as you need it to be.

 

Security Extensions: Unique to Reporting Services, but based on technologies that ASP.NET developers should be familiar with, security extensions present a unique challenge. The difficulty does not lie in developing or understanding them, but in deciding when and how to use them. In addition, they are hard to deploy. Deploying a security extension touches just about every configuration file imaginable. The Reporting Services team is close to releasing a technical article and comprehensive sample that should shed some light on these types of extensions. Currently, the only type of security extension that has been written or conceived of is a Forms Authentication extension, which provides Forms-based ASP.NET authentication and then models Windows authorization. Security extensions are for intermediate to advanced developers with knowledge in ASP.NET Security, Forms Authentication and role-based security concepts.

 

Rendering Extensions: Also unique to Reporting Services, rendering extensions are the most difficult of the extensions to develop. Even the most talented developer will find rendering extensions a bit overwhelming. The difficulty lies in the understanding of the report object model and the sheer number of APIs. If you want to develop one, it might help to travel to Microsoft's main campus and stay for a month or two while you work alongside Reporting Services developers. There is no documentation and there are no samples available yet. An alternative to writing a rendering extension might be to first render to XML and then apply an XSLT or simply live with the rendering extensions that Microsoft provides (new ones are in the works). These aren't impossible to write by any stretch of the imagination and many third party developers are getting up to speed. It will definitely help when we release an official version of the rendering extension documentation. Just be prepared for a tough road ahead when developing these suckers.

Comments

  • Anonymous
    March 16, 2004
    You have been Taken Out! Thanks for the post.
  • Anonymous
    March 17, 2004

    I don't worry much about how hard are rendering extensions to come up with. First, one has to use the SOAP API and in particular the Render() method to get the main stream and all resources. This clarifies the client side, although the object model doesn't necessarily fit monolythic export formats like Excel (where the resources are embedded in the main stream).

    Then we have the chm doc from the beta 2. Everything is there. Don't worry again, ISVs and developers involved with charting/report stuff understand very well the object model and know what to do with it.

    I myself am too lazy to write the native Excel renderer, otherwise I would have made it already.

    My 0.5 cent.
  • Anonymous
    March 17, 2004
    You are right, many ISV's and third party developers are making good progress and we are considering a native Excel rendering extension for future versions. Don't be lazy, write some extensions if you have the expertise. A sample posted to gotdotnet or some other source would help a lot.
  • Anonymous
    March 17, 2004
    Is this Forms Authentication based extension actually available somewhere?
  • Anonymous
    March 17, 2004
    It has already been released for publication, but it takes some time to make it out to the Web. It could be a few days. It is coming.
  • Anonymous
    June 10, 2004
    I have come across what I think may be a bug in Reporting Services related to this post. Please see my blog for full details:

    http://www.sharepointblogs.com/rcragg/archive/2004/06/11/540.aspx

    Thanks, Rohan

  • Anonymous
    October 31, 2007
    PingBack from http://www.sharepointed.com/2007/10/31/a-wss-data-processing-extension-for-reporting-services/
  • Anonymous
    November 03, 2007
    PingBack from http://www.sharepointed.com/?p=36
  • Anonymous
    November 03, 2007
    PingBack from http://www.sharepointed.com/2007/11/03/a-wss-data-processing-extension-for-reporting-services/