Microstrategy Document Editor Sections Important Notes:

The Layout area is in the center of the Document Editor interface and provides the framework for precisely controlling where controls (such as text fields, grid and graph reports, images, and widgets) are displayed when the document is viewed in different display modes, printed, exported, emailed, and so on.

To add data to the document, drag objects from the Dataset Objects panel and drop them into the Layout area. Controls are rendered differently depending on what section they are placed in, as described below:

Page Header: The control is displayed at the top of each page in the document. By default, if a document contains multiple layouts, the same Page Header is displayed for all layouts in the document. You can change this setting so that each layout has a separate Page Header.
Document Header: The control is displayed once at the beginning of the document, immediately below the Page Header section. Any data fields placed in the Document Header are calculated using all of the data in the document. The Document Header can be used for grand totals and document information, such as the name and execution time. If a document contains multiple layouts, the Document Header is replaced by the Layout Header, described below.
Layout Header: The control is displayed once at the beginning of the layout, immediately below the Page Header section. Any data fields placed in the Layout Header are calculated using all of the data in the layout. For example, a metric in the Layout Header displays as a grand total. If a document contains only a single layout, the Layout Header is replaced by the Document Header, described above.
Group Header: In Design Mode, this type of section is displayed as Group Header, where Group is replaced by the name of the report object used to group data in the document (for example, Region). There is a corresponding Header and Footer for each group in the Grouping Panel . You can place controls in the Grouping Headers to display information about groups in the document, such as the name of the group element (such as Northeast or Southwest) or group totals. The order of the Group Header sections corresponds to the order of the items in the Grouping panel.
Detail Header: The control is displayed immediately before the Detail section and after the Document, Layout, and Header sections (if applicable). The Detail Header is commonly used to display column headings above their corresponding data fields in the Detail section.
Detail: One row containing the control is displayed for each row of data in the document's dataset. The Detail section typically provides the most detailed or granular information in the document; the Detail section is also where most of the attributes, metrics, and main content are placed. You can place a Grid/Graph anywhere in a document except in the Detail section.
Detail Footer: The control is displayed immediately following the Detail section. The Detail Footer section is often used to display totals.
Group Footer: In Design Mode, this type of section is displayed as Group Footer, where Group is replaced by the name of the report object used to group data in the document (for example, Region). There is a corresponding Header and Footer for each group in the Grouping Panel. Group Footers are often used to display totals at the group level. The order of the Group Footer sections corresponds to the order of the items in the Grouping panel.
Layout Footer: The control is displayed once at the end of the layout, immediately above the Page Footer section. Any data fields placed in the Layout Footer are calculated using all of the data in the layout. It can be used to display closing notes, a conclusion, or a summary. If a document contains only a single layout, the Layout Footer is replaced by the Document Footer, described below.
Document Footer: The control is displayed once at the end of the document, immediately above the Page Footer section. This section is often used to display information such as closing notes, a conclusion, or a summary. Any data fields placed in the Document Footer are calculated using all of the data in the document. If a document contains multiple layouts, the Document Footer is replaced by the Layout Footer, described above.
Page Footer: The control is displayed at the bottom of each page in the document. This section is often used to display the page number, or the date and time. By default, if a document contains multiple layouts, the Page Footers are shared for all layouts in the document. You can change this setting so that each layout has a separate Page Footer.

You can display the Group Header, Detail Header, Detail, Detail Footer, and Group Footer sections horizontally across the page, instead of vertically.

The Layout area provides an alignment grid to help you control the placement and alignment of controls. You can change the density of the grid by defining the Alignment grid density in the Report Services preferences in the User Preferences.

Note: If your layout expands past the width of a single page, a dotted line is displayed to show the page break.

Example of a grid report displayed in the Layout area

More details from MSTR: https://doc-archives.microstrategy.com/producthelp/10.6/DocCreationGuide/WebHelp/Lang_1033/Content/DocumentCreationGuide/Understanding_and_working_with_document_sections.htm

Comments

MicroStrategy URL API Parameters

MicroStrategy URL Structure The following table summarizes the root URL structure used for every request to MicroStrategy Web. Environment Main Application URL Administration URL J2EE http://webserver/MicroStrategy/servlet/mstrWeb http://webserver/MicroStrategy/servlet/mstrWebAdmin .NET http://webserver/MicroStrategy/asp/Main.aspx http://webserver/MicroStrategy/asp/Admin.aspx Every request sent to MicroStrategy Web calls a central controller. Parameters are appended to Main.aspx or mstrWeb (in a .NET and J2EE environment, respectively) to indicate to the controller how the request should be internally forwarded and handled. The following examples show a URL for accessing a MicroStrategy folder when the user does not have an existing session. The URL contains not only the parameters needed to connect to MicroStrategy Web, but also the parameters needed to log on and create a session. J2EE environment: <a href="http:...

Multi-Table Data Import(MTDI) from one or more supported data sources

Multi-Table Data Import(MTDI) from one or more supported data sources In MicroStrategy Analytics Enterprise Web 10 onewards, users can now simultaneously import two or more tables from one or more supported data sources, this feature is called Multi-Table Data Import (MTDI) which has been renamed as Super Cubes in MSTR 2019 (Does it sound like multisourcing for all the users without admin help?) Currently, all connectors in MicroStrategy Web 10 except " OLAP " and " Search Engine Indices " support Multi-Table Data Import. Users are able to add multiple tables/files when doing data import from single connector, as shown below: Users are also able to combine multiple tables/files from different sources and store them into one single Intelligent Cube, as shown below:

Case functions Microstrategy

