In this section we will cover:
ReportServer allows to configure a single default datasource. The default datasource can then be accessed with only a single mouse click when working with reports and parameters. The default datasource is set in the file /fileserver/etc/datasources/datasources.cf.
You can use the name of the datasource, or use the ID of the datasource, for the assignment. Use one of the two variants for the configuration:
By default, ReportServer will pool connections to relational database systems. This increases the stability of the system, since you can define an upper limit of simultaneously open connections and, furthermore, it improves the performance at the same time since database connections are kept open and ready for use.
The connection pools can be configured both globally and per datasource. The configuration is done in the file /fileserver/etc/datasources/pool.cf.
To not use connection pools, change the attribute "disable" to "true": <pool disable="false">.
ReportServer uses the library C3P0 (http://www.mchange.com/projects/c3p0/) to perform connection pooling. To globally set a property, set the property within the <defaultconfig> tags. For data-source-specific settings, use the tag <pool16>, where 16 is the ID of the data source.
<?xml version="1.0" encoding="UTF-8"?> <configuration> <pool> <defaultconfig> <maxPoolSize>40</maxPoolSize> <initialPoolSize>10</initialPoolSize> <acquireRetryAttempts>10</acquireRetryAttempts> <acquireRetryDelay>500</acquireRetryDelay> <checkoutTimeout>60000</checkoutTimeout> <maxConnectionAge>7200</maxConnectionAge> <maxIdleTime>3600</maxIdleTime> </defaultconfig> <pool16> <acquireRetryAttempts>20</acquireRetryAttempts> </pool16> </pool> </configuration>
The possible configuration settings of C3P0 can be found at http://www.mchange.com/projects/c3p0/#configuration_properties. ReportServer simply passes on any set property to C3P0.
ReportServer uses a database to buffer data coming from non-database datasources such as, for example, CSV datasources. This buffer database is called the internal database. Per default ReportServer uses the its own database for this and creates tables with the prefix rs_tmptbl_. You can change the database to be used as well as configure certain aspects of the internal database via the configuration file datasources/internaldb.cf. The default configuration file is
<configuration> <internaldb> <droponstartup>true</droponstartup> <datasource>ReportServer Data Source</datasource> </internaldb> </configuration>
The droponstartup tells ReportServer to remove any temporary tables on startup. This should only be turned off for debugging purposes as having old temporary tables still available after startup will cause errors when using the internal DB. Via the datasource tag you can define the datasource (via its name) to be used as the internal database.
The datasource parameter (a parameter that can be used to allow the user to select values from a predefined set) can return a single value or a list of values. If a user selects multiple values (or uses many filters in a dynamic list) this might lead to problems with certain database systems. This is due to the fact that the number of values that can be used in IN clauses is limited for most database systems.
You can specify the maximum number of values that are to be used in an IN clause in the file /fileserver/etc/datasources/sql.cf. ReportServer will then distribute the selected values over multiple IN-clauses.
For this set the following parameter
<incondition> <maxsize>1000</maxsize> </incondition>
in accordance with the prerequisites of the used database system.
Queries that run for a long time have an impact on the performance of ReportServer. You can specify how long ReportServer should wait for the results of a parameter query. A parameter query is executed when a report is opened.
You can specify a timeout for long running parameter queries in the configuration file /fileserver/etc/datasources/parameter.cf.
Set the parameter <querytimeout>60</querytimeout> to stop queries after 60 seconds.
If you want to use the "post-processing" feature of the datasource parameter enable it using the following lines:
<postprocessing> <enable>true</enable> </postprocessing>
The post-processing feature, for example, allows to switch parameter values or perform complex string operations. Learn more about datasource parameter post-processing in the parameter chapter in the administrator's guide.
Datasinks can be enabled/disabled in the /fileserver/etc/datasinks/datasinks.cf file. Here you have an entry similar as the following for each supported datasink type:
<configuration> <sftp disabled="false" supportsScheduling="true" /> <ftp disabled="false" supportsScheduling="true" /> </configuration>
The disabled option controls if the datasink is overall enabled or disabled. Further, scheduling via datasinks can be enabled or disabled via the supportsScheduling setting. Note that you can not enable scheduling if the datasink is overall disabled.
For the SFTP datasink to work, you have to add your SFTP host to your .ssh/known_hosts file (https://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files#~/.ssh/known_hosts) in order to verify the identity of the remote host, thus protecting against impersonation or man-in-the-middle attacks. Its location be configured in the /fileserver/etc/security/misc.cf file as follows.
<?xml version="1.0" encoding="UTF-8"?> <configuration> <knownHosts>/path/to/.ssh/known_hosts</knownHosts> </configuration>
For manually adding a public key to the .ssh/known_hosts file, check here: https://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files#Manually_Adding_Public_Keys_to_~/.ssh/known_hosts.
As of ReportServer 3.7.0, the old mail/mail.cf configuration file is deprecated. Instead, Email SMTP datasinks should be used together with a default email datasink, which can be defined in the /etc/datasinks/datasinks.cf configuration file as follows.
<email disabled="false" supportsScheduling="true"> <defaultDatasinkName>Default Email Datasink</defaultDatasinkName> <!-- or access via ID --> <!-- <defaultDatasinkId>14</defaultDatasinkId> --> </email>
You can use the name of the datasink, or use the ID of the datasink, for the assignment. Use one of the two variants above for the configuration.
Note that you can configure a default datasink per datasink type, so this is not limited to email SMTP datasinks.