ReportServer 4.0.0 is now available for all users. It contains many new features, improvements and bug fixes. An overview of the most important are shown below.

Library upgrades

Note that as of ReportServer 4.0.0, Java 11 JRE or later is required.

Note that as of ReportServer 4.0.0, legacy JXLS1 is not further supported.

The following important libraries are upgraded in ReportServer 4.0.0:

Hibernate: upgraded to 5.6.3.Final

c3p0: upgraded to 0.9.5.5

These libraries basically manage and control the ReportServer’s metadata database and its connection pools.

Numerous other libraries were upgraded. Refer to the release notes table below for details.

• 79 libraries were upgraded
• 22 libraries were removed
• 18 libraries were added

LDAP support including StartTLS and LDAPS

As of ReportServer 4.0.0 you can use the new “ldapimport” terminal command together with the sso/ldap.cf configuration file in order to manually import LDAP users. For scheduling the functionality periodically, you can use the script found here and schedule it via “scheduleScript”.

Note that encryption is also supported. Both StartTLS (recommended) and SSL (LDAPS) are supported.

Details on configuration options are available in the Configuration Guide. The default sso/ldap.cf file is shown below.

 <?xml version="1.0" encoding="UTF-8"?> <!-- ReportServer Configuration File filename: sso/ldap.cf Configures LDAP --> <configuration> <provider> <host>directory.example.com</host> <port>389</port> </provider> <security> <!-- Allowed values are: none/starttls/ssl Recommended is starttls. --> <encryption>none</encryption> <principal>CN=ldaptest,CN=Users,DC=directory,DC=example,DC=com</principal> <credentials>password</credentials> </security> <base>OU=EXAMPLE,DC=directory,DC=example,DC=com</base> <filter>(|(objectClass=organizationalUnit)(objectClass=user)(objectClass=group))</filter> <externalDir>/usermanager/external</externalDir> <writeProtection>true</writeProtection> <includeNamespace>false</includeNamespace> <logResultingTree>false</logResultingTree> <attributes> <objectClass>objectClass</objectClass> <guid>entryUUID</guid> <organizationalUnit> <objectClass>organizationalUnit</objectClass> <name>name</name> </organizationalUnit> <group> <objectClass>group</objectClass> <name>name</name> <member>member</member> </group> <user> <objectClass>inetOrgPerson</objectClass> <firstname>givenName</firstname> <lastname>sn</lastname> <username>sAMAccountName</username> <mail>mail</mail> </user> <additional> <!-- You can request additional attributes including them here as: <attribute>myAttribute1</attribute> <attribute>myAttribute2</attribute> --> </additional> </attributes> </configuration> 

Support sending reports to Google Drive Datasinks

Google Drive OAuth2-authorized datasinks allow you to send and/or schedule reports to a given directory in your Google Drive account.

For getting your “app key” and “secret key”, you have to create an app registration here (Google API Console) and give it the appropriate API permissions.

The “base root” path in the datasink definition, together with the “folder” path, determines the base path of the datasink. The default folder/folders are also included, which can be overriden in specific uses of this datasink, analogously to other datasink types.

Note that the base path must exist. If the (extension) folder/folders does/do not exist, it/they is/are created. If the report already exists in the same path, it is overwritten.

More information on this can be found here.

The path should be entered like this: “/my/path”. Note that, different as in other datasinks, “./my/path” does not work.

Support sending reports to Amazon S3 Datasinks

Google Drive OAuth2-authorized datasinks allow you to send and/or schedule reports to a given directory in your Amazon S3 bucket.

You can create an access and a secret key as described here (Amazon S3 access keys) and give it the appropriate API permissions. Further, the unique bucket name and region must be entered into the datasink definition.

If the report already exists in the same path, it is overwritten.

More information can be found here

Support sending reports to Box

Box OAuth2-authorized datasinks allow you to send and/or schedule reports to a given directory in your Box account.

For getting your “app key” and “secret key”, you have to create an app registration here (Box Developer Console) and give it the appropriate API permissions.

The “base root” path in the datasink definition, together with the “folder” path, determines the base path of the datasink. The default folder/folders are also included, which can be overriden in specific uses of this datasink, analogously to other datasink types.

Note that the base path must exist. If the (extension) folder/folders does/do not exist, it/they is/are created. If the report already exists in the same path, it is overwritten.

More information on this can be found here.

The path should be entered like this: “/my/path”. Note that, different as in other datasinks, “./my/path” does not work.

Visualize live connection pool

As of ReportServer 4.0.0, you can create a live graph of the connection pool including the following:

• Number of connections
• Busy connections
• Maximum pool size
• Threads awaiting connection checkout
• Unclosed orphaned connections

You can find and control the graph in the System Consoles section analogously as the “JVM Live Memory” system console. An example output is shown below.

You can also use the new “connPoolStats” terminal command for a static snapshot of the current connection state as shown in the following screenshot

Refactor ConfigService location

Note that the location of “ConfigService” changed, so your scripts using ConfigService must be adapted for them to work.

The old location was:

 net.datenwerke.rs.utils.config.ConfigService 

The new location is:

 net.datenwerke.rs.configservice.service.configservice.ConfigService 

Support for missing configuration files

Default configuration files are created on first run of ReportServer. Later, when upgrading ReportServer to a newer version, it is probable that newly added configuration files are missing (i.e. all configuration files added between the version originally installed and the version upgraded to).

