The Quickest Path From CQM To DQM

The quickest path from CQM to DQM

It’s a straight line with MotioCI

Chances are good that if you’re a long-time Cognos Analytics customer you’re still dragging around some legacy Compatible Query Mode (CQM) content. You know why you need to migrate to Dynamic Query Mode (DQM):

  1. CQM is a risk. CQM is old technology and may be deprecated at any time
  2. DQM is future-proofing. DQM is scalable, more efficient and performs better
  3. The Cloud. If moving to the cloud is on your 5-year roadmap you need to move to DQM

The Myth

The job of migrating your packages and reports to DQM just appears daunting. For one thing, you suspect that something will break in the move, but you can’t be sure what. That’s surely the case, and there’s no easy way back. If there’s no easy way back, you just can’t be dead in the water for weeks with your users not having access to reports.

The Straight Line

What if you could just flip a switch and see how all your CQM content works as DQM? With MotioCI testing, that’s exactly what you can do. It’s that easy.

The Deets

We’ve written elsewhere about when you should migrate to DQM. This is how:

  1. Assessment and Inventory – First consider what you have and assess the effort. How many reports do you have? How many packages? How many of your packages are CQM? There are multiple ways in which you can approach this.

Find each Framework Manager model, open it and check the properties.

Or, find every package that has been published and check its properties.

Or, use MotioCI Inventory. The MotioCI Inventory Dashboard and Inventory Summary reports provide an overview of your entire content store. They tell you at a glance how many packages are in your Cognos content store are CQM and how many are DQM. An Inventory report shows additional details about the packages:

      1. Path. Exactly where they’re located.
      2. References. The number of incoming references give you an idea of how many reports depend on it.
      3. Obsolete. If there are no incoming references, that one’s going to be easy. You may not need the package. It’s not being used.

 

 

Testing – First you’ll want to establish a baseline on your CQM reports.

Create a project in MotioCI for your CQM package. MotioCI will help you automatically find all of the reports on which the package is based. Create Test Cases to establish a baseline for each of the reports for content and performance

      1. Output Stability – Creates a baseline for expected output of the report
      2. Execution Time Stability – creates a baseline for expected performance

Execute the Test Cases to generate the report output and record execution time.

 

Evaluation – This where you flip the switch to DQM and run the reports.

    1. Clone the project you created in the previous step so that a second MotioCI project will have the same package and reports. Change the project settings to Force Dynamic Package Query Mode. Create Test Cases for each of the reports to compare output and performance to the CQM baseline results.
      1. Output Comparison – Compares the report output in DQM to the CQM baseline.
      2. Execution Time Comparison – Compares the report execution time in DQM to the CQM baseline.
    2. Execute the Test Cases and evaluate the test results
      1. Success – These test cases pass both output comparison and performance. The reports tested in this group will migrate to DQM with no changes.
      2. Failure – Test Cases will fail if either or both of the Assertions fail.
        1. Failure of Output Comparison – You are presented with a side-by-side comparison of CQM and DQM output of the report with differences highlighted.
        2. Failure of Execution Time Comparison – This group of reports perform more slowly in DQM than CQM.

 

 

Resolution – Based on the results of the Test Cases, you know exactly which reports need attention.

    1. Consider reviewing the MotioCI Report Test Case Failure Detail. With that report, you can see if there are any trends or groups of reports which have similar errors. Make edits to the Framework Manager model and republish the package.
    2. Rerun the Test Cases in the DQM project until you are satisfied with the output and performance.
    3. In some cases, you may need to address individual reports which are failing Output Comparison or Time Comparison. Fix any issues.

 

 

Migration – At this point, all of your CQM reports have been run in DQM and you are confident that they produce the same output and execute in a reasonable time.

    1. In Framework Manager you can safely change the Query Mode Property to Dynamic and republish the package.
    2. As a final step, in the MotioCI DQM project, remove the Force DQM Query Mode property and set it to Default. Re-run your test cases and check the results. This will confirm that changes you have made to the reports and packages have not affected the output or performance.

The Celebration

I forgot to mention this last step. The celebration. It’s time to enjoy all the benefits of DQM and start looking for other projects.

Bonus Pro Tip

