Technical release notes Q1 / 2024
Technical release notes highlight the development work done to make the FA platform fast, secure, reliable, and adaptable.
Overview
In the 2023 Q2 technical release notes, we laid out our goals to significantly improve the performance and scalability of the platform during the remainder of 2023. Looking back on those goals now in March 2024, we were able to make significant performance and scalability improvements in a variety of areas last year. Yet more work remains to be done. We will continue to focus on performance in 2024. We have several quarters’ worth of development ahead of us to make Analytics+ faster, for example.
In addition to performance, this year’s technical release notes feature another focus area: reliability. We not only need the FA platform to process your data quickly and efficiently, but it must also happen extremely reliably - even when the unexpected happens. During Q1, we focused particularly on the reliability of purchase lot and position calculation. That work will continue during Q2, alongside which we will also work to make other data-intensive operations as robust as possible.
Performance
Efficient search for data based on modification date
Why?
It’s useful to be able to find data that has been modified within a given time interval, but we didn't have an efficient way to do that.
Who is this for?
Users who need to search for data that was modified during a given time interval via FA Back, GraphQL API, or queries.
Details
Last modified field for the core data types existed in FA platform since the 2023 Q3 release. For transactions, this field existed even longer than that. Additionally, FA audit logs kept track of when data has changed for many years. Until now, FA platform didn't provide an efficient way to find data based on when it was (last) modified. Now we added the requisite indexing to make this possible.
Improved performance of specific kinds of transaction/trade order searches via GraphQL
Why?
For an (extended) limited visibility user, searching for transactions and trade orders was in some cases very inefficient.
Who is this for?
Applications that list transactions and trade orders based on user credentials with limited visibility access rights.
Details
It was possible to call our transaction or trade order APIs to list all transactions and trade orders that the logged-in user has access to, without any filtering criteria. Now the API supports searching for transactions and trade orders with multiple types, across multiple portfolios.
Improved performance of importing corporate actions
Why?
Corporate action import speed was too slow in environments that contain many corporate action records.
Who is this for?
Users who import corporate actions into FA.
Details
It’s possible to update corporate actions via FA importer. The corporate action importer implementation had an oversight that made it very inefficient for us to check whether to create a new corporate action or update an existing one. That oversight has now been corrected, resulting in significantly faster corporate action imports.
Reliability
Improved reliability of position and purchase lot calculation
Why?
Calculating purchase lots and positions based on transactions is at the very core of the FA platform. This needs to work extremely reliably, even in unforeseen circumstances.
Who is this for?
All users of the FA platform.
Details
Normally, saving a transaction automatically triggers an update of purchase lots, followed by an update of daily positions. Sometimes, unexpected temporary problems may occur in some step in this sequence, and prevent the consequent steps. This may lead to mismatches between transactions and purchase lots, or purchase lots and positions. In this release, we introduced an automatic mechanism to ensure that changes to transactions trigger changes to purchase lots and positions, even if something fails along the way.
Improved performance and reliability of composite transaction records
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. These records are generated in a suboptimal way.
Who is this for?
FA Back users in particular, because that’s where these records are primarily used. All FA users may potentially benefit from the slightly reduced load on the database.
Details
We improved the mechanism that generates the composite records. In particular, we are now able to generate these records faster and more efficiently when responding to changes to a large number of transactions at once. We also added a fail-safe mechanism to ensure that these records get updated even in case of unexpected errors.
Improved visibility to position and purchase lot calculation
Why?
Calculating purchase lots and positions based on transactions is at the very core of the FA Platform. It happens automatically. Users and administrators of the FA platform didn't get enough information about the status of these calculations to be able to spot potential issues with it.
Who is this for?
Users and administrators of the FA platform who want to confirm that purchase lot and position data was updated before proceeding with actions that rely on this data. Users and administrators who diagnose and resolve issues with purchase lot and position data.
Details
With this release, users have access to more information about report calculation activity. You can see in FA Back UI, via database queries, and via GraphQL API when various kinds of calculations were completed. Information about pending and ongoing calculation requests is now also available in FA Back.
Improved reliability in trade order bulking and execution
Why?
This change was done to improve reliability of trade order bulking and execution and to eliminate the risk of the process overriding any existing reference in use.
Who is this for?
Everyone who uses trade order bulking.
Details
We introduced a more efficient method for trade order bulking and bulk trade order execution and implemented a new DTO (data transfer object) to encapsulate all information related to bulk groups or single bulk orders. This DTO streamlines the passing of trade order details between steps, reducing the need for excessive casting and ensuring type safety.
The DTO includes IDs and details of underlying client orders, offering clients the option to override references if needed. We also enhanced the DTO to store information about partial bulk execution.
Improved fault tolerance of bulk order execution
Why?
This adjustment was made to enhance the fault tolerance of bulk order execution while mitigating the risk of potential mismatches between transaction records and purchase lots or positions that could occur in case of unexpected failures during bulk order execution.
Who is this for?
Everyone who uses bulk order execution.
Details
If an unexpected error occurred during bulk order execution, the process could fail to reach completion and trigger report updates. Consequently, there was a risk of bulk order execution saving some transactions without initiating the corresponding position/portfolio report calculations. To mitigate this issue, we implemented error handling (try-catch) within the bulk order execution process. This approach encapsulates the execution of each bulk, ensuring that unexpected failures in one bulk don't impede the execution of others or hinder report calculations.
Security
In this release, we updated various modules (dependencies and libraries) across our applications. These updates were not done in response to any particular issue or vulnerability. Instead, keeping these modules up to date is an important routine activity to ensure that the FA platform remains secure.
A particularly noteworthy update is a module that connects our newer applications with our authentication framework. This was done to ensure that those applications remain secure and compatible with future updates in our authentication framework.