Archive for category Cognos
Avoid Renaming Cognos Data Source Connections
Posted by Scott Andrews in Cognos on December 15, 2011
A recent client of mine was in the habit of naming Cognos data source connections after the environment they were connecting to, as was the custom of the underlying Oracle TNS names. So a connection to a DEV, TEST or QA source would have some notation of this in its name, such as MyConnection_DEV. This worked fine until it came time to migrate the project from one environment to another, and then this data source connection configuration turned into a real headache.
Because each environment had its own unique data source connection name, it was impossible to simply export Cognos packages from one level and import into another. Modifying FM data models and republishing them was necessary, which was a lot more work than it should have been. One developer even complained that he felt like he had to start each project over every time he migrated it. I think that is a good way to look at a Cognos data source connection – a starting point. Modifying this starting point (by which I mean its name, not its attributes) means you are in a sense starting over. A better approach is to maintain a standard name across your DEV/QA/PROD environments so that you do not have so much extra work every time you migrate. With this name constant, you can set your attributes in each environment freely to connect to whichever database you desire. This prevents having to republish packages or remap data connections at every turn.
Manually Modifying Cognos Configuration in Unix
Posted by Scott Andrews in Cognos, Unix on December 13, 2011
If you have a simple Cognos Configuration change to make or if X Window GUIs are not an option, there is another way to make cogfiguration changes. Instead of running Cognos Configuration through the GUI interface you can edit the cogstartup.xml file directly to change your Cognos Configuration settings.
There are some things you need to do before you edit your cogstartup.xml file. The first is to stop the Cognos service. This can be done with the Unix shell command “./cogconfig.sh -stop” This shell script is found in your c10/bin directory.
Next, back up your cogstartup.xml file. If you corrupt the cogstartup.xml file, Cognos services may not restart. You need the backup in case you need to roll back your Cognos Configuration changes.
When you open your cogstartup.xml file, you will notice that some of the information in this file such as user names and passwords are encrypted. You will not be able to retrieve the previous settings of these parameters using this method but you can successfully change them. For best results, open and edit the file in a Unix editor – do not edit in Windows and import back to Unix. The file needs to be encoded in UTF-8.
To change unencrypted parameters, simply modify their values in the xml file.
To change encrypted parameters, remove the encrypted string and type the new value in plain text. Then change the encrypted value to false.
Original XML:
<crn:parameter name=”disp_sharedsecret”>
<crn:value xsi:type=”cfg:systemPassword” encrypted=”true”>HJdtycSUJ&*JFfda</crn:value>
</crn:parameter>
Changed XML:
<crn:parameter name=”disp_sharedsecret”>
<crn:value xsi:type=”cfg:systemPassword” encrypted=”false”>PasswordValue</crn:value>
</crn:parameter>
When you restart your Cognos Service, the value will be encrypted and the encrypted flag will be set to true.
To restart your Cognos Service, run the Unix shell command “./cogconfig.sh -s” If you experience problems with the restart of your service, revert to your cogstartup.xml file backup and try again. For more information on this topic, see the IBM article on it here.
Java Errors when running Cognos Configuration in Unix
Posted by Scott Andrews in Cognos, Unix on December 5, 2011
If you get the following errors running the cogconfig.sh shell script in Unix to start Cognos Configuration, you likely have a problem with your X Window configuration:
./cogconfig.sh
Using /usr/jdk/jdk1.6.0_22/jre/bin/java
02/12/2011,12:18:53,Err,java.lang.ExceptionInInitializerError, com.cognos.crconfig.CRConfigFrame.<init>(CRConfigFrame.java:109)
Exception in thread “main” java.lang.NoClassDefFoundError: Could not initialize class com.cognos.crconfig.CRConfigFrame
at CRConfig.main(CRConfig.java:305)
To resolve:
- Ensure you have X Window capable software installed on the machine in question, such as Exceed.
- Ensure that your Unix interface client has X11 forwarding enabled. In PuTTY, this is listed under Connections > SSH > X11.
Cognos Transformer Problems in Unix
Posted by Scott Andrews in Cognos, Unix on November 17, 2011
Transitioning a cube from a Windows environment to a Unix environment can be tricky. Your cube may build perfectly in a local-build on Windows, only to give you errors like this in a server-build on Unix:
Start processing data source ‘My Data Source’.
Reading source data.
(TR3703) The user ID or password is either missing or invalid. Please re-enter the credentials.
End processing 0 records from data source ‘My Data Source’.
While it appears as though you have a problem with a data source in Unix, the real problem lies with your signon credentials. Once you transition from a local-build to a server-build in Transformer, you need to have a valid Signon defined. But when you do this, there is no way to test to see if your Signon Credentials will work – short of moving your Transformer model to the Unix server and building it. If your signon credentials are invalid, you will get a message like the one above.
So check the Signon Credentials and that should solve your problem. The apparent reference to your data source is a red herring.
Oracle Configuration Errors in Cognos 10
Posted by Scott Andrews in Cognos, Oracle on November 14, 2011
If you ever get the following error when attempting to connect Cognos Framework Manager with an Oracle data source, you have an Oracle configuration problem:
QE-DEF-0285 The logon failed.
QE-DEF-0325 The logon failed for the following reason:
RQP-DEF-0068 Unable to connect to at least one database during a multi-database attach to 1 database(s) in:
DataSource
UDA-SQL-0432 Unable to locate the gateway “cogudaor”
If you have a valid Oracle client installed on your machine (Oracle 9 or up for Cognos 8/10), then check your System Environment variables. I had a recent experience at a client where both Oracle 8 and Oracle 10 client software were installed on a machine. Because the ora805\bin reference appeared before the ora10\bin reference in the Path variable, Cognos Framework Manager could not connect to the data source and reported the above error. Simply by changing the order of those references in the Path variable, the configuration problem was resolved.
Cognos 10 Audit Package on Oracle 10g
Posted by Scott Andrews in Cognos, Oracle on November 9, 2011
While implementing the Cognos 10 Audit package on an Oracle 10g system, I ran into a problem with one of the pre-defined reports. This one report would fail each time, reporting an Oracle error: ORA-12704 character set mismatch.
My first Google search indicated that there was a problem with Cognos 8.3 Audit package on Oracle 10g. A modification was required in the Framework Manager model, changing all references from nVarChar to characterLength16. Although I was running Cognos 10, I decided to try this fix out. It did not adversely affect my Audit package, but it did not resolve the issue either. As all the model query subjects were working as expected in the original Framework Manager model, I reverted back to it and decided to focus my efforts on the Report Studio report.
Eventaully I isolated the problem down to three If/Then/Else statements in the report, and then realized it was not able to compare query results against an empty string. I casted this empty string into a nvarchar and the problem was resolved:
IF [Audit].[Audit Report Table].[Audit Report Column] = ” THEN…
became
IF [Audit].[Audit Report Table].[Audit Report Column] = cast(”, nvarchar(1)) THEN…
Messing with Roles can be Dangerous Business
Posted by Scott Andrews in Business Intelligence, Cognos on November 5, 2011
In the Cognos 8/10 security environment, there are a number of pre-defined Cognos roles that under-pin the entire Cognos security infrastructure. Technically, you can move, rename or delete these roles but do so at your own peril! Cognos recommends not changing these security elements and I’ve had a recent experience that highlights exactly why.
A client of mine, in an attempt to clean up and manage their security environment, moved all of the predefined roles into another directory. On the face of it, this seemingly innocuous act appeared to be no big deal. But then they also installed Cognos Adaptive Analytics. The new Cognos product install did not see the predefined roles, and appeared to have recreated all of them in their original location. This of course caused duplication of all the predefined Cognos roles. The security environment became very confusing as it was very difficult to distinguish between the identically named roles.
Attempting to clean up the duplicates caused untold havoc with users rights and privileges. Some of the old Cognos roles defined certain rights and some of the new ones defined others. Deleting the copied Cognos roles removed most rights under the Capabilities tab and Public Folder rights. All told, a lot of clean up and reconfiguration was required.
So if you get the notion to change your pre-defined Cognos roles, take Cognos’ advice and just don’t do it!
Can’t anybody here play this game?
Posted by Peter Beck, CBIP in Business Intelligence, Client Relations, Cognos, Information Technology, Tech Trends on October 6, 2011
Can’t anybody here play this game? – Casey Stengel
IBM has a new paper out on that age-old question – why do BI projects fail, and what can be done about it? The paper is entitled “Bridge The Gap Between BI Best Practices and Successful Real World Solutions“. The first few pages are the usual marketing fluff, and they generally contradict the “meat” of the paper, which begins a little further in. That is, once again, we see a particular technical/product solution proposed to solve what is not a technical problem. This is accomplished by simply asserting that this particular technical solution maps neatly over the business problems Gartner has uncovered. If you are brave enough to hack your way through to where the Gartner material begins there are some interesting discoveries to be made. By “interesting” I mean “depressing”. Taken as a whole the paper can be thought of as a fine example of what the Gartner research itself reveals.
The paper begins with a set of now-common observations: that BI programs need a business sponsor, that IT ends up “selling” BI to the business (and doing it badly), that BI tends to get “stuck in reporting”, and that “Technology is rarely the culprit if the BI project is considered a failure”. All well and good. And then at page 2 we read, in bold, all-caps:
IBM COGNOS EXPRESS: THE KEY TO A WINNING BI STRATEGY
I see. IBM’s technology will be the “key”. That’s a relief. Gap closed! Close the document and move along.
But if I keep reading, I discover that the folks at Gartner have done some research on the practice of BI programs, most of which are not particularly related to technology (on the contrary.) The results aren’t good. That doesn’t mean they are surprising, of course.
The Gartner section of the paper is called “The BI(G) Discrepancy: Theory and Practice of Business Intelligence”. They break out 9 aspects of BI implementation, and discuss what should be done in each aspect, versus what their research indicates is actually taking place in the real world. The results are a confirmation of what most of us “in the trenches” feel intuitively: there seems to be little correspondence between what should be done, and what actually is done. And technology isn’t going to change that.
The whole thing is worth a read, but the most eye-popping turns out to be the discussion of - BI strategy! That thing that the latest IBM product will provide a “key” for! Turns out only 2% of organizations informally surveyed in mature markets had anything called a BI strategy. That’s not a typo. 2%. And this is among Gartner clients. Let that sink in for a second, and then consider this quote from the paper:
“Nearly shocking results are obtained when reviewing the so-called BI strategy documents. Almost never would those qualify as strategy in Gartner’s opinion. Quite often a strategy is merely a statement like “We have a Microsoft BI strategy” or “Our BI strategy is SAP” indicating what products the organization is using or planning to implement. Other times the “strategy” is merely an architecture diagram… This is as if the Ferrari Formula 1 team described its racing strategy as “using Bridgestone tires, Shell fuel, a V8 engine and red paint.”
I like the use of “Nearly” to suggest seen-it-all unflappability on the part of the author.
The analyst goes on to describe the initial 2% number as “rather optimistic” (raw-ther, old sport!), blows some dust off the dictionary definition of “strategy”, and then (perhaps beginning to get a little exasperated, and reaching for the bottle) muses that:
“The question could be expanded to: Do executives even understand what constitutes a strategy?”
Yes! It does appears that the question could indeed be expanded to that!
Everyone, and I mean everyone, I have ever encountered in this industry who works above the level of writing reports struggles with the problems outlined in the Gartner material every day. And yet here we are, decades now into the world of BI, and it doesn’t appear to be getting any better. BI still seems to be mired in confusion as to what it is – what is its identity within the organization. The default position seems to be: it’s a technology. IBM et. al. seems ok with this, and I can’t blame them. As long as the discussion can be returned to “BI is a product (and our product is the best!)” they seem to be happy, as they have a tangible thing to sell. My own feeling (obviously) is whenever the real answer to this question is found, it won’t be “Cognos” or “Microsoft Analysis Services” or any other piece of software, and I say this as someone who spends his days with the products in front of him.
If executives don’t have a grasp of the rudiments of BI strategy (or perhaps strategy in general), it seems that the best anyone can do is try to keep pushing technology. At least that seems to be what IBM’s “strategy” is with this document – provide a high-level summary, name the product and map it to what is “supposed” to happen in an organization, and hope for the best – and that no-one keeps reading. Or what the Gartner analyst, in the section on what goes on in the real world when it comes to the business case for BI, characterizes as a “leap of faith”. I’m not kidding, they actually use those words to describe what Gartner clients are doing to justify their BI investments.
Check the paper out, it’s worth a read.
Cognos 10, Report Bursting and Saving Output to File
Posted by Peter Beck, CBIP in Business Intelligence, Cognos on August 7, 2011
(The instructions below present setting up C10 for output to a file location on the network within the context of bursting reports, but there is no reason you can’t set up file output for the normal manual or scheduled execution of reports – PB)
Cognos 10 (like all versions of Cognos BI since ReportNet) has a fairly straightforward way of configuring a given ReportNet report for “burst” output – that is, for generating a set of reports from a specific report specification, where the only difference between the reports is some selected value. Consider a generic sales report, where we have 2 different sales reps.
We might want to “burst” the report across the sales rep identifier, so we would get one report for each sales rep. We could then distribute each report to the appropriate rep.
Setting a report up for bursting is performed in the Report Studio interface. Under File… Burst Options we set how the report will burst. We also have the option of selecting how the report will be distributed – either as an email or as a Cognos directory entry. The value for the both the burst specification and the distribution must come from a query in the report.
However, it is quite possible that we might want the output to go out to a file location instead. To set this up requires a little bit of configuration, but it is quite straightforward. In versions of Cognos BI prior to 8.3 this was a bit limiting – we essentially had only one destination we could output to. In even older versions controlling the name of the output report was a pain as well – we needed secondary scripting to re-name the report in the output file based on an associated XML file. This is no longer necessary.
Note about the instructions below: this is not limited to burst output – setting up C10 for file system output can be useful for saving any report you run to the file system – a manually run report, a scheduled report, or burst report.
First, we need to create a shared folder on our server. This can be any name, but should not be located in the installation directory. The user under which the C10 service runs must have full rights to the folder. In this case I’ve created a folder called CognosOutput.
Now I must start Cognos Configuration, and navigate to Actions… Edit Global Configuration:
Under General, I enter the value of my \\server\share combination, prefixed with file://
Click the Test button, and then OK.
Returning back to the main configuration screen, select Data Access… Content Manager, and set the Save Report Outputs… value to True
You are now set up for report output. IBM notes that it is very important that you not be running your Cognos installation as “localhost”, but rather under the name of the server the service is running on.
These steps have set up the top-level directory under which we can save report output. Within Cognos Connection we must now define what the actual destination output locations within this folder will be.
Open up IBM Cognos Administration from the Launch menu in Cognos Connection. Then navigate to the Configuration tab and select Dispatchers and Services, and in the upper right side of the screen select Define File System Locations:
Give the new location a name under the Name section, and (optionally) a description and screen tip. Finally, give it a location – this is where it will appear under the output file folder you set up above. You can use the “\” character to nest a folder beneath another folder. You do not declare the top level folder, so in this case NewOutput could be used as a location, but not CognosOutput\NewOutput.
Now you are ready to burst the report to the file system! Select Run with Options for the report in Cognos Connection, and under Delivery method select Save the Report. Then click Advanced Options and on the the next page, select Save To the Filesystem, and select Edit the Options
In this case I have selected “New Output”, which I have set up to output to NewOutput/NewOutput1 on my file system. I have also renamed the report to August_Sales_Reports
Select OK, and select Burst The Reports from the radio button on the lower left side. Then click Run.
The reports will now be burst to the CognosOutput/NewOutput/NewOutput1 folder:
A couple of quirks: Cognos will append the language setting to the name of the report. It will also append the value by which the report was burst (useful for organizing the reports). It will also output a second XML file that describes the report.
SQL Server Analysis Services Cubes and Cognos PowerPlay
Posted by Peter Beck, CBIP in Business Intelligence, Cognos, Information Technology, SQL Server on July 11, 2011
SQL Server Analysis Services is a popular OLAP product included with Microsoft SQL Server. Especially since SQL Server 2005 this product has been quite powerful and fairly easy to develop with. SQL Server provides the Business Intelligence Development Studio (BIDS), a Visual Studio –like product to aid the development of Analysis Services cubes.
For browsing and reporting on a cube, however, choices have been more limited. Excel provides a good choice, especially since Excel 2007, which contains enhancements that make creating cross-tab reports easier than previous versions.
If your users are committed to Cognos PowerPlay, you can use this tool as well. Setting up a MS Analysis Services cube for browsing with PowerPlay is a little more involved than a regular Cognos cube, but is still quite easy to do.
First, you need to access a tool called PowerPlay Connect. This can be found in the Tools folder of your Cognos installation:
The executeable is ppconnct.exe.
This tool is used to create a binary “pointer file” with a .MDC extension. This file, once created, will behave like a PowerPlay OLAP Cube, but the underlying cube will actually be (in this case) a Microsoft Analysis Services cube.
Start PowerPlay Connect, select File… New to create a new MDC file. For the database type, select MS SSOS (ODBO):
You have a couple of choices next. If you know the server name for your instance SQL Server Analysis Services you can enter it in the next line, under Server:[Port]. In this case I can enter “localhost”, as I am serving the cube from my local machine.
Alternatively, I can select the … button beside Database, and I will be presented with the Chose a Remote Cube dialog box. In this case I then select Microsoft SQL Server OLAP Server at the bottom, and then select a connection I have already created previously using the tool. In this case the connection is called local. I’m then presented with a list of databases available on the connection “local”.
I can then open SSAS_Adventure_Works and the cube that exists in this particular database. A database might have many cubes available in it.
Alternatively I could create a new connection, by clicking on Connections… and then clicking Add. I enter the name I want to give the connection, and then the name of the server, and select Microsoft SQL Server OLAP Server and MSOLAP as the provider:
Since I selected the cube SSAS_Adventure_Works, we see this in the details of the connection string:
I can now click File… Save and save this as an .MDC file:
The file appears as a normal MDC cube, but is really just a pointer file to the SSAS database server:
Using PowerPlay, I can now open the MDC file as if it were an ordinary cube. I can navigate it generally in the same way I would navigate a Cognos cube, althought some things such as Measure Groups that are part of the Microsoft approach to OLAP do not behave exactly the same way. Meaures appear as a single list, much as they do in Cognos cubes.
PowerPlay Connect MDC files can be put on the network, or shared as any other file, and will work as long as the user has access to the underlying Microsoft database.

















