Deployment - Microstrategy

So far, this chapter focused on report design—that is, the process of building reports from basic report components using the Report Editor in MicroStrategy Desktop or Web. You have learned how to design reports using the data definition and view definition. The data definition establishes how the data is accessed and manipulated in the data warehouse. It includes the report filter, Report Objects, and report limits. The view definition represents how the data is presented and manipulated in the Intelligence Server. Concepts such as the view template, formatting, thresholds, view filters, derived metrics, subtotals, and sorting make upthe view definition.

Report design allows you to set up a controlled, user-friendly environment for report creators, who build reports from existing, predesigned reports in either Desktop or Web. Report creators can customize these reports with the wide range of powerful reporting functionality that report designers can make available.

Project progression

Before outlining the steps to set up a report creation environment, let’s explore how a business intelligence project can possibly develop in terms of the complexity of reports and the experience of its users. The goal of project development is to unburden the report designer and the project administrator from participating in every report, by empowering users to find answers to their business questions independently. They are enabled to extract more meaning from the data and to work independently, rather than just view static report data.

The user categorizations in this section are based on the user privileges assigned in MicroStrategy.

At the beginning of a project, simple, non interactive reports are set up by the report designer. Novice users execute the reports and view the data. Users who do not need or desire more complex analyses continue to run these types of reports throughout the life of the project. An example is a simple grid containing Region, Employee, and Revenue.

The first advance is the addition of some user interaction to the reports, such as prompts, drilling, and simple formatting. Defining drill paths allows a report designer to control the information a report creator can access, while providing options to explore and analyze the data. Prompting also provides a report creator with choices, but only those choices that the report designer has deemed appropriate and relevant. These privileges are given to a Web Reporter, although a report designer must set up the prompts and drill maps to ensure that the data definition is constructed correctly.

Drilling and prompting are described in more detail in succeeding chapters.

The next step is the Web Analyst level, where robust report customization is allowed. These options include pivoting, Report Objects access, derived metric creation, and view filter modification. The features available through these privileges allow a user to customize a report to answer a business question and then save the new report.

Reports can be designed with all objects in Report Objects and none on the grid. This provides a blank slate or foundation for report creators to customize and manipulate reports to suit their needs. Users who work with this type of report are Desktop Analysts. They cannot add or delete objects from the report but can alter what is viewed. In this step, report creators achieve independence from the report designers. Hence, they have the necessary tools to create customized reports in a safe environment where they are assured that the data makes sense and is relevant.

Finally, Web Professionals have increased access to all the objects in the project. They can enter the Design View to add and delete Report Objects, and create report filters. Report creation ends here, and report definition begins, because Web Professionals can modify the data definition without oversight.

What we have generically called a report designer in this is a combination of Web Professional and Desktop Designer. Desktop Designers develop new reports from scratch. They access various editors to create report components such as consolidations, custom groups, data marts, documents, drill maps, filters, metrics, prompts, and templates. The remainder of this book is aimed at Desktop Designers.

The following diagram depicts the project progression in terms of the user types.

project progression in terms of the user types

As the project matures and the users’ experience increases, more advanced functionality is deployed to the user community. The Web Reporters begin with the simplest reports but as they become more comfortable with the product, they can become Web Analysts and Desktop Analysts, employing user interaction such as drilling and prompts. From the beginning, Desktop Designers and Web Professionals develop predesigned reports to deploy to less experienced users.


The following graphic sums up the various privileges available in Desktop and Web. Not every user has to be granted all the privileges for a given role. For example, a Web Reporter may be allowed to execute reports only, without prompt and drilling options.

Predesigned reports

There are different ways to design reports for deployment to the report creation environment. A single project can use any, all, or none of these types of reports:

  • static reports
  • prompted reports
  • Report Objects
  • filter and template shortcuts

A single report can use more than one of these types. For example, a prompted report can have filter and template shortcuts.

Static reports

Static reports are basically reports without prompts. These reports are useful for inexperienced users or for delivering data to answer a specific query in a specific format.

Prompted reports

Prompted reports allow user interaction during report execution. A prompted report requires some input to finish the report content. The report definitions are dynamic, changing with each query when the information in the prompt dialog box is altered by a user.

Prompted reports can be as simple as choosing from a list of regions or as complicated as choosing all of the grid units and filtering conditions, such as the Report Builder and Report Wizard that are included in Desktop and Web. Select Employee Analysis. No objects have been placed on the grid definition; they are all contained in Report Objects only. This provides users with a blank template so that the can create their own customized views of the report. Review the Report Objects—only those objects that are relevant to employees are included, such as hire date, employee name, and revenue. Create another report, this time choose Time Analysis. Report Objects contains objects that are all relevant to time—month, year, quarter, and percent growth.

