Identifying Execution State
Hypertext Transfer Protocol (HTTP) is a connectionless and stateless protocol, which means that it does not automatically indicate whether different requests come from the same client or even whether a single browser instance is still actively viewing a page or site. Sessions create a logical connection to maintain state between server and client over HTTP. The user-specific information relevant to a particular session is known as the session state.
Session management involves correlating an HTTP request with other previous requests generated from the same session. Without session management, these requests appear unrelated to the Report Server Web service because of the connectionless and stateless nature of the HTTP protocol.
Reporting Services does not expose a holistic concept of session state such as that exposed by ASP.NET. However, when executing reports, the report server maintains state between method calls in the form of an execution. An execution allows the user to interact with the report in several ways - including loading the report from the report server, setting credentials and parameters for the report, and rendering the report.
While they are communicating to a report server, clients use the execution to manage report viewing and user navigation to other pages in a report, and to show or hide sections of a report. A unique execution exists for each report the client application is running.
In general, the lifetime of an execution starts when a user navigates to a browser or client application and selects a report to view. The execution is discarded after a short time out period after the last request to the execution has been received (the default time out is 20 minutes).
From a Web service perspective, the lifetime starts when the Report Server Web service LoadReport, LoadReportDefinition, or Render methods are called. The application can use other methods to manipulate the active execution (for example, setting parameters and setting data sources). The execution is discarded after a short time out period after the last request to the execution has been received (the default time out is 20 minutes).
An application keep track of multiple active executions between calls to the Web service Render and RenderStream methods by saving the ExecutionID, which is returned in the SOAP header from the LoadReport and LoadReportDefinition methods.
The following diagram shows the processing and rendering path for reports.
.gif "Percorso di elaborazione/rendering del report")
To support the functions described above, the current SOAP Render method has been split into multiple methods encompassing execution initialization, processing, and rendering phases.
To programmatically render a report, you must:
- Load the report or the report definition using LoadReport or LoadReportDefinition.
- Check to see if the report needs credentials or parameters by checking the values of the CredentialsRequired and ParametersRequired properties of the ExecutionInfo object returned by LoadReport or LoadReportDefinition
- If necessary, set the credentials and/or parameters using the SetExecutionCredentials and SetExecutionParameters methods.
- Call the Render method to render the report.
While a report is in session, the underlying report stored in the report server database can change. For example, the report definition can change, the report can be deleted or moved, and user permissions can change. If the report is in an active session, it is not affected by changes made to the underlying report (that is, the report stored in the report server database).
You can also manage a report session using URL access commands. For more information, see Managing Report Sessions Using a URL.
Vedere anche
Riferimento
Reporting Services Web Services Class Library
Render
Altre risorse
Using Reporting Services SOAP Headers