It's all about the answers!

Ask a question

Is DNG link creation callback attempt part of OSLC spec?


0
1
Matthew Stone (23311) | asked Jun 06 '17, 12:08 a.m.
edited Jun 06 '17, 12:09 a.m.

Is the DNG OSLC link creation callback feature part of the OSLC spec?  When you attempt to create a link using an OSLC provider (Friend) as the source for linking to a DNG resource, DNG attempts to let the provider know a link is being established.   Is this concept part of the OSLC spec?  Even if it is, I believe DNG should still create the link on its side rather than say "the other server failed".  If you're lucky to get that much information.

From what I'm seeing, this callback concept is creating a misleading interruption because DNG is attempting to let the provider know its creating a link but it cannot consume the providers' RDF resource response  As a result the link creation process fails overall.  I'm testing this with the baseline OSLC provider sample Bugzilla Adapter.  DNG shouldn't care if it cannot reconcile the provider's RDF resource (it should this occasion)  but it should create the link anyway because that's what the end user instructed the tool to do.  Furthered by the fact it has the uri the delegated UI provided.  And even more so because a DNG administrator registered this "friend" and "association" as a resource for linking.

Thoughts?

My 2 cents - DNG and other Jazz tools should always know how to communicate with the Lyo Bugzilla example. It's clear it doesn'tHere too.


Comments
Matthew Stone commented Jun 06 '17, 12:15 a.m.

For the record, I'm using DNG v6.0.3 and Lyo Bugzilla 3.0.0-SNAPSHOT.  Both the latest. Am I missing something?

2 answers



permanent link
Jean-Luc Johnson (8125) | answered Jun 06 '17, 7:25 a.m.

The callback process you have described above is not part of the OSLC specification. I have just checked the code of the OSLC Bugzilla adapter and a HTTP PUT method has been implemented. It worked for me year ago when I was developing my OSLC adapter to work with Jazz 5.x applications.
You should contact the IBM support team in order to find out more about your issue.


permanent link
Jim Amsden (29337) | answered Jun 06 '17, 8:52 a.m.
When you create a link from RDNG (as a friend or client) of RTC (as a server providing a consumer key), say Requirement implementedBy WorkItem, you are using the RTC WorkItem selection or creation dialog as defined by OSLC. However, RDNG and RTC have been developed to create "backlinks" to enable easy navigation of a link from either tool. So when RDNG creates the Requirement implementedBy WorkItem, it asks RTC to create the link WorkItem implements Requirement. I'm not sure, but I think that's done with a simple PUT.

The creation of these symmetric "backlinks" is not part of the OSLC specification, but can be supported by tools using standard OSLC capabilities and services in a specific pattern.  Backlinks are in fact contrary to OSLC best practices. They put the same information in two places: RDNG stores the Requirement implementedBy WorkItem link, and RTC stores the WorkItem implements Requirement link. This is essentially redundant information in two different server persistent stores that has to be maintained. OSLC does not define or support inverse properties, so there is no formal relationship between the implementedBy and implements properties. 


When RDNG project areas are config enabled, this redundant information can no longer remain, and all the  Requirement/WorkItem links have to be removed from RDNG and stored in RTC. In this case, the WorkItem implements Requirement property is contributed to the Indexed Linked Data Provider (using TRS) so that RDNG can use a query to calculate and display its incoming Requirement implementedBy WorkItem derived properties.

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.