CADENAS_DATA Caching (RFS-Caching)
By default, $CADENAS_DATA is not cached, but must be checked for each client request to see whether the data has changed (must-revalidate).
This is necessary in order to always be able to display up-to-date data. However, it can lead to increased start times over slow connections.
You can switch to caching with the Allow caching option. Then enter the minimum number of seconds. Then no new request will be made to the server for already cached data before the cache time set here has expired. However, this has the disadvantage that the clients will not notice any changes that occur on the server during this time (catalogs imported/updated). The setting here only affects catalog data, not ERP database content, which is always loaded up-to-date, even if caching is permitted.
It may also be useful to exclude certain clients (such as psworker etc. or the AppServer itself) from this caching. To do this, use the following two options:
However, if an http proxy is interposed, then the timeouts must be reduced for the following directories, otherwise the CADENAS cache invalidation process will not work. (The values should be in the hour range).
In version <=11 a method was described how to connect a proxy to the AppServer via Squid. Although this method still works in theory, it should no longer be used due to new technologies.
To set up a central AppServer with local servers in each branch office that cache as much as possible to reduce data traffic, proceed as follows:
Use a standard Linux nginx web server configured as a reverse proxy.
Configure "proxy_cache" to cache all cacheable data in your local cache directory.
Use a separate SSL certificate for this reverse proxy to provide encrypted connections to the client.
Forward all requests via http or https to the upstream (central AppServer).
Configure the IPs of this server as permitted proxies in the AppServer itself.
server {
# uncomment this and provide ssl certs for nginx for the hostname you want to use
#listen 9022 ssl;
#ssl_certificate /etc/letsencrypt/live/x.com/fullchain.pem;
#ssl_certificate_key /etc/letsencrypt/live/x.com/privkey.pem;
#ssl_protocols TLSv1.2 TLSv1.3;
#ssl_ciphers HIGH:!aNULL:!MD5;
# http port
listen 9020;
# server name (use the one you intend to use)
server_name proxy.example.com;
location / {
# use the ssl variant if you go over unsecure connections
# proxy_pass https://appserver.example.com:9022;
proxy_pass http://appserver.example.com:9020;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# WebSocket support
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# HTTP caching
proxy_cache my_cache;
add_header X-Proxy-Cache $upstream_cache_status;
}
}
# Cache settings
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=10g
inactive=60m use_temp_path=off;
If this is set up correctly, you only need to use a different CADENAS_APPSERVER variable in the branch offices:
CADENAS_APPSERVER=https://proxy.example.com:9022?ws=1&flm=1
CADENAS_APPSERVER=https://appserver.example.com:9022?ws=1&flm=1
Such a caching proxy has the advantage of saving data traffic, as it only transfers data once from the central server to the proxies and from there to the clients.
The CADENAS standard setup is not configured to use such proxies in between. If they are used, the caching for $CADENAS_SITESETUP must be kept to a minimum, as the cache cannot be invalidated by "push" from the AppServer (as is done with the clients). For this to work, the expiry times must be reduced.
For this, a
special section in the pappserver.cfg to
Reduce caching times for RFS:
pappserver.cfg: [FileSystemModuleMaxAges] CADENAS_DATA=3600 CADENAS_DATA/datasetup=3600 CADENAS_SETUP=3600 CADENAS_SITESETUP=3600
This reduces the expiry time to one hour. Changes will not be visible on the clients before one hour has elapsed. If this is too long, reduce the number of seconds until it is OK for your requirement.
If you set the value to 0, caching is effectively switched off and the clients are forced to perform an "If-Modified-Since-Cycle". You can do this during setup and increase the expiration time again later in production.
What is described also works for ENTERPRISE 3Dfindit clients.
In the browser, simply use the host name of the proxy instead of the name of the AppServer directly to access the main location via this proxy.
"https://proxy.example.com:9022/webapps/3dfindit-enterprise"
The following should be noted with regard to SSO:
With OpenID, only the "proxy.example.com" must be added to the "referer_uris" in the application config in Azure or with your OpenID provider. This must be done because a different public host name is introduced for which the redirects are permitted.
For Kerberos, a "setspn -S HTTP/proxy.example.com <serviceuser>" must be set for it to work.
In addition, the IP of "proxy.example.com" must be added as a permitted reverse proxy to the "cloud-support" page of the main app server.
AND the additional hostname must also be added to the permitted "Origin" list in the cloud support page (because both hostnames are now permitted to execute CORS requests).
