To improve the runtime performance of a SWAT Framework-based application, the repository cache has been implemented to store the computed definition for all screens.
Once activated, performance is increased as the backend doesn't need to recompute the screen definitions, which can be a complex process.
Despite the improved performance, repository caching is disabled, by default, as it can interfere with the development process.
As implied, once a screen definition has been cached, it won't take into account any additional changes done to the screen itself until the cached version is removed.
To activate it, one simply needs to add the caching service to the application's services XML file:
<ttServiceLoaderRow> |
The database repository cache service supports the following PASOE config XML entries:
Property name | Details |
---|---|
RepositoryCacheSkipList | A comma-separated list of screen name patterns, which is used to exclude them from the cache so they are recalculated each time they are requested by the user. |
As seen in the 'Activation' section, the repository cache functionality has been implemented through a SmartComponent Library service (Akioma.Swat.Repository.Cache.DatabaseRepositoryCacheService).
This means that the service implements an interface (Akioma.Swat.Repository.Cache.IRepositoryCacheService) and all interactions with the service are done through the interface.
The SWAT Framework support only one repository cache service, DatabaseRepositoryCacheService, which stores the definition in the database.
The repository service fully supports custom implementations of the IRepositoryCacheService interface.
The base builder class now has a new property: 'DynamicDefinition'.
By default, the property is false, in which case any screen containing the corresponding control is unaffected.
Whenever a screen contains a control which has the dynamic definition property set to true, it will be automatically excluded from the build.
This has been introduced for custom controls, where the definition changes during runtime.
As such, it is up to the developer of the custom control to decide whether it is dynamic at runtime or only at design-time.
When screen changes are made in an environment where caching is enabled and the screen has been cached, the changes won't be visible.
For this, the clear cache functionality is available to remove the specified screens from the cache so the changed definition can be reconstructed.
As of SWAT Release 19.11.0, the repository cache service itself provides a clear cache method to clear all the screens matching the specified MATCHES pattern.
DEFINE VARIABLE oCacheService AS Akioma.Swat.Repository.Cache.IRepositoryCacheService NO-UNDO. |
Additionally, there also are 2 procedures available to allow clearing caches from external scripts:
Akioma/Swat/Repository/Cache/clear-repository-cache-be.p, which calls the clear cache method on Akioma.Swat.Repository.Cache.RepositoryCacheEntity
RUN Akioma/Swat/Repository/Cache/clear-repository-cache-be.p ("*"). |
Akioma/Swat/Repository/Cache/clear-repository-cache-be-pct.p, which calls into Akioma/Swat/Repository/Cache/clear-repository-cache-be.p and is compatible with PCT
<PCTRun baseDir="${baseDir}" <propath refid="${propathId}"/> |
DEPRECATED:
The clear cache functionality is available by calling the business entity method 'ClearCache' of 'Akioma.Swat.Repository.Cache.RepositoryCacheEntity'.
The method accepts a Consultingwerk.CharacterHolder parameter, which is used as a 'MATCHES' pattern to identify all the cached definitions that need to be removed.
Below is a sample on how to clear the whole cache by calling the method with the '*' pattern:
DEFINE VARIABLE hDataset AS HANDLE NO-UNDO. |