SUBSCRIBED REPORT DELIVERY in Visual Basic .NET

Generate Data Matrix 2d barcode in Visual Basic .NET SUBSCRIBED REPORT DELIVERY

ne of the most appealing features of Reporting Services is that it can be easily extended by writing custom add-ons in the form of extensions. Part 4 discusses the implementation details of three custom extensions that you can use to extend the RS features. You ll learn how to author a dataset data extension to report off ADO.NET datasets. You ll also see how to distribute reports to Web services by means of a custom delivery extension. In addition, we ll show you how to replace the RS Windows-based security model with a custom security extension. Aside from being feature-rich, your reporting solutions must also perform and scale well under increased user loads. To ensure that these objectives are met, you need to know how to evaluate the Report Server performance and capacity before going live in a production environment. In this part, you ll learn how to establish performance goals, how to create test scripts with the Application Center Test, and how to stressload your Report Server installation.

13.1 13.2 13.3 13.4 13.5 Understanding Reporting Services extensibility 454 Reporting with a custom dataset data extension 460 Distributing reports to Web services using custom delivery extensions 473 Implementing custom security 482 Summary 496

An important characteristic of every enterprise-oriented framework, such as Reporting Services, is that it has to be easily extensible. Simply put, extensibility relates to the system s ability to accommodate new features that are built out of old ones. When a software platform is extensible, it allows developers to customize it to meet their specific needs. For example, when your reporting requirements rule out Windows-based security, RS allows you to replace it with custom security models. One of the most prominent and appealing aspects of RS is its modular architecture, which is designed for extensibility. You ve already witnessed this in chapter 6 when you saw how to supercharge your reports by writing custom code. In this chapter, we explore additional ways to take advantage of the unique extensibility model of RS by writing custom extensions. Specifically, we develop the following extensions: A dataset data extension to report off ADO.NET datasets A Web service delivery extension to distribute reports to Web services A security extension to implement custom authentication and authorization

By the time you finish reading this chapter, you should have enough knowledge to develop, install, and manage custom extensions. First, though, let s discuss the essential concepts that you need to know to effectively leverage the extensibility features of RS.

You can extend RS by plugging in custom extensions written in .NET code. To do that, you need to be familiar with the concept of interface-based programming. Based on our experience, many developers find working with interfaces difficult to grasp. For this reason, let s make a little detour at the beginning of this chapter and explain the basic concepts and benefits of this style of programming. First we provide you with an understanding of interface-based programming and then focus on working with interface inheritance. By no means will our discussion attempt to afford exhaustive coverage of these topics. If you need more information, refer to the .NET product documentation, which includes many technical articles on object-oriented programming.

Interface-based programming Suppose that you are an architect on the Microsoft RS team and you are responsible for designing a flexible model for plugging in delivery extensions. As you saw in chapter 12, RS comes with two delivery extensions out of the box: e-mail and file share extensions. As useful as these extensions are, it is unlikely that they will meet all subscription-based distribution requirements. For example, what if an organization wants to automate the report-printing process by sending reports directly to a printer Instead of enduring the Herculean effort of creating and supporting all possible delivery scenarios out there, you prudently decide to let customers author and plug in their own extensions. What implementation pattern will you choose Obviously, you must establish some standardization to which other developers will have to conform. Once you ve come up with an easy-to-follow standard pattern, you could use generic code logic to load and execute custom extensions. As a seasoned architect, you set the following high-level design goals for the envisioned extensibility model: It must allow developers to write and plug in their own extensions. It shouldn t require an intimate knowledge of how the extension is implemented, or what it does for that matter. In other words, as long as the extension adheres to the standard, it can be treated as a black box. It should be as robust as possible. For example, the model should be able to determine at runtime whether a given custom extension follows the standard design pattern and, if it doesn t, the Report Server will not attempt to load it.