Shortcuts to filters and templates

The sample reports explained previously in this have filters and templates that are created within a report and are known as embedded filters and templates. An embedded filter is generated when a filter is created on the fly in a report or when a copy of an existing filter is added to a report. Changes made to an embedded filter affect only the report in which it is contained because the filter exists only within that report. In contrast, a shortcut to a filter stands alone as a filter and can be used in multiple reports. When the filter is changed, the changes are propagated to all other reports that contain a shortcut to the same filter.

The difference between an embedded template and a shortcut to a template is similar to the difference between an embedded filter and a shortcut to a filter. An embedded template exists only within the context of a report, while a shortcut is linked to an existing template.

The diagram below illustrates the difference between embedded objects and shortcuts.

difference between embedded objects and shortcuts

Separating the data definition of a report into a shortcut to an existing filter and a shortcut to an existing template helps make report deployment scalable and easily maintained. Details on shortcuts are included later in this chapter, in the Shortcut to a filter and Shortcut to a template sections.

Deploying predesigned reports

Choosing the type of predesigned reports to use is only one of the decisions a report designer makes when deploying reports. Other considerations are:

  • predesigned report access
  • object reuse
  • caching
  • privileges

Privileges have already been discussed in the previous section.

Accessing predesigned reports

To deploy these reports to users, you simply place them in a certain folder so that other users can access them. Reports saved in the Reports folder under the Public Objects folder can be viewed by other users on the system. Desktop users can navigate to reports in the Public ObjectsReports folder and execute them by double-clicking them. A Web user can navigate to the Shared Reports section and run those reports by clicking them.

You can also use the Reports folder under Object Templates to save reports that are frequently used to create new reports. They are displayed when a MicroStrategy Desktop user selects New, then Reports or a MicroStrategy Web user clicks Create New Reports.

To view the Object Templates folder, select Desktop Preferences from the Tools menu. Click Browsing Options. Select Display Hidden Objects, and click OK until you are returned to the Desktop. For more information on object templates, see Object templates. Neither the deployment folders nor the reports are special, except that they are available for other users to access.

Reusing objects

Shortcuts to filters and templates promote object reuse and good object management. For example, a project can have 50 reports that are all based on the same filter. When that filter has to be changed, how it was created is important. If the filter was built as a standalone object and implemented as a shortcut in the reports, the filter can be changed, and the alteration is applied to all of the dependent reports. However, if each report uses its own embedded filter, then that change must be duplicated in each of the 50 reports. Preventing this kind of object explosion and maintenance overhead is the basic justification behind object reuse.

Filters, of course, are not the only objects that can be reused. Templates, metrics, custom groups, and consolidations are among the objects that can be recycled.

When objects are used in multiple places, you can use the Search for Dependents tool to discover which objects contain them or other objects they contain. For example, you can search for all templates that contain the metric Profit or all metrics that are used by the template Store Sales.


In general, a cache holds recently accessed values to increase performance. For reports, a cache usually contains frequently requested reports, providing faster execution because then the reports do not access the data warehouse. For reports, the following caches are used:

  • The report cache contains pre-processed report data and is stored on disk.
  • The Intelligent Cube is identical to the report cache but is stored in the Intelligence Server memory. It allows manipulation of the data displayed in the report view.
  • The report view is an in-memory representation of the current view of a report, based on the view definition of that report. Each user running the same report has a unique report view on the Intelligence Server.

Intelligent Cubes do not need report re-execution for the following report modifications:

  • drill
  • pivot
  • page-by
  • sort
  • subtotals
  • outline mode
  • banding
  • report view format, such as changes to fonts and cell properties
  • column alias
  • add and remove report objects
  • derived metrics
  • view filter
  • thresholds
  • ranking

The traditional benefits of report caching include executing a report once and allowing many users to access the same report quickly from cache. Caching also improves database processing time. The new Intelligent Cube provides additional advantages that include the following:

  • The response time for retrieving data and modifying the report should be almost immediate.
  • Report caches can be created and refreshed on a scheduled basis during off-peak hours.
  • The report view does not need to display all the report objects available in the Intelligent Cube.
  • Objects can be moved between the report grid and Report Objects to allow ad hoc analysis within defined limits.
  • Multiple users can simultaneously have a unique representation of a report in the cube.
  • No additional SQL is generated when the Intelligent Cube contains all the necessary report objects. If a modification to a report needs additional information, SQL is automatically generated and submitted to the data warehouse.
  • Report definitions and views are stored in a central metadata repository, therefore any MicroStrategy user interface can easily share them.

