It's all about the answers!

Ask a question

Eclipse Lyo RM Reference/ReferencedBy DNG

Thomas C. (111) | asked Jul 25 '23, 7:16 p.m.
edited Jul 26 '23, 2:40 p.m.

 Anyone here used Eclipse Lyo to create an application, which can link to DNG? I managed to create one and add Requirements. I can link my Requirements in DNG by using "References" linktype. However the corresponding link in my application is not created. Anyone knows why?

David Honey commented Jul 27 '23, 5:01 a.m.

Your question might be better directed at the Eclipse Lyo forum

Ralph Schoon commented Jul 27 '23, 6:22 a.m. | edited Jul 27 '23, 6:27 a.m.

This is, as so often, a minimalistic question about a very complex problem. It would be surprising if anyone would even attempt to answer such a question. I think it should not be a problem, to provide more information if an answer would be expected.

I wasted 15 minutes looking into my test system. Here some considerations based on that - which does not require Lyo or programming.

  1. The link type "References" is only available if you link two applications that support the RM profile. You have to set up the provider relationship to the same or another RM server to see the link type. So the question is, what app was linked to what app? Topology, etc.
  2. When the link is created, my assumption is that the link is only stored in one of the applications, as all the links are handled. Since there are no back links stored, why would one expect to see it in the other application?
  3. If the link is manually created, how does the data look like?

Thomas C. commented Jul 27 '23, 7:26 a.m. | edited Jul 27 '23, 7:32 a.m.

I already asked this question on the OSLC forum, so there is a bit more information there.

Essentially I created a RM application with custom Requirements and added it as a friend to DNG. In DNG I can add a link by clicking on a DNG-Requirement in my module and opening the Selector of my application. It shows my custom Requirement and allows me to add one. After clicking on "OK" a link is set in the "References" field in my module and by hovering over it, it also shows the attributes. However a link in my "ReferencedBy" field in my application is not set. There should have been one, which points back to the DNG-Requirement.

Ralph Schoon commented Jul 27 '23, 8:01 a.m. | edited Jul 27 '23, 8:01 a.m.

Did you actually read my comment? 

If you create the link manually, what happens?

As far as I understand it, there is nothing that specifies that the OSLC API has to create a back link. This is a design choice. As far as I am aware DNG does not expect back links. Instead the link is provided to the link index. This application is then queried for if a link exists. I am not the expert here, but your RM application would have to query the LDX/LQE for the links one of your requirement it is involved, for the links not being stored by your application.   

Thomas C. commented Jul 27 '23, 8:07 a.m. | edited Jul 27 '23, 8:08 a.m.


Adding a link manually works fine. However there should be a response from DNG to automatically add it to my application aswell. It works e.g. when I link my custom requirement to a Change Task. A link is then created in the "implementedBy" field. Just requirements in "referenced" does not.

Ralph Schoon commented Jul 27 '23, 8:18 a.m.

Again, as far as I am aware, incorrect assumptions about how the API has to behave and the existence of backlinks in the DNG OSLC RM implementation.

EWM/ccm uses back links for links between work items.

DNG does not. AFAIK DNG only stores links between DNG/RM applications. It does not use back links, but a link index to query if links exist. Links between DNG and other domains are stored by those other domains.  

Adding a link manually works fine. Does not explain where the links are stored, especially if looking at the link direction. My assumption would be, if the link starts in your application, it would be stored there. If it starts in DNG, it would be stored there.

I am not completely sure about this, this is best effort, so take it with a grain of salt.

Thomas C. commented Jul 27 '23, 9:23 a.m.


I googled using some of your keywords and found this error: It sounds exactly like my error, but is apparently fixed. It just seems strange to me, that there is a dedicated field (ReferencedBy), which exists solely as an opposite to "references", but does not get updated when setting a link. 

David Honey commented Jul 27 '23, 12:43 p.m. | edited Jul 27 '23, 12:44 p.m.
Thomas, you may be conflating two separate concerns:
  1. Inverse labels. For example, in ELM, the validatesRequirement link is owned by a test case and persisted in ETM. However, from a reporting and UI link display aspect, you might view incoming links to requirements in DOORS Next, and it will used a label such as "validated by". An inverse label says nothing about the ownership and persistence of the link.
  2. Back links. Many OSLC specifications define resource shapes that include representations of forward and reverse links, in which a relationship between a source and a target might be represented by a forward link stored in the application that owns the source, and a reverse link stored in the application that owns a target.
DOORS Next never stores links to artifacts in other domains, such as quality management or change management.
showing 5 of 8 show 3 more comments

One answer

permanent link
Thomas C. (111) | answered Jul 27 '23, 2:02 p.m.

 @davidhoney Yeah, I assume that is the error. It should be the problem which is also described here:

Therefore I assume I have to update my Lyo Application with some kind of function, which searches in the DNG module for links, essentially "Link Discovery"

David Honey commented Jul 28 '23, 4:16 a.m.
ELM applications such as DOORS Next and Engineering Test Manager use a Jazz Foundation service for discovering incoming links. For example, DOORS Next will discover the incoming links from work items and test cases to requirements it is managing by querying LDX (Link Index Provider). This uses a private proprietary undocumented API that is currently not open for use by 3rd parties.

The OSLC OP (Open Projects) working group has started work on a new OSLC specification named LDM (Link Discovery Management) whose aim will be to define a standard mechanism for OSLC clients to discover incoming links to specified artifacts. If you are interested in this topic, I recommend participating in the OSLC OP working group.

Thomas C. commented Jul 28 '23, 4:57 a.m.

I will keep an eye on it. For now I will use a Query as described here to search for linked artifacts in DNG and update the Requirements in my application accordingly. 

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.