Skip to main content

MSTR Passthough Functions; Applysimple, ApplyComparison, Applyagg, ApplyOlap

Database Passthrough Functions


MicroStrategy’s unquestionable strength is it’s SQL Engine. The ability to define an object layer over your data that empowers end users with no technical knowledge of the data structure to build any report is truly remarkable. Of course, it’s still just a set of options, and while it accomplishes probably 90% of use caes that you’d ever need, there’s still some room left for cases that it just doesn’t support (or support efficiently). MicroStrategy adds functionality over time through releases, but fortunately we don’t have to wait. Thankfully there are functions that allow us to slightly modify the behavior of objects by directly providing a snippet of SQL but without compromising the overall usefullness of the engine like we would if we turned to a full Freeform SQL Report. You’ve probably used one or two, but did you know there are five?
ApplySimple

This is the most common function, as you can use it in an Attribute definition. The only real limitation is that you can only reference columns from the same physical table (though you can get around that limitation by using Logical Views). Some things you can do with ApplySimples include Embedding HTML in Attributes, performing dynamic grouping similar to a Custom Group but with better performance, and building a fancy filter.
Filtering

You can drag an attribute into a filter like normal, choose an Attribute Form (like it’s ID), but instead of choosing the methods “Exactly” or “Elements in List”, you can choose “Custom”. This will allow you to type the ApplySimple function and write whatever SQL snippet you want. I generally use this trick if I need to set an ID equal to the results of a subselect, usually the result of a Max or a Join. MicroStrategy can generally generate this type of SQL, but I find using this method usually comes out with more efficient SQL, especially compared to using a Set Qualification Filter.
ApplyComparison

This type of passthrough can be used to create flexible filters. While this feature is similar to using an ApplySimple in a filter, the difference is that you can customize both sides of the condition, whereas with the ApplySimple you can only customize one side to be equal to a single Attribute Form.
ApplyAgg

This useful function is used in Metrics, and counts as aggregation. If you need to do some fancy aggregation or use a database function that MicroStrategy doesn’t natively support, this is your tool. Keep in mind that whatever you put inside an ApplyAgg will NOT be grouped by, so make sure that the SQL output will be valid.
Adaptive Metrics

A great example of the power of ApplyAgg is through the creation of Adaptive Metrics. These are metrics that use different aggregation functions at different levels. For example, you may need to do a Count() in the detail table and a Sum() in the aggregate table. One way to accomplish this is to use ApplySimple’s in the Fact creation to embed the aggregation function into the fact definition, and then use an ApplyAgg in the Metric. Since an ApplyAgg satisfies MicroStrategy’s need for an aggregation function, this results in the Fact controlling it’s own aggregation. Follow this tech note for the details to build your own. A neat trick!
ApplyOLAP

ApplyOLAP is used to define compound metrics. Despite the name, it only support Database Specific OLAP functions like Rank, Tile and RunningSum (assuming your DB supports those). The resulting metric is an OLAP metric. Personally, I’ve never used this one before and can’t even think of a use case for when you would.
ApplyLogic

This is a logical function that allows you to pass a condition down to the database level to conditionally return a value. Traditionally, we use the IF and CASE functions built into MicroStrategy for this, but if there is some special kind of comparison function you have (most likely a custom function you’ve built on your DB), then this would be an easy way to call it.
There aren’t any tech notes or documentation in the Product Manuals for ApplyOLAP or ApplyLogic, so if you have any tips or experience with them, feel free to share.

Comments

Popular posts from this blog

Types of prompts in Microstrategy

Types of prompts in Microstrategy The different types of prompts allow you to create a  prompt  for nearly every part of a report. Prompts can be used in many objects including reports, filters, metrics, and custom groups, but all prompts require user interaction when the report is executed. The correct prompt type to create depends on what report objects you want users to be able to base a filter on to filter data, as described in the list below. Filter definition prompts   allow users to determine how the report's data is filtered, based on one of the following objects: Attributes in a hierarchy : Users can select prompt answers from one or more attribute elements from one or more attributes. The attribute elements that they select are used to filter data displayed on the report. This prompt lets you give users the largest number of attribute elements to choose from when they answer the prompt to define their filtering criteria. For example, on a repor...

Microstrategy "Error type: Odbc error. Odbc operation attempted

 "Error type: Odbc error. Odbc operation attempted: SQLExecDirect. [HYT00:0: on SQLHANDLE] [MicroStrategy][ODBC Oracle Wire Protocol driver]Timeout expired" is shown when executing reports from Web When users are trying to execute some reports in MicroStrategy web in particular, they may receive the Error “SQL Generation Complete Index out of range” and “Timeout expired” error as shown below: Possible Causes: One possible cause is that the MicroStrategy Intelligence Server using a cached database connection that was already dropped by the RDBMS. To resolve this: Admin should delete the database connection caches and create a new DSNs in case they are sharing DSNs to connect to different databases. In addition, change the settings for the ‘Connection lifetime’ and the ‘Connection idle time out’.  Follow the steps below to perform the mentioned changes and verify the report after each step and some of the settings require i-server r...

Create an alert-based subscription in MicroStrategy Distribution Services

Create an alert-based subscription in MicroStrategy Distribution Services on Web Subscription to a report or Report Services document which will be executed when a certain conditional threshold is met based on another executing report. For example, a scheduled report executes which shows the Revenue by day for the past week. If the Revenue on any one day falls below a certain value, a subscription to another report or Report Services document can be triggered and delivered to a recipient. An alert based subscription can only be created directly on a report; however, another report or Report Services document can be delivered when the alert based subscription is triggered. Note: you need a grid report to create an alert and you cannot create if you want to create on a document with text boxes. The following example will walk through the basic steps on how to setup a subscription based on an alert like this: Follow the brief  steps bel...

