Tag Archives: Report

Interview Question #10: Placing Hierarchies in Report Template in MicroStrategy

Question

Which of the following about placing hierarchies in the report template is true?

A. You can only place one hierarchy in the report template.

B. The report level is always resolved to the lowest level attribute in the hierarchy.

C. You can use user hierarchies as well as the System Hierarchy on the template.

D. For the SQL Engine to resolve the level of the report, one or more attributes from the same hierarchy should be referenced in the report filter.

E. Both B and D.

 

 

 

 

 

Answer

D. For the SQL Engine to resolve the level of the report, one or more attributes from the same hierarchy should be referenced in the report filter.

 

Why the others are false

A. You can only place one hierarchy in the report template. You can place any number on the report.

B. The report level is always resolved to the lowest level attribute in the hierarchy. Since the hierarchy contains several attributes, the SQL Engine does not automatically know which attribute to place on the result set.

C. You can use user hierarchies as well as the System Hierarchy on the template. Cannot use System Hierarchy.

E. Both B and D. B is False.

MicroStrategy Course Where You Will Learn About This Topic

MicroStrategy Engine Essentials Course

Using the R Integration functionality, how to perform Text Mining on a MicroStrategy report and display the result

Readers:Jaime Perez

Here is another great post in the MicroStrategy Community from Jaime Perez (photo, right) and his team. A lot of work when into the preparation of this post and it shows some great ways to use the “R” integration with MicroStrategy.

Contributors from Jaime’s team include:

ssonobe  ssonobe

Lili 

Joanne A 

Ohingst  Ohingst

Enjoy!

Michael

Text Mining Using R Integration in MicroStrategy

Users may wish to perform text mining using R on the result of any arbitrary MicroStrategy report and display the result. One of the problems that hinders the users from achieving it is that the number of output elements is not always consistent. For example, a report may have three attributes named ‘Age groups’, ‘Reviewer’, and ‘Survey feedback’ and the report might display four rows of feedback as follows:

01.jpg

If the above report result is sent to R as an input and the R script breaks down each sentence of the feedback into the term frequency that is grouped by the age groups, it will have 18 rows.

02.jpg

Since the number of output elements is greater than the number of the MicroStrategy report rows, the report execution will fail. Using the objects in the Tutorial project, this technical note (TN207734) describes one way to display the result of text mining on a MicroStrategy report, using the R integration functionality.

PREMISE:
– Following the instructions in TN43665, the MicroStrategy R Integration Pack has already been installed on the Intelligence Server.

The Steps Involved

STEP 1: Decide on the input values that need to be sent to R via R metrics
The first step is to decide on which data you wish to perform text mining. In this technical note, the sample report will let users select one year element, the arbitrary number of category elements, and specify the Revenue amount in prompts. The report will then display the value of the normalized TF-IDF (term frequency and inverse document frequency) for every word showing up in the qualified Item attribute elements, grouped by the Category elements.

A user may select the following values for each prompt and the report may look as shown below.

  • Year: 2012
  • Category: Books, Movies, and Music
  • Revenue: greater than $15,000

03.jpg

Eventually, the user may want to see the normalized TF-IDF for every word showing up in the Item attribute elements as shown below:

04.jpg

Since the final output displays each word from the Item attribute and it is grouped by the Category elements, the necessary input values to R are as follows

  • The elements of the Category attribute.
  • The elements of the Item attribute.

 

STEP 2: Create metrics to pass the input values to R

The input values to R from MicroStrategy must be passed via metrics. Hence, on top of the current grid objects, additional metrics need to be created. For this sample report, since the inputs are the elements of two attributes, create two metrics with the following definitions so that the elements are displayed as metrics.

Max(Category@DESC) {~}

Max(Item@DESC) {~}

05.jpg

 

STEP 3: R script – Phase 1: Define input and output variables and write R script to obtain what you wish to display in a MicroStrategy report

