Fynapse Release Policy
Overview
In Fynapse we aspire to provide an exceptional user experience, through iterative delivery of continuous value to our clients.
To achieve our objective and to assure that clients are running on the most recent release with access to the latest features we deploy releases, which include:
- New features
- Feature enhancements
- Fixes
Release Notes and updates to the Fynapse Help section always accompany a release.
Maintenances
There are three types of maintenance windows scheduled in Fynapse:
- Planned infrastructure maintenance - maintenance of Fynapse cloud infrastructure. Fynapse can be used in read-only mode, but access is not blocked/limited.
- Planned release maintenance - deployment of a new Fynapse version with new features, enhancements, and bug fixes. Fynapse can be used in read-only mode, but access is not blocked/limited.
- Ad hoc maintenance - usually related to deployment of patches with bug fixes. Instance accessibility depends on the specific scenario which was the cause of the patch.
All planned maintenances are communicated a week in advance in an email. Information about ad hoc maintenances is communicated with as much notice as possible.
Backup and Recovery
For all maintenance, data backups are automated and do not require user intervention. Transactional data backups are done on a daily basis via the storage volume snapshot mechanism. Reference and configuration data (smaller volume) use a combination of a full daily backup and Write Ahead Log that is copied to a distributed object storage. Data in-flight is redundantly stored in a commit log, so it can be recovered in case of a failure, providing no data loss in a disaster scenario.
The backup retention period is 7 days.
How Maintenance Windows Affect API Integration?
REST API will not be available during maintenance window. We advise that you prepare a retry mechanism in your environment.
Communicating via REST API can be prone to network disruptions, as well as other types of disruptions, for this reason a retry mechanism should be implemented to get a full confirmation that the data was ingested by Fynapse. Fynapse makes sure that the transactional data it receives is deduplicated on a record by record basis (a 24 hour deduplication window), so even if the same data is sent to Fynapse twice it will not cause any duplicates in the system.
A recommended process of sending transactional data to Fynapse would include:
- Preparing a chunk of transactional data (compatible with
POST /api/v1/ingestions/{ingestionId}endpoint payload) - Keeping track of all the chunks of data to be sent to Fynapse
- Sending out the data chunks asynchronously
- Cache ingestion IDs (
POST /api/v1/ingestions) to use when data is sent - Fynapse will automatically close ingestions with a long period of inactivity, so rotate the ingestion IDs every time an ingestion closed error is returned by Fynapse
- Close ingestion IDs manually to segment the data that is to be tracked with statistics API (e.g. after every 10m transactions, after every 1 hour)
The inbound data deduplication window is extended for the duration of any scheduled maintenance.
Feature Flags
To ensure the impact of a release to the client is low and close to zero our new capabilities that cause material behavioral changes for Fynapse and require you to adjust configuration and/or integration points will be deployed with a feature flag. Feature flags allow clients to take advantage of the latest product features while also allowing a testing window without interference to the on-going processing.
When a new feature is released it is by default disabled in Fynapse environments. This allows you to decide when you want to start testing how the feature will affect your existing configuration and business logic.
If, after consulting with the release documentation to assess the impact on your configuration, you want to start testing the new feature, you can enable it using the feature flag.
You will be able to enable and disable a new feature for a period of 4 weeks, starting from the day the feature was released.
If you need to extend the testing period for the new feature, please raise an ASD support request with Aptitude Software Support.
The table below lists which new functionalities and changes are released with a feature flag:
Fuse Flags
A special category of feature flags are fuse flags. Some of the features will enable data migration and this migration might not always be possible to revert back. These features will use fuse flags, which, once enabled, cannot be reverted to the disabled state.
An example of a fuse flag is Enable Multiple Currencies. Enabling multiple currencies can only occur on a clean system, before you start configuring Journal Line Definition.
If you enable the flag, you will not be able to disable it without wiping the system configuration.
Communication
We communicate with our users directly by:
- in-app messages - we publish two types of announcements:
- preview - which details the projected scope of the upcoming release
- release announcement - which details the scope of the release
- Status Page updates - communication regarding releases is carried out via Status Page.
