It's all about the answers!

Ask a question

What Happened to the quickprintmodule Context in RRDNG (RM) Publishing?


Nate Decker (37812856) | asked Jan 19 '16, 10:39 a.m.

Background

You can use Rational Publishing Engine (RPE) in conjunction with the CLM's Requirements Management (RM) application (i.e., Rational Requirements Composer (RRC)/Rational Requirements DOORS Next Generation (RRDNG)) to develop report templates to publish data to a polished document. When deploying these report templates to RM, you must specify a context in the manifest file. The context tells RM when the report should be listed as available. Prior to version 6.X, here are some of the contexts that were available:

view, module, quickprintmodule, collection

I believe that setting the context to "quickprintmodule" would allow the report to be listed as available from inside of a Module using the button in the top-right corner of the module "Generate a Document-Style Report". In 6.0.1, the ability to deploy reports to this area seems to have been removed. Only the out-of-the-box reports (Print Module Book, Print Module Table, and Traceability Report) are shown in this area. I had heard rumblings from IBM that this was a change that was happening, but I objected strongly to it when I heard it was coming.

One of the benefits of the quickprintmodule interface is the report automatically consumes as its input the current module view that is being displayed. Whatever artifacts and columns are currently defined in the current view are passed along to the report. This allows you to generate your published document, including all of the rich text content of the artifacts, with a single data source: the undocumented "views" data source (which is evidently different from the documented "view" data source). You can see how this is being done in the out of the box templates by examining those templates in RPE.

Complaint

This seems to be a case of IBM saying, "Do what I say and not what I do." We are being told not to follow the provided example templates, but to create RPE reports using the documented API instead (an example would have gone a long ways here). Doing it this way requires the user to enter a bunch of parameters about which attributes and/or artifacts they want included in the report and necessitates using multiple data sources in the RPE template which significantly increases the complexity of the RPE template. It also has slower performance than using the views data source.

I have a couple of elaborate reports that were modeled after the built-in report templates and which exploited the views data source. These reports no longer work correctly and will need to be refactored so they can be launched from the Reports drop-down without any visibility into the currently displayed view in the Module. Add this to the fact that input arguments in the RPE template seem to be broken in 6.0.1 (I have an open Service Request about this and it's looking like this might be a defect in the 6.0.1 release) and there are some serious obstacles to get back to the capability we already had prior to 6.0.1. New features are great and are welcomed, but breaking my old stuff is bad business.

The Question

Given the change that IBM has forced upon us, is there a way to go back to deploying my report resource as a quickprintmodule context resource? As a brute force solution, I could rename my own template to be "printModuleBook" and overwrite the existing one, but that would be a pretty serious hack. If there is still a way to do this in 6.0.1 and it's just not being well documented or advertised, I would really like to know. If it's deliberately removed and not intended for customer use, then I can get into my refactoring. I would just hate to spend a bunch of hours on this effort if it isn't required.


Comments
Robert Huet commented Jan 20 '16, 12:44 p.m.

Yep, this will be a big problem for us too.  If this functionality has been removed from v6.0.1, what is IBM's recommended solution going forward which does not involve having to make a REST API call for every artifact in the module?  This is a performance killer for larger modules, which is why the "views" REST API was implemented for the printModuleBook and printModuleTable out-of-the-box reports.

Accepted answer


permanent link
Ivan Bravo (1762) | answered Feb 12 '16, 9:33 p.m.
JAZZ DEVELOPER
On 6.0.1 you still can deploying your report templates as a quickprintmodule context.
The context quickprintmodule should be used only with report templates using the "views" schema.
As the out of the box templates (printModuleBook and printModuleTable) are set on the manifest file, the only entry on the context needs to be quickprintmodule.

Please verify that on your current configuration for these reports the entry modules is not included in the context section.

Jut to clarify the new behavior on 6.0.1, basically it avoids reports to be displayed on  "Generate a report for this View" when their are based on "modules" schema, since they are now able to run correctly from this menu. So a report based on "modules" schema needs to include module on their context (Context: module) and application is not allowing this reports on "Generate a report for this View" menu.




Nate Decker selected this answer as the correct answer

Comments
Nate Decker commented Feb 16 '16, 9:30 a.m.

Yes this was my problem. I had multiple contexts listed, but evidently only the quickprintmodule context is allowed now. If you want another context, it seems like you'll need to maintain a separate copy of the report for that context.

I don't really understand this decision. It doesn't seem like we gain anything by adding this restriction to the manifest file's configuration.

There are still some qualms with the views context though. Most notably, it isn't documented in the article on the RM REST API. This implies that it is an "undocumented" API which should be avoided in implementations. However, I've heard that there are no plans to deprecate the views API and that we are actually encouraged to use it because it provides better performance than the other data sources.

The documentation should really be updated to include views.

Your answer


Register or to post your answer.