Hi everyone,
Since our v15 upgrade a handful of scheduled reports have been consistently failing to send, and the only error they display in the View Reports screen is 'Error sending email for request Id 'XXXXXX' The report itself runs fine and can be viewed within the application, but the email functionality is failing.
Does anyone have any insight or breadcrumbs as to what causes this problem, or what this error actually means? I've seen reports fail to send but then fix themselves a few days later, or in other cases building an identical copy of the schedule to an identical recipient list works fine for some reason. I'd love to get any sort of lead on how to resolve, or pinpoint whether there's any local email environment issues at play (we're on RAMP).
Thanks!
Hi Evan —
Not sure if this is the issue, but we had a similar problem that concerned semi-colons — if the email recipients included a semi-colon at the end of the list, it would fail to send the email. We had to trim semi-colons off of recipient lists to get everything back up and running.
DGomez
Hey Evan,
I actually have an open ticket with TASK about this very issue. We are a RAMP client. We adjusted everything to allow SSRS reports to be used in analytics. We found that once we did this, none of our SSRS reports would send through scheduled reports. I have another call coming with TASK to try some things to see if it will work.
- Chris
Hi Evan, I'm going to get a support ticket started for you so we can assist you wtih this issue.
Daniel - thanks for the tip! Did a sweep and found a couple culprits lurking with that extra semicolon, though it seems to be one of a few factors at play...
Chris - good to know! We haven't gone down the rabbit hole of SSRS reports in Analytics yet, but I'll file this away when we inevitably explore it.
Gregg - thank you, appreciate it!
We haven't been able to send emails of scheduled reports either, so I'm interested in this as well. In fact scheduled reports would not run at all. After some investigation with Tessitura support, I finally changed the Local_Library_List in T_DEFAULTS from:T:\userreports\userreports.pbl,T:\userreports\nscan.pblto:\\admiral\tessitura\userreports\userreports.pbl,\\admiral\tessitura\userreports\nscan.pbl
They work now, but why? We've had the T: drive mapping in that setting for years. And now v15 doesn't like it.
What do you all have for your Local_Library_List in T_DEFAULTS? Drive mapping? Or unc path?
This trailing semi-colon issue is fixed in 15.1.
Thanks Ryan!
With Tessi Support's help, we also illuminated that one other reason for report delivery to fail is if the message body is left completely empty. I can't recall if this was always true or something that's cropped up with the move to TPS and v15, but just FYI for everyone to make sure you leave something in that field!
David Vivino (Past Member)
I'm on RAMP so my experience may be different. I have UNC paths...
\\kriostess\pub\XXXX\Live\User Reports\lsccustomreports.pbl,\\kriostess\pub\XXXX\Live\User Reports\performance_copy.pbl,\\kriostess\pub\XXXX\Live\User Reports\entitlements.pbl
where XXXX is my 4 digit RAMP site code.
This is going to be addressed in 15.1. This is a new issue as of 15.0, with the move of email duties to the Tessitura REST API.
This is a symptom of moving the Report Server duties to the Tessitura Processing Service, which is finally a windows service. Historically, sites would set up a single shared network location for custom Infomaker libraries so changes made to custom datawindows/reports could be deployed with a single update. This can still be achieved using UNC, instead of a mapped drive. Mapped network drives are not recommended for use with a windows service for several reasons, some of which are outlined here:
https://docs.microsoft.com/en-us/windows/desktop/services/services-and-redirected-drives
Because the LOCAL_LIBRARY_LIST setting in T_DEFAULTS is used both by TPS and the client desktop application, we can no longer officially support mapped network drives. The easy workaround is to swap out a mapped network drive for a UNC file path in this setting. This is what RAMP uses (as Tom attests to) and addresses the issues mapped drives brings.
We are updating the help system and documentation in T_DEFAULTS to note this change.
Best,
Ryan
Has anyone else had this issue again recently, or able to provide additional suggestions? We just upgraded and are having this same problem. I've tried all the things mentioned here to fix this error on our end (checking for trailing semi-colons, empty email bodies, checking the local library path format (it was already UNC), etc).
Sheila Kearney Miller If none of these tips work, another known issue is saving/sending reports in Excel format. We had to reschedule a number of our reports to .CSV as a workaround. I believe this will be addressed in v15.1.
Not sure if that's your issue, but worth sharing!
Sheila, if you haven't already, please open a support ticket and we can walk through the issue.