Archive for December, 2011
If you are unable to render Cognos reports as PDFs but they run correctly as HTML, you likely are experiencing a font error. Check for this error to confirm:
CCLAssertError:0:Fatal: CCL_ASSERT_NAMED(bFoundFont, “[RSPdfOutputText::onDISetText] No font available for the text data”);
Cognos report PDF generation requires that you have:
- fonts installed on your Cognos server, and
- the Cognos configuration setting for fonts defined properly so those fonts can be found.
To resolve this, you need to go into Cognos Configuration and modify the settings for the Environment > Font Settings > Physical Font Location. The fonts included with your Cognos 10 installation should be found in your C10/bin/fonts directory. To see these fonts, make sure your font setting includes “../bin/fonts”.
In Cognos Content Administration, there is an Export feature to create a compressed file to load your Cognos content onto other Cognos servers. There is one section that is somewhat dangerous, in my opinion. This is the Directory Content options page. Imprudent use of these settings can overwrite your destination server’s security environment and data source connections!
What you need to understand is that when you select “Include Cognos groups and roles”, you are selecting ALL Cognos groups and roles – not just the ones associated with the package or packages you selected one screen before. And when you select “Include data sources and connections”, you are likewise selecting ALL data sources and connections. And if you leave the default selection in place that reads “Replace existing entries” you will overwrite all of your definitions on your destination Cognos server.
Now, depending on what you want to do, this might be OK. But on a standard single package migration, you will almost never want to deploy these options.
This might also be a good time to suggest backing up your destination server before you deploy exported content. Better to be safe than sorry!
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.
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.
<crn:value xsi:type=”cfg:systemPassword” encrypted=”true”>HJdtycSUJ&*JFfda</crn:value>
<crn:value xsi:type=”cfg:systemPassword” encrypted=”false”>PasswordValue</crn:value>
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.
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:
Exception in thread “main” java.lang.NoClassDefFoundError: Could not initialize class com.cognos.crconfig.CRConfigFrame
- 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.