Setting Execution Properties

Report Execution Settings— The message ID, state ID, and synchronous nature of the request can be set. The report can be directly saved in the inbox, and usage of server-side caches can be controlled whether they should be used and updated or not used at all.

The synchronous nature of the execution request is determined by the value of the MaxWait property. If it is –1, the report is synchronous, waiting indefinitely. If the value is 0, the request is invoked (or the status checked once) with no waiting. Any value greater than 0 is treated as the maximum time to wait in milliseconds.

By default, an asynchronous request is polled a fixed number of times. If the caller wants to poll at a different frequency, a value may be supplied in the setPollingFrequency method. The argument is the number of milliseconds to wait before polling again.

These execution properties or flags are listed below:

Execution Flags— These are values in EnumDSSXMLExecutionFlags that allow you to specify how Intelligence Server should utilize caches and the History List in executing this report.
Result Flags— These are values in EnumDSSXMLResultFlags, specifying the amount of report data (in XML format) that is returned to the Web API. Depending on whether you wish to view the report as a complete grid, a graph, and/or just some simple values or properties of the report, different Result Flags can prevent unnecessary resources and time from being spent retrieving more data from Intelligence Server than necessary for your purpose.
PromptsEventHandler— In case of a prompted report, the ReportBean provides direct access to underlying Prompts collection and the event handler that should be used by the underlying PromptBean.
View Mode— Specifies the mode (*grid, graph or grid and graph) in which the report is displayed.

Intelligence Server Caching— A boolean value supplied to the UseCaches property controls whether an Intelligence Server cache is used. The manner in which a report bean executes a report is controlled by the presence of the MessageID and UseCache properties as shown below.

UseCache?	Message IDSupplied?	Behavior
Yes	No	New report is executed. Results are saved back to the Intelligence Server cache.
Yes	Yes	Attempt to reuse the existing Intelligence Server cache. In the event that the message ID is no longer valid, re-execute the report.
No	No	New report is executed. The results are not saved back to the Intelligence Server cache.
No	Yes	The report is refreshed as per the Web API call, RefreshReport. The report is re-executed against the DW and the results are stored back into the same message ID.

In-memory HTML Caching— A report bean can be held in the end user’s session or the application context by caching the report results. In this case, the report grid does not have to be transformed with every request to transform, but only when the report is retrieved from Intelligence Server. In this way, the report bean may be instructed on when to release its XML and re-execute the report (or simply retrieve the results). This is done using a simple expiration time period, in hours. If a value of 0 is supplied, the results are immediately expired.

The following methods initiate requests to Intelligence Server:

getMessageID()— This triggers a report execution request unless the caller has specified an explicit message ID. If a report execution request has already been initiated (from another method), this merely returns the message ID held by the object.
getReportData()— This triggers a report execution and causes the report XML data to be collected and used to populate this object. It enables the caller to retrieve information about the report without having to parse XML data.
Other methods that initiate requests to Intelligence Server are— getReportInstance(), getWebGraph(), isDrilled(), isPrompted(), and refresh(). All of them have a condition similar to getMessageID() when initiating a request to Intelligence Server.