In the R script, define (1) a variable that receives the inputs from MicroStrategy and (2) a variable that will be sent back to MicroStrategy as the output as depicted below. Since the number of output elements must match with the number of input elements, it is defined as “output = mstrInput2” to avoid the errors. In other words, this script executes R functions to obtain the data that you wish to display in a MicroStrategy report, but the output is the same as the input. More details about how to display the result in a MicroStrategy report will be followed up later in this technical note.

06.jpg

 

In this technical note, after manipulating the input value, we assume that the variable named ‘norm.TF.IDF’ in the R script holds the values of the TF-IDF for each term.

07.jpg

 

STEP 4: Create tables in the data warehouse to store the value of your R output

In order to display the values of the ‘norm.TF.IDF’ defined in a MicroStrategy report, tables to hold the result need to be created in the data warehouse. In other words, additional report will later have to be created in MicroStrategy and it will extract the data from the database tables, which are created in this section.

In this specific example, the variable ‘norm.TF.IDF’ has the elements of words (terms) and categories and the values of the normalized TF-IDF. Considering the types of data, the first two should be displayed as attributes and the values of the normalized TF-IDF should be presented in a metric. Hence, two lookup tables to hold the term and category elements and one fact table need to be created to store all the data. On top of these tables, one relationship table is also required since the relationship between words and categories is many-to-many.

 

STEP 5: R script – Phase 2: Populate the tables in your R script

As previously mentioned, the variable named ‘norm.TF.IDF’ contains the values, which a user wishes to display in a MicroStrategy report as shown below.

07.jpg

 

In this R script, four more variables are defined from ‘norm.TF.IDF’, each of which contains the subset of data that will be inserted into the database tables.

 

tm_Category holds the unique elements of the Category.

10.jpg

 

tm_Word holds the unique elements of the Word (Term).

11.jpg

 

tm_Word_Cat stores the values of the many-to-many relationship.

12.jpg

 

tm_Fact contains the values of TF-IDF for every Word-Category combination.

13.jpg

 

In the R script, populate the database tables with the above four subsets of ‘norm.TF.IDF’.

# Load RODBC
library(RODBC)

# RODBC package: assign ch the connectivity information
ch <- odbcConnect("DSN_name")

# Delete all the rows of the tables
sqlClear(ch, "tm_Category", errors = TRUE)
sqlClear(ch, "tm_Word",     errors = TRUE)
sqlClear(ch, "tm_Word_Cat", errors = TRUE)
sqlClear(ch, "tm_Fact",     errors = TRUE)

# SQL: insert the data into tables; use parameterized query
sqlSave(ch, tm_Category, tablename = "tm_Category", rownames=FALSE, append=TRUE, fast = TRUE)
sqlSave(ch, tm_Word,  tablename = "tm_Word", rownames=FALSE, append=TRUE, fast = TRUE)
sqlSave(ch, tm_Word_Cat, tablename = "tm_Word_Cat", rownames=FALSE, append=TRUE, fast = TRUE)
sqlSave(ch, tm_Fact, tablename = "tm_Fact", rownames=FALSE, append=TRUE, fast = TRUE)

#Close the channel
odbcClose(ch)

 

STEP 6: Create and add an R metric, which implements the R script

The R script is done. It is time to implement this R script from MicroStrategy by creating an R script. In the deployR interface, open the R script and define the input and output that you specify in Step 3 as follows. Since the elements of the Category and Item attributes are characters, choose “String” as its data type. Likewise, since the output is the same as the mstrInput2, its data type is also set to string.

14.jpg

 

Create a stand-alone metric and paste the metric definition of the deployR utility. Then, replace the last parameters by the Category and Item metrics that you created in Step 2.

15.jpg

 

Add the R metric to the report.

15.2.png

 

The report and R will perform the following actions after adding the R metric
i. The report lets users select the prompt answers
ii. MicroStrategy sends the Category and Item elements to R via the R metric
iii. R performs text mining to calculate the TF-IDF based on the inputs
iv. R generates subsets of the TF-IDF
v. R truncates the database tables and populates them with the subset of the TF-IDF
vi. R sends the output(which is actuary the input) to MicroStrategy
vii. The report displays the values of all object including the R metric

 

