release notes

Release notes Indicium 2022.2.15

Related products: Indicium Service Tier
Release notes Indicium 2022.2.15

Hello everyone,

In this sprint, we added support for generating DevExpress reports on .NET 6, and we have improved our support for Amazon SNS (Simple Notification Service).

You can read more about Indicium's features in the Indicium user manual.

We will keep you updated regularly about Indicium's progress.

About Indicium

Two types of the Thinkwise Indicium Application Tier are available:

Contents of this release

Indicium - New

Support for generating DevExpress reports

We have added support for generating DevExpress reports on .NET 6. This allows Indicium to generate reports on Linux. Please note:

  • Reports targeting DB2 data sources are not supported.
  • You must install and update the dependencies mentioned here 

On Linux, Indicium will use the .NET 6 version of the DevExpress reports plugin by default. Windows will continue to use the .NET Framework 4.7.2 version by default, but you can use the .NET 6 plugin by changing the Runtime app setting to NET:

{
"Reporting": {
"DevExpress": {
"Runtime": "NET"
}
}
}

Amazon SNS (Simple Notification Service) support

As of this release, Amazon SNS can be used to call Indicium's standard APIs (for example, tasks, tables, etc.).

Until now, Amazon SNS could not call these standard APIs because while Amazon SNS sends JSON messages, it sets the Content-Type header to text/plain, instead of application/json. We have introduced a new middleware that recognizes Amazon SNS requests and changes the text/plain Content-Types to application/json, making them compatible with the Indicium APIs.

Indicium - Changed

  • We have improved our error logging regarding features that are not supported on some platforms, for example, Linux. The error message now clearly indicates that this is the reason.
  • We have improved Indicium's error logging in several places. The severity, content, and category of many error messages are now more accurate, and these error messages are now easier to parse for Azure Application Insights and AWS CloudWatch. Some additional improvements for AWS CloudWatch will be coming up in the next release.
  • By default, Indicium only allows redirects to its own domain. For OpenID clients, it is also possible to redirect to the URLs that are allowlisted in the OpenID clients. 
    Finally, redirect URLs can also be allowlisted in IAM's global settings. If Indicium does not accept a redirect URL, then Indicium redirects to its own root URL. This was considered confusing, so we improved our logging to state why a redirect URL was not accepted and how to fix this.
  • Indicium's import API now calls layouts and defaults with @import_mode=1.
  • We updated the description of secrets stored in AWS Secrets Manager to clarify their purpose and the implications of deleting them.

Minor fixes and tasks

  • [Indicium Basic] In a group of mandatory and mutually exclusive prefilters, when the Look-up state of all filters was set to "Off hidden", Indicium did not show any result. This has been fixed. Now, if no filter is selected, all filters are combined with OR clauses into one statement.

Great that you fixed the everlasting Amazon SNS issue this way, saves your customers some workarounds!

Regarding DevExpress: what would you recommend for Windows (.NET 6 or .NET Framework) and what is the impact?


Great that you fixed the everlasting Amazon SNS issue this way, saves your customers some workarounds!

First thing that came to my mind, great news! :)


  • We have improved Indicium's error logging in several places. The severity, content, and category of many error messages are now more accurate, and these error messages are now easier to parse for Azure Application Insights and AWS CloudWatch. Some additional improvements for AWS CloudWatch will be coming up in the next release.

@Vincent Doppenberg Could these changes and the future improvements for AWS CloudWatch be clarified?


Regarding DevExpress: what would you recommend for Windows (.NET 6 or .NET Framework) and what is the impact?

TL;DR: There might be a small performance gain with slightly increased memory usage when using the .NET 6 plugin on Windows. The gains are small enough that I would just keep on using the (default) .NET Framework version for now. They perform roughly the same at the moment.

Some more details about what we encountered while implementing the feature itself:

  • DevExpress uses System.Drawing.Common to render the reports.
  • System.Drawing.Common is meant to work with GDI+ which is a Windows component.
  • This is why you need to install the extra dependencies, including libgdiplus, on Linux.
  • In addition to that their cross platform renderer requires Pango (libpango) for things like text measurements.
  • In .NET 6 System.Drawing.Common has started to throw exceptions when used on platforms other than Windows. Because, again, it depends on a Windows component.
  • To get around this DevExpress advises to either pull in the last .NET 5 version of System.Drawing.Common or to enable a runtime switch. Due to the way our plugin system works we cannot use the switch workaround and Microsoft is going to remove it eventually so we have opted to pull in System.Drawing.Common 5.0.3 for now.
  • We have not provided a setting to also enable the cross platform render on Windows because you would also need to install Pango and during the initial tests it looked like the  renderer was slightly slower than the default one.
  • DevExpress is working on creating another renderer that is not dependent on GDI+ but instead uses SkiaSharp. The most recent information about that which we could find was that it is supposed to be released in their 22.2.x releases. We will be keeping an eye out for that to update the plugin with it.

During testing we did not see a massive difference between the plugins when rendering reports on Windows. This might have been because they still use the same render engine. As stated there was a very slight decrease (~5-20 ms over 500 ms calling a report with 20 pages) in the time it took for the request to be done but the plugin process also used a bit more memory (~5 MB).

Since generating a report is pretty expensive anyway we do not see this as a massive improvement and you might be better off increasing the worker count with Reporting:DevExpress:WorkerCount instead if you are looking for more throughput.

We opted to add the Reporting:DevExpress:Runtime setting so developers could at least try out the .NET plugin themselves on Windows but I expect you will still see roughly the same performance as the default plugin.

Of course this might change in the future. If it does we will be sure to mention it in the release notes of that Indicium version.