Correlating the report request with the report session in C#.NET

Creating PDF417 in C#.NET Correlating the report request with the report session

Hashtable sessionCollection = new Hashtable(); rs.Render("reportA" .); sessionCollection.Add("reportA", rs.SessionId); rs.Render("reportB "); sessionCollection.Add("reportB ", rs.SessionId); // need to call report A again

SessionHeader sessionHeader = new SessionHeader(); sessionHeader.SessionId=sessionCollection["reportA"].ToString(); rs.SessionHeaderValue=sessionHeader; rs.Render( reportA .);

Each time we render a report we retrieve the session identifier from the Web service proxy and stuff it into the hashtable collection. When the same report needs to be rendered again, we set the proxy s SessionId accordingly. Now that you ve learned the SOAP access basics, we ll look at a practical example that emphasizes its advantages over URL access. SOAP and report interactive features One important limitation that you will inevitably discover when requesting reports by SOAP is that most interactive features, such as drilldown, drillthrough, document maps, toggled visibility, and document maps, rely on URL access. For example, request the Sales by Territory Crosstab report using the Access Options sample. As you would recall from chapter 4, this report allows the end user to drill down by expanding row or column groups. At first glance, when this report is requested by SOAP, it appears that the drilldown interactive feature is unaffected. Don t be fooled, though! This feature relies on direct access to the Report Server by URL. The way this works is that when the interactive feature is requested by the end user (in this case by clicking the + indicator) the HTML Viewer framework fires an HTTPGET request to the Report Server to refresh the report. Once again, in order for the request to succeed, the Report Server must be directly accessible by HTTP-GET. In many cases, this will present a problem because you would typically choose SOAP over HTTP-GET when direct access to the Report Server by URL is not an option, for example, to generate reports on the server side of an Internet web-based application. As a developer, there is really nothing you can do to change this behavior and avoid using HTTP-GET for interactive features. This poses an interesting dilemma, which may further complicate your decision-making process when you are pondering which access option to choose. How important are the report s interactive features to your end users If interactivity is a must, then your choice is predetermined and it is URL access. Of course, we are not excluding the possibility of a hybrid approach where the report is rendered initially by SOAP but URL access is used to support the interactive features. But what about security if URL access is the only option This is an especially valid question for Internet-oriented web applications. The good news is that you can have the best of both worlds: URL access to provide a rich user experience and a comprehensive level of security that doesn t rely on Windows authentication. To accomplish the second objective, you may need to write a custom security extension to replace the default RS Windows-based security mechanism. In chapter 15 we will show you how you can do just this. 326

At this point you are probably ready to throw SOAP out the window. After all, it is more difficult to implement and cannot be used for reports with interactive features. Not so fast! As you will see next, requesting reports by SOAP can be very useful. 9.3.4 Automating the report generation process While URL access is more suitable for interactive applications when the user can initiate the report request explicitly, it falls short when the report needs to be generated in an unattended mode, such as for automating the report generation as a result of an event. For example, in the business-to-business scenario, a vendor may need to pull a report on a regular basis to find out the customer s inventory level. If the inventory level falls below a certain threshold, the vendor system can send a notification to the manufacturing department. We will implement a similar example in chapter 11. Thanks to its object-oriented nature, when reports need to be generated in n unattended mode, SOAP may be a better choice than URL. Let s examine a simple code demo to emphasize this point. An automation solution: AW Campaigner Back in chapter 6 we demonstrated how to export the Sales Promotion report to an RSS-compliant XML format. When there is a new campaign, the report s author could run the report by passing the offer identifier, export the report to the XML, and update the RSS blog file manually. Let s enhance this example by implementing the AW Campaigner solution for automating the whole process. To fulfill the new requirements, our implementation approach will involve the following steps: Step 1 Create a table trigger that will fire when a campaign record is inserted into the SpecialOffer table and invoke the stored procedure. Step 2 Create a SQL Server stored procedure that will invoke a custom Web service fa ade. Step 3 Create a Web service fa ade that will run the report and update the RSS file. Figure 9.6 shows the sequence diagram of our solution. The AW Campaigner process is initiated when a record is inserted into the SpecialOffer table. This causes the trgSpecialOffer trigger to fire. The trigger calls the spUpdateRssFeed stored procedure. The stored procedure in turn invokes our StartCampaign web method of the Campaigner Web service. The Campaigner Web service then requests the Sales Promotion report via SOAP. It asks the report to be exported as XML. Finally, the Campaigner Web service updates the RSS blog file. The source code of the Campaigner Web service can be found under the 09 folder in the AWReporterWeb web project, while the stored procedure and trigger script files are included in the Database project. Next, we ll explain how each component is implemented. WEB SERVICE-BASED REPORT ACCESS 327

Figure 9.6 The AW Campaigner Web service sequence diagram shows that a table-level trigger initiates the blog file update process.

Triggering the process The campaign process starts when a new offer record is inserted into the SpecialOffer table. The trgSpecialOffer trigger is implemented as an AFTER INSERT trigger on the SpecialOffer table, as shown in listing 9.6.

Listing 9.6 When a new record is inserted into the SpecialOffer table, the trgSpecialOffer trigger fires.

CREATE TRIGGER trgSpecialOffer ON [dbo].[SpecialOffer] AFTER INSERT AS /* Get the new special offer id. */ DECLARE @SpecialOfferID int SELECT @SpecialOfferID = SpecialOfferID FROM inserted DECLARE EXEC @Result varchar(8000) spUpdateRssFeed @SpecialOfferID, @Result OUT

The trigger gets the identifier of the record from the inserted table and calls the spUpdateRssFeed stored procedure, passing the special offer identifier to it. One thing to watch for when you work with triggers is that all database operations inside the trigger are performed within the scope of an implicit transaction. This bit me quite badly at first. I wondered why the web method call inside the spUpdateRssFeed stored procedure never succeeded. Upon further investigation, I realized that the trigger 328