Hello guys!
I have a problem when integrating Lyo generated adapter with IBM Jazz Requirements Management solution. The problem is that we can not enforse the Jazz to accept a resource in a form generated by Lyo. To fix this problem we were using forwarding to a custom JSP file containing RDF presentation of a resource.
But some days ago, I was researching ITO sample and detected that that one can generate an RDF presentation in a way that we need. But I can not get the same in my own adapter because I don’t understand what Lyo classes require to work properly. Let me please explain the details with next screenshot:
The top part displays an RDF document that is generated by Lyo. It builds <oslc_qm:TestCase …> presentation of resource. But IOT sample can create multi-section presentation with parts named as <rdf:Description …> (it’s shown on the part of screenshot in the bottom). This presentation works in Jazz like a charm.
Could please somebody help me to cope with this problem. I was trying many approaches. And I remember that I have got it somehow some months ago but I can reproduce it nomore.
Now, I’m using Lyo v5.1.1.Final. But IOT sample is designed based on very old version of Lyo. May be this is why it worked, isn’t it?
Thank you!
The problem is down to Doors NG not working well with RDF. If I recall correctly, in some cases it only works with a very specific form of RDF/XML-ABBREV. Lyo has maintained a custom ABBREV serializer, but I think some changes in new major versions of Jena or order of providers in Lyo may have affected the output slightly (of course, Lyo output is spec conformant).
I would be interested to here what you mean with “the problem is that we can not enforse the Jazz to accept a resource in a form generated by Lyo.” What is the problem? How does it manifest itself?
I have been recently been able to create links to Doors NG, using a Delegated UI. But maybe you have a differnece scneario?
Hello guys,
Sorry, it was my failure. I didn’t explain the problem clearly missing of my view that another use case can be applied. Let me please say that I don’t create any links to RM artifacts from outside. We develop a custom Lyo-based OSLC adapter that can communicate with Jazz RM app directly from RM app itself. It means that RM starts a sequence of actions, and if the adapter will correctly respond on each step, then I can expect that Jazz will provide correct information from it to the adapter.
So, I have now started IOTP adapter taken as a sample (it’s started at a single Tomcat 9 server), registered in Jazz RM as a friend, and “Implementation Requests” association on project administration page was made.
Next, I go to some RM artifact, and try create a link to the adapter’s resource in “Links” section.
It works perfect when I use IOTP sample taken from here:
You can see that I was able add a link in Jazz for the adapter’s device (although, I use some fake data taken from custom JSON files). And this adapter returns on GET request RDF presentation of a device in format of multiple sections:
This format is properly processed by Jazz when I return it back from the adapter. But in our own adapter, we can not understand how this kind of presentation with multiple sections of Description element is formed. Our adapter can return something like next by default:
This format can not be accepted by Jazz and the chain of requests stops right after getting a response by first GET request. In case of IOTP adapter (and in case of other Jazz apps), we can see the following PUT request sent to the adapter, but our adapter can not get this additional request. We can do it in our adapter only with forwarding to our custom JSP file returning the required RDF presentation.
So the question is what is responsible in IOT for proper presenting of a resource in RDF format. It occurs somehow automatically, may be because of better describing the device resource in a clas, or by another reason. And we can not understand what the difference is.
Thank you!
Are you sure the problem is in the difference in the format?
You say that your adaptor does not handle the PUT requests. Could that be hte problem? Jazz is sending a PUT request that you are not handling. Hence a error.
Can you implement a Put Request, that simplee returns 200.
Did you try feat: Control the RDF output format manually by berezovskyi · Pull Request #277 · eclipse/lyo · GitHub ? I developed that PR to fix your issue exactly. I don’t know what caused a regression - some change in Lyo or a Jena version upgrade. Worse is that the regression is not manifesting 100% of the time - lyo-samples client code works OK without a need for the PR. I will be able to investigate DNG with IOTP adaptor no earlier than a month from now.
@jad, yes, it’s a format difference. DNG does not accept all valid RDF/XML serialisations.
No, the problem is that Jazz doesn’t send back PUT request by some reason. I believe that the reason is just another format of first RDF document returned from the Lyo adapter to Jazz. At least, I have added custom JSP file (with rdf:Description tags used) returned from Lyo to Jazz, and next Jazz starts sending PUT request into the adapter.
I believe that Jazz expects to get RDF document in some predefined format. And it doesn’t support all possible formats of RDF documents.
