It's all about the answers!

Ask a question

Retrieving custom artifact fields from a global configuration context


Xander Houtman (132) | asked Oct 08, 4:27 a.m.
edited Oct 08, 4:28 a.m.

Hi Jazz community,


I have a question regarding OSLC.

DNG version: 6.0.5
Goal: Export a requirements module using OSLC from any configuration context, global or local. Given are the module URI, configuration context URI, and (global) component URI.
Module URI example: "https://redacted.com/rm/resources/_RedactedModuleId"

What works: exporting from a local context.

Problem: When exporting from a global context (baseline, stream, or staging baseline), details about the custom properties of the module and requirements cannot be obtained.

Tried so far:
Using different headers for the configuration. I have used "vvc.configuration", "oslc.configuration", "oslc_config.context", and "Configuration-Context"

Example of working query (Local config)
https://redacted.com//rm/types?resourceContext=https://redacted.com/rm/customartifact/MyOwnExample
With headers:
("Configuration-Context","https://redacted.com/rm/cm/stream/_RedactedStreamId")
("Accept", "application/rdf+xml")
("OSLC-Core-Version", "2.0")

Example of broken query (Global config)
https://redacted.com//rm/types?resourceContext=https://redacted.com/rm/customartifact/MyOwnExample
With headers:
("Configuration-Context","https://redacted.com/gc/configuration/123")
("Accept", "application/rdf+xml")
("OSLC-Core-Version", "2.0")

Workaround:
Since I have a module URI and global config URI, I can query all Local configurations in the global configuration, then query all Project Areas in these local configuration, and finally figure out which local project area contains the module that is being exported. Based on this, I would be able to obtain the local configuration URI, and use that in the query.

Suspected problem:
Because the custom artifact details page is not linked to a module, it is not linked to a local project area, hence not linked to a local configuration. Hence, the version of the custom artifact cannot be established, as its version lives in local configurations.

Question:
Is there a better way of dealing with this? It seems so overkill to do all these queries simply to get the local configuration URI.

Accepted answer


permanent link
Benjamin Röhl (135318) | answered Oct 08, 4:42 a.m.
Hi,

I have faced the same issue.

As a workaround, we are querying another service:
Accept: application/json

You will receive a response with a "highestOrderConfigurationUri" property, pointing to the local configuration Uri.

Might be faster than traversing the global configuration yourself ;)
Xander Houtman selected this answer as the correct answer

Comments
Xander Houtman commented Oct 08, 8:11 a.m. | edited Oct 08, 8:36 a.m.

Hi,

Thank you for the answer.
I almost did not get it to work, but I found the problem.
So for those stumbling onto this issue:

1. componentUri and configurationUri are case sensitive for configurationResolutionService
2. The componentURI argument seen from the webview speaks of the same component, but is not in the right format. Expected for componentUri is as follows:
https://{server}/rm/cm/component/[COMPONENT_ID]
Seen in your web-browser when looking at that component is the following:
https://{server}/rm/rm-projects/[PROJECT_ID]/components/[COMPONENT_ID]
If you fill in an invalid componentUri argument, the service returns a 200 answer, which is deceiving.


Xander Houtman commented Oct 08, 8:38 a.m.

Leaving an additional comment, so my reputation goes to 15, and I can upvote your answer.


Benjamin Röhl commented Oct 08, 8:39 a.m.

You will get it from the DOORS NG module resource properties (via OSLC API)

Your answer


Register or to post your answer.