Getting started with reporting by using Lifecycle Query Engine data sources in version 6.0.4
Jazz Reporting Service team
Last updated: 15 June 2018
Build basis: IBM Jazz Reporting Service version 6.0.4
You can use the Report Builder in the Jazz Reporting Service to create and run reports about artifacts across projects or versioned data in configurations. Using indexed data from the Lifecycle Query Engine (LQE) data sources, you can, for example:
- Create a multi-project report that shows test cases, the requirements that they validate, and related defects.
You can also include designs from Design Manager; however, this feature is in technology preview and is not for production use. Without enabling the preview, users can work with DM artifacts in reports by creating SPARQL queries in the Advanced section of Report Builder.
- Run this report, scoping the results by choosing a configuration (stream or baseline).
Learn how to set up your environment and understand some of the limitations when you use either the LQE or LQE scoped by a Configuration data source.
Consider the limitations described here before you use LQE data sources for production reports.
If you are interested only in document-style reports, you can export Report Builder reports as Rational Publishing Engine templates to make document authoring easier. For example:
- Create the documents required for a Bill of Materials (BOM) for a product: lists of requirements, and test cases and their status when a product was delivered.
- Provide a document-style report to someone who cannot access a CLM dashboard.
- What’s new
- For administrators:
- Choosing an LQE-based data source
- Using reports from version 6.0 and earlier
- Reporting on current data
- Reporting on metrics and historical trends
- Running cross-project reports
- Details of Report Builder capabilities:
- Tracked resource set (TRS) feeds in LQE 6.0.4
- Synchronizing project membership information
- Choosing an artifact type
- Creating traceability relationships
- Identifying equivalent but conflicting properties in merged shapes
- Identifying equivalent properties across projects in an application
- Reporting on edited links
- Report Builder limitations
What’s newReporting on RTC SCM change sets
You can report on Rational Team Concert SCM change sets, such as who created the change set or how many files were affected. This capability excludes the following types of information:
- specific file information
- RTC build information
- SCM baselines and streams.
Project scoping and project columns are simplified
All ready-to-copy reports contain a Limit Scope filter in the Filters dialog box that controls the availability of project selections for the entire report. Project column filters are now based on the selection in this filter and the available artifact types.
As before, other enumerated columns are based on the selected values of their respective project filters.
Reporting on artifacts in configurations
As before, configuration and component selections are available, but in the Filters dialog box, which is less cluttered.
Reporting on multiple top-level artifact types
You can now report on multiple top-level artifact types. You can include top-level types across products in one report without defining traceability relationships between them. This is particularly useful in LQE-based reports where there might be custom types in the LQE data source from various tools. For example, you can now write a single report to show all open high-severity items across all tool types.
Traceability relationships with different source artifacts
You can now also trace relationships between multiple source artifacts and one target artifact.
For example, you can show all stories that do not have test cases and all features (requirements) that do not have test cases. In the “Choose an artifact” section, select the Story type. In the “Trace artifact relationships” section, select the Enable multiple traceability paths check box. Click the Add an Artifact button and select Feature. Then create the traceability relationships from Story and Feature to look like the following image:
On the “Format Results” page, to group the project fields of the story and feature into one column in the result table, you can put the project fields next to each other and give them the same label.
Improved ability to create branched traceability paths
It is now easier to create branched traceability paths where the branching occurs after one of the artifacts in the middle of the traceability path. The Add a Relationship button appears on each relationship in the path when the Enable multiple paths or add other source artifacts check box is selected. If you create a relationship from an artifact other than the source artifact in a path, the artifacts leading up to this artifact will be duplicated in the new path.
For examples, see this New and Noteworthy item about traceability improvements.
Shared column enhancements
Previously, you could write a report where two columns defined on the Format Results page could share the same column in the table view in the report results. This is accomplished by giving adjacent columns the same column label.
Shared columns are especially useful when a report contains two attributes that are considered the same. For example, one project might use one attribute for status and another project might use another attribute for status, but in the report you want to see the status in the same column regardless of which project the artifact is coming from. Shared columns are also useful when you work with multiple traceability paths as in the following example.
Easily assemble nested condition groups
When you construct complex conditions, you can now use All must match and Any can match instead of the AND or OR operators. Grouped conditions are outlined so you can see them easily; you can also drag and drop conditions or groups, to reorder them.
Build custom expressions directly in Report Builder
Previously you had to write SQL or SPARQL queries in the Advanced section of Report Builder to do special formatting or complex calculations in a report. You can now add custom expressions, written in the query language of your data source, directly in the Report Builder interface.
For example, you might use custom expressions to do these tasks:
- Show in hours a value that is expressed in seconds in the data source.
- Show calculated values by using a database function that is not available in the Calculated Value section.
- Change how a date is shown.
Editing SPARQL queries
To report on some items, you must edit the query text (including SPARQL code) in a report. Before you begin, check whether query editing access is restricted for the data source that you use.
To check permissions:
- In Report Builder, go to the Data Sources page at https://server:port/rs/endpoint, and click a data source name.
- If query editing is restricted to report managers, only they can make the changes in the Advanced section.
- Use Report Builder to create your report. For guidance about which LQE data source to select, see Choosing an LQE-based data source.
- Name and save your report.
- Return to the Format Results page. In the Advanced section, click Edit and OK to disable the Report Builder interface.
If you cannot click the Edit Query button, ask your report manager to do the rest of these steps.
- Edit the query: remove all references to the original artifact type, and replace the existing query text with SPARQL code to access the item you want to report on.
- Validate the query.
Important: If you manually edit and save the query text in the Advanced section, you can only use the Report Builder interface to add query parameters and columns to the report. You can no longer modify the traceability links.
- Save and run the report.
See the complete version 6.0.4 New and Noteworthy list here.
For LQE-based data sources, Report Builder now starts within a minute because it reads the metadata from the disk, so you can edit or run reports right away.
Report Builder writes the metadata to a file on disk in the server/conf/rs/MetaModelCache folder. A background job runs twice a day to refresh all data sources, keeping the cache files up-to-date. When Report Builder starts, it verifies that it can connect to the data source and looks for any cached metadata. This cached metadata is used instead of sending queries to the actual data source. If the data source can’t be accessed, the cached metadata isn’t read and you can’t run reports.
For details, see this New and Noteworthy item.
Before you can report on artifacts from the LQE-based data sources, you must activate and enable configuration management in the RM and QM applications. These steps are not required for Design Manager or RTC: Design Manager uses configurations but you don’t need to enable them, and RTC does not send information about versioned artifacts to LQE. Be sure to follow the steps in the Interactive Upgrade Guide.
Enabling configuration management in your CLM tools
- Upgrade all Rational solution for Collaborative Lifecycle Management (CLM) and JRS applications to version 6.0.4. Report Builder cannot use the version 6.0 metadata that was published to LQE by the CLM applications.
- Enable configuration management in QM and RM:
- Get an activation key. See Enabling configurations in CLM applications (v6.0.4).
- Set the activation key for the QM and RM applications. Go to the corresponding administration page:
For the RM and QM applications, enter the key under Advanced Properties, in the Local Versioning Component field; then, click Save. Other CLM applications Jazz Team Server also have this advanced property, but you add the key to the property only in the QM and RM applications.
- For each QM and RM project area that will use configurations, enable the feature on the Configuration Management page.
The system archives the project’s data in the data warehouse. The project now sends data only to LQE as described in Choosing an LQE-based data source.
- Click Explore Project and if there are no artifacts, create some for the project. The initial configuration and its versioned resources are published to LQE.
Connecting to LQE data sources
You must establish a connection to the LQE data sources before users can build reports and use them on their dashboard. In a browser window, open the Setup page at https://server:port/rs/setup and click Connect to data sources.
Remember to complete this step each if you add more LQE data sources.
Choosing an LQE-based data source
Before you enable configuration management in RM and Quality Management (QM) project areas, their information is sent to both the CLM data warehouse and LQE. After you enable configuration management in these project areas, they stop sending feeds to the CLM data warehouse, which archives their data. From that point on, those project areas send the configuration management data to the lifecycle index and is accessed by using the LQE application.
IBM Rational Engineering Lifecycle Manager can use Report Builder to report on data in the LQE scoped by a Configuration data source.
RTC does not support configuration-enabled projects areas, so it does not publish any versioned resources to LQE. All RTC data in LQE is compatible with all configurations.
Which LQE data source to use?
- LQE data source:
- Report on RM and QM projects that are not configuration-enabled.
After an administrator activates configuration management, each project must be enabled individually. Therefore, some projects are enabled, and others are probably not enabled.
In the Limit scope section, select only non-enabled projects. If you select a mix of projects, or select only configuration-enabled projects, your report will be meaningless. See this example.
- Report across all configurations in an RM or QM configuration-enabled project area. Your report will contain information about all the versions of the selected artifact in those configurations.
Consider this scenario: an enabled project represents a product, and each stream in the project represents a release. You can report on some aspect of the product, such as requirements not implemented, across all the releases. To get the same information by using the LQE scoped by a Configuration data source, you run the report on each stream and then manually collate the results.
Your report results might be very large with unexpected results because the property values come from all versions of each artifact, and all combinations of those values are shown. See this example.
- Report on RM and QM projects that are not configuration-enabled.
- LQE scoped by a Configuration data source:
- Report on artifacts in RM or QM configuration-enabled project areas. When you run the report, you must choose a configuration. You must choose a global configuration if your report contains traceability relationships between these artifacts:
- RM artifacts across RM components
- RM and QM artifacts
- RM and QM artifacts to DM artifacts
- Report on a global configuration itself (not the artifacts in the configurations that it references). Use a SPARQL query in the Advanced section.
- Report on model information that is managed by Design Manager (Rational Rhapsody® Design Management). This feature is in technology preview, and is not for use in production environments.
- To learn about the limitations of the technology preview feature, read this Jazz.net article. To enable the technology preview, go to the Data sources page at https://server:port/rs/endpoint, and click the link to read and accept the license agreement.
- Without enabling the preview, users can work with DM artifacts in reports by creating SPARQL queries in the Advanced section of Report Builder.
- Report on artifacts in RM or QM configuration-enabled project areas. When you run the report, you must choose a configuration. You must choose a global configuration if your report contains traceability relationships between these artifacts:
Use the data warehouse if you have thousands of active users, or have more than 5 million resources in the projects to report on, or need to report on some artifacts types or project elements. To help you decide whether to use the data warehouse or not, see this topic in the product documentation.
Remember, the data warehouse does not contain information about configuration-enabled projects.
Using reports from version 6.0 and earlier
- You must recreate all existing reports created in Report Builder version 6.0 that use LQE or LQE scoped by a Configuration (previously called LQE using Configurations) data sources, because this capability was a technical preview feature in that version.
- Existing Report Builder reports for the data warehouse should still work in version 6.0.4.
- Recreate manual Report Builder reports with custom SPARQL queries if they no longer generate the results that you expect.
- SPARQL queries created in Rational Engineering Lifecycle Manager should continue to work if the corresponding metadata assumptions are still true. For example, a query that assumes that artifacts have back-link properties will not work, because back links are no longer created and links in the “reverse” direction are not stored.
Reporting on current data
As you build your report, your choices are shown in the My Choices pane on the right side of the page. To change your choices:
- Click the heading near the top of the page and go to the section to change.
- In the My Choices pane, click the pencil beside the section to change.
- Step 1. Choose data.
- Step 2. Format results.
- Step 3. Name and share the report.
- Step 4. Run the report.
What to do next
- To see your report in the list of other reports, click All Reports or My Reports.
- To further edit your report, click a pencil in the My Choices pane at the right. Click Save to save your changes.
- You can export your report to a spreadsheet, IBM® Rational® Publishing Engine, Microsoft® Word, PDF, and HTML files. You can also export a report graph to an image file.
Step 1. Choose data
- Open Report Builder at https://host:port/rs, and click Build.
- Choose a report type.
- Select Current Data (table or graph) to report on the latest information about artifacts in and across projects.
- Select the LQE data source for what you want to report on: one configuration or all configurations. Click the pencil to select a different data source. To help you decide which data source to select, see Choosing an LQE-based data source.
- Limit the scope.
Choose the project to report on and click Continue. If you don’t select any projects, the report includes all projects you can access.
The list shows the projects that you can access in the data source that you selected. If your projects are not in the list, see the administrator who created the data sources for Report Builder.
The projects that you select affect the artifact types that you will see in the Choose an artifact and Trace artifact relationships sections. For example, if you don’t select a QM project, you cannot report on QM artifacts, and you cannot create traceability relationships that include QM artifacts (for example, a report that shows requirements and the test cases that validate them).
- For Lifecycle Query Engine, only projects that are not enabled for configurations are listed. If you select List all projects when reporting on configurations themselves, configuration-enabled projects are included in the list. To limit the configuration results, select specific projects. Reporting on a mix of configuration-enabled and non-enabled projects might generate invalid results because there might be several versions of the same artifact.
- For Lifecycle Query Engine scoped by a Configuration, only configuration-enabled projects are listed. When you run the report, you must choose a configuration.
Some artifact types are project-specific. Go to step 4 to select the artifact type, then return here, and select List only the projects that contain the artifact for your report.
You must know which RM and QM projects are configuration-enabled. Select only one type (enabled or not enabled projects). This constraint does not apply to RTC projects, which are compatible with either type of RM and QM project.
For example, to show related work items, select the correct RTC projects even though they are not configuration-enabled; otherwise, you cannot add the relationship to the work items in the Trace artifact relationships section.
If don’t see the project that you want, see the administrator who created the data sources for Report Builder.
- Choose an artifact.
Select an artifact or specific types, and click Continue. You might have to expand some artifacts to make a choice; if you don’t expand the artifact, and select it, all of its types are included in the results.
The top-level artifact types correspond to OSLC types. Nested artifact types correspond to merged artifact types from one application. If you select an OSLC type, your report might contain results from any application that publishes that type.
If you select an artifact type that is project-specific, you can return to the Limit the scope section, and select List only the projects that contain the artifact for your report.
For details, see “Choosing an artifact type” later in this article.
Tip: To report on requirements in Requirements Management modules, click Requirement > Use Case Module, and in the next step, define a Uses trace relationship between the Use Case Module and Requirement artifact types. For details, see Modules later in this article.
- Trace artifact relationships.
Explore how your artifacts are linked to other artifacts from the same, or from other lifecycle tools. Click Add a relationship. For each artifact type, you see all the existing relationships. Pick one, and click OK.
To report on multiple artifacts, select one artifact in the Choose an artifact section; then, select Enable multiple paths or add other source artifacts, click Add an artifact, and choose the artifact to add. For example, you can now write a single report to show all open high-severity items across all tool types.
- Reporting on requirements in modules: if you chose Requirement > Use Case Module in the previous step, define a Uses trace relationship between the Use Case Specification and Requirement artifact types, as shown in Modules.
- Some custom link types are not shown in the list of existing relationships: for example, custom link types from artifacts that do not own the link. For details, see DOORS Next Generation limitations.
You can select multiple relationships between two artifacts of the same type, as shown in the following example:
Example: To show that a requirement is validated by a test case, click Add a relationship, and under QM Test Case, select Validated by. To also list the work items associated with the test cases, click Add a relationship > Related Change Request and click OK. To specify what type of related change request to add, select Work Item and click OK. In the Set conditions section, you can further define the relationships.
Tip: When you name and share your report, include the traceability link names so that team members can find your report easily.
From one artifact, you can trace multiple relationships to other artifacts, and show all the results in the same report. Choose how to combine the results:
- Merge: The results are shown in the same rows.
- Append: The report shows the results for each traceability relationship. All the source artifacts are in the same column.
- Append in new columns: To count the source artifact relationships separately, append the results in different columns.
For each relationship that you trace, you can set conditions. For step-by-step instructions on how to build this type of report, read the Tutorial.
Example: Trace how features are linked to work items, test cases, and child requirements, and see all the relationships in a single table.
To remove the last relationship from the right of an artifact, click Back. To remove an artifact or relationship and all the items to the right, click X beside the item name.
To change the name of an artifact in the traceability box, double-click its name and type the new one. Changing the name in the traceability diagram makes it clearer to your team members, especially if your report uses custom artifact types or custom links. For example, if you want your report to refer to related defects instead of change requests, double-click Change Requests in the traceability diagram, and type Defects.
After you build the artifact relationships, click Continue.
- Set conditions.
Set conditions to further refine your report and further identify relationships among artifacts.
You can set conditions for any attribute of the artifact type that you selected, and any attribute of the related artifact types in your traceability paths.
For example, to show that a requirement is validated by a test case, select the Validated by relationship under QM Test Case. Then, set a condition to focus only on approved test cases. For the artifact type QM Test Case, choose the attribute Has Workflow State, and set the value to Approved.
You can set a condition to return data only for specific components. You must select an application-specific artifact type (such as QM Test Case, or System Requirement). These artifact types contain a Component attribute that you can choose, and then select the component to report on. The Component attribute is not available if you select a global artifact type (typically the expandable top-level artifact type in the Choose an artifact section) or types from projects that aren’t enabled for configurations.
Tip: If you add the Component attribute as a column but do not add a condition for it, when you run your report you can select a component to filter the results that you see.
- Click Add condition and select an artifact type.
- Choose the attribute that you want to specify a condition for, and select the values to return the artifacts you want.
- Click Add to keep the window open so that you can add other conditions. Otherwise, click Add and Close.
- Optional: Change the lock to control whether people can or must supply a value for the condition when they run the report.
Sometimes several projects use the same custom attribute, and although the attribute has the same name across the projects, its ID is different in each project. To report on this attribute, add a condition for each project. Then, to consolidate them in your report, group the attributes by using an OR condition.
You can assign the same RDF URI to custom attributes that are used in multiple projects. For details, see Identifying equivalent properties across projects in an application.
Example: Each project you report on has a risk status attribute, and it means the same to each project. Select this attribute for all the projects; then, group the attributes, and add an OR condition between them. To show the results in one column, instead of one column for each project, see the “Show the report as a table” section in this topic.
- To edit a condition, click the pencil icon beside it.
- To create logical groups of consecutive conditions, select them, and click Group.
- To remove conditions, select them, and click Remove.
After you create your conditions, click Continue.
Step 2. Format results
- Choose whether to show the report as a table or a graph.
- Click Refresh to see a subset of the data for your report. To see all the results, you must run the report.
For details, see this help topic.
Step 3. Name and share the report
- Give your report a name and a description. The description is important to help other team members find your report if it is public.
Note: You might include the traceability link names that you built in the Trace artifact relationships section, so that team members can find your report easily.
- Tag your report to make it easier to find or to group it with related reports. Each tag becomes a category on the All Reports and My Reports pages.
- Specify how to publish the report:
- Public (publish to catalog and visible to everyone): The report is in the Report Builder catalog. Team members can add the report as a widget to their Jazz dashboards.
- Private (publish to catalog and visible only to creator and owners): The report is in the Report Builder catalog. Only the report creator and owners can add the report to a dashboard and see it. Other users see the widget, but they cannot run the report.
- Private (visible only to creator and owners): The report is available only on the My Reports page.
- Specify whether the default visualization for your report is a table or a graph. For example, if you select Graph, but then run the report to generate a table, the next time you run the report, the results are shown again in a graph.
- Click Add owners. Your report can have multiple owners who can modify the report, and assign other owners.
- Click Save, and click Continue.
Step 4. Run the report
To see the complete report, click Run report. Provide values for all required parameters or filters.
To export your report results, click Export near the upper right. You can export your results to a spreadsheet, to Rational Publishing Engine as a document-style report, or export a report graph to an image file. See the links to help topics at the end of this article.
Reporting on metrics and historical trends
Before you report you historical trends, you must configure LQE to collect metrics — for details, see this help topic. Then you can report on metrics and historical trends by following the procedure in this help topic.
Remember these points when you configure LQE to collect metrics:
- Collecting data can be resource-intensive. Schedule the task to run when the server is not heavily used.
- To avoid performance issues, select only the configurations you want to focus on.
If you collect historical metrics from all the data, you end up running resource-intensive data collection jobs for each configuration.
- Metric collection is not automatically enabled for new configurations; you must add new configurations to existing tasks.
- If you don’t select any configuration, or if you don’t use configurations, the task collects metrics from all data.
When you use an LQE data source, some of the metrics are different than their equivalent in the data warehouse.
- Change Management:
–Work item creation and Work item closure gather data only about work items that were closed or created on the previous day
–Work item totals collects data for the following dimensions: Project Area, Work Item Type, Iteration, Status, Filed Against.
If you use the data warehouse, this metric included data for additional dimensions: Team Area, Found In, Severity, Priority, Creator.
- Requirements Management:
Custom attributes, such as Status or Difficulty, are not included in the metrics.
- General differences:
To run a trend report against a configuration, you must configure LQE to gather metrics for that configuration. Metrics are not gathered by default.
Running cross-project reports
When you run your report, you see only the artifacts that you have access to.
Assume you have created a cross-project report to show QM test cases and the RM requirements that they validate.
The results depend on whether you’re reporting on a specific configuration or across projects that are not enabled for configurations.
Reporting on versioned artifacts from a specific configuration
- Data source: The report must use the LQE scoped by a Configuration data source.
- Traceability: You must know which configurations will return results based on the traceability relationships and conditions defined in the report. For example, if you’re reporting on specific projects, you won’t get results if the configurations are not in the report’s scope.
- Global configuration: Because the report includes artifacts from different lifecycle tools, ensure that the configurations from those tools are in a global configuration.
When you run the report, in the Filters > Choose a Configuration section, select the global configuration that contains the local configurations to report on. If you run the report against a local configuration only, you will not see any results.
- Hierarchy: Configurations are shown hierarchically:
You can see these levels in the image:
- Components: A configuration-enabled project area can have multiple components that logically organize its resources. Each component can have multiple configurations that contain the different versions of the component’s artifacts.
- Streams: Global streams and local streams that are not associated with a global stream.
To reduce clutter, local streams that belong to a global configuration are not shown, unless those streams have baselines.
For example, you cannot select the “Config Banking (RM) Initial Stream” stream, but you can expand it to see its baselines and select one to report against.
- Baselines (nested): All baselines created from the preceding stream.
Streams that do not publish project information to LQE are shown at the bottom of the hierarchy (none shown in the preceding image).
Reporting on projects that are not enabled for configurations
- Data source: You must select the LQE data source.
- Mixed environment: If you work in an environment that has projects that are enabled for configurations and ones that are not, limit the scope of the report by selecting specific projects that are not enabled. Don’t try to report across them. Otherwise, the report results show all the combinations of all the property values for an artifact; the values are extracted from the multiple versions of that artifact in a configuration-enabled project.
- In Stream_1, an artifact has these properties and values: state=draft and priority=low.
- In Stream_2: state=approved and priority=high.
Instead of two entries in the report results, there are 4 (cross product of the property values):
- state=draft priority=low
- state=draft priority=high
- state=approved priority=low
- state=approved priority=high
Details of Report Builder capabilities
TRS feeds in LQE version 6.0.4
TRS feeds: If you add a TRS feed for an application that is registered with a different Jazz Team Server (JTS), all user URIs in the artifacts refer to the user registry in that other JTS application. Therefore, you must also add the feed from the other server (https://host:port/jts/trsUsers).
Permissions: Ensure that the data source permissions are assigned correctly:
- Assign the Report Builder functional user (jrs_user) to the Lifecycle Query Engine Index data source permissions.
- Assign the Everyone group to the Rational Jazz Team Server data source permissions. This includes all JTS user TRS feeds that are added manually.
- In version 6.0, the Everyone group was manually added to the Lifecycle Query Engine Index top-level LQE entry on the Data Groups page. In version 6.0.4, you must remove this Everyone group from this entry.
Project access: To see the access for each project, look at the application’s Process feed (TRS 2.0 for DOORS Next Generation Process Resources, TRS 2.0 for GC Process Resources, and so on).
Synchronizing project membership information
Project membership updates: You might not see updated project membership information immediately in Report Builder. The system refreshes LQE with project membership information every 10 minutes. To change this default interval, go to the Advanced Properties tab of the LQE application and click the Show Internal link.
Example: Before you add members to a project in a CLM application, you might change this interval to 1 minute so that the new project members can see the information they need in Report Builder sooner.
After LQE refreshes, change the interval back to its previous or default value.
Choosing an artifact type
Top-level and nested artifact types: The top-level artifact types correspond to OSLC types. Nested artifact types are merged artifact types from one application.
If you select a top-level (OSLC) type, you might see unexpected results in your report if multiple applications publish that type of artifact to LQE.
Example: If you choose the OSLC Requirement type to find all DOORS Next Generation requirements, your report might also return Requirement artifacts published by the Design Management (DM) application. Report Builder does not support DM types at this time. To exclude DM requirements from your report results and report only on DOORS Next Generation requirements, select the nested Requirement type, and in the Limit scope section, select only DOORS Next Generation projects.
Combined artifact types: Merged (non-OSLC) artifact types are combined based on their name.
- If two project areas in an application define semantically different types but use the same type name, Report Builder assumes they are equivalent.
Example: If QM project area Proj1 defines an artifact shape type QM Test Case and QM Proj2 defines a QM Test Case that has different properties, the hierarchy in the Choose artifact section shows only one QM Test Case type.
- If you select a merged type for your report, it shows resources from both projects, which might include unexpected results.
To avoid this problem, in the Limit scope section, select only the projects that contain the type that you want to report on.
Differences in Requirements Management:
- Most DOORS Next Generation merged shape types are shown under both Requirement and Requirement Collection.
- If a specific merged type is shown in both places, it is the exact same type. The generated report does not infer which hierarchy you chose it from. The system examines all the artifacts that correspond to that merged type, whether the underlying artifact type is Requirement or Requirement Collection.
Creating traceability relationships
In the Trace artifact relationships section, the list of target shape types is shown hierarchically. If you choose an OSLC type, such as Requirement, the report results include all the Requirement types published to LQE that satisfy the traceability relationship, project scope, and conditions that you define.
Identifying equivalent but conflicting properties in merged shapes
Conflicting properties: Conflicts among properties can occur when the system (LQE + Report Builder) merges project-specific artifact shapes. These conflicts are indicated by a question mark in the Add Attributes to the Report section of Report Builder.
Visual cue: Hover over the question mark to identify and select the correct property (attribute). The tooltip typically includes the project name and indicates the reason for the conflict.
Effect on cross-project reports: If you add a property that has a conflict, your report might return unexpected results. These properties prevent cross-project reporting. The report results for that type are limited to the resources in the corresponding project.
Identifying equivalent properties across projects in an application
Different projects might use different names for an equivalent property. For example, in RM projects, a Feature in Project1 might use a property called Priority, and in Project2 that same property might be called Urgency.
Report Builder considers properties as equivalent when you specify the same RDF URI in the projects that use it.
- Complete one of the following steps:
- RM application: Click Administration menu > Manage Component Properties > Artifact Types.
- QM application: Click Administration menu > Manage Project Properties > Custom Attributes.
- For an artifact type, specify the RDF URI for that property and then click Save.
- Repeat for each project that uses that property.
If the property is an enumeration, in each project where the values are equivalent, you should also specify an RDF URI for each value in the enumeration.
Reporting on edited links
After a link is edited, Report Builder reports show the new link version regardless of whether the link direction or type was changed. For example, if you change a link of type Link to a Synonym link, the updated link is shown in reports that show requirements that are related through the Synonym link type.
Report Builder limitations
Artifacts from DM applications: Reporting on model information from Rational Rhapsody® Design Management or the Design Manager web client is in technology preview. It is not for production use. To learn about the limitations of the technology preview feature, read this Jazz.net article. To enable the technology preview, go to the Data sources page at https://server:port/rs/endpoint, and click the link to read and accept the license agreement. After an administrator enables the technology preview, you can report on these items by using the Report Builder interface.
Without enabling the preview, users can work with DM artifacts in reports by creating SPARQL queries in the Advanced section of Report Builder.
Artifact types and information you cannot report on with Report Builder: Neither the data warehouse nor the LQE contain the following information. Instead, use the dashboard widgets for the specific CLM application.
- RTC: Plan resources, work item comments and complexity
- DOORS Next Generation: Change set information; review or module hierarchy information; tags
Artifacts from DOORS: Reporting on DOORS (DOORS Web Access) artifact types is not supported at this time. If an LQE TRS feed exists for the DOORS application, you might see the corresponding artifact types on the Choose data page in the Choose artifact > Requirements Management section, but reporting on them is not supported.
Attributes with the same name: Sometimes a set of projects uses the same custom attribute, even if the attribute has a different name across the projects in an application. Across projects, when you specify the same RDF URI for the attribute, Report Builder shows only one instance of it. If the attribute has a different name across projects, Report Builder shows the first name that it discovers. For example: Project1 might have an attribute called Priority; Project2 might have an attribute called Urgency, and both attributes have the same RDF URI. In Report Builder, the attribute might be listed by either name.
Editing SPARQL queries: To report on some types of artifacts or project elements, you must manually edit the query for your report in the Advanced section of Report Builder (for example, to add SPARQL code). After you save your changes, you can only add query parameters and columns to that report in Report Builder. You can no longer modify the links in Trace artifact relationships section.
Reporting about configurations: You can now report on global configurations by using the Report Builder interface. To report on data about local configurations themselves, you must write SPARQL queries in the Advanced section of Report Builder. Use the LQE scoped by a Configuration data source for your report.
For example, to find out which local configurations refer to a specific requirement, create a Report Builder report about requirements, and replace the generated query with a custom SPARQL query that extracts data from the configurations directly. See editing queries for details.
Otherwise, Report Builder exposes configurations only in the Choose a Configuration menu when you run a report that uses the LQE scoped by a Configuration data source. Because you can pick only one configuration from this menu, the query that Report Builder generates cannot find the information you want from all configurations.
Link validity: Using the Report Builder interface to report about link validity is not supported at this time. You must write SPARQL queries to access this information. See editing queries for details. In the LQE application, you must have permission to read data in the TRS 2.0 for Link Validity Resources data group. If your report does not return link validity information, ask an application or project administrator to grant you this permission.
Translation: When you create a report that uses an LQE-based data source, the types and property names that you see in Report Builder are extracted from metadata that is published to the LQE by the lifecycle tools. Typically, this metadata contains only English names.
LQE scoped by a Configuration data source limitations
Manually created data sources: If you manually create LQE data sources in Report Builder, you must create the (all-data) LQE data source first, and then create the configuration aware LQE data source; be sure to check the option to require configurations before saving the data source. After you save a data source, you cannot change this option.
Reports on configurations: Reports that are run against a configuration have access to all versioned artifacts in that configuration, as well as all non-versioned artifacts.
Errors when no configuration is defined: When Report Builder runs a query on the Lifecycle Query Engine scoped by a Configuration data source, a configuration must be defined in the request, or LQE generates an error. If Report Builder detects this situation, the query is redirected to the normal (all data) LQE data source, but the results might not be correct.
Both LQE data sources: Typical queries that must be redirected to the normal (all-data) LQE data source include queries to obtain the metadata for the data source and queries to find the available configurations. Therefore, Report Builder cannot create and run an LQE configuration-based report unless both LQE data sources are defined.
DOORS Next Generation limitations
Change sets: Reporting on change sets is not supported at this time. They are not published to LQE.
Components: When you create a component, use a template to populate it. By doing so, the component data is published to LQE and you can use Report Builder to report on the component and its versioned artifacts.
- If you know you need to clone artifacts into your new component, select a template whose type system matches the component you will clone from.
- If you manually set up the component structure later (by importing a type system), the data is not published to LQE, and you can’t use Report Builder to report on that component or its versioned artifacts.(This issue has been fixed in 6.0.4 and 6.0.3 iFix 001).
Modules: To report on requirements in modules:
- In the Choose an artifact section, click Requirement > Use Case Module.
- In the Trace artifact relationships section, define this relationship:
Traceability and link types: If two artifacts are connected by using any of the following OSLC link types, you can create a traceability report (starting with either artifact A or artifact B).
These are the names that you see in Report Builder. The names in parentheses, (), are the link types in DOORS Next Generation. For details, see the help topic about link types in requirements projects.
- Affected By
- Artifact Term Reference
- Constrained By
- Decomposed By (Parent Of, Child Of)
- Elaborated By
- Embeds (Embeds, Embedded In)
- Extraction (Extracted, Extracted From)
- Implemented By
- Link (Link To, Link From)
- Specified By
- Tracked By
- Validated By
In your Report Builder report, for the following link types in DOORS Next Generation, you can define traceability links that start with the source of the link (the first link type listed in each pair). To create an equivalent report that starts with the target of the link, you must add SPARQL code to the query in the Advanced section of your report:
- Elaborates, Elaborated By
- Specifies, Specified By
- Satisfies, Satisfaction
© Copyright IBM Corporation 2017