With ReportServer you can schedule reports and distribute the result either using mail, directly into a TeamSpace, or sent to any datasink configured, (check Section 4.2. for more details). The next section discusses some important settings.
In order for ReportServer to be able to send mails you must specify the mail server settings. Make the following configurations in your Email SMTP datasink.
Setting up the SMTP server. Replace the values host, port, username, and password according to your SMTP server.
Host: mail.yourmailserver.com
Port: 25
Username: rs@yourmailserver.com
Password: passwordsecret
SSL: false
TLS enable: false
TLS require: falseIf you are using SSL or TLS please also specify these values. Next, configure the sender name, email address and forceSender options. If the forceSender option is set to true, the emails will be sent using the given (generic) sender details. If set to false, the specific user sending the email will determine the sender details.
Sender: rs@yourmailserver.com
Sender name: ReportServer
Force sender: false
Encryption policy: allow_mixedThe encryption policy option controls whether or not mails have to be encrypted or whether it is ok to send mails unencrypted if a user's public key is not specified. Choose between strict and allow_mixed. Note that if you choose strict then mails to users that do not have public key registered with ReportServer will not receive any messages.
Details on setting the default email datasink can be found in Section 4.2.2.
ReportServer comes with a powerful scheduler. ReportServer's scheduler allows you to schedule the execution of reports. The executed report can then either be stored in a folder in a TeamSpace or sent to any datasource configured. Refer to Section 4.2. Datasinks for more details.
The schedule and report recipients are user provided on scheduling. You can configure the messages that ReportServer will send out on certain events. Each message can be customized to your specifications.
ReportServer will send out the following emails:
The following configurations are done in the file /fileserver/etc/scheduler/scheduler.cf. To include information such as "the user who created the schedule entry", "the report's name" etc. in your message you can use a variety of expressions. Substitutions are defined in the ReportServer formula language. You will find further information about the ReportServer formula language in the Administrator's, as well as in the User Guide.
| Expression | Description |
| ${job.getName()} | job's name |
| ${job.getDescription()} | job's description |
| ${job.getId()} | job's ID |
| ${report.getName()} | report's name |
| ${report.getDescription()} | report's description |
| ${report.report.getKey()} | report's key |
| ${report.getId()} | report's ID |
| ${user.getUsername()} | username |
| ${user.getFirstname()} | first name of user |
| ${user.getLastname()} | last name of user |
| ${user.getEmail()} | user's email address |
| ${user.getTitle()} | user's title |
| ${user.getId()} | id of user |
| ${executor} | job's executor. You can use the same methods above as with user |
| ${scheduledBy} | job's scheduler. You can use the same methods above as with user |
| ${teamspace.getName()} | name of TeamSpace (only available in fileaction) |
| ${folder.getName()} | name of folder in TeamSpace (only available in fileaction) |
| ${folder} | name of folder in FTP server (only available in fileactionFtp) |
| ${message} | the message that was specified by the user on scheduling |
| ${subject} | the subject that was specified by the user on scheduling |
| ${recipients} | A list of the job recipients. Please check below for the exact configuration (list of users) |
| ${owners} | A list of the job owners. Please check below for the exact configuration (list of users) |
| ${filename} | filename as specified by the user (report is scheduled in teamspace) |
| ${nextDates} | date of next execution |
| ${RS_CURRENT_DATE} | current date |
| ${errMsg} | error message on erroneous execution |
| ${stacktrace} | detailed stacktrace on failed execution |
For substitution of a list of users (currently supported: list of job recipients and list of job owners), you can use a fluent API that allows you to configure the output exactly as you need. Available methods for this are:
| ${withSeparator()} | use a given separator between users. Default is a new line. |
| ${addString('','')} | add a String, e.g. a comma |
| ${addBlankspace()} | add a blank space |
| ${addNewline()} | add a new line |
| ${addUsernames()} | add usernames |
| ${addFirstnames()} | add first names |
| ${addLastnames()} | add last names |
| ${addEmails()} | add emails |
| ${addTitles()} | add titles |
| ${addIds()} | user ids |
| ${print()} | create the result string. This method has to be called in the last place. |
As mentioned, you can use a fluent API for configuring the output. E.g.,
${recipients
.addFirstnames()
.addBlankspace()
.addLastnames()
.addBlankspace()
.addString("(")
.addUsernames()
.addString(")")
.print()
}will print the following:
Barry Jones (bjones)
Diane Murphy (dmurphy)
Gerard Hernandez (ghernande)
Larry Bott (lbott)
If you want to separate the users by a comma instead of a new line, you can enter use the withSeparator() method as follows:
${recipients
.withSeparator(", ")
.addFirstnames()
.addBlankspace()
.addLastnames()
.addBlankspace()
.addString("(")
.addUsernames()
.addString(")")
.print()
}which will print the following data:
Barry Jones (bjones), Diane Murphy (dmurphy), Gerard Hernandez (ghernande), Larry Bott (lbott)
Below you can find some example configurations:
Configuration of email message with attached report (successful execution)
<mailaction html="false">
<subject>${subject}</subject>
<text>Text of message: ${message}</text>
<attachment>
<name>rep-${report.getName()}-${RS_CURRENT_DATE}</name>
</attachment>
</mailaction>Configuration on successful execution of report and storage in TeamSpace
<fileaction disabled="false" html="false">
<subject></subject>
<text></text>
</xmlcode>Configuration on successful execution of report sent to email SMTP server
<fileactionEmailDatasink disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionEmailDatasink>Configuration on successful execution of report sent to table datasink
<fileactionTableDatasink disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionTableDatasink>Configuration on successful execution of report and storage in SFTP server
<fileactionSftp disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionSftp>Configuration on successful execution of report and storage in FTPS server
<fileactionFtps disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionFtps>Configuration on successful execution of report and storage in FTP server
<fileactionFtp disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionFtp>Configuration on successful execution of report and storage in Samba server
<fileactionSamba disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionSamba>Configuration on successful execution of report and storage in SCP (SSH) server
<fileactionScp disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionScp>Configuration on successful execution of report and storage in the local filesystem
<fileactionLocalFilesystem disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionLocalFilesystem>Configuration on successful execution of report and storage in Dropbox
<fileactionDropbox disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionDropbox>Configuration on successful execution of report and storage in OneDrive - SharePoint (O365)
<fileactionOneDrive disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionOneDrive>Configuration on successful execution of report and storage in Google Drive
<fileactionGoogleDrive disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionGoogleDrive>Configuration on successful execution of report and storage in Amazon S3 bucket
<fileactionAmazonS3 disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionAmazonS3>Configuration on successful execution of report and storage in Box
<fileactionBox disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionBox>Configuration on successful execution of report and storage in Printer datasinks
<fileactionPrinter disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionPrinter>Configuration on successful execution of report and storage in Script datasinks
<fileactionScriptDatasink disabled="false" html="false">
<subject></subject>
<text></text>
</fileactionScriptDatasink>Configuration of notifications on scheduling, unscheduling and execution errors
<notification disabled="false" html="false">
<scheduled>
<subject></subject>
<text></text>
</scheduled>
<unscheduled>
<subject></subject>
<text></text>
</unscheduled>
<failed>
<subject></subject>
<text></text>
</failed>
</notification>If you would like to send emails in the HTML format please set the corresponding html attribute to "true".
In case you do not want to have one or more notifications, you can disable the individual notifications using the disabled attribute:
<fileaction disabled="true" html="false">The subsequent section outlines several advanced scheduler properties, which are configured within the file /fileserver/etc/scheduler/scheduler.cf configuration file.
If you do not want to use the scheduler you can disable it using
<properties>
<disabled>true</disabled>
</properties>You can also disable the scheduler by setting the following property in your reportserver.properties file:
rs.scheduler.disable = trueIf the property is set both in reportserver.properties and in /fileserver/etc/scheduler/scheduler.cf, the property set in reportserver.properties is taken into account, while the one set in /fileserver/etc/scheduler/scheduler.cf is ignored.
Keep in mind that this changes will only take effect after reboot. To enable or disable the scheduler while ReportServer is running, use the terminal command scheduler daemon start/stop. This command only works if the scheduler is not disabled in the file reportserver.properties. If it is, you first have to delete this property in order to be able to enable/disable the scheduler while ReportServer is running. Refer to the Administration Guide for more information on this command.
By default, ReportServer initializes a scheduling thread pool containing 5 threads. Consequently, a maximum of 5 scheduler jobs can run simultaneously. This setting can be modified by adjusting the following:
<properties>
<workingthreads>5</workingthreads>
</properties>Allows configuration of the scheduling thread pool's name. The default is dwScheduler.
<properties>
<asyncpoolname>dwScheduler</asyncpoolname>
</properties>Allows configuration of the working thread's sleep time (in milliseconds) before checking for and executing the next set of scheduled jobs. The default is 10,000 milliseconds (10 seconds).
<properties>
<checkinterval>10000</checkinterval>
</properties>This allows you to configure the timeout for a proper scheduler shutdown. It ensures that the scheduler blocks until one of the following occurs: all tasks have completed execution after a shutdown request, the specified timeout is reached, or the current thread is interrupted. The timeout is specified in milliseconds. The default value is 60,000 milliseconds (60 seconds).
This ensures that the scheduler attempts an orderly shutdown by waiting for the ongoing tasks to complete. However, if they do not finish within the timeout period, the scheduler forces an immediate shutdown to ensure the system does not hang indefinitely. This mechanism helps balance between graceful task completion and the need to shut down promptly.
<properties>
<shutdownwait>600000</shutdownwait>
</properties>When an execution veto occurs, such as with conditional scheduling, and when a RETRY is needed but no specific waiting period is defined, the system uses a combination of a default base waiting time and a random waiting time to determine the delay before the next retry.
The formula used to calculate the waiting time before the next RETRY is as follows:
int minutes = stdvetodelay + new Random().nextInt(rndvetodelay)In this formula:
By default, stdvetodelay is set to 180 minutes, and rndvetodelay is set to 20 minutes. This means that the waiting time before the next retry will be at least 180 minutes, with an additional random component ranging from 0 to 20 minutes, making the total waiting time somewhere between 180 and 200 minutes.
Here is how you can configure these values in the properties file:
<properties>
<stdvetodelay>180</stdvetodelay>
<rndvetodelay>20</rndvetodelay>
</properties>This configuration ensures that the system waits for a base period (stdvetodelay) and then adds a random delay (rndvetodelay) to determine the next retry time, helping to avoid predictable retry patterns and potential resource contention.
Further, refer to Section 4.13. Scheduler Settings for more scheduler settings.