Settings for Outer Join between metrics in MicroStrategy

Settings for Outer Join between metrics in MicroStrategy MicroStrategy adopts multi-pass logic to determine the execution plan for a report. This means that every metric is evaluated in separate SQL passes. Outer Joins come into play when MicroStrategy Engine merges the results from all SQL passes into one report. For a multi-pass report, different Outer Join behaviors can give the user completely different results. In addition, report metrics can be of different types which can, in some cases, influence the result of the outer join. In MicroStrategy, there are two settings that users can access to control Outer Join behavior : Formula Join Type and Metric Join Type . Metric Join Type: VLDB Setting at Database Instance Level Report and Template Levels Report Editor > Data > Report Data Options Metric Level   Metric editor > Tools > Metric Join Type Control Join between Metrics Formula Join Type: Only at Compound/Split...

Customers Who Live in the Same City as Call Centers

Customers Who Live in the Same City as Call Centers Your new utility company has call centers located throughout the country, and your recent surveys indicate that customers who live in the same city as a call center are particularly satisfied with service due to extremely rapid repairs during power outages. To begin your new advertising campaign, you want to generate a list of Call Centers that coincide with Customer Cities. The following steps create an attribute-to-attribute qualification filter that generates the list of desired cities. To Create an Attribute-To-Attribute Qualification that Compares the Call Center and Customer City Attributes In MicroStrategy Web, log in to a project. Open any folder page (for example, click Shared Folders on the home page). Click the  Create Filter  icon  . From the Object browser on the left, select the  Customer City  attribute from the Customers hierarchy and drag it to the filter pane on the right. Change  Qualify...

Metadata Doctor (MD Doctor) in Microstrategy

Metadata Doctor (MD Doctor) in Microstrategy Metadata Doctor (MD Doctor) is a utility that detects and fixes certain physical inconsistencies in MicroStrategy 9.4.x - 9.5.x metadatas that may prevent MicroStrategy 9.4.x - 9.5.x products from functioning correctly.  In simple terms, it detects physical inconsistencies by running SQL against different metadata tables and then comparing results.  If an entry is found in one table but not in the main lookup table of the metadata then that denotes a physical inconsistency and MD Doctor will  delete  that orphan entry.  Note:  MD Doctor is not a supported tool for MicroStrategy 10.x metadatas. NOTE:   MD Doctor should be used only after a metadata backup has been taken.  MD Doctor should not be used repeatedly.  It is meant to primarily serve as a quick-fix to physical inconsistencies and get environments up and running.  If repeated use of MD Doctor is needed then ...

Algorithm to calculate Logical Table Size in Microstrategy

How are the fact tables determined using the logical table size for SQL generation 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.   IMPORTANT:   The system hierarchy is defined by the parent-child relationships between attributes of the same family (formerly known as a dimension), not by user-defined hierarchies (i.e., drilling hierarchies).   MicroStrategy Engine utilizes an algorithm based on attribute keys to calculate the Logical Table Size (LTS): Given the following tables: ...

Microstrategy Removing sections that do not have metric data

Removing sections that do not have metric data This is an interesting feature which might not be explored by many of us and it comes us handy. A  cross join between datasets can result in rows or Group Header/Footer sections that do not have metric data. For example, a document contains two datasets. Dataset 1 contains Year and Revenue, with data for three years (2007-2009). Dataset 2 contains Year and Profit, filtered to return data for only two years (2008 and 2009). If you place Year and Profit in the Details and execute the document, it displays three rows, although no profit data exists for 2007. This is a product of the cross join between the two datasets. You do not want to see the blank line for 2007 since it does not give you any data for profit. You can select the  Trim sections for which no metric value data is available  check box. This removes the row for 2007, since no metric data for Profit is available for 2007. The results are shown below: ...

MicroStrategy Hadoop Gateway operation modes

MicroStrategy Hadoop Gateway operation modes MicroStrategy Hadoop Gateway is a native connector which was built based on Spark 1.6.x. You can choose one or more data files from Hadoop HDFS and load them into MicroStrategy Intelligence Server. Data files can be published as either an In-Memory Cube or a Live Connect Cube. MicroStrategy Hadoop Gateway supports three operation modes : YARN client Standalone (HDP cluster does not support Standalone) Local YARN client mode: The driver runs in the client process, and the application master is only used for requesting resources from YARN. Running in this mode requires YARN service to be enabled on your Hadoop cluster. Standalone mode:  MicroStrategy Hadoop Gateway uses Spark Master to coordinate data processing. Local mode:  no application is deployed in the Spark nodes. All data processing is executed in the MicroStrategy Hadoop Gateway host. This modality is intended for testing and troubleshooting.

Compound key attribute

Compound key attribute A compound key attribute is an attribute whose primary key is made up by the combination of two or more columns. The multiple columns are joined with other attributes, typically in a many-to-many relationship . To create a compound key, users must create multiple attribute forms, group them together and set the form group as the key for the attribute. Use the same steps as specified in the help menu: Open attribute editor (right-click on attribute and select 'Edit') Select the forms that will make up the compound key From the 'Edit' menu, choose 'Group' NOTE: Modifying the key form will trigger required updates when saving. This may make related application objects (reports, filters and metrics) unusable. Click on 'Yes' to continue, when prompted, in a dialog box, to confirm this action Save the changes. Choose 'Update Schema' from the Schema menu