STEP 7: Create MicroStrategy objects to display the data

From the tables created in Step 4, create the Word and Category attributes and the fact named weight. The object relationship is as depicted below.

08.jpg

09.jpg

 

Now, create a new report with these objects. This report will obtain and display the data from the database tables.

16.jpg

 

STEP 8: Utilize the report level VLDB properties to manipulate the order of the report execution jobs

There are currently two reports and let each of which to be named R1 and R2 as described below

  • R1: A report which prompts users to specify the report requirements and implements the R script executing text mining
  • R2: This report obtains the result of text mining from the database and display it

 

If the two reports are placed in a document as datasets as shown below, there is one problem: R2 may start its execution before R1 populates the database tables with the result of text mining.

17.jpg

 

In order to force R2 to execute its job after the completion of R1, the VLDB properties PRE/POST statements along with additional database table may be used. The table tm_Flag contains the value of 0 or 1. R2 is triggered when R1 sets the value of completeFlag to 1. The detailed steps are described below with the script for SQL Server.

 

i. Create another table in the database, which holds the value of 1 or 0

CREATE TABLE tm_Flag
(
   completeFlag int
)


INSERT INTO tm_Flag VALUES(0)

 

ii. In the VLDB property ‘Report Post Statement 1” of the R1 report, defines a Transact-SQL statement that changes the value of completeFlag to the value of 1.

DECLARE @query as nvarchar(100)
SET @query = 'UPDATE tm_Flag SET completeFlag = 1'
EXEC sp_executesql @query

 

iii. Define the VLDB property ‘Report Pre Statement 1’ in R2 so that it will check the value of completeFlag every second and loop until it turns to 1. After the loop, it will revert the value of completeFlag back to 0. After this Report Pre Statement, R2 will obtain data from the database, which has been populated by R1.

DECLARE @intFlag INT
SET @intFlag = (select max(completeFlag) from tm_Flag)

WHILE(@intFlag = 0)
BEGIN
	WAITFOR DELAY '00:00:01'
	SET @intFlag = (select max(completeFlag) from tm_Flag)
END

DECLARE @query as nvarchar(100)
SET @query = 'UPDATE tm_Flag SET completeFlag = 0'
EXEC sp_executesql @query

 

Activity Diagram

18_revised.png

 

 

Overall execution flow

  1. Answer prompts

19.png

 

2. Only the text mining result is displayed to users

20.png

 

Third Party Software Installation:

WARNING: The third-party product(s) discussed in this technical note is manufactured by vendors independent of MicroStrategy. MicroStrategy makes no warranty, express, implied or otherwise, regarding this product, including its performance or reliability.

 

MicroStrategy Leads in Forrester Wave Agile BI Report, Q2, 2014

Forrester Wave Agile BI Q2 2014

MicroStrategy Analytics Platform received top scores for the features technology professionals need to enable business user business intelligence (BI) self-service, as well as for the effectiveness of its advanced data visualization (ADV) functionality in the recently published Forrester Wave: Agile Business Intelligence Report for Q2, 2014.

According to the report, “Forrester also scored MicroStrategy highly for the business user capabilities to provision applications and data and perform data integration tasks within the BI tool. MicroStrategy received high client feedback scores for its agile, business user self-service and ADV functionality. Clients also gave MicroStrategy a top score for its product vision.”

The report also stated that “in addition to its Agile BI offerings, MicroStrategy’s traditional strengths are its organically grown architecture and a powerful ROLAP engine, which in the long-term can often reduce total cost of ownership by reducing the number of reports and dashboards that need to be produced. With its integrated desktop and cloud-based SaaS offerings, MicroStrategy buyers can start small and scale quickly.”

To get a free download of the complete report, visit MicroStrategy’s Web site at http://www.MicroStrategy.com.

MicroStrategy Report Optimization: Computational Distance

Computational Distance

Source: MicroStrategy University, Deploying MicroStrategy High Performance BI, V9.3.1, MicroStrategy, Inc. September, 2013.

Computational Distance

