One can create the hard/art way of using native RPE to run the queries. LQE is preferred and much easier.
Contents of this page:
You need RPE to define your own custom templates to generate the documents based on live data in the Rational Jazz database.
A thought: Having a report will all the thousands of test cases and results in one pdf, would you find the needle you need? Would an interactive dashboard not be more efficient?
All RPE pages are listed below: |
![]() Figure: A page from a document generated with the Comprehensive Test Plan Template. |
Article is now published at: Whole Jazz article and template
Make note that this template will generate a report based on what's available in the Test Plan.
Output example | RQM-RRDG-TP_5.pdf |
Template Source | RQM-RRDG-TP - V35.dta |
Some best proactices and thoughts on document generation and development.
Figure: Use simple containers to print variables.
Figure: By adding condition you can easily switch them on/off leveraging the debug variable.
Figure: Setting the condition based on the debug variable.
Personally I give de text printed enabled by the debug switch in a different color/font, eg. red (FF0000).
At the bottom of this page some RPE logging options are shown.
java.lang.System.out.println( ">>>> " + testPlanID);
All are in CaMeLcAsE.
To understand whats requested by a REST request, you must dig into the actual XML messages. Here two options are described, using the a browser (Firefox) and Poster (a Firefox plugin).
The REST interface is a different one than the OSCL. This is documented on Jazz.net.
Personally I hate it when the Pallete Element Tool remains active. I'm so glad you can switch it off!
Window -> Preferences -> RPE -> Document Desing => Keep current palette element tool **** ==> No
By default, at my installation a IE browser is opened when you select the PDF file in the pop-up. At this moment I don't know a setting to change this to my default FireFox.
Some examples of interesting RPE Elements.
I experienced the following, but I could not reproduce.
There are 2 ways to handle a table row. All have their pro-s and con's.
Figure: Table Row Definition in line with the 2nd option.
Suppose you have an source and will give several rows of data. This data must be presented
in a table. The table should have a header row. Clearly this header row must be generated once
and the following rows should be formatted nicely in 1 table.
If you start a table for every row the cells are formatted according to the contents
giving an ugly formatting. This can be solved by a hardcoded width of the columns.
Option 1: Define a variable e.g. TD_HEADER and which is set to true when the table starts and is switched off when a table row is printed.
Option 2: Start the table with the headerrow (no variable needed). IN the table you start the
logic to iterate across the data. Advantage is that you don't have an additional variable like
TD_HEADER. Disadvantage is that you have a more complex structure.
You need such a 'trick' when you want to have a single closing row (e.g. summing). This row should be
outsite of the iterating logic.
This is shown in the above image.
There is an option "Once per table:" for a ROW. At this moment I don't see the value of it.
Output example | example-table.pdf example-table.htm |
Template Source | example-table.dta |
An example to iterate over an array of names.
Output example | example-table.pdf example-table.htm |
Template Source | example-table.dta |
The hyperlink is very use full in the IBM Rational situation. This because every resource is a URL. So by putting these into the documents (PDF, Word, HTML etc) you give the user the option to open with one click the artifact. The up-to-date information (print is always old), can be viewed. Context is given (e.g. relations) and the information can be adapted.
Fields
Content: the actual link which will be executed.
Specific > Display: What's shown
Figure: The specific attribute set to testPlanURL
Figure: The script getting the ID. Recently I prefer to use a Javascript element to capture the scripting and reference just a variable in these situations. The code is easier to access than hidden in the element.
var p1=TestPlanURL.indexOf(":")+1; p1=TestPlanURL.indexOf(":",p1)+1; p2=TestPlanURL.indexOf("/",p1); java.lang.System.out.println( "p2 >>>> " + p2); port=TestPlanURL.substring(p1,p2);
To get the last ID from the URL https://business.vanlint5.nl:9443/ccm/resource/itemName/com.ibm.team.workitem.WorkItem/113
href.substring(href.indexOf("WorkItem/")+9);
As JavaScript you can use the following statements for logging information:
// _sessionLogger methods _sessionLogger.info( "This will be shown in the console as well as in the rpe.log file"); _sessionLogger.debug( "This will only be shown in the rpe.log file"); // logging docspec information _sessionLogger.info( "RPE version number: " + _sessionInfo.engineVersion); _sessionLogger.info( "RPE build number: " + _sessionInfo.buildNumber); // this property is only populated at runtime. Editing the script and closing the script window will show "" as the result in Studio _sessionLogger.info( "Template path (requires docgen): " + _sessionInfo.getTemplateProperty( "path"," "));
My rpe.log can be found at: C:\Users\IBM_ADMIN\AppData\Local\Temp\RPE
Clean once a while the /output and /temp directory.
I found a dramatic improvement by restructuring the template.
Parent Task Child Task Child Task Child Task
So for every Parent Task we have several Child Tasks.
Like in RPE, the datasource is orange background, comments has a yellow...
The initial setup was basic, leveraging standard RPE. Child work items don't give a href, so a pre-build url must be created based on the id.
Build Query on the selected Parents | |
One query gets a single Parent Task | |
Datasource one Child Task
See samplequery-1 | |
|
So for the parents a query is executed and for each child tasks. We can calulate
TotalNumberOfQueries=1 + NumberOfParentTasks*NumberOfChildTasks
Samplequery-1
https://business.vanlint5.nl/ccm/rpt/repository/workitem?fields=workitem/workItem[id=69979]/(id|summary)
Similar queries are executed for each child task.
As a test I collected first all child tasks for a parent tasks. So I had a list of ID's for a parent task.
Build Query on the selected Parents | |
One query gets a single Parent Task | |
Collect all Child Tasks | |
Datasource all Child Task
See samplequery-2 | |
|
So for the parents a query is executed and for each parent if there are child tasks. We can calulate
TotalNumberOfQueries=1 + NumberOfParentTasks
Samplequery-2
https://business.vanlint5.nl/ccm/rpt/repository/workitem?fields=workitem/workItem[id=69979 or id=70008 or id=70167]/(id|summary)
All the child tasks of a parent is queried in 1 query.
In a sample setup each query takes about 3 seconds. Having the first setup having 100 queries took 300 seconds. The second setup reduced the number of queries to 30 and the time to 100 seconds.
Run | Number of queries | Seconds |
Each child it's own query | 100 | 300 |
All children combined in 1 query | 30 | 100 |
A sample template with both options can be found here.
Some sources: