How to derive the vvc.configuration header required for report generation through OSLC query in RDNG?
We are working on a batch utility that simulates the report generation(Word/PDF format) functionality in RDNG. We are using OSLC query for this. The response we receive comes with a status 200OK but reads failure in uploading report. Upon analysis, we came to know that twe need to add the header "vvc.configuration" to our print request.
The CLM 6.0 instance we use does not have any configuration management enabled. How can we fetch this value?.
Request Samples :
POST:
https://abc.com/rm/publish/print/requirement?resourceURI=https://abc.com/rm/resources/_eej_wWHGEeWIKvxOLW5Trg&formatURI=http://com.ibm.rdm/reports/formats/pdf&includeComments=true&showEmbedTitles=true&includeAttributes=true&projectURI=https://abc.com/rm/process/project-areas/_XuHmsmHGEeWIKvxOLW5Trg
Headers :
post.addHeader("Accept", "application/rdf+xml");
post.addHeader("OSLC-Core-Version", "2.0");
post.addHeader("DoorsRP-Request-Type", "private");
post.addHeader("vvc.configuration",vvc);
followed by GET on the Location header received as response.
3 answers
The resource you are requesting (.../publish/) is not an OSLC resource. The publish API is "Reportable REST 1.1" but the request parameters are indicating OSLC Core 2.0, as well as DOORS private requests. DOORS private requests are private and are not supported.
There is no way to obtain values of vvc.configuration programmatically. The design is such that requests that are made which do not supply any configuration context, the request will be made in the "default" configuration of the project. For opt-out projects, this is the only configuration in which requests can be made, so no configuration context is needed.
When you have enabled configuration management features in 6.0, so called "opt-in", then you can obtain configuration context resources using OSLC delegated UI. There is a delegated UI which allows a user to select a configuration. That resource URI is one you can supply via a request parameter which is called "oslc_config.context". DNG implements the OSLC Configuration Management specification, which explains the protocols and terminology. You can use that configuration context parameter on both OSLC and RR APIs.
There is no way to obtain values of vvc.configuration programmatically. The design is such that requests that are made which do not supply any configuration context, the request will be made in the "default" configuration of the project. For opt-out projects, this is the only configuration in which requests can be made, so no configuration context is needed.
When you have enabled configuration management features in 6.0, so called "opt-in", then you can obtain configuration context resources using OSLC delegated UI. There is a delegated UI which allows a user to select a configuration. That resource URI is one you can supply via a request parameter which is called "oslc_config.context". DNG implements the OSLC Configuration Management specification, which explains the protocols and terminology. You can use that configuration context parameter on both OSLC and RR APIs.
Comments
The batch utility we have is compatible with CLM 5.0 but the same doesnt work for CLM 6.0. The only difference we could come across was the vvc.configuration header, which when provided manually helped publish the report. Is there any other way to publish the artifact? We have been using the OSLC query capability in our utilities and have worked well for CLM 4.0.3 and CLM 5.0.
If you don't need to fetch the vvc.configuration parameter programmatically, simply access the project in a browser and grab the parameter from the address bar. Since the project is not CM enabled, there is only one value for the configuration URL. The actual request that returns the configuration URL appears to be /rm/view-history which you can use it in your script if you insist - it returns a JSON only format response.
Comments
The /rm/view-history URL did provide a response in which I can find one of the atom:link tags containing the vvc.configuration link that is being used in the project area.
The problem is that there are multiple "atom:entry" tags and it is impossible for me to programatically fetch the URL specific to the PA from the response using XPath as I cant see any tag for project area.