1.4.5.8.1.3. Pagina della scheda "Caching

RFS caching

Figura 1.253. RFS caching

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).

  • CADENAS_SETUP

  • CADENAS_SITESETUP

  • CADENAS_DATA/impostazione dati

1.4.5.8.1.3.1. nginx come reverse proxy per la cache

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 il proxy websocket verso il server upstream.

  • 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

invece di

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]

    Figura 1.254.  Origini CORS aggiuntive [Additional CORS origins]