Shortcut to a filter

When you add a filter to a report, you can

  • Add it to the report filter. It is combined with any existing filters.
  • Replace the report filter with a copy of the filter. Changes you make to the filter are not propagated to the original filter, and vice versa. This is also called a local or embedded filter and is the same as creating a filter on the fly in the report.
  • Replace the report filter with a shortcut to the filter. Creating a shortcut to a filter allows you to use an existing filter on a report, taking advantage of the benefits of object reuse.

To choose from these options, right-click on a filter in the Object Browser.

In the Report Filter pane of the Design view, if the filter’s name is displayed and a shortcut icon appears in the title bar, it is a shortcut to a filter. This type of filter is sometimes referred to as a linked filter.

If you change the shortcut filter by, for example, removing an attribute, and then save the report, you can either create a local copy of the shortcut or retain the shortcut. If you create a copy, changes made to the filter in this report do not impact other reports. If you keep the shortcut, changes made to the filter in this report are propagated to all other reports that contain a shortcut to the same filter.

An example of a shortcut to a filter is included in Shortcuts to a filter and a template example below.

Shortcut to a template

A template defines the layout of general categories of information in a report. A template specifies the information to retrieve from the data warehouse and how it is displayed in the report grid. Information on the template includes metric default values, banding options, join type setting, and data sorting options. You can create a stand-alone template in the Template Editor. Create a report-specific template using the Report Editor.

A shortcut to a template, which is sometimes referred to as a linked template, functions similarly to a shortcut to a filter.

When you add a template to a report, you can

  • Replace the report template with a copy of the template. Changes you make to the template are not propagated to the original template. This is also called a local template and is the same as creating a template on the fly in the report.
  • Replace the report template with a shortcut to the template. Creating a shortcut to a template allows you to use an existing template on a report.

To choose from these options, right-click on a template in the Object Browser.

In the Grid definition, if the template’s name is displayed and a shortcut icon appears in the title bar, it is a shortcut to a template.

If you change the shortcut template by, for example, adding a metric to Report Objects, and then save the report, you can either create a local copy of the shortcut or retain the shortcut. If you create a copy, changes made to the template in this report do not impact other reports. If you keep the shortcut, changes made to the template data definition in this report are propagated to all other reports that contain a shortcut to the same template. In the example, all those reports display the new metric in Report Objects.

Shortcuts to a filter and a template example

The following procedure creates a report using shortcuts to an existing filter and a template. The template places subcategories and revenue values by year on the report. The filter excludes April, May, and December from the metrics. When you are done, changes made to the shortcuts will impact other reports that use the same filter or template.

To create a report with shortcuts to a filter and a template

  1. Create a new report.
  2. Right-click the Revenue Template, which is found in the Supporting Objects folder. Select Replace with shortcut to template.
  3. Right-click Month Filter in the same directory, and select Replace Report Filter with a shortcut to this filter.
  4. Save the report. The Advanced Save Options dialog boxopens.
  5. Select Retain the shortcut to the filter and Retain the shortcut to the template. You can select to remember these settings for the next time you save a report.
  6. Click OK.

When the report is executed, it looks like the following report sample.

Shortcuts to a filter and a template example

This report is saved as Shortcuts to Filter and Template.

Now change the view definition of the report, which does not change either of the shortcuts. Move Year from the grid to Report Objects. Add a threshold of revenue greater than $1 million. Format the cell with bold font and 25% grey fill. The report is redisplayed as the following.

Shortcuts to Filter and Template.

This report is saved as Shortcuts to Filter and Template with Thresholds.

This does not change the linked template, because the attribute is removed from the view only; it remains on the Report Objects. The revenue is now calculated for all time, except for April, May, and December, which are excluded from the metric by the filter.

Impact of modifying templates

Recall how changes to a linked filter impact any dependent reports—if you create a local copy, changes made to the filter do not impact other reports. Alternatively, you can keep the shortcut, which allows changes made to the filter in this report to be propagated to all other reports that contain a shortcut to the same filter.

The effects of altering a template are more complex. For example, if a metric is removed from a template, the change can affect all, some, or none of the dependent reports. It depends entirely on how often the metric is included in the view definition of reports. The Template Dependency Validator allows you to conduct a quick impact analysis before saving any changes to a template.

The tool helps prevent the view definition from breaking the report because the view is asking for an object that is no longer in the data definition since it was removed from the underlying template. By alerting you to a potential problem, you can resolve the issue before any reports are affected. For example, a report has a shortcut to a template, which contains Country, Region, Metric 1, and Metric 2. The view filter is set to “Metric 1 > 20.” This is illustrated in the following diagram.

