It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×5,996
×5,814
×469

question asked: Apr 25 '18, 11:52 p.m.
question was seen: 1,982 times
last updated: May 04 '18, 2:39 p.m.

Related questions

FAQ - How this Forum works

Why is REST API not returning audit history for some artifacts in DNG?

0
Robert Huet (231●1●28●84) | asked Apr 25 '18, 11:52 p.m.
edited Apr 25 '18, 11:54 p.m.

For some artifacts in our DNG 6.0.4 repository, the "resources" query with "&history=true" is not returning any audit history.  Also, when we run the out-of-the-box Audit History report (which uses this same query) we get nothing.  However, when we run the "revisions" query, we get all the revision history records.  Also, the audit history shows up in the "Audit" tab in the UI.  Again, this only happens for some artifacts.  Others return the history just fine via the API.

We have a Sev 1 PMR open on this because it is critical to our project to be able to get reliable audit history reports to communicate what requirements have changed.  These reports go to overseas developers who don't have access to the system.  However, IOT Support cannot reproduce the problem and has not been able to resolve it.  Any insights on what could be causing this behavior and or how to further troubleshoot it would be greatly appreciated.

Comments
Donald Nong commented Apr 26 '18, 12:09 a.m.

As it only happens for some artifacts, have you been able to find the pattern(s) of these artifacts?

Robert Huet commented Apr 27 '18, 10:30 a.m.

Not yet.  I agree, we need to spend some time trying to establish what these artifacts that are not returning history have in common.

Robert Huet commented May 02 '18, 1:19 p.m.

 It turns out that the artifacts that are not returning history have "Validated by" links to Test Cases in RQM.  We added debugging parameters to the log and identified the following error in the history service.  Our logs are still in the hands of the development team.


Caused by: com.ibm.rdm.fronting.server.exception.DownStreamAuthRequestedException: Propagated exception; original message [DownStreamAuthRequestedException: DownStreamAuthRequestedException: PROVIDER_REQUIRES_AUTH: Host is requesting authentication https://<server>/qm/oslc_qm/contexts/_aC9CQPfREeOd1div3hxkJQ/resources/com.ibm.rqm.planning.VersionedTestCase/_6OQ4sQT8EeeskuyKHUAgjQ {preAuth=false, skipAuth=false userId=ADMIN  GET toConn=120000ms toSock=3600000ms -01 306ms https://<server>/qm/oslc_qm/contexts/_aC9CQPfREeOd1div3hxkJQ/resources/com.ibm.rqm.planning.VersionedTestCase/_6OQ4sQT8EeeskuyKHUAgjQ}]

Donald Nong commented May 02 '18, 10:08 p.m.

Thank you for keeping us updated and it is good to hear that you've made some progress. Is it a distributed environment? If so, please let the team know. I remember seeing a defect where the authentication is not handled properly in a RQM/DNG distributed integration environment, and this one may be similar.

One answer

Most liked answers|Newest answers ↑|Oldest answers

0
permanent link
Robert Huet (231●1●28●84) | answered May 04 '18, 2:39 p.m.

 Development has opened a defect on this problem.  Turns out that it only affects DNG repositories that have opted out of using configuration management.

We are now testing a patch to fix this issue.

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.