IBM Business Monitor 8.0.1 - DB2 or not DB2

BAM includes, and makes use, of Cognos Business Intelligence 10.1 ( aka Cognos BI ), which is installed with the product.

Cognos BI runs, in this particular instance, on one of the WebSphere Application Server (WAS) instances that forms the BAM infrastructure.

In my case, I'm following good practice for scalability and resilience by deploying BAM in the so-called "Gold Standard' deployment pattern, similar to IBM Business Process Manager.

This involves BAM ( or BPM ) being clustered across four discrete WAS instances: -

and is known as the "Remote Messaging, Remote Support, and Web topology pattern".

The IBM documentation: -

explains this, and other topologies, further.

So, as is evident from above, Cognos is deployed onto the Support cluster.

I had assumed that Cognos would be a well-behaved client of WAS, and make use of JNDI and JDBC to connect, via WAS, to it's underlying database - COGNOSCS.

However, now I'm not quite so sure.

I have already blogged about the need to configure WAS to make use of the 32-bit native DB2 drivers: -

and thought that was all I had to do.

However, I spent the best part of a day struggling to work out why Cognos wouldn't fully start.

In terms of logging, apart from the WAS SystemOut.log file: -

Cognos also has its own set of logs: -

$ ls -al /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/cognos/PCSR011.Support/logs

More specifically: -

$ cat cogconfig_response.csv 

and: -

$ cat cogserver.log 

but it's still not happy, as can be seen above.

In addition, I was seeing the following exception: -

DPR-ERR-2109 The dispatcher cannot service the request at this time. The dispatcher is still initializing. Contact administrator if this problem persists.

when attempting to access the Cognos Dispatcher URL: -

Despite reading scores of IBM documentation: -

In the end, I looked back through a design document that I'd recently written for an IBM Business Monitor client, who's actually using Oracle rather than DB2, where I'd recommended that they use Dynamic Query Mode, which makes full use of WAS' own JDBC driver, rather than needing a native, client-side driver.

This Technote describes this more fully: -

but, in essence, it's a matter of setting a generic JVM argument ( for the Support cluster member ): -

and restarting the cluster member.

Having done this, I still see: -

<snip>

EXEC, "[Content Manager database connection]", "Testing Content Manager database connection."
ERROR, "[Content Manager database connection]", "The database connection failed."
ERROR, "[Content Manager database connection]", "Content Manager failed to start because it could not load driver "com.ibm.db2.jcc.DB2Driver"."
FAILURE, "[Content Manager database connection]", "Failed."
</snip>

in cogconfig_response.csv, but Cognos now behaves itself perfectly, as per conserver.log: -

$ cat cogserver.log 

and I can access the Cognos URLs: -

and also add/remove/edit Cognos iWidgets within Business Space: -

One final point - it's sometimes necessary to modify the Cognos configuration outside of the WAS/BAM environment.

This can be achieved in one of two ways: -

(1) Use the cogconfig.sh GUI -

$ /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/cognos/PCSR011.Support/bin64/cogconfig.sh

This requires a GUI environment ( X11 or VNC on Linux ), which may be a problem for some Unix boxes.

For me, I accessed my RHEL VM as follows: -

$ ssh -X wasadmin@rhel6

and then started the tool: -

$ source /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/setupCmdLine.sh 

which loads the GUI up via my Mac's X11 client Xquartz.

(2) Use the wsadmin scripts that come with BAM: -

as per the following link: -

Of course, there is a third option - one that I would not recommend - to hand-edit the Cognos configuration file: -

This is, I believe, modified ( and, more importantly, validated ) by options (1) and (2) above.

As I say, this is a W-I-P. Next on my list is to find out whether I can configure the Cognos dispatcher to work with SSL.

I did try changing the dispatcher endpoints to HTTPS URLs, but then got exceptions such as: -

but that's a problem for another day.