Thursday, February 28, 2013

[MSTG] Applying Selections As Filters Or Slices

 


Applying selections as filters or slices




Filtering 

Data for the current selection is calculated only when it is requested by the user. The selections are used to filter the underlying dataset before the metric values are aggregated at the level of the Grid/Graph that is displayed in the document. If the source attribute is not included in the Grid/Graph, the metric values from all the selected elements are aggregated and shown at the level specified in the Grid/Graph.


Slicing 

Data for each available item in the selector is calculated in advance when the document is first displayed. Selections made while viewing the document are used to determine which slices of data are combined and shown in the Grid/Graph. 

Even if the source attribute is not included in the Grid/Graph, the data is still sliced at the level of the source attribute, and therefore the metric values from multiple selected items are not added together. Instead, the data for each selected element is shown separately in the Grid/Graph, the same as if the source attribute had been included in the Grid/Graph.




For example:

The dataset report of a document contains Region, Year, and the Revenue metric. A Grid/Graph displays Year and Revenue only, and is targeted by a selector with Region as its source. The selector is defined to slice the data. When Central is selected, three rows, one for each year, are displayed, as shown below:



If you select Mid-Atlantic as well as Central, six rows are displayed, two for each year, as shown below



This occurs because the selector slices the data by region before the user selections are made, and cannot aggregate the slices for multiple regions.

If you change the selector to filter rather than slice the data, the yearly revenue is aggregated across the selected regions. The yearly revenue is calculated by adding the Central and Mid-Atlantic values for each year, and only one row for each year is displayed in the Grid/Graph, as shown below:




Other important differences between filtering and slicing selectors are described below:

1) Slicing allows the total to be displayed as an item in the selector. A filtering selector does not display the total as a selector item.

2) Slicing allows you to specify that the selector automatically uses a default selection when other changes in the document cause the selection made by the user to return no data.

3) If a selector is sliced, you can define the current state, which determines how the target is displayed when the document is executed. The target can display all the selector items, a specific number of the first items in the selector, or a specific number of the last items in the selector. If a selector is filtered, you can define the current state as unset only, which displays all the selector items.



When a document is viewed off-line (exported to Flash, in a subscription, or in MicroStrategy Office):

1) If a selector is applied using filtering, only the data for the current selections are included in    the document. An off-line user cannot change the selector and update the target.

2) If a selector is applied using slicing, all the slices, and therefore all the data, are included in the document. An off-line user can change the selector and update the target.

3) To continue with the yearly regional revenue document described above, the selector is applied as a filter. Only Central is selected, and the document is exported to an MHT file to be used off-line, without using MicroStrategy. The MHT file contains only the data for Central, and no other selections can be made.

4) If the selector is applied as a slice instead, all the data is sliced and included in the MHT file. Even if only the Central region is selected when the document is exported, you can use the selector in the MHT file and display other regions.




[MSTG] Execute Command Manager Scripts

 

 Execute command manager scripts





Command manager is a MicroStrategy tool which could be used for many tasks. Command manager scripts are executed against the metadata repositories to perform certain tasks, like user creation, listing all the users, purging report caches, updating schema and so on.


Executing a command manager script - End-to-End explanation.


For our exercise, lets run a script to get the list of all the report caches in a given project.
 

Open Command Manager (Programs /MicroStrategy /Administrator /Command Manager)

Connect to the project source as shown below.



Click on "Insert Outline"



Note : These are command outlines. In simple words, they can be treated as examples.


The "Choose Outline" window open with list of all the commands organized in folders.

Expand the "Cache Outline" folder, select "List_Report_Caches_Outline" and click on insert as shown below.




Modify the displayed command as you need and click on execute. Below is an example where "BI Reporting" is the name of the project.
 



Once the command is executed successfully, you will see the names of the caches deleted in the results pane.
 

This is one simple example on using command manager. You can select any outline you want and perform the same steps to execute the command.


Command manager scripts can also be executed from the command line, from version 8.x. As they can be executed from command line, batch file can be created and scheduled to achieve certain tasks.





[MSTG] Security Model



MicroStrategy Security Model


The MicroStrategy security model techniques control the following aspects of your BI implementation

             1.Access to the data coming from the database
             2.Access to the functionality
             3.Access to meatadata objects
 
MicroStrategy provides the following security features to implement access control to database data

Connection mapping

Pass-through execution

Security filters


Connection Mapping : By default all users in a microstrategy project use the same database connection(DSN) and database login when connecting to the database,which is defined by the database instance you assigned to the project.This means that all users have the same security level on the database side No Connection Mapping-Different MicroStategy 

Requests Appear as coming from the Same Entity

You use connection mapping to differentiate MicroStategy users from each other at the datawarehouse level or if you need to direct them to separete data warehouses.
Connection mapping is not required.

