CADENAS_DATA Caching (RFS-Caching)
Per impostazione predefinita, CADENAS_DATA non viene memorizzato nella cache, ma deve essere controllato per ogni richiesta del client per vedere se i dati sono cambiati (must-revalidate).
Questo è necessario per poter visualizzare sempre dati aggiornati. Tuttavia, può comportare un aumento dei tempi di avvio su connessioni lente.
È possibile passare alla cache con l'opzione Consenti cache [Allow caching]. Inserire quindi il numero minimo di secondi. In questo modo non verranno effettuate nuove richieste al server per i dati già memorizzati nella cache prima che sia trascorso il tempo di cache impostato. Tuttavia, questo ha lo svantaggio che i client non noteranno le modifiche che si verificano sul server durante questo periodo (cataloghi importati/aggiornati). L'impostazione riguarda solo i dati del catalogo, non il contenuto del database ERP, che viene sempre caricato aggiornato, anche se la cache è consentita.
Può anche essere utile escludere alcuni client (come psworker ecc. o lo stesso AppServer) dalla cache. A tale scopo, utilizzare le due opzioni seguenti:
Nessuna cache per i seguenti indirizzi IP/aree [No caching for the following IP addresses/ranges]: Inserire qui l'indirizzo IP; è necessario inserire più indirizzi IP separati da virgole.
Nessuna cache per i seguenti user agent [No caching for the following user agents]: Inserire l'indirizzo IP; è necessario inserire più indirizzi IP separati da virgole.
Ulteriori impostazioni della cache [Further cache settings]:
Tuttavia, se viene interposto un proxy http, i timeout devono essere ridotti per le seguenti directory, altrimenti il processo di invalidazione della cache di CADENAS non funzionerà. (I valori devono essere compresi nell'intervallo di ore).
Nella versione <=11 era descritto un metodo per collegare un proxy all'AppServer tramite Squid. Sebbene questo metodo funzioni ancora in teoria, non dovrebbe essere più utilizzato a causa delle nuove tecnologie.
Per configurare un AppServer centrale con server locali in ogni filiale che memorizzano nella cache il maggior numero possibile di dati, procedere come segue:
Utilizzare un server web standard Linux nginx configurato come reverse proxy.
Configurare "proxy_cache" per memorizzare tutti i dati memorizzabili nella cache locale.
Utilizzare un certificato SSL separato per questo reverse proxy per fornire connessioni crittografate al client.
Inoltrare tutte le richieste via http o https all'upstream (AppServer centrale).
Configurare gli IP di questo server come proxy consentiti nell'AppServer stesso.
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;
Se l'impostazione è corretta, è sufficiente utilizzare una variabile CADENAS_APPSERVER diversa nelle filiali:
CADENAS_APPSERVER=https://proxy.example.com:9022?ws=1&flm=1
CADENAS_APPSERVER=https://appserver.example.com:9022?ws=1&flm=1
Un proxy di caching di questo tipo ha il vantaggio di risparmiare traffico di dati, in quanto trasferisce i dati una sola volta dal server centrale ai proxy e da questi ai client.
L'Impostazione Standard di CADENAS non è configurata per l'utilizzo di tali proxy intermedi. Se vengono utilizzati, la cache di CADENAS_SITESETUP deve essere limitata al minimo, in quanto la cache non può essere invalidata da un "push" dell'AppServer (come avviene per i client). Affinché questo funzioni, i tempi di scadenza devono essere ridotti.
Per questo, un
sezione speciale nel pappserver.cfg a
Riduci i tempi di memorizzazione nella cache per RFS:
pappserver.cfg: [FileSystemModuleMaxAges] CADENAS_DATA=3600 CADENAS_DATA/datasetup=3600 CADENAS_SETUP=3600 CADENAS_SITESETUP=3600
Questo riduce il tempo di scadenza a un'ora. Le modifiche non saranno visibili sui client prima che sia trascorsa un'ora. Se questo tempo è troppo lungo, ridurre il numero di secondi fino a quando non è adeguato alle proprie esigenze.
Se si imposta il valore a 0, la cache viene disattivata e i client sono costretti a eseguire un "If-Modified-Since-Cycle". Si può fare questo durante la configurazione e aumentare nuovamente il tempo di scadenza in produzione.
Quanto descritto funziona anche per i clienti ENTERPRISE 3Dfindit.
Nel browser, è sufficiente utilizzare il nome dell'host del proxy invece del nome dell'AppServer per accedere alla posizione principale tramite questo proxy.
"https://proxy.example.com:9022/webapps/3dfindit-enterprise"
Per quanto riguarda l'SSO, si noti quanto segue:
Con OpenID, solo il "proxy.example.com" deve essere aggiunto al "referer_uris" nella configurazione dell'applicazione in Azure o con il vostro provider OpenID. Questo deve essere fatto perché viene introdotto un nome host pubblico diverso per il quale sono consentiti i reindirizzamenti.
Per Kerberos, è necessario impostare "setspn -S HTTP/proxy.example.com <serviceuser>" perché funzioni.
Inoltre, l'IP di "proxy.example.com" deve essere aggiunto come reverse proxy consentito alla pagina "cloud-support" del server principale dell'applicazione.
E il nome host aggiuntivo deve essere aggiunto all'elenco delle "Origini" consentite nella pagina di supporto del cloud (perché entrambi i nomi host sono ora autorizzati a eseguire richieste CORS).


![Origini CORS aggiuntive [Additional CORS origins]](https://webapi.partcommunity.com/service/help/latest/pages/it/3dfindit/doc/resources/img/img_4282ee4ddcde44e897e3d165f1a48489.png)