why all artifacts not getting return by OSLC API upon specific scenario?
aaresha vora (11●3)
| asked Oct 29 '18, 2:09 a.m.
edited May 18 '22, 11:18 a.m. by Shailee Sinha (11●3)
why all artifacts not getting return by OSLC API upon specific scenario?
In doorsNG, we have created following requirements structure.
At project level created following two requirements one text and module:
Requirement#1
Module#1
At Module#1, added the Requirement#1 (i.e. created a shared requirement)
Request URL: fetching all the requirement artifacts which are updated after given time.
https://{{host}}:{{port}}/rm/views?oslc.query=true&projectURL=https://{{host}}:{{port}}/rm/process/project-areas/{{projectKey}}&
oslc.where=dcterms:modified>="2018-10-26T06:51:18.423Z"^^xsd:dateTime and oslc:instanceShape=<https://{{host}}:{{port}}/rm/types/{{entityTypeKey}}>&oslc.prefix=dcterms=<http://purl.org/dc/terms/>,oslc=<http://open-services.net/ns/core#>&oslc.select=*
Response#1 : all 3 artifacts [expected results)
API result is correct as soon as we are not performing below step.
Step: insert one more child artifact below the shared Requirement#1.
Response#2 : After above operation, API should return all 5 artifact as meeting the criteria. but actual result not holding shared artifact Requirement#1. Expected result [Base Req#1, Module#1, Shared Req#1, Base Child 1.1 , Shared Child 1.1]
Refer the URL for request and response of the API.
https://documenter.getpostman.com/view/4087218/RzZ1qNC5
Can anyone help us to understand why the API behaviour is getting change upon adding the child artifact in module? i.e. why shared artifact corresponds to base requirement#1 not included in API response even though that artifact is exist and meeting criteria.
|
||||
Be the first one to answer this question!
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.
Comments
Hi - what version and ifix are you using?
Please give me an example of the name of the type for requirement#'1 and of modue#1 - these shouldn't be the same type, but the only way I think you can get your response#1 is if they are, because your query is asking for only artifacts of a single specific type. "oslc:instanceShape=<https://{{host}}:{{port}}/rm/types/{{entityTypeKey}}>"
When I do the steps as you describe using 7.0.2 iFix009, I get five results, HOWEVER I don't think you should modify the format of an artifact from Text to Module (or vice-versa); the natural way in DN is to define types for your requirements, e.g. Hardware Requirement in Text format, and different types for your modules e.g. Hardware Specification in Module format. If you need a single query to return instances of both these types you can do e.g. oslc:instanceShape in [<requirementsShapeURI>,<moduleShapeURI>]
Using this approach of distinct types for modules and requirements means they can have different attributes which feels quite appropriate because modules are different from requirements you can also easily query just for modules or just requirements.