Partially Update of an artifact via OSLC in Doors Next Generation

I don't believe we support PATCH - you'll have to GET the full artifact content, modify/add what you need, then PUT to update the artifact - in more detail:

First GET the artifact XML, using headers OSLC-Core-Version: 2.0 and Accept: application/rdf:xml plus the configuration MUST be specified using either header Configuration-Context or query ?oslc_config.context=... - while it may be possible to use header vvc.configuration note that this is legacy and you should probably best avoid it - personally I'd recommend the query parameter as it's nice and visible so it's easy to check for its presence.

Then update the XML perhaps to change the dcterms:title, or to add a Link To link add e.g. <j.0:Link rdf:resource="https://SERVER:PORT/rm/resources/TX_abc1231231231231231"/> where namespace j.0 is defined as xmlns:j.0="http://www.ibm.com/xmlns/rdm/types/"

Best way to see how the XML for a link should look is to manually create a link of the type you want from the artifact then GET it and examine the XML. Note you will only be able to create one instance of a particular link type to a particular artifact URL. You can try but you won't get more than one - the second link creation is silently ignored.

NOTE you only modify the rdf:Description which is for the artifact itself - no need to mess with the other rdf:Description present if there are outgoing links. How to locate the correct rdf:Description - it has an rdf:resource which is the same URL as the url for the GET. Or you could find the rdf:Description which contains a dcterms:identifier tag.

Then PUT the updated XML to the artifact URL using the same headers and configuration as the GET, with header If-Match set to the value of header ETag from the GET response.

It's possible (and not incorrect behaviour) for the update to fail with a "412 Precondition failed" if the artifact was updated by another user (which changes the etag) between the GET/PUT so your code should be prepared to handle this unlikely but not impossible case e.g. exiting with an exception or by reget the artifact and new etag and make the change again and do another PUT. Don't simply get the new etag and PUT the previous XML because that would lose the other user's change that has been made.

I strongly suggest you first try the GET/modify/PUT using a REST client in your logged-in browser because this helps you focus on getting the http GET/PUT working without worrying about coding it. Once you've got it working in a REST client you can develop code to do the exact same thing. IME one of the first things you should put in your code is logging of the full details of every http operation - host, URL, request headers (including cookies) and body and response headers (including set-cookies) and body. With this in place you're now in a good position to see the any difference between the successful manual REST client operation and the http request generated by your code.

HTH

Ian

Servers SHOULD implement PATCH, but the do not have to. 

Please be aware that the DNG module API is not an OSLC API as far as I am aware and does not have to adhere to such a standard.