It's all about the answers!

Ask a question

repitition of versioned artifacts in reports


Saqib Niaz (7116) | asked Aug 11 '16, 10:53 a.m.
I have implemented a configuration-enabled RM provider. Added one of my project's stream to a global configuration. Linked a requirement i.e. req1 from my system to a test case in jazz QM. While linking my artifact with QM's test case, i have sent the URI of the base artifact not the versioned artifact (not sure about this point).
Provided feeds both for processes and artifacts and added to LQE. Artifacts feed contains unversioned/base artifacts, versioned artifacts and configurations available in our system.
Example, i have published three RDFs for an artifact req1, one unversioned and two versioned.
I am creating a report on the test case in discussion and linking the test case with the requirements that it validates.
Report shows the test case and its linkage to all the versions of my req1, so req1 appears 3 times in the report. While only one version of req1 was linked?
When i hover over my req1 link in report, jazz sends a request to my server for the base resource and send oslc.config_context with it to resolve it to proper version.
How to avoid repetition of my artifact for all versions of that artifact? How to make it appear once??

Accepted answer


permanent link
Kevin Cornell (5411) | answered Aug 11 '16, 3:16 p.m.

When working with projects that are enabled for configurations, you should always use a global configuration if you are creating links between artifacts (requirements and test cases) that reside in different projects (or tools). The global configuration should be associated with a single stream (local configuration) from each project. Links (artifact references) must always be stored using the concept URI (not the versioned URI). This allows child streams in one or both projects to still find the links to the corresponding artifact in the child stream (a global configuration is associated with the child streams).

If your tool supports both configuration enabled projects and non-config projects you should only publish versioned resources (RDF graphs) for the artifacts for both types of projects. Meta-data such as resource shapes, can be published as un-versioned resources (although some tools like DNG publish versioned resource shapes ... one for each stream). When a query is run against a configuration (local or global), only the versioned resources referenced in the "selections" for that configuration are examined along with all unversioned resources. Therefore if a non-config project published un-versioned resources, a query running against a configuration could incorrectly pick up values from those un-versioned resources.

In a non-config enabled project, only one versioned resource should exist in LQE for any artifact. If the artifact is modified in the tool, either update the existing versioned resource in LQE or delete the existing versioned resource and create a new versioned resource.

In a config-enabled project, there can be multiple versioned resources for the same artifact (same concept URI) but any local configuration (stream or baseline) should only refer to a single version of an artifact. If the artifact is modified, a new versioned resource is published and the “selections” resource for that configuration must be updated by removing the reference to the previous version and adding the reference to the new version (this is typically done using a TRS patch event instead of updating the entire “selections” resource). If a previously published versioned resource is no longer referenced by any stream or baseline, it could be deleted from LQE, but the necessary bookkeeping to determine this could be complex.

In Report Builder, there are 2 types of LQE data sources: (a) the normal LQE that uses the “all-data” endpoint, and (b) the LQE scoped by a Configuration data source. The normal all-data LQE data source can see all resources, including the multiple versioned resources for a given artifact. Thus if you are running a report against projects that are not enabled for configurations, you must use the normal LQE data source in RB and MUST limit the scope to only those non-enabled projects. If you are running a report against projects that are config-enabled, you must use the LQE scoped by a Configuration data source. when you run the report, you are prompted to choose a configuration. When running traceability reports, you must always choose a global configuration that is associated with the local configurations from the corresponding projects.

In order to prevent empty traceability reports across projects, if a local configuration is associated with at least one global configuration, the RB configuration picker will not allow you to select that local configuration because it would restrict the results to only half of the resources in the traceability path.

Saqib Niaz selected this answer as the correct answer

Comments
Saqib Niaz commented Sep 07 '16, 10:17 a.m.

Thanks a lot @kcornell for elaborating the solution in such detail. The answer is really helpful.

Your answer


Register or to post your answer.