Details and Restrictions

Objects of object classes derived from Administration Object (COOSYSTEM@1.1:AdministrationObject)are not frozen. Consequently, changes executed as part of the update process are visible to Kernel instances.

Running transactions may result in an error during the Fabasoft Folio Backend Service update. Whether or not a transaction can be executed successfully depends on the state of the transaction when the Fabasoft Folio Backend Services are restarted.

Typical error scenarios:

• COOSYSTEM@1.1:COOSTERR_NET, COOSYSTEM@1.1:COOERR_COOSRVNOTREACHABLE, COOSYSTEM@1.1:COOERR_DOMAINSRVNOTREACHABLE, COOSYSTEM@1.1:COOSTERR_RPCSEQUENCE
  These errors can occur if the connection to the service is broken. The user should have either no impact (in case of successful retries) or see the error message COOSYSTEM@1.1:COOERR_DOMAINUPDATE (Fabasoft Folio is down for maintenance and will be back shortly) in case of a longer downtime.
• COOSYSTEM@1.1:COOSTERR_SQL (in conjunction with a “Unique constraint violation”)
  This error can occur if a transaction execution fails (e.g. due to a broken RPC call) and the transaction logic retries the operation. If the first execution was successfully on database side then the transaction retry results in a database error. In this case the error message COOSYSTEM@1.1:COOERR_DOMAINUPDATE (Fabasoft Folio is down for maintenance and will be back shortly) will be shown to the user. Further, new requests, should be successful for the user. This scenario can also identified by the message “Retry transaction … after … ms” in the error log.

Enabling the “Update Mode” causes RPC calls to be retried for at most 30 seconds. Requests may take a longer time until responding with an error.

A web server setup automatically disables “Update Mode” by deleting the update cache.

The error log (e.g. WebService.error.log) shows all occurred errors – also if a retry solves the problem.