Best Practices for deploying custom reports

Thanks for your insight, Nick! I will definitely make a similar enhancement request. And that’s a great tip about the SSRS reports!

Thank you,

~Katie

From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Nick Reilingh
Sent: Monday, December 21, 2015 7:45 PM
To: Catherine Lachance-Duffy
Subject: Re: [Tessitura Technical Forum] Best Practices for deploying custom reports

Woohoo, this is exactly the kind of topic I like talking about! :-)

Overall, my feelings on the matter are that the network could solve the problem very easily by allowing an imported XML report setup to overwrite an existing report. I'm pretty sure I've submitted an enhancement request to the same effect, and would encourage you to do the same.

With option #1, are you doing the deletion on the database directly? My recollection was that Report Setup didn't allow you to ever delete a report, so I assumed it was too dangerous and always avoided it (also for the reasons as you mention of report history and PERMISSIONS having to be recreated).

I've always resorted to option #3 -- copy/pasting from gsrsetup test to gsrsetup live, despite the fact that it's the equivalent of rewriting code in the production environment. I'm sure option 2 is theoretically possible, but for that to be worthwhile to me it would basically need to be a reimplementation of the XML export/import workflow that we already have in gsrsetup -- save the inability to overwrite existing definitions.

I think you've correctly identified that the issue with all of this is how you update scheduled reports with a new set of parameters. gsrsetup lets you update parameters for reports with schedules anyway, so that can't be used as an excuse for implementing the XML overwrite I'd like to see, but there's still no way for a program to interpolate or guess at what the new parameters should be for an existing scheduled report whose parameter setup has changed. So I think the only reasonable answer is to flag these scheduled reports as temporarily broken somehow, and manually touch each one to correct or reconfirm the scheduled parameters for the new setup.

I have a couple other notes about scheduled reports that might be useful -- I've had good luck with getting scheduled report parameters to behave properly when they change between report instances (as long as they are updated for a new setup, as above), but changing settings for the _schedule_, like who is receiving emailed versions of a report, takes some special attention. Email settings are copied from the schedule master request to a new request for the next instance immediately after a report run, and changing the email settings on the schedule does not update this new request -- so email changes will only take effect on the subsequent schedule run. I've written some update code for this and posted about that behavior here and here.

One last thing that I found out relatively recently has to do with scheduled instances of SSRS reports. Basically, there's an extra step of caching that happens when running an SSRS report schedule, due to SSRS being such a robust and complete system outside of the Tessitura/Infomaker/PowerBuilder environment. TessiWeb manipulates SSRS to create a linked report for each schedule -- you can view these by navigating to Tessitura/ScheduledReports on the SSRS web interface, in the format lnk_reportname_scheduleID. This doesn't have anything to do with gsrsetup at this point; this is your parameter setup on the SSRS report itself. When you create the schedule, the linked report takes a snapshot of your SSRS report's parameter settings (not the parameter values, necessarily), and stores them in this linked report. If you change the parameters on the SSRS report (even changing a single parameter from nullable to not), the linked report will be out of sync, and an existing tessitura report schedule will fail (even if you've updated the parameters on your schedule -- since the schedule tries to run against the linked report, not against the "real" one). The fix here, to avoid recreating the schedule, is to manually refresh the linked report for any scheduled SSRS report after deploying parameter changes. This is pretty easy to do, again from within the SSRS web interface -- just "manage" the report links in question, and on the properties tab, click Change Link; reselecting the the report with updated parameters you just deployed. This will refresh the parameters on the linked report in use by the schedule. So, I treat this as a post-deployment workflow step whenever I update an SSRS report.

Thanks for your insight, Nick! I will definitely make a similar enhancement request. And that’s a great tip about the SSRS reports!

Thank you,

~Katie

From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Nick Reilingh
Sent: Monday, December 21, 2015 7:45 PM
To: Catherine Lachance-Duffy
Subject: Re: [Tessitura Technical Forum] Best Practices for deploying custom reports

Woohoo, this is exactly the kind of topic I like talking about! :-)

Overall, my feelings on the matter are that the network could solve the problem very easily by allowing an imported XML report setup to overwrite an existing report. I'm pretty sure I've submitted an enhancement request to the same effect, and would encourage you to do the same.

With option #1, are you doing the deletion on the database directly? My recollection was that Report Setup didn't allow you to ever delete a report, so I assumed it was too dangerous and always avoided it (also for the reasons as you mention of report history and PERMISSIONS having to be recreated).

I've always resorted to option #3 -- copy/pasting from gsrsetup test to gsrsetup live, despite the fact that it's the equivalent of rewriting code in the production environment. I'm sure option 2 is theoretically possible, but for that to be worthwhile to me it would basically need to be a reimplementation of the XML export/import workflow that we already have in gsrsetup -- save the inability to overwrite existing definitions.

I think you've correctly identified that the issue with all of this is how you update scheduled reports with a new set of parameters. gsrsetup lets you update parameters for reports with schedules anyway, so that can't be used as an excuse for implementing the XML overwrite I'd like to see, but there's still no way for a program to interpolate or guess at what the new parameters should be for an existing scheduled report whose parameter setup has changed. So I think the only reasonable answer is to flag these scheduled reports as temporarily broken somehow, and manually touch each one to correct or reconfirm the scheduled parameters for the new setup.

I have a couple other notes about scheduled reports that might be useful -- I've had good luck with getting scheduled report parameters to behave properly when they change between report instances (as long as they are updated for a new setup, as above), but changing settings for the _schedule_, like who is receiving emailed versions of a report, takes some special attention. Email settings are copied from the schedule master request to a new request for the next instance immediately after a report run, and changing the email settings on the schedule does not update this new request -- so email changes will only take effect on the subsequent schedule run. I've written some update code for this and posted about that behavior here and here.

One last thing that I found out relatively recently has to do with scheduled instances of SSRS reports. Basically, there's an extra step of caching that happens when running an SSRS report schedule, due to SSRS being such a robust and complete system outside of the Tessitura/Infomaker/PowerBuilder environment. TessiWeb manipulates SSRS to create a linked report for each schedule -- you can view these by navigating to Tessitura/ScheduledReports on the SSRS web interface, in the format lnk_reportname_scheduleID. This doesn't have anything to do with gsrsetup at this point; this is your parameter setup on the SSRS report itself. When you create the schedule, the linked report takes a snapshot of your SSRS report's parameter settings (not the parameter values, necessarily), and stores them in this linked report. If you change the parameters on the SSRS report (even changing a single parameter from nullable to not), the linked report will be out of sync, and an existing tessitura report schedule will fail (even if you've updated the parameters on your schedule -- since the schedule tries to run against the linked report, not against the "real" one). The fix here, to avoid recreating the schedule, is to manually refresh the linked report for any scheduled SSRS report after deploying parameter changes. This is pretty easy to do, again from within the SSRS web interface -- just "manage" the report links in question, and on the properties tab, click Change Link; reselecting the the report with updated parameters you just deployed. This will refresh the parameters on the linked report in use by the schedule. So, I treat this as a post-deployment workflow step whenever I update an SSRS report.