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.
Glossaries / “References Term” Link missing gives excellent insight into the notions of “module version” and “core version” of DNG artifacts, differences between these versions relevant to reporting and also the way in which you can get to the “core version” of an artifact from the module’s contextBinding.
Kudos to Sam and Ivan for the great information provided here.
The GEBS Reporting webinars series focused on Document Generation and RPE continues Tuesday, December 9th with Episode 7 – Accelerate RPE with Author XG: Advanced Techniques for Authors, Controllers & Managers. More details and the registration link can be found here.
This is the last webinar for the year so I want to thank our friends at GEBS Reporting for all the work, education materials, training and all the other things they have provided for or built around RPE so far.
The default log settings for the RRDG used by DNG trim some of the debug information that would be otherwise logged. This additional information is not needed normally but can prove extremely useful when debugging problems as stack traces and additional information will be present in the log.
To configure DNG and RRDG to log additional information you need to do the following. Thanks to the support team for this information.
- Go to rm/admin >debug
– Go to Logging > Configure Loggers
- Scroll all the way to the bottom of the page until you see a text box under “Text-based log configuration”. In there is the RRC log4j file in a form we can edit from the web.
– Set the following settings to DEBUG:
log4j.logger.com.ibm.rational.rrdg=DEBUG, rrdg, stdout
- Click on Submit Query
Note: the log4j.appender.rrdg.Threshold=DEBUG is not captured in this image.
My colleague Shikha Aggarwal has recorded a video showing how to use the color outlining feature of Document Studio 1.3. This feature is meant to help designers better understand templates with very complex nesting.
Up to date information and comments on RPE and Document Generation for Rational tools