Cognos facts

Posted on by

Issue:
We had several issues on a new Cognos server:
Issues during installation:

  • After uninstalling Cognos, users would get a “not authorized” error message when opening blogs and wikis
  • The Cognos install wouldn’t verify. It complained about problems connecting to the SQL server (suggesting wrong credentials)
  • The transformer cubes wouldn’t build

Issues after installation:

  • The numbers of the old and the new Cognos server wouldn’t correspond with differences up to 30% for unique logged in users
  • The numbers of unique users for the last month wouldn’t correspond to the count of the last login table in SQL for a users with a last login date in the last month
  • It would not be possible to use a custom timerange for the content metrics
  • Content metrics for more than 6 months ago wouldn’t show

Explanation:
As I described in my article about the Core Group Coordinator, our Cognos server was installed on the same server as the Deployment manager. I decided to split them and install Cognos on it’s own server. As the old Cognos server was already no longer working properly at the time of the move (in hindsight due to issue #3), I decided to go for a fresh install. In the process of installing Cognos on the new server, I uninstalled it after the initial install, which was when issue #1 arose. The same issue was seen during the uninstall of the old Cognos server, but at least I was prepared for it by then. For issue #3 as well as the issues after the installation I opened a PMR/case. Issue #3 is documented on the IBM site, but not well and it’s hard to find.

Solution:
As the authorisation errors pointed in the direction of WebSphere’s security.xml and that file also turned out to have a modification date of around the moment we received the first incidents of users, I grabbed the security.xml from the backup and compared it with the current file. It turned out that the uninstaller had changed this particular line in the security.xml:

<singleSignon xmi:id="SingleSignon_1" requiresSSL="true" domainName="" enabled="true"/>

As you might notice, the domainName is missing here, which messes up your authentication mechanism. I consider this a serious bug in the uninstaller of Cognos. Be aware of it.

The second issue I ran into were problems with connecting to the SQL database. At this client we use MS SQL as SQL backend. For MS SQL you have to leave the metrics.db.local.name property blank in the cognos-setup.properties file. This is properly documented by IBM… if you can find the documentation :-).

With this problem fixed our verification (cognos-installation-verify) succeeded successfully. Regretfully that didn’t mean all our problems were solved. The next step after the verification is to build the Transformer cubes and this process would just end after a minute or 2 with a fail. This turned out to be caused by the fact that the Transformer model is using a Framework Manager package that contains relatively long requests. The solution for this is described in this document. We had configured the Cognos BI URLs to use the IBM HTTP Server so we had to change the KeepAliveTimeout parameter. A setting of 30 sufficed to get the transformer cubes to build. That’s quite a change from the default 10 and the recommended setting in the Connection’s tuning guide of 5. I haven’t seen any consequences yet of this higher number.

With this setting our transformer cubes built successfully and we could put the server into production. Then over a period of a couple of weeks we got mention of the post-installation issues. It turned out that the previous Cognos server had reported too high numbers for the number of unique users. I measured this by getting the number of rows from the PEOPLEDB.EMPINST.PROFILE_LAST_LOGIN table for last logins after the specified period (January 2018 in our case). This number was far lower than the reported number of unique users. The numbers of the new Cognos server weren’t correct either however. When at the 31st of May I took the number of rows since the 1st of May, I got a number which was about 10% higher than what Cognos reported for May. IBM has since then confirmed that these numbers are supposed to be equal and is investigating why they aren’t.

That you can’t use a custom timerange on Content turned out to be working as designed. The Metrics table doesn’t retain all the info that would be required for this query as it would otherwise become too big. Another interesting comment from IBM was that the Metrics table only keeps metrics of the past 6 months. That does mean that if you remove your old powercubes and build them from scratch (using build-all.bat/sh) you loose information of the period before that last 6 months, so make sure you don’t remove your old PowerCubes or run the build-all command after the initial building of the cubes. That’s information I couldn’t find anywhere online and I’ve seen documentation that suggests to just rebuild your powercubes from scratch if you have any problems with Cognos.