It's all about the answers!

Ask a question

Partially Update of an artifact via OSLC in Doors Next Generation

Philipp Thomann (305) | asked Feb 15 '22, 5:16 p.m.
edited Feb 15 '22, 5:27 p.m.

I am developing an application with which I fetch Data  from our Doors Next Generation (7.0.1) using OSLC and C#.
I fetch Base Artifacts (Typ = Text ) with its Attributes and Modules (Typ = Modul) with its Attributes.
  --> So far so good

If I want to update the Attributes of the Artifact (Typ = Modul): I experience some difficulties....

I am getting an error when the Modul has "Active" Links to Text Artifacts... (update of all properties) is not a literal node

--> I was able to find an workaround... If i delete the Link - update the Attributes and create the link again i can avoid this issue But this way takes alot of time and is also not really "save" e.g. when an unexpected error occurs

Is there a possibility to PARTIALLY the Attributes Related to the Modul? For example: I only want to update the Name Attribute and ignore all others... I was thinking something like the PATCH keyword like I found here:
But this doesn't seem to work
Many thanks
Best regards

Accepted answer

permanent link
Ian Barnard (1.9k613) | answered Feb 17 '22, 6:19 a.m.

Hi Philipp

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=""

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.


Philipp Thomann selected this answer as the correct answer

Philipp Thomann commented Feb 18 '22, 3:07 a.m.
Hi Ian

Many thanks for your detailed answer.
I will investigate where and if I deviate in my actions and post an update by next week.

Have a nice weekend.

Philipp Thomann commented Feb 23 '22, 3:22 a.m.
HI Ian

The problem in the was the following: While using custom Links: An URI has to be defined in the Link types settings. When this is done the update works as expected.

Many thanks.

One other answer

permanent link
Ralph Schoon (63.0k33645) | answered Feb 16 '22, 2:58 a.m.

 Please see (search for PATCH).

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.

Ralph Schoon commented Feb 16 '22, 2:59 a.m.

The link does not have anything to do with the Jazz Products as far as I can tell.

Philipp Thomann commented Feb 16 '22, 3:59 a.m.
Hi Ralph, thanks for your response! Considering what I've just read its likely that our server might not support PATCH...

But to my Issue I actually want to solve: I can not update the Attributes of a Module when It has active links to other artifacts...
 --> ERROR: is not a literal node
Error status 400

(I am only replacing one "Name" with another)

When no links between the Artifacts exists the PUT update works perfectly.

Do you have any Idea why I might experience this Issue or can you point my in a direction? :)

Many thanks

Philipp Thomann commented Feb 16 '22, 4:07 a.m. | edited Feb 16 '22, 4:07 a.m.
Maybe now I am super confused but:

You can use Open Services for Lifecycle Collaboration 2.0 (OSLC) capabilities in the Requirements Management (RM) application for the Rational solution for Collaborative Lifecycle Management (CLM). This article includes examples of how to use those capabilities in an HTTP poster tool. These basic examples are described.

From this sentence I concluded, that DOORS NG should follow the OSLC Standard... But I probably misunderstood something

Ralph Schoon commented Feb 16 '22, 4:21 a.m.

I do not want to write an epic here. I see a lot of questions around OSLC. There are all kinds of problems with these questions.

Users claim to use OSLC, when they are not and it is clear they do not understand what OSLC does and does not do and how it works. The questions usually fail to provide the necessary details to be able to tell. In this case there is a Module API for DNG and there is an OSLC API. They do different things and support different things. There is no way to tell which API is used and if it is used correctly from the question.

OSLC is a standard and as such defines what a compliant system MUST or SHOULD support. The server can not implement the should parts.

Philipp Thomann commented Feb 16 '22, 4:28 a.m.

Thanks for your response. I opened a ticket at our support with a detailed problem description... I will post the findings later under this question

Your answer

Register or to post your answer.