You are not logged in.
Pages: 1
Hi,
I'm quite encouraged by what I've read of ReportServer. My concerns are around automated deployment of ReportServer and packages of reports. I have a pipeline (sequence) of non-production environments that I would be using to validate new releases of ReportServer, configuration changes, and new reports. Because much of the configuration of ReportServer is handled through the web interface I'm thinking it may be hard to automate in a consistent way using tools like Puppet and RPM. In this regard it's in no worse shape than Oracle BI Publisher or MicroStrategy - any reporting solution with its own metadata database is going to be a challenge to a certain extent.
In any case, here's some feedback on a few changes that could make ReportServer easier to automate.
1. persistence.xml includes a mix of internal software configuration that changes from release to release (a list of classes) and user-supplied data (database connection parameters). If you can split this out somehow and store the user-supplied data in a separate configuration file, the internal data could be deployed with the software release and the user-supplied file would not have to be merged on each release.
For extra flexibility, ReportServer could load the user-supplied file from the classpath; this would allow me to add a directory under /etc to the Tomcat classpath and store configuration there instead of inside the webapp deployment directory. It would make upgrades easier by avoiding a mix of
2. reportserver.properties includes a mix of defaults and configured settings, if I understood correctly. If you split this into an internal defaults file, with a user-supplied file that only overrides the defaults, the user-supplied file would not have to change on each release.
3. Configuration files such as mail.cf are stored in the database. I would like to have some way to push these out through Puppet - for example, ReportServer could look for them from the classpath before trying the database.
4. Report files like BIRT .rptdesign bundles are uploaded through the web interface. What I'd like to do is build a bundle of reports in my build system and deploy them to the Linux server filesystem through Puppet and RPM, and then somehow have them available to ReportServer (e.g. via the Tomcat classpath).
5. Report metadata is also configured through the web interface - parameters, data source configuration, metadata. I'd like to have a way to export a report's metadata from one ReportServer instance so I can import it into another instance, preferably on the server command-line so I can automate it with Puppet when I deploy new/updated reports.
I admit I haven't yet purchased the scripting or administration guides, so I may be missing some key information that would answer some of the items above.
Thanks,
Mike
Offline
Hi Mike,
thanks for the list of suggestions. I've created a ticket and we'll discuss what we can do to make automation easier.
Especially the changes you propose for the handling of config files seems to make a lot of sense.
Using ReportServer scripts should allow you to handle 3,4 and 5. For example you could have
a script that periodically checks some file system folder for reportserver export files and to import anything it finds. Similarly you could
handle changes of config files. The script guide should get you started here. You might also want to take a look at http://blog.datenwerke.net/ where we've blogged
a bit on a few scripting basics.
In any case, it would be great if you could tell us a bit more about your setup, what you plan, what the problems are and especially how you would see an ideal solution.
I can't promise anything but we are always inclined to making ReportServer better and making it easier to support larger setups sounds like a good target to spend some
time on.
Regards,
Arno
Offline
Hi Arno,
Thanks for the reply. I can expand a bit on how I would like to deploy ReportServer, configuration, and reports.
I'd start by downloading the ReportServer webapp and defining a job on my build server to package it into an RPM so it can be versioned and deployed to the correct location on our servers. Through Puppet I can configure particular versions of the RPM to be deployed in various environments. Puppet can be told to restart Tomcat after the RPM is deployed.
I would use CATALINA_OPTS to add a directory to the classpath (e.g. /etc/rs). I'd use Puppet to deploy configuration files to that location. For example, mail.cf - this is a file that will be identical on most of our systems, except for the hostname. Puppet knows our mail server hostnames and can be configured to generate mail.cf from a template, deploy it somewhere like /etc/rs/filesystem/etc/mail/mail.cf, and restart Tomcat when it changes. The same would be true for database connection parameters and other ReportServer properties.
I would like to use the the same mechanism to deploy scripts for bin/onlogin.d, etc., and also for resources (logos).
It would be nice to be able to configure Global Constants in a file somehow so we can manage the set of constants required in each test or production environment. In our case each environment will need the same constants with possibly different values. One challenge I see is constants that refer to a fileServerAccess URL (e.g. RS_DOKU_LOGO - fileServerAccess?id=262) might refer to an ID (262) that is only known after the instance is fully deployed, so some fiddling would be required.
I don't have a clear idea about how to deploy reports. We consider them a software artifact and I would like to package and deploy them in an RPM, like software. Perhaps our build server could programmatically gather report export files for all the reports on the development instance, strip out the DatabaseDatasource and User entities, and package them into an RPM to be installed under a path like /etc/rs/reports. Or we might treat the export as a manual process; the developer tweaks the report in the development instance, exports it, and checks the export into source control where it would be automatically included in an RPM.
I'd use Puppet to install the RPM full of report exports and automatically restart Tomcat. Maybe I could use a startup script in ReportServer to import all export files from that location. I would also want the script to purge any reports that are no longer included under that path - if a report is deleted in the test environment, it should eventually be deleted in production.
One last comment: the Active Directory integration is handled through a pair of Groovy scripts. This is very flexible, but I worry it may be brittle with upgrades as internal ReportServer APIs change over time. To make upgrades easier you might consider making AD/LDAP a built-in feature with a few configurable parameters. It wouldn't be as flexible as the script-based approach, of course.
Thanks,
Mike
Offline
Pages: 1