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.
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.
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.
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”