Any BI system consist of a series of processes and tools that take raw data at the very bottom-at the transaction level in a database-and by using various technologies transform that data into the finished answer that the user needs. At every step along the way, some kind of processing is done in the following components-the database, network, BI application, or the browser.

The concept of “computational distance” refers to the length in terms of systems, transformations, and other processes that the data must undergo from its lowest level, all the way to being rendered on a browser as shown in the image above.

The longer the computational distance is for a given report, the longer it will take to execute and render. The preceding image shows a hypothetical example of a report that runs in 40 seconds. Each processing step on that report, such as aggregation, formatting, and rendering, adds to the report’s computational distance, increasing the report overall execution time.

Reducing the Computational Distance of a Report

Computation distance offers a useful framework from a performance optimization perspective because it tells us that to improve the performance of a report or dashboard, you must focus on reducing its overall computational distance. The following image shows different techniques such as caching, cubes, and aggregation that can be used to optimize performance for the 40 second hypothetical report.

In the next blog post, we will next look at two key computational distance reduction techniques offered in the MicroStrategy platform-caching and Intelligent Cubes.

Reducing the Computational Distance

MicroStrategy Report Optimization: Components of Performance

Readers:

Today, I am adding the second post in my MicroStrategy Report Optimization series. This will be a multi-part series (I will leave it open-ended so I can continue to add to it).

Today, we will look at the components that comprise performance.

Best Regards,

Michael

Source: MicroStrategy University, Deploying MicroStrategy High Performance BI, V9.3.1, MicroStrategy, Inc. September, 2013.

Components of Performance

There are five key layers or components that a typical BI query must go through. They are:

  • Caching Options
  • Data Transfer
  • System Architecture and Configuration
  • Client rendering or Data Presentation
  • Data Warehouse Access

The components above are not listed in any specific order of access during the execution of a query. The image below illustrates the five components.

The Components of High Performance

Caching and Intelligent Cubes

MicroStrategy’s memory technology is engineered to meet the increased demand for higher BI performance, which is driven by the rapid expansion of both data volumes and the number of BI users in organizations across industries. MicroStrategy accelerates performance by pre-calculating computations and placing the results into its memory acceleration engine to dramatically improve real-time query performance.

Data Transfer

Data transfer over one or more networks are a very important component of a BI implementation. A slow or poorly tuned network performance in any of those transfers will translate into poor performance from a report or a dashboard execution perspective.

System Architecture and Configuration

Successful BI applications accelerate user adoption and enhance productivity, resulting in demand for more users, data, and reports. MicroStrategy provides the ability to adapt quickly to constant changes and evolve along with business requirements. MicroStrategy Intelligence Server hs been proven in real-world scenarios to deliver the highest performance at scale with the fewest servers and minimum IT overhead.

Data Presentation

Dashboards provide graphical, executive views into KPIs, enabling quick business insights. MicroStrategy enables higher performing dashboards, averaging 30-45% faster execution and interactivity. Using new compression methods, MicroStrategy dashboards have a smaller footprint than ever before – up to to 55% smaller – resulting in faster delivery using less network bandwidth. Dashboards deliver ever more analysis and data for end-users.

Data Warehouse Access

High performance BI starts with optimizing SQL queries to retrieve results from the database as quickly as possible. BI performance is dependent largely on the time that the queries take to execute in the database. An average reporting request usually takes 40 seconds to complete, out of which 34 seconds, or 85% of the query time, is spent executing in the database.

Therefore, it is critical to optimize report queries to reduce database execution time.

MicroStrategy Report Optimization: Introduction

Readers:

I have received an e-mail from a reader that wanted me to discuss how to optimize MicroStrategy Reports.

I think this is an excellent topic and will today start a new blog topic called MicroStrategy Report Optimization. This will be a multi-part series (I will leave it open-ended so I can continue to add to it).

Before we start the series, it is important to understand report execution flow in MicroStrategy. That is what I will start with today.

Best Regards,

Michael

Source: MicroStrategy University, Deploying MicroStrategy High Performance BI, V9.3.1, MicroStrategy, Inc. September, 2013.

Report Execution Flow

