Chapter 16. ReportServer Scripting

ReportServer Enterprise Edition comes with scripting support. Scripts can be used in a variety of ways and can, for example, serve as a basis for reports and datasources, perform administrative tasks, or even contribute new functionalities. In this section we want to give you an introduction to the comprehensive script subject, and make you familiar with the various options provided by ReportServer scripts. Scripts and their fields of use will be treated in the ReportServer script manual in detail.

ReportServer scripts are written in Groovy (http://groovy-lang.org/) and run in the same VM where ReportServer is located. The decisive advantage here is that the scripts have access to the complete set of services provided by ReportServer. However, it also means that scripts represent a potential security and stability risk. Persons who are authorized to write or change scripts have full access to the system. The permissions to write scripts should thus be granted with care.

The following explanations address persons with basic knowledge in programming. Java and/or Groovy experience are not necessarily required but might be helpful. Under https://groovy-lang.org/ you will find many excellent tutorials on programming in Groovy.

Scripts are located in the internal file manager, by default beneath folder bin. Several configuration options can be configured in configuration file /etc/scripting/scripting.cf (also see the ReportServer configuration guide).

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<scripting>
		<enable>true</enable>
		<restrict>
			<location>bin</location>
		</restrict>
		<startup>
			<login>fileserver/bin/onlogin.groovy</login>
			<rs>fileserver/bin/onstartup.groovy</rs>
		</startup>
		<cache>
			<maxsize>10000</maxsize>
			<expiresafter>30</expiresafter> <!-- in minutes -->
      </cache>
	</scripting>
</configuration>

The first option allows the global deactivation of scripts. Please consider that if you apply it, you will not be able to use script reports anymore, and that the documentation report available in the demo data will not work any longer. By the second option (restrict.location) you will define a root folder in which scripts have to be filed. This allows to give access rights for the file system to individual users without enabling them to create or change scripts.

The next section (startup) allows to configure two special scripts. As soon as a user has signed on, the onlogin script will run with the rights of this user. Here, for instance, interface enhancements can be loaded. To do this, ensure to grant users the execute right for the script. The start-up script, on the other hand, will run when starting the system. Note that then the script is run without any logged in user. Instead of specifying scripts, you can also specify folders. In this case, all scripts within the folder are executed.

The cache section controls the internal script caching mechanism. This is used for performance reasons, e.g. for not recompiling the same script twice when used frequently. The maxsize setting specifies the maximum number of entries the cache may contain. The expiresafter specifies that each entry should be automatically removed from the cache once the given fixen duration has elapsed after the entry's creation, or the most recent replacement of its value.