Submitting a Request for Page Execution

Page execution is initiated when a user submits a request through a Web browser. The user's request is in the form of a valid URL that can be accepted by the corresponding Web server and interpreted by the application. The user's request is generally triggered when the user clicks a link on a Web page, types a Web address in the browser's address or URL field, or enters data in a form.

Click on any box in the diagram to see a detailed explanation of that step in page execution. Click here to return to the Overview of Page Execution.

Every request to a MicroStrategy Web product corresponds to a specific event, or action. An event is the structure used by MicroStrategy Web products to identify the actions that must be performed and to specify what component should execute those actions. Within a request, the evt parameter identifies the event to be handled. It is set to a particular eventID value, which specifies the event that needs to be handled and corresponds to the ID attribute of an event in one of the event definition files. (A comprehensive list of event names and IDs can be found in the default event definition file, events.xml, as well as in the Event Handlers Reference.) The value of the src parameter in the request specifies where the event originated. This is generally the component on a page.

Submitting a request

When a user clicks a link or submits a form within a MicroStrategy Web product, the request (in the form of a URL) travels via HTTP to the servlet (in a J2EE environment) or ASP.NET page (in a .NET environment). Before any page execution can occur, the user's request must be processed by this server-dependent component in the application server. This component translates the information into server-independent structures, such as the ContainerServices and RequestKeys objects, which are used internally by MicroStrategy Web products. Except during this initial processing, user requests to MicroStrategy Web products are processed identically in a J2EE and a .NET environment.

The following examples show typical request URLs, with the events (specified by the evt parameter) for common user tasks and the sources (specified by the src parameter) from which the events originated.

Example of a request URL when a user is moving from page to page:

J2EE environment:

Copy

mstrWeb?evt=3002&src=mstrWeb.3002

.NET environment:

Copy

main.aspx?evt=3002&src=main.aspx.3002

In the examples above, 3002 is the ID of the event to be handled, and the source of the event is the servlet itself. Event 3002, which is known as the openShared event, opens the shared reports folder.

Example of a request URL when a user is working within a single report page:

J2EE environment:

Copy

mstrWeb?evt=4001&src=mstrWeb.report.frame.rb.4001&reportViewMode=1&reportID=B5C67DFC11D60B5610008CB3D1CEE6A4...

.NET environment:

Copy

main.aspx?evt=4001&src=main.aspx.report.frame.rb.4001&reportViewMode=1&reportID=B5C67DFC11D60B5610008CB3D1CEE6A4...

In the examples above, 4001 is the ID of the event to be handled, and the source of the event is a report bean on the report execution page. Event 4001 executes a report and receives two parameters, ViewMode and reportID.

Example of a request URL for a typical folder browsing process:

This is an additional example of a common event within a URL, a request to access a folder-browsing page:

J2EE environment:

Copy

mstrWeb?evt=2001&src=mstrWeb.shared.fb.2001&folderID=78AAF4654A62E9D384D0E094BE585507

.NET environment:

Copy

main.aspx?evt=2001&src=main.aspx.shared.fb.2001&folderID=78AAF4654A62E9D384D0E094BE585507

In the examples above, 2001 is the ID of the event to be handled. This event will be handled by a bean called fb in the shared page, and the event expects a folderID parameter that specifies the ID of the folder from which content should be displayed.

Problem solving at this step in page execution

Three possible errors can occur at this stage:

The user types an incorrect URL in the browser.

In this case, the request might not even get to the Web server. The "Error" page is not displayed, and no error information is generated by the application. Check the URL to confirm that you entered the information correctly.
Controller initialization fails.

This type of error can occur only once, when the application is first loaded. (This happens the first time that a request is submitted to the Servlet or ASP.NET page.) The "Error" page is not displayed, and no error information is generated by the application. The most common reason for this type of error is malformed XML. Check to make sure that you used well-formed XML when you modified files such as the Page Configuration file, the Style Catalog Configuration file, microstrategy.xml, or web.xml.
Controller initialization results in the Error page being displayed.

This type of error can occur only once, when the application is first loaded. (This happens the first time that a request is submitted to the servlet or ASP.NET page.) You have several sources of information to use in problem solving for this type of error. The "Error" page displays, information about the error is written to the error log, and the stack trace of the error is included as a comment in the HTML source of the "Error" page.

See Error Handling for a more detailed discussion of error handling in MicroStrategy Web products, and see Logging Architecture for more information about error logging.

Next step in page execution

After the request has been submitted and accepted, the next step in the page execution flow is selecting the page to be executed.