YOu create it and assign it to users or groups only if your environment can benefit from it.

Connection mapping enables you to leverage existing security views defined in the data warehouse when using MicroStategy.Consider the following scenario as an

Example:
Connection mapping also enables you to map users to different warehouses in a single project.

 
Pass through Execution
 
Pass through execution is an alternative to the connection mapping method.with pass through execution,you can link a MicroStrategy user to a database user.Every time the MicroStrategy user requests an execution against the warehouse,the database user credentials linked to him are applied

 
Security Filters
 
A security filter is a filter object that you assign to users or groups to restrict the result set when they execute reports or browse elements.security filters enable you to control,at the MicroStrategy level,what warehouse data users can see.The criteria specified by the security filter is added to the WHERE clause of every SQL pass,for all the reports the user executes.
Ex:Two regional managers have each their own security filters,according to the regions that they manage-one with Northeast and the other with Southeast.when these two regional managers run the same report,they may get different results 


Report Executed by a User without Security Filter

The user without a security filter can see all the regions avaliable in the warehouse,since there are no restrictions in the SQL clause.


Report Executed by a User with Security Filter = Northeast

The user with a security filter on the Northeast region can only see data for this specific region.The WHERE clause on the SQL impose this restriction

 
Controlling the Access to Functionality
 
We can also control the access to application functionality,such as the ability to read,modify or delete an object or the ability to create reports,use OLAP services,log in to MicroStategy Web and so forth.The microstategy system provides a rich set of security settings to enable you to control the users' access to the functionality:

privileges-Define the actions the user can perform

Security roles-Define sets of privileges

Permissions-Control access to objects

 
Privileges—Defining Actions Users Can Perform :
 
Privileges determine whether a user or group can perform a specific function,such as creating a report,viewing report SQL or using the administration monitors.You can grant users or groups the privileges you want them to have.Privileges can be assigned to users and groups directly or through security roles.

The difference is the Privileges assigned directly to users and groups grant functionality across all the projects in the project source

Privileges assigned through security roles grant functionality just within a specific project

Everyone,public/guest,Third Party Users,LDAP groups:No privileges

Predefined product-based groups:Privileges associated with their corresponding licenses

 
Security Roles :
 
A security role enables you to assign project-specific functions to users or groups by granting them sets of privileges on a project-by-project basis.You can also use this feature to determine whether a user or group can access a specific project.
  

Predefined Security Roles

Normal Users--It has no privileges granted and it is assigned to the everyone group.

Power Users--It has privileges that are typical for users who need access to advanced functionality in the interface.It is assigned to the System Administrator group and to the Administrator user.

Project Administrators--It is a group of several security roles that contain different sets of privileges according to the administraton role they present.For specific information about each of these security roles,see the System Administration guide.

 
Permissions--Controlling Access to Objects

Permissions define the type of access users have over individual objects or folders in the system.For example in the case of a report, a user may have permission to view the report definition and execute the report,but not to modify the report definition or delete the report

Each object and folder in the system contains an Access Control List(ACL) that specifies which permissions different sets of users have on that object.You edit an object ACL using the object's Properties window.You then assign a predefined grouping of permissions or create a custom grouping.

Types of Object Permission: view,modify,full control,deny all,default,custom
In a new MicroStrategy project,the default behavior enables users to save objects only within their personal folders.Administrative users are the only ones who can save objects within the Public Folder directory.You may change this design by assigning different object permission to the folders.Folders ina new project are created with these default ACLs


Access Control List(ACL)

The Access Control List (ACL) of an object is a list of users and groups and the access permissions that each of them has for the object.When granting permissions to objects,you must specify the following elements:

User -- Defines what users and groups can access the object

Object -- Defines the object permission for the user.For example you can assign view access for some users and modify access for other users.

Children (folders only) -- Defines the object permission for the objects that belong to that folder

The Default ACL of a newly created object has the following characteristic:

   Owner = Full Control
   Other users = Children ACL of parent folder
   New folders = ACL of parent folder
   Moved objects = Retains original ACL
   Copied objects = Inherits ACL  of children ACL of parent folder


Conflicting Permissions

If a user has permissions assigned to an object and is in a group that has a different permission grouping assigned to the object,the highest level of permission is granted to the User Permission ranked from highest level down to lowest level are listed below.The permissions at the top of the list override permissions lower down the list,when both types of permissions are assigned to a user:

Denied All--Highest level permission

The permissions with the fewest restrictions

The permissions with the most restrictions(except Denied All)--Lowest level permissions

 
Access Control Lists and Report Execution
 
In MicroStrategy,two of the permissions that can be grated on an object are Use and Execute.These two permissions have the following effects when granted to user for anObject