It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×1,036
×475
×331

question asked: Mar 13 '15, 9:46 a.m.
question was seen: 4,049 times
last updated: Mar 13 '15, 10:43 a.m.

Related questions

FAQ - How this Forum works

What is Preventing my RPE Report Resource from Being Portable?

0
Nate Decker (378●1●42●61) | asked Mar 13 '15, 9:46 a.m.
edited Mar 13 '15, 10:01 a.m.

I have developed a very simple report resource for RTC using RPE. The report has a single data source which I have made external and initialized with the ${public} parameter. At the beginning of the report, the data source is dynamically reconfigured to pull data from work item(s) that are specified with an external variable that the user can populate in the report dialog.

I have two different server installations where I am testing this: a Sandbox, and a Production environment.

The report works successfully on the Sandbox. None of the URL's are hard-coded into the report, they are derived from the ${public} parameter.

When I take the same report and deploy it on our production environment, I get an error when I try to run the report:

Error in engine Can not redirect to the OAuthentication identify URL. Request URL: [the URI that the data source is using for the dynamic configuration]

Anyone know what is going on here?

Some of the notable differences between the sandbox implementation and the production implementation:

1) The Sandbox is a single server with all applications running on that one machine. Production has separate servers for JTS/RM, and CCM. Single sign-on is enabled on the Production server though.

2) The Production server used to have another name which still shows up in some places in the configuration. I'm not sure if this is related; the only reason I mention it is because of the "redirect" word in the error message.

Other things I've tried:

1) permutations of the "Configuration required" argument for the data source. I currently have it set to URI, but I've tried "credentials" and "full" as well. Similarly, I've tried changing the Authentication argument on the dynamic data source reconfiguration step. I've tried OAuth, Auto, and blank. Both OAuth and Auto seem to work on the Sandbox.

2) Rather than try and detect the server name at run-time using the ${public} parameter. I've tried hard-coding the server's URL. I think one of the times that I did this, I got the error to not display. However, none of the work item data was fetched successfully. My containers were empty.

Any insight would be appreciated.

Edit: I've attached the report for what it is worth in the IBM developerWorks forum for RPE:
https://www.ibm.com/developerworks/community/forums/html/topic?id=18d08681-071d-445d-abb2-da809038e985&ps=25

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Alanna Zito (1.3k●3) | answered Mar 13 '15, 9:57 a.m.
JAZZ DEVELOPER
Hi Nate,

What version of CLM are you using?  Since the report is working in your sandbox, I wonder if you could be running into RRDG authentication should be able to handle the case where the app is a friend of itself (313087), which was fixed in 5.0.1.  On the production server, can you check to see if the CCM app is a friend of itself (you may need to ask an admin)?
Comments
Nate Decker commented Mar 13 '15, 10:18 a.m.

We are on 4.0.6. When I look at the application administration page for the CCM application, I see it is listed as a friend of itself. The administration page for JTS didn't show the same thing (it was not a friend of JTS) so I've made that change just in case it mattered.

The change doesn't seem to have made a difference. I'm still seeing the error message. It was worth a shot so thanks for the suggestion, but it looks like something different is at play here.

Nate Decker commented Mar 13 '15, 10:27 a.m.

I'm not really married to the whole portability objective. I think it would be a nice feature for the report resource, but it's not a show-stopper if I can't get that to work.

It's noteworthy that if I hard-code the URI into the report resource, and if I change the Data Source Schema's "Configuration required" property to "full", I no longer get the error message. However, the data source seems to be unable to fetch information about the work items. I'm not sure if that's a different problem or just a different manifestation of the same problem.

I thought I would provide this information if it helps at all.

If I could get it to fetch data successfully when hard-coding the URI, that would be an acceptable solution.

Alanna Zito commented Mar 13 '15, 10:39 a.m.
JAZZ DEVELOPER

Just so I'm clear - did you remove CCM as a friend of itself, or did you add it as a friend of the JTS?  The workaround for defect 313087 is to remove CCM as a friend of itself.

I can't think of any reason that the oauth error could be related to whether or not the URI is hard-coded, so my guess is that it's a different problem - I'm not really familiar with what effect the "Configuration required" property would have.  When you have the report configured like that, does it still run properly in RPE?  

Do you have access to the server logs (ccm.log?) If so, could you try running the report, and then check to see if there are any errors, warnings logged? 

Alanna Zito commented Mar 13 '15, 10:43 a.m.
JAZZ DEVELOPER

Just so I'm clear - did you remove CCM as a friend of itself, or did you add it as a friend of the JTS?  The workaround for defect 313087 is to remove CCM as a friend of itself.

I can't think of any reason that the oauth error could be related to whether or not the URI is hard-coded, so my guess is that it's a different problem - I'm not really familiar with what effect the "Configuration required" property would have.  When you have the report configured like that, does it still run properly in RPE?  

Do you have access to the server logs (ccm.log?) If so, could you try running the report, and then check to see if there are any errors, warnings logged? 

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.