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.
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 ;)
Comments
