Retrieving custom artifact fields from a global configuration context
Hi Jazz community,
I have a question regarding OSLC.
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
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 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. Leaving an additional comment, so my reputation goes to 15, and I can upvote your answer.
Mine looks like: https://redacted/rm/cm/component/_IwscYDzrEeWJpodFEUUUBg
You will get it from the DOORS NG module resource properties (via OSLC API)
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.