DNG XML Issues - Configurations Give Nothing
Hi everyone -
If I follow the following configuration-aware URL:
The XML content returned is blank.
If I remove the configuration, I retrieve the results I am looking for:
What could be causing this? We've tried re-indexing DNG and that hasn't appeared to rectify this issue.
I am hoping someone can help me understand this issue.
Thanks,
David (DNG v6.0.2 iFix015)
|
2 answers
Does the module exist in that stream? And what does the rm.log say when you issue that request?
You could also enable DEBUG logging for the PublishService class.
|
|
I tested this on my end on 6.0.4. This does work as expected, barring any typos.
Create a config enabled project. Make sure there are two components with modules. I used the OOTB Agile Sample as a component template.
Both of these calls return XML data that reflects the content of the module resource in the specific component. The component is referenced by the oslc_config.context.
The other observation is that the modules had different resource URIs in my scenarios.
During my testing, I got the same blank response as you David only once. And that is when I had a typo in one of my URIs. Otherwise it works as expected per this test.
https://servername:9443/rm/publish/modules?resourceURI=https://servername:9443/rm/resources/_c65ad2c94b6a459f9b81529ff2c3ea77&oslc_config.context=https%3A%2F%2Fservername%3A9443%2Frm%2Fcm%2Fstream%2F__yOsdpAOEeiuro6eBu0pQw
https://servername:9443/rm/publish/modules?resourceURI=https://servername:9443/rm/resources/_02d546b8634e47f691c4899e5b025ac0&oslc_config.context=https%3A%2F%2Fservername%3A9443%2Frm%2Fcm%2Fstream%2F_FodVdpAOEeiuro6eBu0pQw Comments Hi Rosa -
I appreciate you taking a second look at this. There's obviously some coordination I need to perform on my end to diagnose if error messages are being tripped.
I will say that even expanding the module URL (the way that you have) does not result in content. The only way I can access the content is by removing the OSLC config context parameter (but obviously is not ideal for a host of reasons).
I did test with a different module and I was successful. Is there any explanation for this behavior?
Thanks!
David
David
I am not sure what you mean by expanding the module URL the way I have.
If you have an example of it working with a different module using the same understanding and constructs I provided then it could be an issue with this module itself.
The only way to go into it further would be a support case, which would require gathering logs, and possibly uploading a REQIF of the module.
I found that in my case ( which is consistent with how it should work) when working with the original/initial component and modules and this API, the XML results are the same with and without the oslc config context when dealing with the initial component.
It only really matters once you have more than one component and you trying to make sure you retrieve the module xml from that configuration.
Rosa -
By expanded, i mean the fact that you used the full resource URL when constructing the "resourceURI=" statement, whereas you could typically just use the hashed string:_c65ad2c94b6a459f9b81529ff2c3ea77.
I don't know that ignoring the configuration would solve my issue. We're in 6.0.2, so we don't get the luxury of componentized data.
I appreciate your willingness to help here. I do not want to seem ungrateful for your advice to open a ticket and follow that process - but in my experience, our issues have typically come back to a need to re-index LQE. Could LQE be the culprit here?
Thanks,
David
To be honest, I don't know if LQE plays a role in the output of the DNG Reportable REST API. My gut says no, but not 100%.
I think I may have to rethink this and try this scenario on a 602 server because as you mentioned, with the introduction of components in 603, the behavior of the API may be different.
Have you confirmed that there is a module in that stream or config context? I always start by what the UI reports. Change to that stream or changeset or w/e the config context is and make sure the module exists there.
Rosa -
We've noticed the most issues tend to be resolved after rerunning the LQE indexer / TRS feeds. It likely does not help that we're in an outdated version.
I can confirm that the module is in the stream / configuration I am attempting to view it in, in addition to being in the "trunk" stream.
Thanks,
David
|
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.