Selecting the Page to be Executed

After the user's request (in the form of a valid URL) has been accepted by the Web server, it delegates the request to the appropriate server-specific object— a servlet such as mstrWeb for a J2EE environment or main.aspx (the equivalent of a servlet in ASP.NET) for a .NET environment. The servlet or ASP.NET file retrieves information from the request and translates it into server-independent structures. This information, which includes where the event originated, helps to determine the page to which execution will be directed. This page, known as the target page, will ultimately display the results of the user's request. Sometimes the name of the target page is present in the request, but often it is inferred by looking at all the data. In many requests, the target page is the same as the source page, which is present in the request in the form of the src URL parameter.

Once the target page has been selected, the application creates the page and all of its beans, as defined in the Page Configuration file. In MicroStrategy Web products, a page acts primarily as a container for the components (MicroStrategy WebBeans), which are responsible for gathering data and presenting it to the user.  

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.

The servlet or ASP.NET file works in conjunction with the Controller, MSTRWebController. The servlet or ASP.NET file has server-specific logic for processing URLs, while the Controller contains all of the MicroStrategy-specific logic for handling the request. The servlet or ASP.NET file retrieves information from the request and constructs the ContainerServices and RequestKeys objects to hold this information. The servlet or ASP.NET file then calls the Controller. Servlets call the Controller directly, while ASP.NET pages use JNI (Java Native Interface) to make the call from ASP.NET to Java. Once it has been called, the Controller uses the RequestKeys object to determine the target page and to access configuration information needed for initializing Web components (such as beans that need to be populated) and identifying the JSP or ASP.NET template and page section information.

The target page is generally the same page that originated the request, but in some cases a different page is used. The application proceeds in the following order until it has selected a target page:

1. If the event specified in the request (that is, the event identified by the evt parameter in the request) is one of the events listed below, the application will attempt to use a specific page (indicated below) as the target page. If it is possible to use the specified page, the application will ignore the src parameter in the request and the target attribute of the event identified in the request (as defined in events.xml), if either exist.

2. If the request contains a src parameter, the application uses the page specified in that parameter as the target page.    

3. If the request does not contain a src parameter or the src parameter is simply the name of the servlet, the application searches the events definition file, events.xml, for the event specified in the request. If the application finds a match (that is, it finds an event whose id attribute is the same as the eventID specified by the evt parameter in the request URL), it checks to see whether the matching event has a target attribute. If it finds one, it uses the value of the target attribute as the target page.  

4. If there is not a src parameter in the request and the event specified in the request (that is, the event identified by the evt parameter in the request) does not have a target attribute, the application automatically uses the Error page (that is, the <page> element in the Page Configuration file whose name attribute has the value "error") as the target page.  

The names and IDs of every event that the application can handle by default are listed in the events definition file, events.xml. Some, but not all, of the events in these files have a target page specified. If they do, it is identified by the target attribute in the <event> element in the events definition file.A sample URL for a common user request with an event that has an associated target page is shown below:

J2EE environment:

mstrWeb?evt=2001&src=mstrweb.shared.fb.2001

ASP.NET environment:

main.aspx?evt=2001&src=main.aspx.shared.fb.2001

The code for the corresponding event in events.xml is shown below:

<eventHandler type="3">
  <events>
    <eventid="2001"name="browseFolder"target="shared">

Event 2001 is raised when a user tries to return to a specific folder from the Report page. In the example shown above, the application would select the Shared Reports page as the target page because the event in the user's request has a target attribute defined as "shared" in the event definition file. The location of the report is shown above the report grid. Each folder in the path is highlighted with its event (directing the user to that folder in the Shared Reports page.

Customization

Modifying the selection of the default target page does not require Java programming. It requires only that you create custom events definitions. Optionally, you can change the URL to have the src attribute point to the desired target page.

Problem solving at this step in page execution

Two possible errors can occur at this stage:

• The Controller cannot determine the target page.

  You will get an error message such as "Cannot display page (null)". A possible cause of this error is that your URL does not include a src parameter and the event specified by the evt parameter does not have a target page.

  You will get an error message such as "Cannot display page (target)".  A possible cause of this error is a misspelling in the URL.

In either case, execution cannot continue on the same page and will always be redirected to the "Error" page The Error page is the page in the Page Configuration file whose name is "error".. Information about the error will be written to the error log, and the stack trace of the error will be saved so that it can be included as a comment in the HTML output for the "Error" page. You have several sources of information to use in problem solving for these types of error.  Logging information can be viewed in the log file, and the stack trace can be viewed in the HTML source for the "Error" page when it is displayed. 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 target page has been selected, the next step in page execution is validating the session.

See also

• Using the URL PI to Access a MicroStrategy Web Page