To better understand how some of the components affect the report performance in a MicroStrategy environment, it is important to become familiar with the report execution flow.

The following image depicts the different steps involved in the report execution process.

Report Execution Flow

The following steps and components are involved in the report execution flow.

Report Execution Flow Steps

 

Tips & Tricks #11: The URL path is not visible in the report properties dialog box in MicroStrategy Web

The Issue

Each report and document has a URL path that could be used to directly execute the object when pasted in the browser address bar. The URL path can be found in the properties section when a user right-clicks on the object.

The expected view of that window is as follows:

The view observed by some users without the link feature:

The Cause

The required feature is not enabled in the MicroStrategy Web Admin page.

The Fix

  1. Navigate to the MicroStrategy Web Admin page.
  2. Select ‘Security’ on the left-hand side.
  3. Under ‘URL’, enable the feature – “Session information is included on the URL”.

 

Workaround 

If the session information setting should remain off for security reasons, use the Show Link feature as shown below.

 

Reference

MicroStrategy Knowledgebase Technical Note 39787, Updated July 22, 2013.

Tips & Tricks #9: How Do Changes on the Source Report (Dataset) Get Reflected in MicroStrategy Report Services 9.x Documents

In MicroStrategy Report Services Documents, document datasets and their original source reports  (such as a grid report being used as a dataset) are not completely connected to each other. Depending on the changes made on the source report, it can be reflected differently on the document. Basically, the change can be divided into two types.

Type 1 – Formatting Changes

Formatting changes, for example, changing autostyles, thresholds, subtotals.

If a user chooses the option Add to Section without Formatting, the grid/graph showing on the document will not use the report’s stored formatting. Any formatting changes on the source report will not be reflected on the document.

Tip 9-1If a user chooses the option Add to Section with Formatting, the grid will be added with the current format of the report.  However, any formatting changes made to the source report AFTER the dataset has been included in the document will NOT be reflected on the document.

For example, a user disabled the subtotal (see screenshot below) for the original report after the report has been included as a dataset in a document, the document will still show the subtotals.

Tip 9-2

To force the document to recognize the report’s formatting changes, the user needs to delete the grid/graph from document section and add it again using the With Formatting option. By doing this, the latest formatting properties of the grid/graph on the source report are retrieved.

Type 2 – Adding/Removing Objects and Modifying Report Filters

Another type of changes made on the report involving adding/removing objects and modifying report filters.

Unlike the formatting change, this type of change does carry over from the source report to the document datasets.

For example, if users add/remove/modify report filters (see screenshot below), the change will be reflected on the data when running the document.

Tip 9-3

If an object is removed from the source report (see screenshot below), the user can see the change in the document’s Dataset Objects window. After the user runs the document, the object will be removed from grid/graph on the document.

Tip 9-4

If an object is added to the report (see screenshot below), the change will show in the document’s dataset objects window. However, the object will not be automatically added to the grid/graph. The user has to manually add the object to the grid/graph or add the dataset to the section again to make it show up.

Tip 9-5

NOTE:   As of MicroStrategy 9.0, a new feature was introduced where a user can add a dataset report to a Report Services document as a shortcut by selecting the Add to Section As a shortcut option, as shown below:

Tip 9-6

If the grid/graph is added to the document using this option, then the document would be updated automatically if ANY type of change is made on the source report.

Bryan Redux #2: Removing Sections of a Report via URL API

Readers:

Here is another blog re-post from my friend, Bryan Brandow’s MicroStrategy site.

If you want to directly visit Bryan old site, the URL is http://www.bryanbrandow.com.

Best Regards,

Michael

Bryan originally posted this on July 22, 2011.

Removing Sections of a Report via URL API

WhBryan Brandowile working with the Web SDK to try to make a small customization, I stumbled on a pretty useful set of URL API codes that allow you to quickly modify the Report Page by removing various elements.  While such customizations are common, I wasn’t aware that they were available out of the box.  I would think that these would be very useful in doing simple linking to reports via an IFrame from another application, such as a Portal.

