Developer release notes Q4 / 2023
The 2023 Q4 release includes various features and enhancements that help you extend the FA Platform. The highlights are described below.. For more in-depth descriptions of how you can take advantage of the new features, please refer to FA Developer Guide.
GraphQL API additions and improvements
New APIs
New APIs for working with multiple documents in a single request (upload, delete, download).
New GraphQL APIs for managing user preferences. The endpoints loadPreference, savePreference, and findPreferences may now be used to store user-specific information, e.g. default column selections.
New mutation API importSwitchOrder for importing a switch order to a given portfolio. This API applies limited visibility checks and creates 2 trade orders into the given portfolio (sell/buy), that are linked in such a way that executing the sell will update the buy to match in terms of the size of the trade.
New importPortfolioMonthlySavings mutation endpoint for filling in monthly savings data.
New holidayCalendar and holidayCalendars endpoints, and additional context query possibilities for HolidayCalendars. It is now easy to check whether a given date is a holiday according to a given holiday calendar, check when the next business date is, and list holidays according to a given holiday calendar.
New endpoint for fetching a portfolio based on the ID field in the portfolio IDs tab.
A new feature for managing business processes. The UI for querying this data uses GraphQL APIs. Look for endpoints containing the phrase BusinessProcess.
Several changes to flowable-related APIs; You can read more about them in the “Flowable improvements” section.
Changes to existing endpoints
It is now possible to request a contact type object within the contact context through the contactType attribute.
We no longer allow importing multiple records for the same contact/portfolio/security with a single API call. Starting from this release, whenever the system encounters an import payload with the same contact/portfolio/security multiple times, the duplicate records are rejected. Previously, such imports could lead to undesired results.
It is now possible to import manual prices via the importPrices mutation API.
You can now request the transactions and trade orders in the context of an accountItem. Combined with other filtering criteria, this returns transactions and trade orders recorded against that specific account.
The contacts endpoint now supports three additional parameters: includeAddresses, includeContactType, and includeRepresentatives. The purpose of these parameters is to optimize performance for API calls that fetch a large number of contacts. If your API call does not provide these parameters but requests e.g. address information, your API call works, but produces a separate database query for each contact. If you make an API call that may return many contacts and you want the results to include address information, you should set the “includeAddress” parameter to true. The same principles apply for contact type and representative information and their new parameters.
Flowable improvements
Until now, we have not provided an intuitive way to add a back button to multi-stage flowable processes where the user needs to provide information across multiple stages of the process. Specifically, it has been difficult to allow the user to go back to a previous step if the current form has mandatory fields still missing. To resolve the issue, we introduced a new skipRequiredFieldValidation button to our completeProcessTask endpoint.
In addition to skipping required field validation, it also adds a skipRequiredFieldValidation process variable with values “true” or “false” depending on whether the validation was skipped. This can be used to detect whether to transition the user backwards or forwards in the process flow. Any data the user filled in before going back is saved. For backwards compatibility and security purposes, skipping required field validation is prevented by default. To enable this feature, the form needs to contain a hidden field skipRequiredFieldValidationEnabled.
We also added a cancelProcessInstance mutation API which deletes the given process (based on process instance ID) if your user rights allow it and if the process does not have a preventCancel variable with the value true.
Finally, we improved the performance of our processTasks and processInstances endpoints, especially when returning a large number of tasks or process instances.
Support for running standard FA Client Portal in a root URL
Previously, the standard FA Client Portal ran via the <base-url>/public/myinvestments path. This made it convenient to install and try out the standard FA Client Portal in any environment; You simply needed to install it from the AppStore and open the url.
In production use, FA Client Portal is almost always run directly from the “root”, e.g. portal.investmentcompanyname.com, not portal.investmentcompanyname.com/public/myinvestments. Running FA Client Portal from a root URL previously required building a customized version. This made it hard to set up and maintain a version that is run in a custom domain; Every update required rebuilding it instead of just updating from our pre-built standard files.
Therefore, we changed the Q4 version of our standard FA Client Portal to run from the root by default to eliminate such challenges. This means the standard FA Client Portal cannot be run from a non-root-URL from this release onward. Installing FA Client Portal now requires explicitly defining a URL for it. If you want to install the default FA Client Portal or are currently running the standard version from the /public/myinvestments directory, please reach out to our support and we will set up a new FA Client Portal URL for you.
You may continue to use non-root-URLs in custom FA Client Portals. Define the homepage parameter in package.json to “/public/myinvestments” or similar and then build the project.
Other improvements
We added a new field called account_type to account details. This distinguishes between cash accounts, credit accounts, and other accounts and replaces the previous cash_account field. The previous field is kept (and updated when changes to account_type are made) for the sake of backwards compatibility.