Doors Next Revision History data inaccurate
I am using the below-mentioned endpoint to fetch VVC Revision History
PARAMETERS: url : <artifact_resource_url>
HEADERS: Accept: application/rdf+xml, OSLC-Core-Version: 2.0, Oslc.Configuration: <gc_configuration_url>
When any Folder-Bound artifact resource URL is passed as a GET request, it returns with an XML response with Vvc Revisions History Service, with perfectly accurate and curated data, containing all the revisions and links to respective versions.
But,
When a Module-Bound artifact resource URL is used instead, the response data is comparatively less, & not all the revisions are listed (in most cases, only the latest ones).
I need Revisions History for the artifact-data as well as links.
Folder-Bounded artifact responses do NOT capture Links/Link History, whereas Module-bounded artifacts do,
When a Module-Bound artifact resource URL is used instead, the response data is comparatively less, & not all the revisions are listed (in most cases, only the latest ones).
I need Revisions History for the artifact-data as well as links.
Folder-Bounded artifact responses do NOT capture Links/Link History, whereas Module-bounded artifacts do,
hence, I need a solution here.
3 answers
Rather than tell you what you can't do - let's try a different approach. The DNG Reportable REST API allows you to retrieve revision information for artefacts as well, and that IS officially supported. That approach might get you what you need.
You have a couple of options here:
- https://server:port/rm/publish/resources?history=true returns the artefact history as part of the content, and it can also be filtered by time range and by a specific user. See: https://jazz.net/wiki/bin/view/Main/DNGReportableRestAPI#Scope_and_Filtering_Parameters
-https://server:port/rm/publish/revisions returns revisions for a resource or collection (artefact or module) and information about the revisions (versions) of the artifact, the author of the changes, the date, and a link to the specific version of the artifact. See: https://jazz.net/wiki/bin/view/Main/DNGReportableRestAPI#Specialized_namespaces
Your question seems to swap things round - in the first part you say artefacts in a folder (i.e. artefacts in the base context), are perfectly accurate, but artefacts in a module context aren't. But then in the last part you say the opposite?
From my experience, when you pull revisions from a module context, you see changes to the artefact *in the module's context* - so when it was inserted or moved, or when links, comments or tags are added, edited, removed in the module's context. You get only the things that can be recorded within the context of the module and nowhere else.
When you pull the artefact revisions from the base context, you see changes to the artefact that affect it globally - so changes to attributes, state, and links, comments and tags that are made directly on the artefact. The base or global context can't possibly know all the places that artefact is used and so won't track changes across each of the module contexts that it appears in.
So, if you are trying to build up an audit history of an artefact in a module that includes ALL changes, you need to pull both the module and base context and merge them. This is why an audit history of a module insde the UI is quite long and takes time to generate
vvcrevisions isn't a supported API.
Comments
Hi Davyd
That's a technote for use with clients by IBM support when we need to capture some information as part of a case - that doesn't mean it's a supported API.
Regards
Ian
Being a url that DOORS Next responds to in some way DOES NOT make that url a supported API. Supported APIs are documented https://jazz.net/wiki/bin/view/Deployment/ELMProductAPILanding
If that's the case then I would recommend not making it a public tech note with the heading "How to capture vvc revisions for an artifact or stream on IBM DOORS Next?" and the Summary "Steps for users to capture vvc revision of a specific artifact on IBM DOORS Next."