Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MicroStrategy Design Challenges - Tips and Best Practices

Design Tips and Best Practices for MicroStrategy
Source: http://www.persistent.com/resources/whitepapers-and-ebooks

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

MicroStrategy Design Challenges - Tips and Best Practices

  1. 1. 10 MicroStrategy Design Challenges Design Tips & Best Practices for MicroStrategy BI Architects and Developers www.persistentsys.com eBook
  2. 2. Contents Technical Design Challenges #1 Developing Multi-language Reports 4 #2 Developing Metadata for Various Business Functions 7 #3 Improving Warehouse Performance 9 #4 Improving Report Performance 11 #5 Data Authorization 13 #6 Time Series Analysis in MicroStrategy 15 #7 Ad-hoc Report Creation via Guided Process 17 Process Design Challenges #8 Metadata Development in a Distributed Environment 19 #9 Testing Metadata 21 #10 Handling Updates of OEM Applications 23 Conclusion 25
  3. 3. A Quick Primer MicroStrategy is a Business Intelligence tool used to design and develop BI solutions that addresses a myriad challenges faced by various industry verticals in analytics. BI solutions are developed to serve the analytical needs of multiple customers coming from various industry verticals. As the functions and needs of every industry and business are disparate, designing a BI solution for each specific need becomes an interesting challenge. In this eBook, we share 10 interesting and common design patterns and challenges encountered when working on MicroStrategy projects. Some of these design patterns are more involved than others. We will discuss design problems such as multi-language support, ad-hoc reporting, authorization, etc. and also provide possible solutions for these, as well as things to consider while developing BI solutions. This eBook focuses on data warehouse and metadata related problems in MicroStrategy projects and is split in to two parts-technical and process related design challenges. If you are developing a metadata and BI framework using MicroStrategy, this eBook will help you overcome the common design loopholes. This eBook will also be helpful if you are architecting BI solutions. This eBook focuses on Data warehouse and metadata related problems in MicroStrategy projects and is split in to two parts-technical and process related design challenges. eBook Persistent © 2013 Persistent Systems Ltd. All rights reserved. 3 10 MicroStrategy Design Challenges
  4. 4. Developing Multi-language Reports BI solutions need to provide multi-language support. Multi-language support implies that data on the reports and the metadata showing up on the reporting user interface be translated to the user's preferred language. Business users may not really differentiate between data and metadata; however, developers need to make sure that the following items are translated appropriately to the users' preferred language(s):  Metadata objects provided by the tool (e.g. labels on the menu such as File/Open dialogs and other general interface)  Metadata objects created by developers (user defined metrics, attributes, prompt text, chart titles, etc.)  Data on the reports (e.g. data showing up on the reports coming from the data warehouse) Support for multiple languages, for the first two objects on the list, is relatively well defined in a BI tool. MicroStrategy provides a Repository Translation Wizard (part of Object Manager), which can export the metadata object strings for translation. The translated object strings can then be imported into MicroStrategy. However, when it comes to the third item–data on the reports–it can turn out to be quite challenging, because the solution depends on how the warehouse is modelled. We will look at various ways to store multi-lingual data in the warehouse and how MicroStrategy can use this data to provide multi-lingual reports. eBook Persistent © 2013 Persistent Systems Ltd. All rights reserved. Challenge Solution Common patterns used for storing the multi-lingual data in the warehouse:  Column-based or database-based translation: In this pattern, the translated data items are placed in separate columns, tables, or in separate databases. Most BI tools provide well-defined language translation methods, when the warehouse is modelled using this pattern. This pattern, however, calls for additional ETL effort and maintenance activities, for any language-related changes. Various ways, using which, you can store data in the database are: #1 1Challenges 2 3 4 5 6 7 8 9 10 4 10 MicroStrategy Design Challenges
  5. 5. eBook Persistent MicroStrategy supports out-of-the- box column-based language translation A column per language: There is one column per language in the dimension table. A table per language: The translated data can be stored using one dimension table per language. A database per language: A separate database instance for each language to store translated data. Based on the user's preferred language, the BI tool connects to the appropriate data source. This configuration can be done in MicroStrategy. For the column or table-based approach, MicroStrategy provides SQL-based Data Internationalization. MicroStrategy uses appropriate SQL queries to access data in the warehouse. For the database-based approach, MicroStrategy provides connection-based Data Internationalization. MicroStrategy uses ODBC APIs to access data from the appropriate warehouse. In either case, you have to take additional steps to configure your project to enable internationalization. Figure 1. One column per language ID NAME NAME_DEFAULT NAME_ENGLISH NAME_FRENCH NAME_GERMAN 1 Blackboard Blackboard Blackboard TABLEAU NOIR TAFEL ID NAME 1 Blackboard DIM_PRODUCT_DEFAULT ID NAME 1 Blackboard DIM_PRODUCT_ENGLISH ID NAME 1 TABLEAU NOIR DIM_PRODUCT_FRENCH ID NAME 1 TAFEL DIM_PRODUCT_GERMAN Figure 2. One table per language DB_DEFAULT DB_ENGLISH DB_FRENCH DB_GERMAN Figure 3. One database per language © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 5 10 MicroStrategy Design Challenges
  6. 6. The tables or columns that store translated data must follow consistent naming conventions. For example, as showed in the Figures 1 and 2, if you are using '_FRENCH' for storing French data, then use the same suffix for all the rows and columns in the tables that store French data. It is important to configure the project to use the underneath language tables. The Language section needs to be filled to choose the appropriate method (SQL-DI or Connection-DI) for translation. Also, specify the suffixes that will be used.  Row based translation: This pattern stores the translated data in different rows of the same table and is illustrated in Figure 4. In DIM_PRODUCT, we will have one row per language for a particular product. With this approach, adding more languages to the warehouse and maintaining multi-lingual data becomes flexible and easy. However, reporting solution for this model, when using MicroStrategy, becomes very complex. DIM_PRODUCT ID NAME LANGUAGE 1 1 1 1 BLACKBOARD BLACKBOARD TABLEAU NOIR TAFEL Default English French German Figure 4. Product Dimension with multi-language data MicroStrategy does not have an out-of-the-box solution for row-based translation. Your creativity will need to come into picture! One of the various ways this can be done is by using the system prompt and security filter combination to capture the logged in user and the user's language preference. Security filter functions similar to a normal filter. However, the qualification defined by the security filter is added to the WHERE clause of every SQL that MicroStrategy generates. For this type of solution to work accurately, metadata relationships between the language tables and the dimension tables should be modelled precisely during the metadata modelling phase. © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 6 eBook Persistent10 MicroStrategy Design Challenges
  7. 7. Developing Metadata for Various Business Functions Enterprises prefer a BI solution that works for multiple business functions/groups. For example, in the retail industry the same BI solution needs to work for sales, purchase, inventory, billing, etc. The boundaries around these functions need to be drawn within the solution such that, only authorized business groups get access to specific reports and operations. This section lists a few of the multiple considerations that need to be made to develop such a BI solution. eBook Persistent Solution Even if the same BI solution supports multiple business groups and functions, there is a lot of common metadata that they share. Also, there would be parts of metadata and reports that are mutually exclusive for each business function or department. As a first step when developing a BI solution developers should identify a set of objects that are common across business functions and objects that are exclusive to each business function. A thorough design/paper work must outline the metadata/object separation. Business functions will be sharing confirmed dimensions and will have common data, as well as data and tables that are exclusive to certain functions. Within MicroStrategy, it makes sense to have a single metadata database that supports all the functions. As the common set of metadata objects resides in a single codebase or metadata database, there is no duplication of common metadata and resulting maintenance work. The setup for development and testing environments also becomes simple. Challenge #2 BI Solution se laS Inven tory © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 7 10 MicroStrategy Design Challenges
  8. 8. eBook Persistent The following pointers can help when using a single metadata database:  Identify the common and specific metadata objects across business functions.  Identify the list of reports for various business functions.  Decide on a strategy for separation of metadata across business functions. This would involve a detailed design of user groups and their update policies, access control lists and corresponding update policies, specific objects needing authorization, etc.  Creating one user group per business function.  Create ACLs (Access Control Lists) so that objects belonging to a particular business function can be accessed by the authorized business user group only.  MicroStrategy administrator can see all the objects and should be aware of the boundaries and metadata.  The roles that MicroStrategy provides must also be considered to create a separation within the business functions. For example, users who can only run reports would belong to MicroStrategy Web Reporter group, while users who can create an ad-hoc report would belong to MicroStrategy Web Analyst group.  All the ACLs and updates to users/groups can be controlled via Command Manager scripts to make bulk operations easy rather than setting permissions manually through MicroStrategy's admin UI.  MicroStrategy admin manual has a section on setting up user security and provides details of the various aspects described above. © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 8 10 MicroStrategy Design Challenges
  9. 9. Improving Warehouse Performance Performance boost, performance improvements, and performance issues constantly haunt BI architects and BI developers. Performance issues in a typical BI solution can originate in the data warehouse, BI application, web, or in the BI tool itself. Reports are the face of a BI application. While the BI team gets all the credit for excellent reports, they are the first to be blamed for performance issues! As a first step, we need to locate the root of the problem. Performance can be improved, by tuning the data warehouse objects and the reporting tool components. In this section, we will walk through some of the techniques applied to the warehouse to boost performance. eBook Persistent Challenge #3 Solution When working on performance improvement, define the benchmarks first. Run the tests to determine low performing reports. MicroStrategy's Enterprise Manager provides a breakup of the time taken for query execution, report execution, rendering, etc. This specifies whether the focus of tuning should be on the data warehouse or the report components. Reports where query execution takes a long time, serve as sample reports for tuning the warehouse. An easy way to do this is to run the query, generated by MicroStrategy, directly on the database. Note that MicroStrategy generated SQL has multiple passes and DDL for creating temporary tables. You would need appropriate access on the database. Design of the warehouse, modeling techniques, breaking data into multiple data marts, and other such factors affect database performance. In this section we discuss some solutions, assuming, the data warehouse architecture and model are already in place. Examine the following elements:  Aggregation layer: Ensure that the reporting query is getting data from the aggregated table. The data in the fact table can be stored at the lowest granularity and data required on the reports should be at higher granularity. It is important to ensure that the required summarization layer is available in the data © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 9 10 MicroStrategy Design Challenges
  10. 10. warehouse. For example, the click stream data is available at granularity up to seconds.However, most of the reports need data only at the daily granularity level and above. The fact table should have pre-aggregated data for such levels. MicroStrategy's aggregate awareness functionality can be leveraged to shift from fact to fact in a report at the required granularity.  Archival strategy: Is there an archival strategy in place for the warehouse? If not, it makes sense to develop one. Large amount of queried data or dormant data will definitely affect the performance of reports.  Data mart maintenance-index rebuilds and update of statistics: Data is regularly added to the warehouse. Based on the frequency of changes, statistics should be updated and indexes should be rebuilt to provide optimum performance. Analyze the commonly used filters for reports and create corresponding indexes.  Analyze SQL and query execution plans: Indexes that are not in place and those that have too many columns can cause slowdowns. Get SQL passes from MicroStrategy for the slow reports and check the execution plan. Come up with an indexing strategy if the existing one does not seem to work.  Create materialized views: Some views in the warehouse may have complex logic and thereby a complex query in the background, causing slowdown. It makes sense to replace such views with materialized views, based on which database technology is being used. Incremental refresh of materialized views will improve the performance. When your BI solutions need to work with multiple databases, materialized views may not be supported across all the technologies. Complex views can be persisted as tables, which will need some ETL work as depicted in Figure 6: Warehouse tables Metadata model Reports Warehouse tables Materialized views or persisted tables Metadata model Reports Figure 6. Creating Views under Reports-Before and After Scenarios © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 10 eBook Persistent10 MicroStrategy Design Challenges
  11. 11. Improving Report Performance If tests indicate that the data warehouse is fairly well tuned and the reporting layer needs to be worked on to address performance issues, you will find a solution to the major causes in this section. eBook Persistent Challenge #4 Solution Keeping tabs on how the SQL is generated at the time of report development is a good practice. SQL generated by MicroStrategy may have too many SQL passes or heavy SQL passes, in turn affecting the performance. MicroStrategy enables tweaking SQL generation through VLDB properties among few other things that can be done to boost the performance. Let’s go through these techniques in brief:  VLDB properties: These properties control the behavior of MicroStrategy. These settings can be done at the database instance level, attribute level, or report level. For example, by setting an appropriate option in the VLDB property called 'Cartesian Join Warning ' you can disallow MicroStrategy to stop executing SQL with cross joins. You can also direct MicroStrategy to stop the execution if a warehouse table is involved in cross joins (only if the temporary tables are not involved). This way you can avoid situations where huge fact tables get cross joined with dimensions such as Date.  Report as a Filter: A report may be pulling data from joins across huge dimensions. For example, selecting a set of products from complex product hierarchy tables may take a long time. For every SQL pass that MicroStrategy creates, large dimensions and the joins between them get involved. If dimensions parsing can be done once to store the results set into a temporary table, the temporary table then can be used in all the remaining passes. As depicted in Figure 7, report as a filter provides a way to use the dataset of the report, as a qualification inside another report. © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 11 10 MicroStrategy Design Challenges
  12. 12.  iCubes: iCubes or Intelligent Cubes are objects that provide pre-cached data which can be queried on the reports. Rather than returning data from the warehouse, if it is placed in the memory (pre-cached), so the results are returned quickly. The reports accessing iCubes can use all of the OLAP Service features for analysis and reporting purposes. If you want to generate reports, fetching huge data multiple times, iCubes can be beneficial. The cube leverages both memory and a file on the disk, so data is quickly reloaded into memory when required. iCubes, however, has some limitations and thereby needs to be used judiciously based on the need.  Aggregate Awareness: Most of the data warehouses provide aggregated layer of fact tables. For example, the sales can be stored at an hourly level and at the daily level, as fact_productsales_hourly at the granularity level of hours and fact_productsales_daily at the granularity level of days. Both the facts have exactly same columns, except for the column that indicates time of sales. When a report is pulled to show the daily sales, MicroStrategy will pull information from the fact_productsales_daily and when an hourly sales report is generated, it will pull data appropriately from the fact_productsales_hourly table. MicroStrategy is aggregate aware and it will choose the best table to run the report from and we can use this wonderful feature for optimal performance.  Metadata partitioning: In MicroStrategy, you can build metadata that provides a way for MicroStrategy to choose a table for the query. This provides a more flexible way for us to provide partitioning than just basing on database partitioned tables. © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 12 eBook Persistent Product Category 1 Product 1 Product 2 Model 1 Model 1 Model 2 Product Category 2 Product 1 Product 2 Model 1 Model 1 Model 2 Product table hierarchy is joined in every pass SQL PASS 1 SQL PASS 2 SQL PASS 3 SQL PASS SQL PASS 1 SQL PASS 2 SQL PASS 3 Single SQL Pass on the product hierarchy tables Figure 7 Creating report as a filter 10 MicroStrategy Design Challenges
  13. 13. Data Authorization Data authorization is a means to ensure that the right people get access to the right data. This is a common design issue for any BI solution and for that matter any data-centric application. Authorization, in a broader sense, includes access to objects and operations in addition to data. In this section we will limit the scope of discussion to data authorization. The authorization module design in a BI tool is tightly linked with the warehouse model and how data is organized into that data model. For example, in a Product Sales application, a user can only see data for the region that he/she is responsible for. As showed in Figure 8, users can be responsible for sales in more than one region. For example, John should be able to see the sales data for North and South regions only. Using the BI tool, we built a single report for sales analysis and the same report would show the appropriate slice of data, based on which the user is running the report. eBook Persistent Challenge #5 User table defining access to regions User Region Fact table storing the data for the regions Product SalesRegion John John Andrew Sarah North South West East North South West East 40 20 30 30 Figure 8. Tables providing authorization data © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 13 10 MicroStrategy Design Challenges
  14. 14. Solution As showed in Figure 8, the warehouse model has a user dimension, which stores the regions that users are authorized for. This table stores the information on data access restriction. After the user is authenticated, we can use MicroStrategy's system prompt for user ID in a security filter. The security filter appends a WHERE clause to every SQL that MicroStrategy generates. This implements a simple authorization framework and is depicted in Figure 9:  User logs into MicroStrategy  User is identified and the system prompt is answered with the User ID  The metadata relationship between the user and regions is used to initialize the security filter  This security filter is applied to every query that MicroStrategy generates  Security filter restricts the joins to only those regions that the logged-in user is allowed access to One of the issues that can come up is multi-path joins in MicroStrategy that can prohibit the security filter from getting applied. This can occur when there are ambiguous paths from the authorization table to the fact table. Ambiguous paths should be avoided. User Login Data Access Table Fact User authenticated User authorized to access only certain data WHERE Fact.region = DataAccessTable.region MicroStrategy features used:  System prompt  Security filter  Metadata Relationships Figure 9. Implementing data authorization © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 14 eBook Persistent10 MicroStrategy Design Challenges
  15. 15. eBook Persistent Challenge #6Time Series Analysis in MicroStrategy Analysis of numbers along the time dimension is a commonly found pattern in the reports, for example:  Month-on-month comparison of product revenue for the current year  Typical TY/LY analysis (This Year v/s Last Year) for product sales The number of time periods used in a particular domain and the unit of time periods may vary from business to business. Some businesses may use conventional time periods and may limit analysis to a fixed set of time periods such as Last Year, Last Week, This Year, This Week, etc. Some businesses use custom time periods to suit their requirements. MicroStrategy provides various ways to implement these time periods on the metadata for time-based trend analysis. Figure 10. TY / LY Comparison of Product Sales © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 15 10 MicroStrategy Design Challenges
  16. 16. Solution MicroStrategy provides transformations-schema objects that map to a specified time period-which can be used to implement features such as, Year- To-Date (YTD) and the like. The transformation object is applied to a metric called a Transformation Metric. Without using transformations, to calculate product sales for a year, the Product-Sales metric can be used with a filter for that particular year. With transformations, it becomes more intuitive. Transformations can be table based or expression based in MicroStrategy. In the table-based approach, the lookup tables or the corresponding dimension tables need to have fields with corresponding linkages to define the last year with respect to the current year. However, this creates the need for managing the warehouse tables. In case of expression-based transformation, an expression or formula is involved to compute the 'previous year' or 'previous week' calculations. This lessens the pain of data warehouse maintenance; however, it increases the burden at the time of report execution, as the system needs to compute the results. If there are multiple time periods in the business and time periods are continuously added or updated, transformation would be an expensive solution. An alternative to using transformation is to create time periods in a database table and provide filters for reports in MicroStrategy. Another way would be to create filters for various time periods within MicroStrategy itself and make no changes in the data warehouse. These filters can be maintained by a background command manager script that can update the filter values before running the reports. For these solutions metadata modeling needs to complete such that end users can easily select the required time period for the report. © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 16 eBook Persistent10 MicroStrategy Design Challenges
  17. 17. eBook Persistent Challenge #7Ad-hoc Report Creation via Guided Process It is important to empower business users to create their own reports. Dependence on the technical team for every trivial analytical need is often not desirable. The metadata objects layer in MicroStrategy, provides a wonderful way to make business objects available to the users for drag-and-drop ad-hoc reporting. However, while creating ad-hoc reports, there are chances that users might choose the wrong combination of objects on their ad-hoc reports, causing system instability. With a wizard-guided report development process users can draw an accurate ad-hoc report. Solution An ad-hoc report is developed around a specific subject area associated with a fact. For example, a user might want to analyze the sales of a product. For this, he/she needs metrics from sales facts and various attributes, such as product name, category, and month from the dimensions around that fact. In such cases, providing only relevant set of objects to the user is a better option than providing access to a whole set of objects such as inventory, order related objects, and others. In addition, users who are not very tech-savvy may need a guided process for report development. MicroStrategy provides a feature called 'Object Prompts', that enables you to add objects to your report. We can create a 'prompted report' that prompts users to add filters, attributes, metrics, prompts and other such objects. We can control objects that are provided for selection and restrict them to only a particular business function or a subset of business functions, giving a focused approach to the users. The developer needs to: 1. Create separate folders for each function and provide navigation to create ad-hoc reports. 2. Create Search Objects to get references of all objects, related to that business function. This way you ensure that any modifications made to the respective objects are included in the Object Prompt list when the report is executed next time. © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 17 10 MicroStrategy Design Challenges
  18. 18. 3. Create separate Search Objects for each class of objects (metrics, attribute, filters, etc.) in that business function. 4. Create a prompted report or template using the above prompts and make it available only to the authorized user group. Using this approach, developers can enforce selection of mandatory objects on reports. This approach helps users to select the required objects through a controlled process. The objects included in any ad-hoc report created by this process will be related to one function or a sub-function for analysis. Developers can add critical prompts (e.g. date) to ensure that the ad-hoc report restricts the amount of data generated, thereby reducing load on the system. ACLs can be applied on the template to restrict accessibility to authorized users only. This technique boosts user productivity and reduces system instability. © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 18 eBook Persistent10 MicroStrategy Design Challenges
  19. 19. eBook Persistent Challenge #8Metadata Development in a Distributed Environment Too many cooks spoil the broth! Large project teams are geographically distributed and many times they deal with large amounts of metadata. Various modules are developed simultaneously and it is a challenge to ensure that metadata objects from one module do not conict with those of another module and corrupt relationships. Developing a MicroStrategy metadata model is similar to developing a dimensional data model. In this section, we discuss best practices to deal with distributed metadata development. Issues that can come up at the time of distributed development are:  Same object being modified at more than one location: In this case a conict will occur at the time of merging objects. Conict resolution process will get rid of one set of objects and in the process it may end up removing some essential metadata relationships.  Same new object being added to the metadata from two sources: For example, team A adds attributes related to an Employee and team B adds attributes related to that Employee, from two different locations. In this situation, MicroStrategy will create two sets of attributes for the Employee in the same metadata. Solution Development teams should use a well-defined process, along with the right tools for effective multi-site development. Unfortunately, MicroStrategy does not provide enough support for versioning. Therefore, versioning needs to be managed manually. This can be done using 'packages' in MicroStrategy. Packages are binary files that contain metadata objects and can be created using the Object Manager component in MicroStrategy. © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 19 10 MicroStrategy Design Challenges
  20. 20. We would suggest the following for version control:  Decide and develop confirmed dimensions: These are base dimensions for the project and it is crucial to define dimensions for objects to be developed. In situations, where two different teams use the same underlying tables to create metadata objects for separate server instances, MicroStrategy does not flag them as egregious. Such instances can lead to erroneous and confusing models. Follow strict discipline for conformed dimensions, do not allow changes to objects without a build manager's approval.  Define teams for metadata object mapping: The team assigned to a metadata object owns that object, implying, when there are merge conflicts their copy is marked as the master copy.  Nominate a release manager per team: This manager should maintain integrity of the builds for the team.  Merge early and merge often in the project lifecycle. Do not let the changes accumulate over a long time.  Nominate a release management team: This team controls the master copy of metadata (in the form of Packages) and ensures integrity of metadata. This team uses a master MicroStrategy server, as showed in Figure 11. The production builds will be created on this server and all satellite teams merge their code here. The Build Management team manages Metadata using well-defined file naming conventions for version control.  When new objects are created, it should be communicated to all teams.  Automate regression tests and run them after every merge operation to identify integration problems early on. Team A Team BTeam D Team C MasterBuild Machine © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 20 eBook Persistent10 MicroStrategy Design Challenges
  21. 21. eBook Persistent Challenge #9Testing Metadata Testing reports is a common practice. However, engineers do not target metadata specific testing. Metadata is very critical and one inappropriate relation can potentially bring down any report. In case of ad-hoc reporting the challenges are elevated, as developers do not have control over objects used by business users in their reports.Therefore, every combination of objects used for reporting should give accurate results. This section discusses how metadata testing can be done and some of the challenges involved. Solution When testing Metadata, create ad-hoc reports (e.g. simple grid reports) for all use cases of a particular subject area. Each of these reports needs to be manually tested for accuracy. Once manual testing is done, we can leverage MicroStrategy's Integrity Manager to automate testing of the specific report for future executions. The idea is to keep this report and its results intact, irrespective of any changes in the metadata. You can create baselines for reports with different parameters (prompt answers). Another useful way of tracking metadata changes is to develop MicroStrategy documentation (documentation wizard) for all the metadata objects. After every set of considerable changes to the metadata, compare the latest documentation report with the earlier one. All the differences that show up should be explainable and attributable to the project features being implemented. © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 21 10 MicroStrategy Design Challenges
  22. 22. Some challenges involved in the baseline comparisons done using Integrity Manager are as follows: A report may have 'Printed For' displayed, as showed in Figure 12. This field changes based on who runs the test suite and the Integrity Manager will flag an error each time. In the test-automation environment, a command manager script can be used to change the value of an object before the tests are run. Sales Report Year Printed for - John 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 Region Central Mid-Atlantic Northeast Northwest South Southeast Southwest Web Total Average Minimum Maximum Units Sold 10,425 9,405 18,456 3,853 11,703 4,905 8,363 3,992 71,102 8,888 3,653 18,456 (User name may change) Figure 12 Date eld that changes every day © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 22 eBook Persistent10 MicroStrategy Design Challenges
  23. 23. eBook Persistent Challenge #10Handling Updates of OEM Applications ISVs include MicroStrategy as a part of their product. Customers usually request for rights to customize/modify metadata to some extent such that alterations in metadata are reected in the latest product releases. The design challenge is to make provisions to accommodate for any customization in subsequent results. A design process needs to be followed to eliminate conicts that can prove to be detrimental for the product. A combination of stringent processes and BI application design need to be in place to handle custom metadata effectively. Solution In MicroStrategy the Administrator has full access to metadata objects and can change any part of the metadata. As a first step, it is important for ISVs to define a list of data that can be customized by the customer. Company releases Product Ver I Company releases Product Ver II Customer buys Product Ver I Customer customizes Ver I Ver I - A Customer wants to buy Product Ver II Ver II B = Ver I A + Ver II Figure 13. Releases and custom metadata © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 23 10 MicroStrategy Design Challenges
  24. 24. Metadata is similar to a data warehouse model, so care needs to be taken when modifying it. Certain objects cannot be changed at all, for example, metadata relationship between the USER attribute and data access related attributes. Schema objects defined in the metadata form the layer that is closest to the warehouse columns and any changes to these objects can affect the functioning of the BI application drastically. Therefore, it is important for ISVs to document use cases, rules, and guidelines for customization. For new releases of the product, conflict resolution rules need to be defined for all objects to appropriately change, overwrite, or duplicate metadata objects at the time of new production release. If it is essential for customers to change properties of metadata objects, it is advisable to make copies of the objects involved and make changes on these copies, rather than on the original objects. This ensures that changes are not overwritten when a new version of the product is installed, and these changes are implemented after the installation is complete. This is a clean way of handling such exceptional changes. MicroStrategy's Installation and Configuration guide provides good level of detail deployment of OEM applications. © 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10 24 eBook Persistent10 MicroStrategy Design Challenges
  25. 25. eBook Persistent © 2013 Persistent Systems Ltd. All rights reserved. Conclusion We discussed various techniques to improve report building, system performance, and user productivity with MicroStrategy in this eBook. Some of the important points discussed can be summarized as:  Metadata modeling is a complex task, so set aside sufficient time for this activity. Any mistake at this stage turns out to be very expensive to fix down the line. With MicroStrategy it is of utmost importance that metadata relationships be clearly chalked out.  Eliminate ambiguity in object selection path. Multi-join paths lead to inappropriate SQL statements. This can lead to serious consequences such as authorization failure or unauthorized access, in addition to performance complications.  Metadata testing should start much before actual reports are built, so incorporate ad-hoc reports as part of the development and testing cycles.  MicroStrategy does not provide adequate versioning abilities, as part of the development environment. Therefore, when developing a complex project, teams should plan on supplementing this inadequacy by using other version control methods.  Overall, MicroStrategy addresses complexities of building products around Business Intelligence and Analytics. When working with MicroStrategy, consider its features and limitations right from the design phase. Use every opportunity to make changes on the warehouse side, in order to have a better BI solution. If you have worked on MicroStrategy and faced problems, other than the ones discussed in this eBook, we would like to hear from you and know your approach towards solving them. 25 10 MicroStrategy Design Challenges
  26. 26. eBook Persistent About Persistent Systems Established in 1990, Persistent Systems (BSE & NSE: PERSISTENT) is a global company specializing in software product and technology services. For more than two decades, Persistent has been an innovation partner for the world's largest technology brands, leading enterprises and pioneering start-ups. With a global team of more than 6,000 employees, Persistent has 300 customers spread across North America, Europe, and Asia. Today, Persistent focuses on developing best-in-class solutions in four key next-generation technology areas: Cloud Computing, Mobility, Analytics and Collaboration, for telecommunications, life sciences, consumer packaged goods, banking & financial services and healthcare verticals. For more information, please visit: www.persistentsys.com. India Persistent Systems Ltd. Bhageerath, 402, Senapati Bapat Road Pune 411016 Tel: +91 (20) 2570 2000 Fax: +91 (20) 2567 8901 USA Persistent Systems, Inc. 2055 Laurelwood Road, Suite 210 Santa Clara, CA 95054 Tel: +1 (408) 216 7010 Fax: +1 (408) 451 9177 Email: info@persistentsys.com © 2013 Persistent Systems Ltd. All rights reserved. 26 10 MicroStrategy Design Challenges

×