NOTE in Visual C#

Paint PDF-417 2d barcode in Visual C# NOTE

Ensuring data consistency by using report sessions is more of a concern with URL access than with SOAP. When the report is requested via SOAP, the whole report payload is streamed back to the client. This means that you will get all pages of a multipage report, and no additional requests to the Report Server are necessary when the user pages from one page to the next. On the other hand, when the report is request by URL, only the first page is rendered. Navigating to another page initiates a new URL request. That said, you might still want to consider leveraging report sessions with SOAP as a performance enhancement technique.

Unlike the automatic report session management that the browser provides when the report is rendered by URL, you have to take care of correlating the report sessions yourself when requesting the report by SOAP. The reason for this is that the Web service proxy keeps only one session identifier, so each subsequent report request overrides the report session identifier set by the previous request. There are two cases when you may need to take care of handing the report sessions by yourself: Rendering the report images via calls to RenderStream Please note that this is needed only if the session identifier is overridden by another report request. Typically, you will download the report images via calls to RenderStream immediately after the report is rendered. If this is the case, you don t have to handle report sessions explicitly because the proxy will already have the session identifier associated with the report. 324

Optimizing the Report Server s performance As we explained in chapter 7, if the Report Server can correlate the report request with a session, it will bypass the execution phase and use the cached copy. As you will see in chapter 16, report session caching can boost the Report Server s performance considerably. If the report data are not volatile and some data staleness is tolerable, we recommend that you leverage report session caching. To understand how to handle report sessions when requesting reports via SOAP, you need to know how the Web service proxy stores the session identifiers. How SOAP access handles report sessions When the report is requested via SOAP, the Report Server exposes the report session related properties under the SessionHeader proxy class. The SessionId member of this class returns the report session identifier that matches the SessionID primary key in the SessionData table from the ReportServerTempDB database. You can check the IsNewExecution property to find out whether the call to the Render method has resulted in a new execution. If IsNewExecution is false, the Report Server has served the report request from an already existing report session. The Report Server overwrites the SessionID member after each call to the Render method. Therefore, if you are not proactive, two subsequent report requests will share the same sessions only if they ask for the same report (assuming that the parameter set is the same). For example, let s say you run report A, then report B, and then report A again. When report B is rendered, its session identifier will overwrite the previous session identifier, which means that you will lose report A s session identifier. When report A is run again, even if the parameter set is the same, its execution will create a new report session and IsNewExecution will return true. Therefore, if you need to leverage report sessions, you need to write some code to store the report session identifiers and correlate them with the requested reports. Next we ll discuss a possible implementation approach that does this. Correlating the report request with a report session You could keep the reports-to-session association in a collection of some kind. For example, a hashtable collection, as shown in listing 9.5, can do this by storing the report names and session identifiers as name-value pairs.