Release notes Indicium (2021.2.10)

Hello everyone,

In this sprint, we've added more awesome features and solved some issues.

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

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

• Download Indicium Universal release 2021.2.20 here.
• Download Indicium Basic release 2021.2.20 here.

Support Expired

As per our Lifecycle policy, the support for the Thinkwise Platform version 2019.1 has expired.

Indicium Universal

File extension whitelists per storage configuration

We've implemented support for the file extension whitelists per storage configuration. This feature will be available in the soon-to-be-released Thinkwise Platform version 2021.2.

As of this version, file extension whitelists need to be configured per storage configuration in the Software Factory. For more information, check the upcoming Software Factory 2021.2 documentation and release notes.

Note: this will replace the current setting in Indicium's appsettings.json.

Basic support for import

In this version of Indicium, we have added an API for importing .xls, .xlsx and, .csv files into subjects in the Universal GUI. It is an initial, basic version of the API that does not yet support all the import features currently available in the Windows GUI. We will further improve this implementation and remove the limitations in future versions of Indicium.

The following limitations apply:

• The rows to be imported must be in the import file's first worksheet.
• The import file must contain column headers, and they must be on the first row.
• The column headers must be translated into the language of the user that is calling the API.
• The data must start on the second row, right below the headers.
• In the import file, lookup columns should contain their display value, not their database value.
• In the import file, columns with domain elements should contain their element translations, not their database values. The elements must be translated into the language of the user calling the API.
• Columns are mapped automatically based on their translation, which cannot be influenced right now.
• The Import permission checkbox in IAM does not affect this API at the moment, but the Insert permission box must be checked for at least one of the user's user group roles. These checkboxes are available in the menu Authorization > User groups > tab Effective group rights > tab Table rights > tab List.

As a rule of thumb, files that are exported by Indicium through the export API can be successfully imported using the import API, barring UNIQUE constraints on data.

Some additional noteworthy points that apply to this import API:

• Each record in the import file is treated as a separate insert made by the user that is calling the API. Meaning:
  • Users need insert permissions.
  • Default and layout logic apply and are called with default_mode=0, layout_mode=0, and import_mode=0.
    • The layout is called once before the import to ensure that the add_button_type is regular.
    • The default and layout procedures are called after every cell if the corresponding property has default/layout input checked.
    • The layout procedure is called after processing the last cell to determine if the confirm_button_type is regular.
  • Users cannot circumvent column-level authorization through the import API. Readonly, Hidden and Unauthorized columns that are present in the import file will be ignored.
• Context values cannot be changed. This means that if an import is performed on the 'sub_project' table in the context of a project parent record with 'project_id 1', that all records from the import file will be imported with 'project_id 1' as well.
• Expressions will be evaluated, but only if they are an input parameter for the default or layout procedure, otherwise they serve no purpose. Unchecking the default/layout input checkboxes for expression columns greatly improves performance.

The import API works in a very similar way to the resource staging API. The first step is staging an import resource:

POST
/iam/my_appl/my_table/stage_import

Or, if you want to import into a detail subject in the context of a parent record:

POST
/iam/my_appl/my_parent_table(1)/detail_my_detail_table/stage_import

The import file must be passed along as a binary file to the stage_import request. Indicium will respond with a '201 Created status' code upon success and return a Location header that points to the newly created import resource.

The import can then be started by calling the commit action on the import resource in the same way as it would work with resource staging.

POST
/iam/my_appl/_staged_import_my_table(<guid>)/commit

Indicium will give the following response after the import has completed:

200 OK

{
   "successful_records": 293,
   "failed_records": 1,
   "errors": [
       "Failed to import row 187. <some reason>"
   ]
}

Report processing with multiple workers (load balancing)

We've added settings to Indicium that can configure a report type to use a plugin to spawn multiple worker processes. This can be used to increase request throughput at the cost of more RAM resources.

• Reporting:<ReportType>:Enabled, can be set to false to skip loading the dependency entirely.
  • The default is true in order to remain consistent with previous Indicium releases.
• Reporting:<ReportType>:WorkerCount, controls how many plugin processes are spawned for that report type.
  • The default is 1 in order to remain consistent with previous Indicium releases.
• Reporting:<ReportType>:Preload, can be set to true to make Indicium spawn and warm up the plugin processes by exporting a dummy report during startup.
  • This can reduce the time users have to wait for their report when the initial request to a plugin process is made.
  • Note that the preload currently does not hit data sources contained in the report. So even with preload enabled, there are still some assemblies that may be loaded on the initial request.
  • The default for this setting is false to remain consistent with previous Indicium releases (wait until the first request for a report type is made before starting the process).

The report types that these settings can be configured for are:

• CrystalReports
• DevExpress
• SSRS:Local
• SSRS:Server.

Example configurations:

{
  "Reporting": {
    "CrystalReports": {
      // Start and preload a single plugin worker process for Crystal Reports.
      "Preload": true
    },
    "DevExpress": {
      // Start and preload 3 plugin worker processes for DevExpress reports.
      "Preload": true,
      "WorkerCount": 3
    },
    "SSRS": {
      // Disable SSRS local and server report types.
      "Local": {
        "Enabled": false
      },
      "Server": {
        "Enabled": false
      }
    }
  }
}

Minor fixes and tasks

• Fixed lookups that are filtered by an expression were not cleared if the expression value changed. For example, the column project_id is an expression that filters the lookup sub_project_id. Then, the column hour_id is changed by the user, causing the project_id expression value to change. Now, the sub_project_id column should be cleared. Indicium differed from the Windows and Web GUIs in this behavior, this has been corrected.
• We've fixed an issue with logging in on Indicium's login screen without specifying a returnUrl parameter in the query string.
• The min/max constraint validation is now checked before the length/precision constraint validation. This fixes the strange behavior that when a numeric(4,2) column has a maximum value of 60, the error message for the value 80 is different than the error message for the value 100.

Indicium Basic

Extended property force_recompile

The extended property force_recompile, which was already available in Indicium Universal, has now been implemented in Indicium Basic as well. This extended property accepts a comma-separated list of table/view names and forces the SQL Server to always recompile the query plan for these tables/views, in order to fix performance issues. Because Indicium uses parameterized queries, the SQL Server sometimes reuses existing query plans when it shouldn't, leading to the queries taking much longer than necessary.

Please note that forcing recompilation of the query plan causes a small performance hit as well, so only use it when there is a performance issue and this measure makes a noticeable difference.

Minor fixes and tasks

• Fixed an issue that caused authentication to fail when it shouldn't for authentication type ‘IAM’.
• Fixed an issue that caused Indicium to be unable to call a task's stored procedure in rare cases. When creating a task in de Software Factory, an Object name will be suggested using the task's ID or Alias and some type of prefix or suffix, depending on the platform. This Object name is the name of the procedure on the database. Instead of directly using the Object name to call the stored procedure, Indicium used the same convention that the Software Factory uses to produce the default Object name. In most cases, this worked, but when a developer deviated from the default Object name, Indicium would fail to call the stored procedure. This has now been fixed.