Having left you hanging from my previous post Mass Producing MicroStrategy Projects, this post will explain the solution that our company is currently implementing for fast POC deployments.  In fact, this process could very well become our “out-of-the-box” solution that empowers customers to rapidly run analysis without building any MicroStrategy reports.  Because we are still refining this process, any feedback that can streamline this process even further would be a great addition to our product suite.

For clarification purposes, I’m going to specify the problem and assumptions again.

Problem:

Create a MicroStrategy project in half a day, each customized for different customers’ datasets. This process has to be scalable, meaning there’s a possibility of needing to create a few projects everyday.

Assumptions:

• Some sort of automated ETL will put 70% of the text data (or text blobs) in various structured tables that will stay constant from project to project. This means 70% of the schema will be the same for every customer project.
• The other 30% “custom” data (which varies from customer to customer) will sit in a dimension table (called “Customer_Dimensions”). Some sample columns of this table are Products_Type (if a product company), Service_Type (if a service company), Customer_Income (if in finance vertical), Hotel_Locations (if in travel vertical), etc.
• Every warehouse sits on a different cloud, which means 10 customers will require 10 clouds hosting the warehouse schema and data.
• Only one I-server is available to all users.

Below are the list of MicroStrategy components we are using to automate the deployment process.

• MicroStrategy Intelligence Server
• MicroStrategy Desktop & Architect & Administrator
• MicroStraegy Command Manager

Now that I gave away the secret ingredient (Command Manager), you probably have an idea where this will go.  But there’s more, so keep reading.

Creating the “Template” Project

Creating a project from scratch takes time - a lot of time.  Each metric, each report, takes time to test, debug, and fix.  Designing the right schema is key to simplicity and performance, so never sacrifice design time just to build a project more quickly.  Now, assume we have a project that is properly created  already, meaning the 70% of constant schema have correct attributes and facts pointing to proper look-up and fact tables, we can already create half of the out-of-the-box reports.  (If we need six OOTB reports, I mean 50% of all six reports, not 100% of three reports).  What about the other 50%?  Well, Object Prompts and Search are your most valuable tools when building ad-hoc reports.  Create an Object Prompt and set it point to Search result that will return all the objects from a certain folder (let’s name this folder Dynamic Attributes); put this Object Prompt inside all the OOTB reports, and we’re all set to go with our “template” project.

Project Duplication Is Your Friend

The actual deployment of these projects are extremely simple if we have a “template” project to copy from.   You know how this works, so I’m not going to go into too much details here.

Table Names Have to be the Same

One of the assumptions I made before was, of course, every project’s schema points to the same set of table instances.  This is the key, because anyone who has tinkered with the Warehouse Catalog knows that it is very sensitive to changes. Moreover, renaming any table will cause a domino effect of changing all the affected attributes and reports.  Our goal here is to never open the Warehouse Catalog.

Remember that each project needs to point to a different warehouse sitting on various clouds since customer data largely vary.  Here, we need to create a new Database Instance and point it to the correct warehouse.  Every new duplicated project should be configured to the respective Database Instance, which maps to the correct warehouse on the cloud.  Remember to unload the project or even restart the I-server for the DB Instance to take effect.

Command Manager Magic

Let’s check our status.

• New project deployed and pointing to the correct customer warehouse.  Check.
• Run the OOTB reports and they should return correct data, even though they only contain 70% of the schema objects.  Check.
• The remaining 30% of the schema objects?  Keep reading.

Write a command manager script that creates the remaining 30% of these “dynamic” attributes.  They are dynamic because each customer data varies and have different dimensions that they want to analyze their text with.  Since we have already configured the DB Instance to point to the correct warehouse, we can easily look at “Customer_Dimension” table in the warehouse.  Make sure you create these attributes inside Dynamic Attributes folder so the Object Prompt we created above will return all the customer-specific dimensions.

And We’re Done!

This is our first stab at automating fast project deployment.  Even though it is not perfect, for example, there’s no way to snowflake “Customer_Dimension” table, it is a good start.  For POC purposes, this is sufficient; however, to make this automation work for our customer deployments, we might need to refine this process further.

will Automation, Process categorization, text analytics, unstructured data