ReportServer 4.1.0 is now available

ReportServer 4.1.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.

Groovy 4 Support

ReportServer 4.1.0 now supports the newest Groovy 4.0.0 version, which contains many awesome new features and capabilities. Check the Groovy 4 release notes for details.

BIRT Upgrade

The BIRT libraries were upgraded to the newest version 4.9.0. More information can be found here.

“Write” permissions additionally needed for editing report variants

As of ReportServer 4.1.0, “Write” permissions are needed in able to edit, create or delete a report variant. Previously, only “Execute” permissions were needed.

Support sending dynamic list reports to Table Datasinks

Table datasinks allow you to send and/or schedule dynamic list reports into to a given table in any datasource supported by ReportServer. This allows you to easily transfer data from MySQL to Oracle, for example. The destination table must exist and must be compatible with the dynamic list, i.e. the fields must exist, have the same name, and have compatible data types.

Check permissions by via “haspermission” terminal command

As of ReportServer 4.1.0 you can check permissions via the new “haspermission” terminal command.

The command allows to check if a given user has a given permission on a given target. Returns “true” if the user has the permission, else “false”.

The -g flag allows to check generic permissions. Documentation of these including the exact target types you can enter can be found here.

For other objects, e.g. Users, Datasources, etc., you can check the entity types here.

The following example checks if the user with id “6” has “Execute” permission on the “AccessRsSecurityTarget” generic target, i.e. if the user is allowed to log in into ReportServer.

The following example checks if the user with id 115254 has “Read” permission on the datasource with id 144497.

Check is a table exists via “tableExists” terminal command

The “tableExists” terminal command allows you to check the existence of the “T_AGG_CUSTOMER” table as shown in the following example.

Check is a column list exists in a given table via “columnsExist” terminal command

The “columnsExist” terminal command allows you to check the existence of a column list (CUS_CITY, myColumn) in the “T_AGG_CUSTOMER” table as shown in the following example.

Fetch column metadata of a given table via “columnsMetadata” terminal command

The “columnsMetadata” allows you to fetch column metadata of the “T_AGG_CUSTOMER” table as shown in the following example.

Metadata documentation of the fields above can be found here. The first 8 columns are displayed by default and CHAR_OCTET_LENGTH is an optional column in the example above. You can choose to append any number of the listed column-description columns by passing their name as an argument.

Advanced: Fetch any datasource metadata via “datasourceMetadata” terminal command

The “datasourceMetadata” command is a very powerful command that allows you to dynamically call any method of the DatabaseMetaData interface.

There are any number of applications for this. You will need to specify the datasource you want to access, the name of the method you want to execute and its parameters. The command will look up a method matching the name and argument count. If there is exactly one matching method it will be executed.

Arguments passed are converted into the expected parameter types as need. Supplying the String “null” will evaluate to null as an Object. Examples:

Lookup JDBC minor/major version and driver

Fetch column metadata similar to the columnsMetadata example

Fetch information about your datasource with via “info datasource” terminal command

Now you will be able to display some selected meta-data about your datasource from within the terminal. It features 4 sections: general information, url information, functions section and supports section. If you require more information still, use the “datasourceMetadata” terminal command as mentioned here.

Example:

Note that this information is also available in the new datasource information window as shown in the following screenshots.

Include internal datasource information on “env” terminal command and “General Info” System Console

The “env” terminal command now includes information on your internal datasource. Note that this internal datasource has to be set in the /fileserver/etc/datasources/internaldb.cf configuration file.

Terminal operators >, >> and >>>

All terminal command results can now be redirected either to a file in the internal ReportServer filesystem (> for new files and >> for appending results), or to an existing datasink (>>>). In such way, you can send long command results per email, OneDrive – SharePoint (O365), etc.

Test LDAP configuration via “ldaptest” terminal command

You can now test your LDAP configuration with the new “ldaptest” terminal command and its subcommands as shown in the examples below.

ldaptest filter

ldaptest users

ldaptest groups

ldaptest organisationalUnits

The following screenshot shows the corresponding “ldapimport” results:

Find the base root of a onedrive-drive belonging to a group via “onedrive” terminal command

The “onedrive” terminal command allows you to access some onedrive api functions from within ReportServer. As of now it has the following commands: onedrive group getmygroups & onedrive group getdrivesof.

The following example shows how to acquire a driveId of group you belong to in order to configure the baseroot of a onedrive datasink.

Use onedrive group getmygroups to see which groups you belong to

Use the groupId of the group to acquire its drives with onedrive group getdrives of

Use the driveId to configure the baseroot of the datasink as such /drives/your-driveid/root:

Allow to test the SSL configuration via “ssltest” terminal command

The “ssltest” command allows you to test your SSL configuration as shown in the screenshot below.

In case you installed a server’s certificate, for example for LDAPS or LDAP StartTLS, this command is useful for testing the installed certificate analogously to the following: “ssltest ipOrHostOfYourServer 10389”

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

ReportServer 4.0.0 is now available

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