In order to find out which configuration files are missing without having to search all release notes between these versions, “showmissing” allows you to compare the current set of configuration files with the expected set of configuration files of the currently installed version. Then it shows all missing files.

With help of “createmissing”, you can create the default missing configuration files found with “showmissing” into the appropriate location inside your /fileserver/etc path.

For copying all default missing configuration files into a given folder you can use “createall”. This allows you to compare configuration file contents/fields, etc.

You can see examples below:

Support for database-independent table copying

As of ReportServer 4.0.0, copying the contents of a table to another table is supported database-independently, i.e. the tables may reside in different database types. E.g. you may copy the contents of a table from a MSSQL database to a table in an Oracle database. All datasource types supported by ReportServer are supported.

The destination table must exist and must contain the same fields as the source table. Their field types must be compatible.

Refer to the following example:

 copyTableContents id:DatabaseDatasource:58 RS_SCHEMAINFO id:DatabaseDatasource:60 myschemainfo entity_id false 200 

The example copies the contents of the RS_SCHEMAINFO table of your internal datasource with id 58 into a table with name “myschemainfo” in the datasource with id 60.

Again, note this is database-independent. In the example above the datasource with id 58 is a MSSQL datasource, while the datasource with id 60 is an Oracle datasource.

The command prints some information for you to be able to see what is happening in the background. In the example above the information printed is:

Refer to the Admin Guide for more information on how to use this command.

Allow better browsing of dynamic list preview results

Dynamic list previews can now be browsed as shown in the following screenshot.

Allow to compress all reports before sending them or scheduling them to a datasink

Reports may now be compressed before being sent to any datasink. Please refer to the following screenshots:

Allow to send files in filesystem to datasinks

You can now send files in ReportServer’s virtual filesystem directly to your datasinks. Refer to the following screenshot.

Allow to print environment information to terminal

Prints environment information of the current installation including relevant environment variables.

Show user information including transitive groups of a given user

You can now use the “id” terminal command for printing including user information.

This includes group information and organizational unit information of a user. Group information includes direct and indirect groups (via another groups or via organizational units).

As an example refer to the following screenshot

The user “dmurphy” is member of 3 groups in the example:

1. Managers: the user is a direct member of this group
2. viaGroup: the user is a member of this group via another group.
3. viaOU: the user is a member of this group via an organizational unit.

Add “report_configuration” entry to audit logs

We added a new entry “report_configuration” which contains the configuration parameters, filters and prefilters. The data is saved in unformatted JSON format. A formatted example with some test parameters (OrderNumber), filters and prefilters is shown below.

Note that this audit log entry is available for all report values.

Also, note you can print all these values into your dynamic list Excel, HTML and PDF export documents as well via report properties.

 { "configuration_parameters":{ "OrderNumber":123, "RS_DOKU_LOGO":"fileServerAccess?id=7837", "_RS_USER_LASTNAME":"root", "_RS_USER_USERNAME":"root", "_RS_REPORT_NAME":"RS_USER_VAR", "_RS_REPORT_KEY":"", "_RS_USER_EMAIL":"myemail@myhost.com", "_RS_LOCALE_USER":"en", "_RS_REPORT_DESCRIPTION":"", "RS_DOKU_LOGO_PDF":"fileServerAccess?id=7837", "_RS_REX_TOKEN":"13666-6-1642082365569--1101439880:0.6843463243681271", "_RS_REPORT_ID":13666, "_RS_USER_FIRSTNAME":"root", "_RS_LOCALE_SYS":"en", "_RS_USER_ID":6, "_RS_USER_TITLE":"", "_RS_LOCALE":"en" }, "prefilters":{ "OR":[ { "==":[ "password", "password" ] }, { "AND":[ { "OR":[ { "AND":[ { "OR":[ { "sex":{ "include":[ "1" ], "null_handling":"--", "case_sensitive":true } }, { "==":[ "password", "title" ] } ] }, { "firstname":{ "include":[ "Anthony", "Barry" ], "null_handling":"Include", "include_range":[ [ "eduardo", "Diane" ], [ "Anthony", "Foon Yue" ] ], "case_sensitive":false, "exclude":[ "George" ], "exclude_range":[ [ "Jaques", "John" ] ] } } ] } ] } ] }, { "AND":[ { ">":[ "firstname", "lastname" ] } ] } ] }, "filters":{ "id":{ "null_handling":"--", "include_range":[ [ "6122", "6136" ] ], "case_sensitive":true }, "username":{ "include":[ "ftseng", "gvanauf", "pmarsh" ], "null_handling":"--", "case_sensitive":true, "exclude":[ "gvanauf" ] } } } 

Allow to disable “lost password” dialog

If needed, the “lost password” can be disabled in the /fileserver/etc/security/misc.cf as shown below:

 <disableLostPassword>false</disableLostPassword> 

Below you can find the complete /fileserver/etc/security/misc.cf configuration file:

 <?xml version="1.0" encoding="UTF-8"?> <configuration> <juel> <expression> <blacklist>getClass</blacklist> </expression> </juel> <errorMessages> <hideViolatedSecurityExceptionDetails>false</hideViolatedSecurityExceptionDetails> </errorMessages> <knownHosts>/path/to/.ssh/known_hosts</knownHosts> <disableLostPassword>false</disableLostPassword> </configuration> 

For a list of all changes please refer to the Release Notes. The upgrade guide is available in the documentation area.

Happy reporting!

You ReportServer Team