The trick to get the URL for a Report by right clicking it in Web, choosing Properties, and then copying the Link at the bottom.  Now, locate the src section of the URL:

ASP: &src=Main.aspx.4001 

JSP: &src=mstrweb.4001

and add in one of the transforms just before the .4001.

Available transforms that I’ve found:

reportNoHeader

reportNoHeaderNoFooter

reportNoHeaderNoFooterNoPath

reportNoHeaderNoFooterNoPathNoToolbar

Example:

ASP: &src=Main.aspx.reportNoHeader.4001

JSP: &src=mstrweb.reportNoHeader.4001

Unfortunately, these are actual transforms and not flags, so you can’t mix and match to fit your needs (for example, if you only want to hide the toolbar, reportNoToolbar will NOT work).  Those are the only 4 that you can use that I’ve found, but they may be handy in a pinch and best of all, not require customization work to use.

Update:

Another method of doing this that does let you pick and choose and supports documents as well:

&hiddenSections=header,footer,path,dockTop

Place that code in the URL, for example (Note: I have shown this on multiple lines. You should paste this in as one long line with no line breaks):

http://webserver/Microstrategy/asp/Main.aspx?Server=ISERVER&Project=PROJECT&Port=0&evt=2048001
&hiddenSections=header,footer,path,
dockTop&src=Main.aspx.2048001
&visMode=0&documentID=04AACFE445AD69198676C8AD56245118
&currentViewMedia=2

List of options (case-sensitive):

  • header
  • path
  • dockTop
  • dockLeft
  • dockRight
  • error
  • content
  • dockBottom
  • footer

Bryan’s Blog Entry Link:  http://www.bryanbrandow.com/2011/07/removing-sections-of-report-via-url-api.html

Tips & Tricks #2: In MicroStrategy Web, Report Execution Fails with Error ‘Results for this message cannot be retrieved from MicroStrategy Intelligence Server. This might be because the execution has failed. Please contact your administrator.’

I had this error the other day. Fortunately, I had just been reading about working set governor settings the other night to prepare for the CPA and MCE exams.

First, let’s discuss the issue.

Issue/Problem

In MicroStrategy Web, when I executed a report, I received the following error message (also, see screenshot below).

(Results for this message cannot be retrieved from MicroStrategy Intelligence Server. This might be because the execution has failed. Please contact your administrator.)

Results cannot be retrieved error message

Basically, what happened was my report request could not be processed. Looking through the MicroStrategy KnowledgeBase, it basically tells you to try to run the report again. If it still throws this error, contact your Administrator.

If you look at the Web Log on the Web Server, you will see an error similar to the following:

<record reset=`true`>
 <package>com.microstrategy.webapi</package>
 <level>SEVERE</level>
 <miliseconds>1157577081154</miliseconds>
 <timestamp>09/06/2006 14:11:21:154</timestamp>
 <thread>154</thread>
 <class>CDSSXMLReportServer</class>
 <method>GetExecutionResultsEx</method>
 <message>(Results for this message cannot be retrieved from 
MicroStrategy Intelligence Server. This might be because the
execution has failed. Please contact your administrator.) 
(com.microstrategy.webapi.MSTRWebAPIException)</message>
 <exception>com.microstrategy.webapi.MSTRWebAPIException: 
(Results for this message cannot be retrieved from 
MicroStrategy Intelligence Server. This might be because
the execution has failed. Please contact your 
administrator.)
 at com.microstrategy.webapi.
CDSSXMLReportServer.GetExecutionResultsCommon(Unknown Source)
 at com.microstrategy.webapi.
CDSSXMLReportServer.GetExecutionResultsEx(Unknown Source)
 at com.microstrategy.web.objects.
WebReportInstanceImpl.
getExecutionResults(Unknown Source)
 at com.microstrategy.web.objects.
WebReportInstanceImpl.pollForResults(Unknown Source)
 at com.microstrategy.web.objects.
WebReportInstanceImpl.populateUserReportCache(Unknown Source)
 at com.microstrategy.web.objects.
WebReportInstanceImpl.pollStatus(Unknown Source)
 at com.microstrategy.web.beans.
