During an update of a Fabasoft Folio backend installation, the Fabasoft Folio object model comprised of component and administration objects are modified as part of the setup process. These modifications can be incompatible to previous versions and therefore should not be visible to Fabasoft Folio Kernel installations or users until the update process is considered completed.
To ensure a consistent state of component and administrative objects (with exceptions), the so-called “Update Mode” must be enabled for Fabasoft Folio Kernel installations.
By enabling the “Update Mode”, the current state of component and administrative objects is persisted on the local machine (next to the client cache) and considered read-only and not refreshable. Object instances of the following classes are affected by this operation:
As long as the “Update Mode” is enabled, potential changes to objects of these object classes are not visible. Objects cannot be modified, locked or refreshed. Attempting to do so results in an error message. As these kinds of modifications usually only affect administrative use cases, the impact on users is effectively non-existent.
A Fabasoft Folio Kernel bootstrap does not affect the “Update Mode”, the state remains frozen until the mode is disabled.
The “Update Mode” can be enabled or disabled via fscadmin:
To switch all Kernel-based services to or from the update mode, an UDP multicast packet is sent. Therefore, it is required that the “Cache- and UDP-Multicast-Protocol” is configured accordingly.
Before continuing with the update, verify that each Fabasoft Folio Kernel-based service was switched to the update mode by checking the following performance counter available for each Kernel-based service:
Note: After enabling the update mode via fscadmin the update mode is in effect. A restart or recycle is not required. After disabling the update mode a restart of all affected Kernel-based services is required.
The Fabasoft Folio Backend Services can be updated using the Fabasoft Folio Setup. During the update process, COO services are unavailable for a short period of time because of binary updates as well as a potential request after object model updates.
In case of a minor delta not involving migration steps during service startup or the restart after object model updates, the downtime is expected to be below 30 seconds. During that time, objects frozen by the “Update Mode” and existing cached objects remain available but cannot be modified. To eliminate downtime, COO service requests block for at most 30 seconds to provide transparent failover. After that timespan, use cases requiring COO services (reading objects that are not in the cache, modifying objects) result in an error message informing users that the services are not fully available.
Before the update, a web server must be removed from the load balancer and existing requests must be completed. The update can be executed via Fabasoft Folio Setup. In the course of the update process, the “Update Mode” is disabled. Consequently, no further action is required after a successful update before taking the web server online again.
To make sure that users working with updated web servers do not fall back to web servers in “Update Mode”, the load balancer must be configured accordingly. One way to achieve that is splitting available web servers into two pools, taking one pool offline and switching to that pool once the pool is fully available.