Custom templates in DNG’s Quick Print menu

When you register a custom template  DNG the template will appear in the Reports->Generate a Document-style report and in the “Quick Print” menu.


This may seem convenient but it is actually a problem since the Quick Print  ( Generate a Report for this View) menu is not functionally equivalent to the Reports one for custom reports.

The difference between using one or the other is in the URL that DNG will configure the report with. The URL ( the data) set by DNG’s Quick Print function is the URL for the current view and not the URL of the module or of the selected artifact(s).  The view data is meant to be used with templates using the View schema of DNG but as that schema is private no custom templates can use it, only OOTB ones do. So as the data will not match the template schema the reports will always be empty.

Until this issue is fixed and custom templates are hidden from the Quick Print you should not use custom templates from the Quick Print option of DNG. All custom templates should be used from the Reports->Generate a Document-Style report menu.

Defect: queries can be pasted in master pages

We’ve recently discovered a defect in RPE Document Studio affecting RPE and older: queries can be copy-pasted from the main template content in the master page header/footer section. Once the a template is saved it cannot be opened again in Launcher or Studio.

RPE Document Studio shows “Failed to create the part’s controls” in the editor area and a null pointer exception in the details window.

Until this defect is fixed please ensure that elements copied from the body content in the header/footer do not have data queries assigned to them.

Incorporating Jazz Reporting Service Reports into Rational Publishing Engine

Incorporating Jazz Reporting Service Reports into Rational Publishing Engine

The Jazz Reporting Service 5.0.1 and newer can be used as data sources to produce document style reports.

Kevin Cornell has put together an article on how to use RPE to generate documents with data returned by JRS queries:
Incorporating Jazz Reporting Service Reports into Rational Publishing Engine

What is JRS

I’m quoting the description from for a quick intro of JRS:

IBM® Jazz Reporting Service is an alternative to the complex reporting capabilities that are available in many Rational® products and solutions. By including Jazz Reporting Service in your integrated lifecycle toolset, you can quickly and easily consolidate data from a variety of data sources across your tools and project areas.

Jazz Reporting Service provides a set of ready-to-use reports that you can use to share information about your lifecycle management projects or you can create new reports. You can also export the report data to Microsoft Excel or integrate the reports with your dashboards.

Example: you can have a JRS query that gives you all the requirements, their associated testcases and defects. This can be exposed as a single data source and simply iterated by RPE, accessing all the desired information without needing any Java Script.

How does it help document generation?

“Live” document generation, that is document generation using the Reportable REST APIs of the point product to get the data, faces a number of problems. The difficulty of these problems increases for documents that have to follow traceability links (inside the same product or cross-domain).

  • performance – multiple requests to the point product take time and can also slow down the server
  • complexity – aggregating the data in the template can be complex and each new domain boundary that the report has to cross makes it more complex.
  • usability – the Reportable REST schemas are not always ideally designed for document generation as they have to serve all types of reporting.

Using JRS queries as data sources instead of the live Reportable REST APIs should allow you to move the data aggregation and collection tasks from RPE to JRS (and the ETL components) which can help with all the above issues:

  • performance – all the data is in the sample place so it can be efficiently retrieved
  • complexity – the data aggregation is done in JRS and you do not need complex Java Script logic in your template.
  • usability- you can design your schema such that it includes only and all the data you need.

NOTE: not all the data that can be accessed through the Reportable REST API is available in JRS. This means that for highly detailed documents you cannot use JRS as the single source of data but even in this scenario JRS can be a valuable solution. For such documents you can use JRS for the frame of the document and the details through the Reportable REST API.



Thank you for using Rational Publishing Engine and for all your feedback, requests and suggestions. Thank you for reading this blog, for participating on the DevWorks forum and on the IBM RFE community. Thank you for joining us at Innovate and on all other occasions.

Thank you for helping us make RPE a better tool.

Merry Christmas to the ones of you who celebrate it and a Happy New Year.  See you all in 2015.

The RPE Development Team

RPE 1.3 iFix 002

RPE 1.3 Interim Fix 2 is available on Fix Central and can be applied using Install manager. You can download the iFix repository or you can install it directly from the online repository. This iFix is cumulative and includes all the fixes made by RPE 1.3 iFix 001

This iFix addresses a number of issues identified after the RPE 1.3 release:

  • Java errors when bidi is true and Hebrew text
  • Standard view is used instead of default view for DOORS if an incorrect view name (non-existent) is provided
  • Results dialog cannot find Word output file if specified with a relative path including ..
  • Document specification version 1.1 (created with RPE 1.1.2) cannot be loaded in 1.3

For the full list of defects fixed and details on the procedure to apply the iFix see the iFix documentation.

RPE and DOORS Web Access

I’m writing this as a response to what seems to be a surge in interest for reporting on DOORS 9 data through the DOORS Web Access, or DWA. This integration is documented in the RPE Infocenter here and on my blog here.

The main point of this article is the scope and limitations of this integration. The RPE-DWA has been added to support exclusively traceability reports  that start from other products (ex: RQM) and use DOORS 9 requirements through DOORS’ OSLC API. As such the RPE-DWA integration is only meant to support retrieving a single requirement at a time through it’s DWA URL.

For all and any scenario where multiple requirements are needed, such as getting the content of a module/view, the traditional DOORS 9 route is the only supported method.

As a rule of a thumb you should you should never use DWA as the starting point for a report. These URLs must be obtained dynamically from other data  sources in your report.

It has to be noted as well that the DOORS OSLC API is not reportable which has two main implications for RPE and document generation. First this API lacks support for OLEs and images which means that only text content will be served correctly. Second there is no XML schema provided with the API (there is not a ?metadata=schema URL) nor there is a way to “discover” such a schema as we have for DOORS 9. The DWA example schema we have provided has been created manually from instances of the data.

To summarize the above for all scenarios other than the one explicitly stated above the RPE-DWA integration is not a viable nor is a supported alternative to the traditional RPE-DOORS 9 integration.

Up to date information and comments on RPE and Document Generation for Rational tools


Get every new post delivered to your Inbox.

Join 92 other followers