We've been working on integrating with the Reporting features on the Tessitura API for one of our clients lately, and we've recently ran into some issues. When I first started working on this (around 5/12/21), we were able to generate Report Schedules and direct Report Request calls that would successfully execute on the Test server (it never worked on the Prod server). Around 5/28/21, the reports requests stopped executing on the Test server as well, and are now stalled in queue with a QueueStatus of "s". We've been trying to debug this without much success, so we have a few questions to try and debug it.
What User, User Group, Resource, and Security permissions are required to generate a functioning Report Schedule as well as do direct Report Requests calls? We want to ensure that our users are configured correctly. Currently, we're attempting to generate them using both an Admin and Non-Admin account.
Seth Mize,
I hope you are doing well today. As I was reading your note I remembered a similar situation we had. I don't know if this is your cause or not.
Since Version 15 or so. If I remember correctly, If a report is scheduled on an account with an expired password or is locked for some reason the reports stop running. Could that be the situation you are seeing?
If not this should like a good question for a support ticket.
Hi Tom,
Thank you for the reply! I'll check into that to see if it's the case. I'll post an update when I find out.
Edit: As I think about it though, we still have access to make API requests. We can create new schedules, fetch data, etc...It's just that the report schedule generate the report request, and the report request never gets picked up for analysis. When you had this issue, did you lose access to the rest of the API or just the report schedules?
I've been having a lot of report server problems since we moved into the eastern zone of AWS Ramp.
Reports that usually take 15 - 30 seconds to run are not working after 15 minutes.
A bunch of blank reports that a day before produced results.
Reports that come back with a 504 errors.
Anyone else seeing this situation over the past few weeks or since moving to AWS RAMP?
David Dwiggins,
It's good to know that I'm not alone. We were compelled to move to AWS mid-June 2021. We have had a support ticket open for about a week now.
I'm wondering if anyone else out there is having the same problems.
I'm also wondering what might be similar between your organization and mine.
Hi Tom and David,
Boann here with the Support Escalation Team. I have reviewed your open support tickets on this issue and based on what we are seeing in our troubleshooting thus far, it does not seem like the issues are related. We are continuing to investigate both issues, and understand how frustrating it can be to have a report run slowly or not complete. We will continue to keep you updated on our progress within each support ticket.
Thank you,
Boann Petersen
Support Escalation Manager
Hi everyone,
We finally resolved the issue with the help of Tessitura, and I wanted to share what we found.
The issue happened when create a Report Request / Report Schedule using a user that was either inactive or not assigned to a valid user group. Once created, whenever the queue processor runs, it halts once it hits the report request with the invalid user (or user w/o a user group). Any request after that would not run either. This can affect more than just the user that created the report request. To fix, simply remove the report request(s) or schedule(s) or update them to an active user that's part of a valid user group that has permission to run the selected reports.
Thanks to everyone who helped with it, and I hope this is helpful to anyone else who comes across a similar situation!
Hey Tom Brown (Past Member) we have also had some strange things happen since the AWS cutover. We were, as you say, compelled to do it about two weeks after you. We've had support tickets open since then. A few things have happened but the absolutely most frustrating has been issues with report delivery out of Analytics.
First, we were receiving reports from dashboards that had been culled or re-named post-cutover - we learned that this was because our "previous" instance of Analytics had not been switched off yet. Even though the client had been cut over, I was still able to log into the old Analytics through Tessitura on the Go, and that instance of Sisense was sending out reports that no longer existed in the actual live instance. There was a lot of confusion around this and it took the network a couple of days to confirm that this is what had happened, which was concerning given how confidently the cutover had been insisted upon.
Once that "ghost" environment was switched off, hell broke loose. Now we're not receiving 90% of our scheduled reports out of Analytics (for dashboards and schedules created prior to the cutover), and dashboards created after the cutover are inconsistently erroring out when we try to use the "send me a report now" functionality, and schedules for those new dashboards aren't working at all. We've been in pre-sales for two weeks so this has not exactly helped with the stress of resuming business after almost a year and a half.
Lauren Cartelli (Past Member),
You are echoing some of my feelings as well.
My CFO just emailed me about Tessitura Analytics. Ours is down right now. Fortunately, my new organization did not have a lot of investment in existing dashboards.
--Tom