You can use the free MotioPI utility to find CQM packages and reports. To find packages with models set to use CQM download and install MotioPI:

  1. Open MotioPI and click on the Content panel
  2. Query for models by setting Query for Types to Model.
  3. Narrow the Source of your search to the appropriate scope. Reduce the scope to increase performance.
  4. Add a filter, select Text Property Model is Dynamic Query Mode = false.
  5. Click Search
  6. Export the results as CSV and open in Excel
  7. Copy the Cognos Search Path of the model for which you want to find reports
  8. Edit the Search Path of the model by removing “/model[@name=” and what follows from the string
  9. Paste the shortened model path string into a new Content Panel in MotioPI.
  10. Edit Query for Types to show Report
  11. Narrow the Scope appropriately
  12. Filter to use Text Property Package Search Path Contains by pasting in the shortened model path string
  13. Click Search
  14. The results will return a list of all the reports that use the CQM package.

Granted, this is a little complicated, you can’t do any testing, and it doesn’t manage your progress in a project, but, hey, it’s free. MotioPI can get you part way there with the first two steps of Assessment and Inventory, then MotioCI can take it from there.

 

Scroll to Top
As the BI space evolves, organizations must take into account the bottom line of amassing analytics assets.
The more assets you have, the greater the cost to your business. There are the hard costs of keeping redundant assets, i.e., cloud or server capacity. Accumulating multiple versions of the same visualization not only takes up space, but BI vendors are moving to capacity pricing. Companies now pay more if you have more dashboards, apps, and reports. Earlier, we spoke about dependencies. Keeping redundant assets increases the number of dependencies and therefore the complexity. This comes with a price tag.
The implications of asset failures differ, and the business’s repercussions can be minimal or drastic.
Different industries have distinct regulatory requirements to meet. The impact may be minimal if a report for an end-of-year close has a mislabeled column that the sales or marketing department uses, On the other hand, if a healthcare or financial report does not meet the needs of a HIPPA or SOX compliance report, the company and its C-level suite may face severe penalties and reputational damage. Another example is a report that is shared externally. During an update of the report specs, the low-level security was incorrectly applied, which caused people to have access to personal information.
The complexity of assets influences their likelihood of encountering issues.
The last thing a business wants is for a report or app to fail at a crucial moment. If you know the report is complex and has a lot of dependencies, then the probability of failure caused by IT changes is high. That means a change request should be taken into account. Dependency graphs become important. If it is a straightforward sales report that tells notes by salesperson by account, any changes made do not have the same impact on the report, even if it fails. BI operations should treat these reports differently during change.
Not all reports and dashboards fail the same; some reports may lag, definitions might change, or data accuracy and relevance could wane. Understanding these variations aids in better risk anticipation.

Marketing uses several reports for its campaigns – standard analytic assets often delivered through marketing tools. Finance has very complex reports converted from Excel to BI tools while incorporating different consolidation rules. The marketing reports have a different failure mode than the financial reports. They, therefore, need to be managed differently.

It’s time for the company’s monthly business review. The marketing department proceeds to report on leads acquired per salesperson. Unfortunately, half the team has left the organization, and the data fails to load accurately. While this is an inconvenience for the marketing group, it isn’t detrimental to the business. However, a failure in financial reporting for a human resource consulting firm with 1000s contractors that contains critical and complex calculations about sickness, fees, hours, etc, has major implications and needs to be managed differently.

Acknowledging that assets transition through distinct phases allows for effective management decisions at each stage. As new visualizations are released, the information leads to broad use and adoption.
Think back to the start of the pandemic. COVID dashboards were quickly put together and released to the business, showing pertinent information: how the virus spreads, demographics affected the business and risks, etc. At the time, it was relevant and served its purpose. As we moved past the pandemic, COVID-specific information became obsolete, and reporting is integrated into regular HR reporting.
Reports and dashboards are crafted to deliver valuable insights for stakeholders. Over time, though, the worth of assets changes.
When a company opens its first store in a certain area, there are many elements it needs to understand – other stores in the area, traffic patterns, pricing of products, what products to sell, etc. Once the store is operational for some time, specifics are not as important, and it can adopt the standard reporting. The tailor-made analytic assets become irrelevant and no longer add value to the store manager.