Skip to main content

"System Prompt" and its uses in MicroStrategy

System Prompt and its uses in MicroStrategy


WHAT IS A "SYSTEM PROMPT"?
"System Prompt" is a system object that was introduced back in version 8.0.0. The object is named as "User Login" and is implemented as a prompt object. The object can be found under Public Objects > Prompts > System prompts, as shown below:

Unlike ordinary prompt objects, system prompts don't require any answers from the user. When a report containing a system prompt runs, the prompt is answered automatically with the login of the user who runs the report. On the other hand, like other prompt objects, answers to system prompts are used to match caches. Therefore, users don't share caches for reports that contain system prompts. For details on how caches are matched, refer to the following MicroStrategy Knowledge Base document:
  • KB5300-7X0-0147 - How are caches matched in MicroStrategy Intelligence Server 7.x?
WHEN ARE SYSTEM PROMPTS USED? 
 
System prompts provide users more flexibility in implementing the security mechanisms of MicroStrategy applications. The following three examples demonstrate how system prompts can be used:

  • The security filter definition process is more simple with system prompts

    A report displays employee information and each manager can only view the information of those employees which the manager supervises. In MicroStrategy 7.x.x, security filters are static; multiple security filters must be defined and assigned to each manager user accordingly. The security filters is defined as follows:

    Manager = "Jane Doe"
    ….
    Manager = "Tom White"

    In MicroStrategy 8.0.0, security filters can be defined in a more dynamic way. For the example described above, only one security filter is necessary and it is defined as:

    Manager = ?

    This security filter can be assigned to a Manager user group. When a user with login "Jane Doe" executes the report, the security filter will generate SQL for condition:

    Manager = 'Jane Doe'
     
  • Report level "security filter" can be implemented

    In MicroStrategy 10.x, security filter functionalities can be implemented at report level by defining report filters with a system prompt. For instance, the Manager = ? condition can be used to define a report filter and users can include that report filter in certain reports but not others. In this way, security is enforced at the report level, not the project level.
 
  • Database tables containing security information can be used

    To synchronize security constraints for all enterprise applications, some organizations maintain security information in database tables and build all enterprise applications based on security tables. With system prompts, it is possible to use database security tables to build MicroStrategy security mechanisms.
     
    Example:

    In the database warehouse, there is a table called SecurityRegion, with two columns, Region_ID and User_ID. SecurityRegion table defines from which region a user is allowed to view data. Using system prompts, users can use SecurityRegion table to create a report with a restriction on regions. MicroStrategy Tutorial project is used in the following example to illustrate this:
    1. Define an attribute qualification filter, Security_Filter_APPLY, as shown below:

      ApplyComparison ("#0 in (select Region_ID from SecurityRegion where User = #1)", Region@ID, ?)
      1. Create a report with the Region attribute on the template and Security_Filter_APPLY as the report filter.
      2. Login as 'Administrator' user. View SQL and notice that only the regions the administrator are allowed to view are returned:
        select a11.Region_ID Region_ID, a11.REGION_NAME REGION_NAME
        from LU_REGION a11
        where a11.Region_ID in
            (select Region_ID from SecurityRegion where User = 'Administrator')
        1. Login as 'Brian Kelt.' SQL for the same report changes to:
          select a11.Region_ID Region_ID, a11.REGION_NAME REGION_NAME
          from LU_REGION a11
          where a11.Region_ID in
              (select Region_ID from SecurityRegion where User = 'Brian Kelt')

      Comments

      Popular posts from this blog

      Microstrategy Custom number formatting symbols

      Custom number formatting symbols If none of the built-in number formats meet your needs, you can create your own custom format in the Number tab of the Format Cells dialog box. Select  Custom  as the Category and create the format using the number format symbols listed in the table below. Each custom format can have up to four optional sections, one each for: Positive numbers Negative numbers Zeros Text Each section is optional. Separate the sections by semicolons, as shown in the example below: #,###;(#,###);0;"Error: Entry must be numeric" For more examples, see  Custom number formatting examples . To jump to a section of the formatting symbol table, click one of the following: Numeric symbols Character/text symbols Date and time symbols Text color symbols Currency symbols Conditional symbols Numeric symbols For details on how numeric symbols apply to the Big Decimal data type, refer to the  Project Design Guide . ...

      Slowly Changing Dimension Types 0, 4, 5, 6 and 7

      Slowly Changing Dimension Types 0, 4, 5, 6 and 7 Ralph introduced the concept of slowly changing dimension (SCD) attributes in 1996. Dimensional modelers, in conjunction with the business’s data governance representatives, must specify the data warehouse’s response to operational attribute value changes.  Core SCD approaches:  Type 1 (overwrite),  Type 2 (add a row), and  Type 3 (add a column).  Since legibility is a key component of the Kimball mantra, we sometimes wish Ralph had given these techniques more descriptive names, such as “overwrite” instead of “type 1.” But at this point, the SCD type numbers are part of our industry’s vernacular. We have written about more advanced SCD patterns, such as the 2005 article entitled “ Slowly Changing Dimensions are Not Always as Easy as 1, 2, 3. ” However, we’ve not consistently named the more advanced and hybrid techniques. With the third edition of  The Data Warehouse Toolkit  (Wiley, 201...

      Internationalization Design Technics

      Microstrategy Internationalization Design Technics MicroStrategy supports data internationalization through two different techniques. You can either provide translated data through the use of extra tables and columns, or you can provide separate databases to store your translated data. These techniques are described below: You can support data internationalization in your database by using separate tables and columns to store your translated data. You can use various combinations of tables and columns to support and identify the translated data in your database. To support displaying the name of each month in multiple languages, you can include the translated names in a separate column, one for each required language, within the same table. Each column can use a suffix to identify that the column contains translated data for a certain language. The same LU_MONTH_OF_YEAR table with translated data for the Spanish and German langua...

      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...

      Custom Subtotal Displays in MicroStrategy

      Defining custom subtotal displays in MicroStrategy By default, when users apply subtotals in a report, the name of the subtotal is displayed in the subtotal line items that appear in the report. Users can use custom subtotals to give more control over the characteristics of a subtotal. Custom subtotals allow users to define custom subtotal line items that appear on the reports  U sers can make the subtotal name dynamic by typing special characters in the subtotal name field as listed in the following table. Character Description #A The name of the attribute under which the subtotal appears. #P The name of the attribute to the left of, or above the attribute under which the subtotal appears. #0 All the forms of the parent element. #1 The first form of the parent element reading from left to right or from top to bottom. #2 The second form of the parent element reading from left to right or from top to bottom. #3 The third form of th...

      Configure a report for use with Bulk Export in MicroStrategy

      Configure a report for use with Bulk Export in MicroStrategy The Bulk Export feature enables a large report to be saved as a delimited text file. Using this feature, it is possible to retrieve result sets from a large dataset without having to load the entire dataset into memory. PS:  Once a report is setup for bulk export it cannot be used as a regular report. So if the report needs to be run as a normal report and as a bulk export report, the first step is to make a copy of the report for use with bulk export. Configure Bulk Export Bulk Export options are only available in MicroStrategy Developer. Open a 3-tier connection using MicroStrategy Developer and edit the desired report. Go to 'Data' on the top menu bar. Select 'Configure Bulk Export': Specify any additional desired configuration options. General Settings Bulk export database instance : This is the database instance to use to store the bulk export results. Temporary tables w...

      Configure Connection Mapping in Microstrategy

      Configure Connection Mapping in Microstrategy The following steps demonstrate the second scenario where two different data warehouses are used within the same project: Create two different database connections -                                                                                        One that points to the data warehouse for the European users                                                                 and the other that points to the data warehouse for USA users as shown below: Select Europe as the default database connection for the database Instance as seen below: Go to P...

      Sort by metric subtotals and attribute elements together in Microstrategy

      Sort by metric subtotals and attribute elements together in Microstrategy Users may observer that when creating a report that contains advance sorting with a metric that contains subtotals the report results appear to be only sorted by the metric values specified. Even if a sort is specified for the attribute elements on the report, the results in the report appear as if the attribute sort was not defined. In the screenshot below, the results for a report are shown where the Advance Sorting option 'Sort metrics hierarchically using: Total' is selected. For this report, a second sort is defined on the Customer Gender - 'DESC' form, users would notice that the ordering of the this attribute is not consistent: The sort definition for the report is shown below: CAUSE: When the option to 'Sort metrics hierarchically using: Total' option is selected, the MicroStrategy Engine first sorts the results based on the Total values, and then sorts th...
      Star schemas and aggregate (or summary) fact tables Aggregate tables can further improve query performance by reducing the number of rows over which higher-level metrics must be aggregated.  However, the use of aggregate tables with dimension tables is not a valid physical modeling strategy. Whenever aggregation is performed over fact data, it is a general requirement that tables joined to the fact table must be at the same attribute level or at a higher level. If the auxiliary table is at a lower level, fact rows will be replicated prior to aggregation and this will result in inflated metric values (also known as "multiple counting"). With the above Time dimension table, a fact table at the level of Day functions correctly because there is exactly one row in DIM_TIME for each day. To aggregate the facts to the level of Quarter, it is valid to join the fact table to the dimension table and group by the quarter ID from the dimension table. Sql select DT...

      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 ...