Print Report not working for users located far away from our servers

ReportWORQ
1

Some of our users located outside the US have had issues using the Print Report feature within ReportWORQ on a Planning Analytics for Excel dynamic report that works perfectly for users based in the US. What happens when they use Print Report to burst worksheets based on a subset is that some of the worksheets will have #VALUES in some of the cells even though it was a valid intersection. The error logs give repeated messages stating that the element isn’t found or is invalid. This happens inconsistently when there is a value in the cell and when the value is zero. It’s not consistent which worksheet will have the #VALUES, but it does seem to be isolated to some DBRW formulas. These are complex, “heavy” dynamic reports with both TM1 formulas and Excel formulas. We’ve tried many things including upgrading Planning Analytics, Pafe, and ReportWORQ.

2

Hi Charissa,

Thanks for reaching out! Can you get one of the affected users to try running a Print Reports job with Debug + Trace logging switched on (via the “Settings” ribbon button in Excel):
image

Be advised this may generate some very large log files-- if you’re able to reproduce the error and capture those log files then reach out to our help desk at: support@reportworq.com. From there we can try to set up a meeting and look them over in more detail. It’s possible a connection timeout is happening, for instance if the connection is briefly interrupted or takes too long to get a response.

Also note that there is a pretty significant update to the Print Reports add-in coming in early 2023 that may help here, which is why I’m interested in seeing what sort of problems you’re running into-- would love to make sure we’ve also covered whatever might be happening for your remote users, if possible.

Thanks!
Mike

3

Thanks Mike for reaching out! We have also suspected the connection being interrupted. We did update our configuration to extend the time-out settings to be multiple hours which fixed nothing. The connection could still be a suspect though based on the behavior. Which makes me think this isn’t a ReportWORQ issue, but an IBM Pafe issue. But of course we have to be able to prove that for IBM to provide any support.

We will work with our end-user in Canada to turn on the Debug Logging and Trace Logging. Which version do you expect us to be using? Currently we have 4.4.0.138 and at the time I installed this it was still in beta. I see there are newer versions.

Thanks for your help.

-Charissa

4

Hi Charissa,

It may not be related to a problem in PAfE, since we don’t rely directly on PAfE to connect to the PA server & refresh reports from Print Reports. However, if you sometimes see similarly slow or inconsistent recalculate behavior with PAfE from those network locations then I expect ReportWORQ would have some of the same problems, too.

If you are planning to try and capture some trace logging information you’ll probably want to update those users to the latest official release, which as of right now is 4.4.0.165 (ReportWORQ 4.4 Official Release, from December 1) and can be found here:
https://docs.reportworq.com/v4/docs

I think some of those trace logging settings weren’t available or fully-enabled in much earlier releases like the one you mentioned.

Some of the updates coming in an early 2023 release are going to performance-related, so it’s possible those updates will “fix” the problems that your Canadian users are seeing, but again seeing some of the log detail will help confirm that.

Thanks!
Mike