Technical release notes Q3 / 2024

Why?

Generating reports in different file formats for internal and external use is a core process of the FA Platform which can take a long time when working with large datasets. In some cases, reporting also caused FA Back to run out of memory and crash. The new improvements address both aspects of report generation.

Who is this for?

This feature is for users who generate large batches of external reports, for example, reports “per portfolio” or “per customer” for large portfolio groups.

Details

We applied several technical improvements to how we manage report generation. We improved memory management to make FA Back more stable during large reporting jobs. We also improved the speed with which large reporting jobs are started.

We introduced an optional setting to enable parallel report generation. Large reporting jobs were previously processed one-by-one, even though a typical instance of the FA Platform is capable of handling multiple such jobs at a time. Processing three reports simultaneously can double the throughput, for example. This new setting works out-of-the-box for JasperReports, query-based reports, and reports based on PDF templates. For jsreports, using the new setting requires additional configuration. If you need improved throughput for large jsreport jobs, contact FA support.

Why?

We want user interfaces for working with reconciliation data in FA Operations to scale to very large datasets while maintaining good performance.

Who is this for?

Users of reconciliation functionality in FA Operations.

Details

Various technical improvements allowed us to significantly improve the scalability of our reconciliation user interfaces in FA Operations. Indexing and pagination now allow us to filter and browse reconciliation results containing hundreds of thousands of records.

Why?

The FA Platform extension for running scheduled fees can take a long time to process for large groups of portfolios, and there was previously little visibility of feature when it is run.

Who is this for?

Users of the standard FA fee calculation extension.

Details

We added process monitoring support to our fee calculation extension, making it easy to track fee calculation progress FA Admin Console, Process monitoring view. We also added a configuration that allows the extension to calculate several fees in parallel. Depending on the fee formula, data, and server resources, calculating three fees in parallel, for example, can more than double fee calculation throughput. Calculating five fees in parallel can more than triple throughput.

Why?

FA Back automatically creates records that combine information from transactions, portfolios, contacts, and other sources. These records are used to provide users with flexible transaction and trade order listings. Previously, we maintained these records in a suboptimal way.

Who is this for?

This improvement is especially for users of FA Back where the records are primarily used. All FA users may benefit from the reduced load on the database.

Details

We were able to eliminate some large updates to our composite transaction record table. For example, when we update contacts or portfolios, we may need to update all our composite records related to those contacts or portfolios, but more commonly we do not. We are now able to recognize when these updates can be skipped, making transaction and trade order searches in FA Back faster when such updates occur.

Why?

Adding contracts to FA via our importer was slower than it should be.

Who is this for?

FA users who import contracts into the system.

Details

We found and removed a specific bottleneck that could cause imports of contracts to take significantly longer than corresponding transaction imports. The bottleneck was particularly significant in environments with extensive currency cross price data.

We improved the scalability and performance of generating deferrals for non-bonds. We also added a background generation button to our Swedish tax reports. The latter is more of a usability improvement rather than a performance improvement, but both work towards the goal of improving user experience when working with large batches of data.

Why?

FA Client Portal users were able to create trade orders too flexibly when having the rights for deposits, withdrawals, and trading.

Who is this for?

This improvement is for environments with deposits/withdrawals/trading enabled in FA Client portal, whether standard or custom.

Details

We introduced a new more restrictive endpoint for users of FA Client Portal and other similar customer applications. Starting from this release, the new endpoint is used for entering trades in FA Client Portal. We recommend that users of customized FA Client Portals also switch to the new endpoint.

In addition to enhanced out-of-the-box validation, this new endpoint allows smooth integration of custom validation logic to your end-client trading. This is done with decision tables. For a sample decision table for FA Client Portal validation, see Transaction and trade order decision tables.

To prevent potential problems, most users are restricted from adjusting most of the information associated with their Keycloak user.  For example, changing a Keycloak user’s name or email address must now be done via FA Admin Console, User management view. This change only affects very limited user information we track in Keycloak, not contact information in FA.