Lots of interesting sessions today. I learned quite a bit about the Dynamic Cubes, which sounds phenomenal. And, as usual, got lots more swag and books.
The biggest treat for me today was a chance to meet and chat with some of the Motio people. A big shout out to Lisa, of LisaLovesMotio fame who is absolutely wonderful.
I had the chance to sit with Motio’s Adam Bonneau, who is a Senior Software Engineer, and Holly Rice, whom I’m sure everyone who is reading this is familiar with. Adam was gracious enough to show me an amazing piece of software he was working on that will revolutionize the way we test our reports in Cognos. Sadly, we only had about an hour to go through the software, so some of my information may be slightly off, especially the terminology.
Sadly, this article will be lacking in screenshots as I haven’t yet been able to beta-test the tool. The request is in, and if (when, right guys?) the tool does go into beta, you can be sure there will be screenshots left and right.
When he first loaded the page, I thought at first it was a local client tool. It is entirely webbased, but it acts and behaves like a thin client. The testing tools can be accessed in two ways, via the main application or through report studio. But before I can go into the tools themselves, a few words about the theory behind the tool.
Motio is building MotioCI with the concepts of assertions. The assertions essentially indicate what you are expecting from the report. This can be expectations before, or after the report has been executed.
An example of non-executed assertion would be checking naming conventions, or if reports are missing specific logos, or if you have queries that aren’t being referenced by any data containers. All of these can be determined by looking at the report XML.
Execution based assertions would be ones that look for specific elements in a report. When you run the report, you’re expecting to see the same values in a list as a static SQL statement. Or you expect two separate lists in two separate reports to have the same order of elements. You might also be looking for average run time, or run time variance.
When the user runs the testing tool, either from Report Studio or directly from MotioCI, you can select a list of predefined assertions to test. The predefined assertions are based on best practices, common corporate policies, and simple common sense. As each report, or dispatcher, or workspace, or package, or any other object in Cognos is tested, it will create a list showing the results of the status of each assertion. Failed, Succeeded, or Stale.
Clicking on Failed will show you exactly why it failed. If a specific query is causing local processing, it will tell you the name of that query. If there is a malformed list or crosstab, it will give you the name of that object.
Stale simply means that it has previously tested the report, but the report has changed since.
All of the data from the testing is saved in a table, which makes it extremely easy to burst a report to the authors and owners of the objects informing them of any problems that have been encountered. This will very quickly allow enterprises to ensure that every single object meets corporate guidelines.
By that point, I was already salivating at the idea of trying it on my own, but then he showed me Assertion Studio.
Assertion Studio, as the name suggests, allows admins to build their own rules. The complexity is astounding, and I strongly suspect that Motio could easily recoup their development costs on training in this studio alone.
The best way to describe Assertion Studio would be to picture a work flow. The report runs, you locate a specific list named VARIABLE, you tell it to find the first n rows, you run an SQL statement that returns the same number of rows, you compare the two result sets.
Or you open a specific report, and do an xpath search for a specific element, and a regex search for a specific pattern. All drill through definitions (element) pointing to \My Folders (pattern), for example. You can say if it finds the element, but doesn’t find the regex pattern then fail it. Or you can add another set saying it finds the element and it finds the regex then do something else.
Additionally, you can also do impact testing from inside MotioCI. From MotioCI you can say that you want to promote your package and a few reports. The tool will automatically determine which reports will be effected by the promotion, and it will allow you to specify which assertions you want to test. Similar to life cycle manager, it will test both versions with the assertions, on the target machine with the same credentials and data source, and allow you to see the results side by side. The difference is that you can very easily see the results of the assertions on the original and new reports. So you can see that the average run time on the original report was 5 seconds, while on the updated it’s only 3 seconds.
There was so much more to this tool, I feel like I’ve barely scratched the surface.
Sadly, I’m going to have to end this post before I detail all of the other wonderful people I’ve met in the Expo or sessions. But I will say that my pen count has increased to about 18. One of them is shaped like a rocket!