Impact of modifying templates

Suppose Metric 1 is removed from the template but not from the report view. When the report is executed, an error occurs because the view filter can no longer be evaluated (Metric 1 no longer exists).

When a template is modified and saved in Desktop, the Template Dependency Validator is triggered. The validator lists:

  • reports that depend on the template
  • reports that will not run if the change is completed

To resolve the problem, do one of the following:

  • Cancel the change and re-evaluate.
  • Open each dependent report and remove the dependencies, then change the template definition.

For the previous example, you could remove the view filter from the view definition of the dependent report.

The changes to the template are not saved until the Template Dependency Validator is closed. For more information on using this tool, see the online help.

Object templates

An object template allows you to use a predefined structure to begin creating a new object. For example, you may want to create many filters that contain the current month as part of the definition. Having a filter object template that contains the current month allows you to skip the step of defining thatpart of the filter each time you create a filter. In other words, you only have to define that filtering condition once. When you use the filter object template, you automatically have the current month condition in every new filter you create.

Another example is a need to build multiple reports containing the attribute Day and the metrics Revenue, Cost,and Profit. To reduce the time spent creating these similar reports, define a report with these objects and save it in the Object Templates folder, thus creating a report object template.

To be used as an object template, the object must be saved in the Object Templates folder. This is the only difference between an object and an object template (like a report and a report object template).

You can create object templates for the following objects:

  • consolidations
  • custom groups
  • filters
  • metrics
  • reports
  • templates

In Desktop Preferences, you can determine, for each type of object, whether to be prompted for an object template when creating a new object.

If an object template is altered, the change is not propagated to previously defined objects.

Do not confuse object templates with templates. A template defines the layout of general categories of information in a report. It specifies the information to retrieve from the data warehouse and the way you want it to be displayed in the Grid view of reporting. A template does not include filters, while object templates can contain filters. Combine a template and a filter to create a report. An object template is already a report and could be run as is, without modifications. An object template is equivalent to a template in Microsoft Word, which defines templates as a special kind of document that provides basic tools for shaping a final document. An object template does not have to be a report; it can be a metric, filter, or other object as described previously.

Empty object templates

Empty object templates are a subset of object templates. The only difference between the two is that object templates contain a definition and empty object templates do not.

Empty object templates allow you to set default formatting and other properties on a project level for new reports, templates, and metrics. This helps you control new objects created in your project. For example, you can create an empty metric object template with currency formatting or an empty report object template set to outline mode. Notice that the empty object template contains properties only, not a “definition”—that is, empty metric object templates do not have formulas, empty report object templates do not include attributes, metrics, or other grid units in the report objects.

Empty object templates are saved in the Object Templates folder since they can be used only as a template.

Why would you use an empty report object template? You may have a set of properties that should be applied to each new report, but you do not want to define those properties for each report. For example, your project has a series of reports that must be exported in Excel format to a particular location. A specific Excel macro must be run after the report is exported. You can create an empty report object template, called Excel Export Settings, with these specifications. When the Excel Export Settings report is used to create a new report, the new report contains the correct information.

An empty metric object template contains formatting and other properties but does not include formulas. Like empty report object templates, they can be used as a starting point for creating objects with specific preset properties. For example, a project requires all currency values to include cents for precision and to distinguish negative values in red font. To meet these conditions, create an empty metric object template named Currency Formatting and set these formats.When a user creates a new metric that returns currency values, he selects Currency Formatting in the New Metric dialog box. The formatting for red negative values and cents is included in the new metric.

The properties available in an object template vary with the type of object.

  • An empty metric object template does not contain a formula but can contain the following properties:
    • formatting properties
    • VLDB properties
    • formula join type
    • metric join type
    • metric column properties
  • An empty report object template does not contain any grid units, that is, attributes, metrics, consolidations, and so on. An empty report contains:
    • export options
    • filters
    • formatting
    • grid options
    • report data options
    • VLDB properties
    • other settings such as merge header cells andautomatic column width
  • An empty template object template is similar to an empty report object template.

You can also set a project default for the empty object templates. This means that if a user chooses Do not show this window again in the New Grid or New Metric dialog box, the default object template is used. This setting is found in project configuration.

Another project configuration setting, Show empty template, controls whether the object template named Empty Report, Empty Template, or Empty Metric is displayed. When a user selects one of these object templates in the New Grid or New Metric dialog box, the object template does not really exist, as an object. Instead, it is created dynamically using a set of default properties. In contrast, when you use an object template, even if it is empty, it is a static object. Regardless of the Show empty template setting, your object templates are displayed.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Microstrategy Topics