CognosPaul’s Bag o’ Tricks!

Back in August I presented at BACon on the extensions that I wrote for PMsquare, and now I’m very happy to announce that we’re giving them away for free! We actually started giving them away for free at the conference, but I’ve been a bit too lazy busy to actually get around to writing this.

First you might ask, what are extensions? As I wrote about in a previous article extensions allow you to modify the UI, adding or removing features as you like. One of the best things about adding new features is using the internal JavaScript API in Report Studio, making it do what you want it to do instead of what IBM wants it to do.

One of the features of that article was an early version of the Clipboard Editor. The basic structure is there, but it’s been improved immensely since. My good friend Michael Hoggard and I worked on it to add a new feature, and to clean it up a little.

But that’s not all! I’ve also added another new and awesome feature. One of my biggest issues with building reports is testing out different prompt scenarios. We could run the report and manually set each prompt, but that can be incredibly time consuming. You could force Cognos to prompt you, by validating or by clicking on “view generated SQL/MDX” but that’s clunky. You also can’t view the currently set parameters, and if you want to change anything you have to clear the parameter values and start again.

To get around this clunky interface, I’ve decided to write my own. I’m very proud to present the aptly named “Parameter Editor”!

This interface allows you to add, remove, and change session level parameters in the report. What this means is you can now see what scenario you’re running the report in, without having to go through the tedious process of running the report, selecting the prompts, and rerunning. But that’s not all! When running in interactive mode, you an also use it to see exactly what parameters were sent through a drillthrough. When previewing a report, you can also play with the parameters. See what happens when you change them from one scenario to another. In the below animation I’m testing several different scenarios, where one fails for some reason!

As you can see you can set both the display and use values. The plus button allows you to add multiple values for each parameter. If both boxes are empty, the script ignores it and doesn’t set a value for the parameter. If only one of the boxes is empty, it will use the value from the other box.

These are session level parameters as opposed to report level. It’s an important distinction. The parameters are set on the report development session only – they aren’t saved with the report.

I do have additional tools that I’m planning on adding to it. Data Modules present a host of opportunity. I feel there is a lot of room for improvement in the UI, especially when it comes to quickly editing multiple items.

And finally, you can download this extension from the PMsquare website here: https://pmsquare.com/freebies

The search prompts haven’t gone through many changes in Cognos since version 8. Despite many requests, changing the default search type (from starting However, one big whopping change is the popup element containing the search items is no longer inside the search control. Instead it’s hidden somewhere else on the page, with nothing tying it to the actual control.

This makes the old script useless, and finding that popup is incredibly difficult. In Cognos 11.1 the method for finding the popup is promptElement._FZH._9FF while in 11.0 it’s promptElement._REG._FZD. This obfuscation means we have to rely on trickery and shenanigans.

Look away now if you value your sanity

prmptElmLoop: //yes I'm using a label here. I'm not feeling at all defensive about it.
  for(var a in  $(prmptElm).find('.clsComboBox')[0]){
    
    if(typeof($(prmptElm).find('.clsComboBox')[0][a])=="object" ){ //if the object itself is an object...
      for(var b in $(prmptElm).find('.clsComboBox')[0][a]){ //...dig deeper.
        if($(prmptElm).find('.clsComboBox')[0][a][b].classList=="po_clsListView_dropdown po"){ //this identifies the actual popup element. 
          $($(prmptElm).find('.clsComboBox')[0][a][b]).find("tr:eq("+(opt-1)+")").trigger('mousedown'); //finds the correct table row and performs a mousedown. 
          if(resizeOptions) prmptElm.style.width='unset';
          break prmptElmLoop;
        }
        
      }
    }
    else continue;

  }

In order to find that options popup, we’re looping through the prompt element and examining each attached method. If it’s an object, we go deeper. Finally we’ll find a method that’s a pointer to the element (which we can identify using the class), and then it’s just a matter of triggering a mousedown event on the correct row.

In order to use it, you need to give the search prompt a name, like mySnS. The custom control needs to have the following configuration:

{
"promptName": "mySnS",
"option": 2,
"resizeOptions": true
}

That’s looking for the prompt name mySnS, selecting “Starts with the first keyword and contains all of the remaining keywords”, and then resizing the options list.

The options are as follows:
* 1 – Starts with any of these keywords * DEFAULT
* 2 – Starts with the first keyword and contains all of the remaining keywords
* 3 – Contains any of these keywords
* 4 – Contains all of these keywords

Important note! I’ve tested this on 11.0.5 and 11.1.0. I have no reason to think it won’t work on other C11 versions but I can’t promise it will continue working. Hopefully methods like this will be exposed with a consistent name in future versions.

The attached zip contains the report XML and the JavaScript.
search-Default.zip (7549 downloads)