ReportInstanceProxy.pollStatus(Unknown Source)
 at com.microstrategy.web.beans.
ReportBeanImpl.localCollectData(Unknown Source)
 at com.microstrategy.web.beans.
ReportBeanImpl.doCollectData(Unknown Source)
 at com.microstrategy.web.beans.
AbstractWebBean.collectData(Unknown Source)
 at com.microstrategy.web.app.beans.
AbstractAppComponent.collectData(Unknown Source)
 at com.microstrategy.web.app.beans.
ReportFrameBeanImpl.collectData(Unknown Source)
 at com.microstrategy.web.app.beans.
AbstractAppComponent.collectData(Unknown Source)
 at com.microstrategy.web.app.beans.
PageComponentImpl.collectData(Unknown Source)
 at com.microstrategy.web.app.
MSTRWebController.processRequest(Unknown Source)
 </exception>
 <userName>Administrator</userName>
 <clientID>172.19.19.2</clientID>
 </record>

The DSSErrors.log file on the MicroStrategy Intelligence Server contains the following errors:

[Kernel][Error] MsiWorkingSet::PersistMsg(): 
failed to attach RI to msg, error 0x80003F79
 [Kernel][Error] CDSSServerMessage::put_OriginalRI: 
WSResultPool->AddRI for msg xxxx return error 0x80003F79
 [Kernel][Error] CDSSServerMessage::put_OriginalRI: 
WSResultPool->AddRI for msg xxxx return error 0x80003F79
 [Kernel][Error] CDSSServerMessage::GetReportInstance():
get_OriginalRI() return error 0x1

Now what?

Solution

The size of the report that was to be executed has 40MB report cache size while the ‘Maximum RAM for Working Set cache size’ is set as 102,400KB, as shown in the image below:

Governing Rules - Default - Working Set

The MicroStrategy Intelligence Server was unable to swap out the report instances of 40MB in the Working Set.  To resolve this issue, I needed to increase the size of Maximum RAM for Working Set cache to a higher value, for example 512,000KB.

What is the ‘Working Set’ Governor Setting?

When a user runs a report from MicroStrategy Web or Web Universal, the results from the report are added to what is called the working set for that user’s session and stored in memory on the Intelligence Server. The working set is a collection of messages that reference in-memory report instances. A message is added to the working set when a user executes a report or retrieves a message from his or her Inbox.

The purpose of the working set is to:

  1. Allow the efficient use of the web browser’s Back button.
  2. Improve web performance for manipulations.
  3. Allow users to manually add messages to the History List.

This setting is accessible via the MicroStrategy Intelligence Server Configuration as shown below:

Governing Rules - Default - Working Set

Working Set Governors

The ‘Working Set file directory’ is the location in the filesystem where the Report Instances may be persisted on disk. A report instance will be persisted on disk in binary format if its size exceeds the limit set by the ‘Maximum RAM for Working Set cache’ governor or none of the report instances in memory can be swapped to make room for the new report instance. The persisted report instance will be persisted as the <filename(GUID)>.po and may be reused if the report is invoked again.

The ‘Maximum RAM for Working Set cache’ is the governor that modulates the size of the WorkingSet Result Pool. The Maximum value is: 2147483647 MB, the Minimum value depends on version and is 200 MB in 9.3.1, and the Default value is: 200 MB. Note that if the value specified is greater then the machines memory it uses the default of 200 MB. The default value is usually sufficient, but if memory issues arise, as noted above, the setting can be increased. Increasing this setting means that the MicroStrategy Intelligence Server may be operating with a higher average memory footprint during its lifecycle, so proper tuning may be needed if memory usage becomes an issue.

Important Notes

  • There is no Working Set (WS) for a session created by the MicroStrategy Desktop client.
  • This is a MicroStrategy Intelligence Server configuration level setting, so it applies to all the projects and all the users and is not specific to a project. If these settings are changed, MicroStrategy Intelligence Server may need to be restarted.
  • The MicroStrategy Working Set is not the same as the Microsoft Windows Operating System Working Set.