MicroStrategy ONE

Overview of Page Execution and Event Processing

This section provides a detailed description of how MicroStrategy Web products handle page execution, from the initial user click to the final display of the resulting page. To perform efficient, effective customizations, you need to understand the standard page execution flow and know which MicroStrategy Web components are customizable at each step of the execution. The key to achieving high-quality customizations is to make the right change to the right component at the right point in the flow.

The diagram below illustrates a high-level perspective of the various phases of page execution and the major steps that take place within each phase. The steps where customization can take place are outlined in bold and include the main components that you would customize at that step in the flow. For example, the first major step in the Create Page phase of page execution is Select page, and the major component that is customized at that step is the events definition file.

A brief overview of each step follows the diagram, while a more detailed description can be found by clicking any of the steps in the diagram.

The overall page execution flow in MicroStrategy Web products is controlled by a single component, the Controller, while the page itself acts primarily as a container for the components (MicroStrategy Web Beans) that gather the data and display it to the user. In general, page execution follows the same execution flow for all pages. This is different from versions of the product prior to 7.3, in which each page had its own execution cycle. Centralizing the execution of page execution makes it easier for you to customize, debug, and upgrade.

When you plan and perform customizations, you need to understand what is taking place at each step in the page execution flow, what types of customizations are required (XML configuration changes, JSP/ASP.NET programming, or Java programming), and what types of information are available to help you troubleshoot problems. The detailed explanation for each step in the flow provides all of this information, as well as links to related topics and relevant customization scenarios.

  • Submitting a request: 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 submits the values of a form.

  • Selecting the target page: Once the user's request is 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 an ASP.NET page such as main.aspx for a .NET environment— which in turn translates the request into server-independent structures. The request is delegated to the Controller, MstrWebController, which retrieves the events that need to be processed and determines the page to be executed. Once the appropriate target page has been identified, the definition for that page is retrieved from the Page Manager.

    Customizations performed at this step involve customizing the events that are defined in the application. They include making changes to a custom events definition file, such as customEvents.xml.

  • Validating the session: After the definition of the target page has been retrieved, if necessary, the session is validated. The session can be validated by the Controller or by a third-party application, such as a portal or custom application, using the External Security Module (ESM).

Customizations performed at this step involve customizing the way the session is validated. This includes customizing the External Security Module.

  • Creating and initializing beans: The application creates an instance of and initializes each bean that is defined for the target page in the Page Configuration file. It sets the bean's name and context and specifies whether the bean should be persisted, what its output format should be, and, possibly, the event handler for the bean. It first sets the initialization properties for the bean (normally, pre-defined default values ), then tells the bean to restore its state, and finally sets the request properties for the bean (values defined dynamically by the user through the request). Beans restore their state from the incoming request.

    Customizations performed at this step involve customizing the definition of pages used by the application, in particular the use and properties of the beans defined for each page. They involve making changes to the Page Configuration file,pageConfig.xml, and/or to additional custom XML page configuration files, such as a menu configuration file or a toolbar configuration file.

  • Processing events: After the beans have been initialized, the page is ready to handle events. Each event specified in the user's request triggers a different set of actions that will modify the state of the bean and, ultimately, the page output. A page can handle one or more events, but each event is processed individually. The sequence for handling multiple events varies, depending on whether the target page remains the same or is changed.

Customizations performed at this step involve adding custom functionality and actions. They include making changes to event definitions, event handlers, and/or event maps.

  • Applying custom logic before collecting data: You can execute custom code before data is collected from Intelligence Server. Pre-data-collection logic is generally used to modify the amount of data collected from Intelligence Server. For example, you might want to limit the display of datamart reports on the Folder Browsing page to only those users with permission to access datamart reports, or you might want to dynamically modify specific properties of a bean, such as execution flags or result flags. (You can apply custom logic both before or after data is collected, but the type of logic differs depending on the point at which it is applied.)   

    Customizations performed at this step involve modifying data collection logic. They include creating customadd-ons(Java files that contain custom logic) and adding them to page definitions in thePage Configuration file,pageConfig.xml.

  • Collecting the data: Once all of the beans have been initialized, the events have been processed, and any specified pre-data-collection logic has been applied, the necessary information is retrieved from Intelligence Server.  

  • Applying custom logic after collecting data: You can execute custom code after data is collected from Intelligence Server. Post-data-collection logic is generally used to modify the state of a bean or perform an action based on the status of the bean (ready, processing, error). For example, you might want to open a prompt after it has already been answered so that it can be displayed on a report, or you might want to add a report to the History List only if the report was successfully executed. (You can apply custom logic both before or after data is collected, but the type of logic differs depending on the point at which it is applied.)

    Customizations performed at this step involve modifying bean information after data has been retrieved from Intelligence Server. They include creating custom add-ons ( Java files that contain custom logic) and adding them to page definitions in the Page Configuration file, pageConfig.xml.

  • Selecting the template to be used: Based on the information in the Page Configuration file, the Controller (MSTRWebController) selects the name of the template file to which execution will be redirected. (The servlet or ASP.NET page will use the name of this file to cause the final content to be displayed.) One or more templates are defined for every page in the Page Configuration file, with each template associated with a different page status. The application selects the template to be used based on the current status of the page and then forwards the execution to this template.

    Customizations performed at this step involve customizing the templates defined for the target page. They include creating custom template files (JSP or ASP.NET pages) and/or modifying which templates are defined for the target page in the Page Configuration file, pageConfig.xml.  

  • Arranging the content: MicroStrategy Web pages are made up of discrete page sections, such as "Header', "Toolbar", and "Content". Page section files(JSP or ASP.NET pages) control the arrangement of these discrete sections on the page that will be displayed to the user. Custom HTML tags are used in these page section files to render the actual content that is displayed in each section.

    Customizations performed at this step involve modifying the "coarse" content of the target page— that is, the arrangement and content of the page sections on the page. They include creating or modifying custom page section files (JSP or ASP.NET pages) that will provide the content for various parts of the target page and using custom HTML tags in these files to render the content. (The actual set of page section files to be used is determined earlier in the page execution cycle, when the target page is selected.) Customizations also include modifying how page sections are defined for the target page in thePage Configuration file,pageConfig.xml.

  • Transforming the beans: Each bean on the target page is rendered by a transform defined by a style from the Style Catalog Configuration file. Each style is associated with a transform, an optional set of transform parameters, and typically a layout definition file that determines the more granular arrangement of the data rendered when the bean is transformed.

Customizations performed at this step involve modifying the HTML output created when beans on the target page are transformed. They include one or more of the following actions: making changes to the Style Catalog Configuration file (the XML file that holds the styles used to render the beans on the target page), creating custom transform files (Java files), and/ or creating custom layout definition files (XML files). Transforms, transform parameters, and layout definition files are associated through a style definition.

  • Displaying the page: Once the beans have been transformed and the content arranged, the page is returned to the browser for display to the user. The "look and feel" of the page that is displayed to the user is determined by the style sheet that is applied.

Customizations performed at this step involve modifying the font, typeface, etc. that are used on the page that will be displayed to the user. They include making changes to the CSS (Cascading Style Sheet) files that will be used when the target page is rendered.