This Readme document contains late-breaking information related to Impromptu Web Reports.
Having a mixed install of Series 7 Version 3 (7.3) MR2 BI products and/or Cognos Planning or Cognos Finance 7.3 SP3 on the same computer as earlier releases of these 7.3 products may cause these earlier releases to fail. The problems occur due to backwards compatibility issues found in the following components: UDA, XALAN and Cognos Web Services (CWS) with Cognos Visualizer.
Note that you will not have these problems if the products on the same computer are all at 7.3 MR2 and SP3 level, or if you install 7.3 MR2/SP3 products on one computer and have other products running 7.3 pre-MR2 or pre-SP3 on a different computer. For example, having Upfront and PowerPlay 7.3 MR2 on MyServerA, drilling through or launching an IWR 7.3 MR1 report on MyServerB will not cause a problem.
If you cannot follow the corrective actions described below, then you must revert all products on the computer to their previous state by restoring them from the backup you made before installing the MR2 maintenance release or SP3 service pack.
The UDA problem may be experienced by the products in Table A, when only a subset of the installed products is upgraded to MR2 or SP3.
The symptoms experienced are varied - there is no common message that identifies the problem. Before working with Customer Support to isolate your specific problem you must eliminate this known UDA issue as being the root cause. Examples of symptoms that have been encountered with 7.3 pre-MR2 products include, but are not limited to:
The build numbers of the UDA component causing the problem are in the range 7.8.23148 to 7.8.24101. To check build numbers, review the contents of your cmplst.txt file located in the <install_location>\cognos\cer4 directory. UDA component build numbers can be found in the [Services] section of cmplst.txt. Note that this is only an issue if there are any products or components in the file that have a 7.3 pre-MR2 or pre-SP3 version.
To resolve this issue you must:
The XALAN problem will be experienced by the products in Table B1, when any of the products in Table B2 are upgraded to MR2 on the specified platforms.
The symptoms experienced depend on the upgrade scenario.
If PowerPlay Enterprise Server 7.3 is kept at the Initial or MR1 level, and any of the previously listed products in Table B2 is upgraded to MR2, then accessing a cube from Cognos PowerPlay Web Explorer using the Enhanced UI may either result in a blank screen or the following message:
Internal error - request failed.
Please contact your administrator
If Cognos Visualizer Server 7.3 is kept at the Initial or MR1 level, and any of the previously listed products in Table B2 is upgraded to MR2, then a Visualizer message is displayed:
Web Browser:
There was an error in the XSL Parse engine.
The return code was: -1
The data returned was:
The error occurred during loading the stylesheet (/viz/templates/en/ZFPIndexPage.xsl), please ensure the stylesheet is valid
Please contact your administrator
Table of Content:
There was an error in the XSL Parse engine.
The return code was: -1
The data returned was:
The error occurred during loading the stylesheet (TOC.xsl), please ensure the stylesheet is valid
Please contact your administrator
The build numbers of the XALAN component causing the problem are in the range 1.2.659 to 1.2.868. To check build numbers, review the contents of your cmplst.txt file located in the <install_location>\cognos\cer4 directory. XALAN component build numbers can be found in the [Third Party] section of cmplst.txt. Note that this is only an issue if the file also contains a pre-MR2 7.3 version of PowerPlay Enterprise Server or Cognos Visualizer Authoring or Server.
To resolve this issue you must request from Customer support a new post-MR2 hot site build for all the products in Table B2 that you want to upgrade to MR2.
The CWS problem will be experienced by the products in Table C1, when any of the products in Table C2 are upgraded to MR2 on the specified platforms.
Cognos Web Services, only when used with Cognos Visualizer Server |
The symptoms are experienced when Cognos Visualizer Server 7.3 is kept at the Initial or MR1 level, and any of the previously listed products in Table C2 is upgraded to MR2. The error messages displayed are dependent on the platform as follows:
On HP-UX the following message is displayed when you configure:
configcp ->/usr/lib/dld.sl: Unresolved symbol: XML_ParserCreateNS (code) from ./libvizxml.sl core file from 'vizwebcws' - received SIGABRT configcp ->/usr/lib/dld.sl: Unresolved symbol: XML_ParserCreateNS (code) from ./libvizxml.sl core file from 'vizwebcws' - received SIGABRT
On Solaris the following message is displayed when you run some CWS requests:
Application Error
The following error has occurred:
The request failed because the server timed out. No Query Processor was available to handle the request.
The build numbers of the Visualizer Server Dispatcher or Query and Report Processor components causing the problem is in the range 600 to 1005. To check build numbers, review the contents of your cmplst.txt file located in the <install_location>\cognos\cer4 directory. Visualizer Server component build numbers can be found in the [Main Applications] section of cmplst.txt.
To resolve this issue you must request from Customer support:
You will not experience this problem if you have a mixed install of RTM/MR1 and MR3 or MR2 and MR3.
You will encounter errors in Configuration Manager on Windows during the apply process if you install any 7.3 Maintenance Release (MR) of Impromptu without also installing Impromptu Web Reports 7.3 MR1 or higher. The same errors occur if you install an Impromptu 7.3 Maintenance Release without installing Impromptu 7.3 MR1 or higher. The errors occur only when configuring Impromptu and Impromptu Web Reports that are both installed on the same computer.
Depending on your operating system, when you apply your configuration in Configuration Manager, you may see a General Protection Fault, or see some or all of the following error messages:
iwcreatedb.exe has generated errors and will be closed by Windows. You will need to restart the program.
There were problems during the apply. Do you want to activate?
If you answer "Yes", in addition to a pop-up message indicating that the activate action failed, the following message appears:
The ordinal 124 could not be located in the dynamic link library CogSP7_1.dll.
If you answer "No" then no additional error messages appear.
To successfully configure both products on the same computer, you must install both products at 7.3 MR1 or higher before you apply your new configuration.
After publication of the IWRCommand Developer Guide and related documentation, the path to the WSDL file was changed in order to clearly identify the schema used (Version 2). The path should read http://server_name/cognos/cgi-bin/imrap.cgi?wsdl-v2. Both Version 1 and Version 2 schemas are supported in the current release.
When you upgrade to Series 7 Version 3, you can use Adobe 5.x or 6.x to view your PDF output. However, there is a known Adobe issue that prevents previously saved PDF output containing drill links created in IWR Series 7 Version 1 or Version 2 from working with Adobe Acrobat Reader 6.x. This change in Reader behavior has been reported to Adobe. However, Adobe has not provided indication of a resolution.
The underlying issue is that Adobe made changes in Acrobat Reader 6.x so that it no longer expands relative URLs embedded in PDF documents in the same way that it did in earlier versions of the Reader. Acrobat 5.x and earlier versions of the Reader were compliant with RFC 1738/2396 (Section 5.2) Internet standards for relative URLs and correctly expanded the relative URL links to complete URLs; as of version 6.x of Reader, this is not the case. Relative URLs are used for all IWR report-to-report and IWR-to-CQ drill links.
Series 7 Version 3 now creates drill links using a "new" style embedded format that will work with both Acrobat Reader 5.x and 6.x. This does not resolve the Adobe issue for previously saved report outputs containing "old" style drill links. To enable PDF reports to work with Reader 5.x compatible "old" drill links and Reader 5.x and 6.x compatible "new" drill links, you can do the following.
Install Adobe Acrobat Reader 5.x and Adobe Acrobat Reader 6.x in separate directories on your hard drive. If you want to use "old" drill links from previously saved report outputs, manually pre-start Acrobat Reader 5.x from your desktop, and this version will be used as the Acrobat Reader plug-in. If you want to use "new" style drill links, you do not pre-start Acrobat Reader. The latest version of Acrobat Reader that you installed will be started automatically as the Acrobat Reader plug-in.
Accessibility references in existing localized documentation imply that the accessibility features have been localized. To date, the accessibility features are limited to English, with the exception of the Upfront Accessible theme, which was recently made available in French. Currently, accessibility features are not available in any other localized products.
When you install and configure Impromptu or Impromptu Web Reports to enable Accessibility, opening a report in Upfront causes the Jaws screen reader to read the frame information for the embedded Adobe application, not the content of the PDF file.
There are several workarounds for this problem:
The following information will be added to the Impromptu Web Reports section of the Upfront Developer Guide, when this document is next reissued.
To automate prompt caching and refresh, your script must enable the setstatic and refreshcachedprompts attributes for all items in your Upfront NewsBox. You apply the reportattributes element type in the same way as you use runaction, executing it against all reports in your published report set.
Note: A setstatic declaration is not needed if this attribute is already set (value: 1). But if it is not set, refreshcachedprompts cannot be set.
The following example sets both required attributes:
UpfrontCmd.exe -u administrator -p "" -sservername:port"<SetNewsItemProperties>
<Id>53465478b4d211d8bac8e210e710e99f</Id>
<Provider>
<pair><name>setstatic</name><value>1</value></pair>
<pair><name>refreshcachedprompts</name><value>1</value></pair>
</Provider>
</SetNewsItemProperties>"<?
On execution of the above command, the following output is produced:
xml version="1.0" encoding="windows-1252" standalone="yes"?>
<Resultxmlns="http://developer.cognos.com/schemas/upfront/">
<Standard_ResultResultCode="Success"></Standard_Result>
<NumberOfObjectsModified>1</NumberOfObjectsModified>
</Result>
To see which NewsItems have report prompts, use DescribeNewsItem and include the lines relevant to your request, as excerpted below:
<DescribeNewsItem RequestId="1">
<Id><%id%></Id>
<module name="provider">
<mod>
<reporthasprompts type="reportattributes"/>
<runaction type="runactions.run"/>
<reportfilename type="reportattributes"/>
</mod>
</module>
</DescribeNewsItem>
Note: Setting these two attributes is equivalent to selecting the Cache Picklist Prompt Values and Refresh Cached check boxes on the Web interface, but the second box will never appear selected on the UI. Instead, to verify that your script has refreshed the cache, try running a report, noting the execution time, changing a cached value, and then running the report again. The new value should be picked up (refresh is working) and there should be a gain in performance (caching is set).