[closed] DOORS Publishing Breaks in 6.0.4 - Word Headers/Footers Responsible
Update:
It turns out that the problem is actually unrelated to the datasource configuration. The error message is misdirecting my troubleshooting. It appears that the server doesn't like the Word document template for some reason. I swapped out the template with the printModuleBook word doc and the report completes successfully. My Word document has embedded macros to facilitate post-processing clean-up on the report and I'm wondering if the server is running into issues opening the Word document somehow. It's odd to me that 6.0.3 didn't have this problem so I'm not sure what has changed in 6.0.4. My testing is on a different server so it's possible there are some configuration differences between the servers, for example it's conceivable that the 6.0.3 server's account that performs the RRDG publishing somehow "trusts" the word document and the 6.0.4 server does not. I'm unclear on how to fix it, but it would appear that the line of questioning in this post is not relevant to the problem.
Update 2:
Evidently there is a bug in the RRDG report generation that prevents reports from generating correctly if a header or footer is present in the word document template. I was able to verify that removing the headers and footers allowed the report to generate successfully. It has been suggested that this is a bug/defect that IBM may have fixed in a subsquent iFix or release. Since we do not have the luxury of upgrading at this time, we will attempt to address the issue by programmatically adding headers/footers back into the document during post-processing via VBA macros.
Original Post Below:
We have a report in Rational DOORS Next Generation (RDNG) written in RPE that works in 6.0.3. It uses the built-in "views" datasource (which is annoyingly not in the API Reference documentation even though it is used by the out-of-the-box reports). The report works as desired in 6.0.3, but when we try and run the same report in 6.0.4, we get the following error:
Report Generation Fail, Review the report data source configuration.
I did a search on this error message and I found an article in IBM support that says that this error occurs if the name of the datasource is not one of the supported names in the REST API. In our case, the datasource was named "resources" which is one of the supported names, but isn't the "views" datasource. As I mentioned earlier, the "views" datasource isn't actually documented in the REST API. I renamed the datasource from "resources" to "views", but this did not solve the issue. I know that the views datasource can still work in 6.0.4 because the out-of-the-box report printModuleBook.dta still works. I've compared the datasource configuration for our report side-by-side with the out-of-the-box report and the datasources seem to match in every significant way. There are some minor differences, but nothing that seems like it would explain this.
It would appear that something was changed in 6.0.4 that broke this report. Is there a way to get this working again?
Related Questions in this Forum:
The question has been closed for the following reason: "The cause of the problem is now known. A viable workaround is available." by zetareticuli Apr 08 '19, 4:19 p.m.
One answer
Hello
The best way forward here is a support case so as to collect all the relevant information(logs, screenshots, etc) and troubleshoot.
Please note that for DNG 6.0.+ the correct API page is https://jazz.net/wiki/bin/view/Main/DNGReportableRestAPI not RRCReportableRESTAPI.
I did do some research for you that you can also do with your jazz.net id in the RM repository and found the following workitems for 6.0.4 that may provide a clue on what is going on.
Comments
Thanks for all the digging, I'll review what you found. Hopefully a solution will present itself somewhere in there.
Unfortunately I cannot use the newer API because this same report is used on multiple networks for multiple instantiations of CLM and one of those networks is still running 5.0.2. Presumably, IBM is making all new versions backwards compatible so I wouldn't expect to have to change anything going from 6.0.3 to 6.0.4. I expect that the updated API provides source for configuration management in DOORS (i.e., streams and components), but the prior REST API should still be valid when not attempting to access those kinds of resources, particularly if you are working with a project area that has not enabled source control features. I would be more paranoid about a 6.X version being the cause of the report not working if not for the fact that it still works on 6.0.3.