Ca se functions Microstrategy Case functions return specified data in a SQL query based on the evaluation of user-defined conditions. In general, a user specifies a list of conditions and corresponding return values. Case This function evaluates multiple expressions until a condition is determined to be true, then returns a corresponding value. If all conditions are false, a default value is returned. Case can be used for categorizing data based on multiple conditions. This is a single-value function. Syntax Case ( Condition1 , ReturnValue1 , Condition2 , ReturnValue2 ,..., DefaultValue ) Example Case(([Total Revenue] < 300000), 0, ([Total Revenue] < 600000), 1, 2) sum(Case (Day@DESC in (“Sat”,”Sun”), Sales, 0) {~+} Sum(Case(Category@DESC In("Books","Electronics"),Revenue,0)){~+} CaseV (case vector) CaseV evaluates a single metric and returns different values according to the results. It can be used to perfo...

The logical table size calculation in Microstrategy

The logical table size calculation in Microstrategy The logical table size is an integer number that represents the granularity or level of aggregation of a particular table. It is called 'logical' because it is not related to the physical size of the tables (number of rows). It is calculated according to the attribute IDs that are present in the table and their level in the system hierarchy. Even though, the number does not reveal the actual number of rows in the table, it is an accurate way of measuring a table size without having to access its contents. MicroStrategy Engine utilizes an algorithm based on attribute keys to calculate the Logical Table Size (LTS): Given the following tables: The algorithm that calculates the table sizes performs the following steps: Calculate the number of levels per hierarchy: Hierarchy 1: 3 Hierarchy 2: 4 Calculate each attribute individual weight according to the level in the hierarchy (level in hierarchy/number of ...

Disable data blending in MicroStrategy

Disable data blending in MicroStrategy Starting in MicroStrategy 9.4 data blending was made available for documents and dashboards. This permits grid, graph and widget objects to source data from multiple different datasets at the same time. This is available under the analytical engine VLDB properties inside of project configuration. The property is named "document grids from multiple datasets" and defaults to enabled but can be set to disabled. Below are the steps to enable/disable the settings of data blending: 1. Go to project configuration by right clicking on specific project(You need admin rights to do this). 2. In the Project configuration windows as shown below select Configure under Project level VLDB settings section. 3. Now it will open the VLDB settings window, select + on " Analytical Engine Settings " and then click on " Document Grids from multiple datasets " option. You will be presented with two...

mstrio – Python and R wrappers for the MicroStrategy

mstrio – Python and R wrappers for the MicroStrategy REST APIs Connecting to MicroStrategy Create a connection to the Intelligence Server using Connection() and  connect() in Python and R, respectively. Required arguments for the   Connection()  function are the URL for the MicroStrategy REST API server, MicroStrategy Intelligence Server username and password, as well as the MicroStrategy project name. By default, the  connect()  function anticipates your MicroStrategy Intelligence Server username and password. LDAP authentication is also supported. Use the optional argument  login_mode=16  in the  connect()  function for LDAP authentication. Extract data from cubes and reports To extract data from MicroStrategy cubes and reports, use the get_cube()  and  get_report() functions. Use...

Microstrategy Dossiers explained

Microstrategy Dossiers With the release of MicroStrategy 10.9, we’ve taken a leap forward in our dashboarding capabilities by simplifying the user experience, adding storytelling, and collaboration.MSTR has evolved dashboards to the point that they are more than dashboards - they are interactive, collaborative analytic stories . Ultimately, it was time to go beyond dashboards, both in concept and in name, and so the've renamed VI dashboards to ‘ dossiers ’. Dossiers can be created by using the new Desktop product or Workstation or simply from the Web interface which replaces Visual Insights. All the existing visual Insights dashboards will be converted to Dossiers With MicroStrategy 10.9, there was an active focus on making it easier to build dashboards for the widest audience of end users. To achieve this, some key new capabilities were added that make it easier to author, read, interact and collaborate on dashboards ...

Components of the MicroStrategy Engine

Components of the MicroStrategy Engine The MicroStrategy Engine consists of three engines: • SQL Engine • Query Engine • Analytical Engine These individual engines work together to fulfill report requests submitted by MicroStrategy that can be resolved by pure SQL alone. The SQL Engine is responsible for generating optimized SQL and producing result sets that can be resolved by pure SQL alone. The Query Engine is responsible for executing the SQL generated by the SQL Engine. The Analytical Engine is responsible for performing any calculation that cannot be resolved with SQL alone.

Command Manager Scripts in Microstrategy to create a user

Command Manager Scripts in Microstrategy to create a user and add to a group CREATE USER "LDAPID" FULLNAME "FirstName LastName" NTLINK "\DOMAIN\LDAPID" PASSWORD "123456" ALLOWCHANGEPWD TRUE ALLOWSTDAUTH TRUE CHANGEPWD FALSE PASSWORDEXP NEVER; ADD USER "LDAPID" TO GROUP "Project Name";

Types of result caches in Microstrategy

Types of result caches Microstrategy The following types of result caches are created by Intelligence Server: • Matching caches • History caches • Matching-History caches • XML caches All document caches are Matching caches; documents do not generate History caches or XML caches. Intelligent Cube reports do not create Matching caches. Matching caches Matching caches are the results of reports and documents that are retained for later use by the same requests later on. In general, Matching caches are the type of result caches that are used most often by Intelligence Server. When result caching is enabled, Intelligence Server determines for each request whether it can be served by an already existing Matching cache. If there is no match, it then runs the report or document on the database and creates a new Matching cache that can be reused if the same request is submitted again. This caching process is managed by the system administrator and ...

Microstrategy Analytics

Search This Blog