Questa pagina si applica a Apigee e Apigee ibrido.
Visualizza la documentazione di Apigee Edge.
Memorizza nella cache i dati di una risorsa di backend, riducendo il numero di richieste alla risorsa. Poiché le app effettuano richieste allo stesso URI, puoi utilizzare questo criterio per restituire le risposte memorizzate nella cache invece di inoltrare queste richieste al server di backend. Il criterio ResponseCache può migliorare le prestazioni dell'API attraverso latenza ridotta e traffico di rete.
Questo criterio è un criterio estendibile e il suo utilizzo potrebbe avere implicazioni in termini di costi o utilizzo, a seconda della licenza Apigee. Per informazioni sui tipi di criteri e sulle implicazioni per l'utilizzo, consulta la pagina Tipi di criteri.
Probabilmente troverai ResponseCache più utile quando i dati di backend utilizzati dalla tua API vengono aggiornati solo periodicamente. Ad esempio, immagina di avere un'API che espone i dati dei bollettini meteo aggiornati solo ogni 10 minuti. Utilizzando ResponseCache per restituire risposte memorizzate nella cache tra un aggiornamento e l'altro, puoi ridurre il numero di richieste che raggiungono il backend. In questo modo si riduce anche il numero di hop di rete.
Per la memorizzazione nella cache a breve termine per uso generico, valuta la possibilità di utilizzare il criterio compileCache. Questo criterio viene utilizzato in combinazione con il criterio LookupCache (per la lettura delle voci della cache) e con il criterio InvalidateCache (per l'annullamento della convalida delle voci).
Guarda il seguente video per un'introduzione al criterio Cache di risposta.
Esempi
10 minuti di cache
Questo esempio mostra come conservare le risposte memorizzate nella cache per 10 minuti.
Supponi di avere un'API al seguente URL:
http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778
Stai utilizzando il parametro di query w
come chiave cache. Apigee controlla il
valore del parametro di query w
ogni volta che viene ricevuta una richiesta. Se nella cache è presente una risposta valida (ossia non scaduta), il messaggio di risposta memorizzato viene restituito al client richiedente.
Ora immagina di avere un criterio ResponseCache configurato come segue.
<ResponseCache name="ResponseCache"> <CacheKey> <KeyFragment ref="request.queryparam.w" /> </CacheKey> <ExpirySettings> <TimeoutInSeconds>600</TimeoutInSeconds> </ExpirySettings> </ResponseCache>
La prima volta che il proxy API riceve un messaggio di richiesta per il seguente URL, la risposta viene memorizzata nella cache. Per la seconda richiesta entro 10 minuti viene eseguita una ricerca nella cache. La risposta memorizzata nella cache viene restituita all'app senza alcuna richiesta inoltrata al servizio di backend.
http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778
Ignora ricerca cache
L'esempio seguente mostra come fare in modo che la ricerca nella cache venga saltata e che la cache venga aggiornata. Guarda anche questo video sull'utilizzo di SkipCacheLookup.
La condizione facoltativa SkipCacheLookup (se configurata) viene valutata nel percorso della richiesta. Se la condizione restituisce true, la ricerca della cache viene ignorata e la cache viene aggiornata.
Un uso comune dell'aggiornamento condizionale della cache è una condizione che definisce un'intestazione HTTP specifica che fa sì che la condizione restituisca true. Un'applicazione client basata su script potrebbe essere configurata in modo da inviare periodicamente una richiesta con l'intestazione HTTP appropriata, causando esplicitamente l'aggiornamento della cache delle risposte.
Immagina ad esempio una chiamata a un'API al seguente URL:
'http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778' -H "bypass-cache:true"
Ora immagina il seguente criterio ResponseCache configurato su quel proxy. Tieni presente che la condizione di bypass-cache è impostata su true.
<ResponseCache name="ResponseCache"> <CacheKey> <KeyFragment ref="request.queryparam.w" /> </CacheKey> <!-- Explicitly refresh the cached response --> <SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup> <ExpirySettings> <TimeoutInSeconds>600</TimeoutInSeconds> </ExpirySettings> </ResponseCache>
Per ulteriori informazioni sulle condizioni, consulta Variabili e condizioni di flusso.
Riferimento elemento
Il riferimento agli elementi descrive gli elementi e gli attributi del criterio.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1"> <DisplayName>Response Cache 1</DisplayName> <Properties/> <CacheKey> <Prefix/> <KeyFragment ref="request.uri" /> </CacheKey> <Scope>Exclusive</Scope> <ExpirySettings> <ExpiryDate/> <TimeOfDay/> <TimeoutInSeconds ref="flow.variable.here">300</TimeoutInSeconds> </ExpirySettings> <CacheResource>cache_to_use</CacheResource> <CacheLookupTimeoutInSeconds/> <ExcludeErrorResponse/> <SkipCacheLookup/> <SkipCachePopulation/> <UseAcceptHeader/> <UseResponseCacheHeaders/> </ResponseCache>
Attributi <ResponseCache>
<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">
La tabella seguente descrive gli attributi comuni a tutti gli elementi principali dei criteri:
Attributo | Descrizione | Predefinito | Presenza |
---|---|---|---|
name |
Il nome interno della norma. Il valore dell'attributo Facoltativamente, utilizza l'elemento |
N/A | Obbligatorio |
continueOnError |
Impostalo su Imposta su |
false | Facoltativo |
enabled |
Imposta il criterio su Impostala su |
true | Facoltativo |
async |
Questo attributo è obsoleto. |
false | Deprecata |
Elemento <DisplayName>
Utilizzalo in aggiunta all'attributo name
per etichettare il criterio nell'editor proxy dell'interfaccia utente di gestione con un nome diverso in linguaggio naturale.
<DisplayName>Policy Display Name</DisplayName>
Predefinito |
N/A Se ometti questo elemento, viene utilizzato il valore dell'attributo |
---|---|
Presenza | Facoltativo |
Tipo | Stringa |
Elemento <CacheKey>
Configura un puntatore univoco a un dato archiviato nella cache.
La dimensione delle chiavi cache è limitata a 2 kB.
<CacheKey> <Prefix>string</Prefix> <KeyFragment ref="variable_name" /> <KeyFragment>literal_string</KeyFragment> </CacheKey>
Predefinita: |
N/A |
Presenza: |
Obbligatorio |
Tipo: |
N/A |
<CacheKey>
crea il nome di ogni dato archiviato nella cache.
La chiave viene spesso impostata utilizzando un valore delle intestazioni delle entità o dei parametri di query. In questi casi, dovresti
che l'attributo ref dell'elemento specifichi una variabile contenente il valore chiave.
In fase di runtime, i valori <KeyFragment>
vengono anteposti al valore dell'elemento <Scope>
o al valore <Prefix>
. Ad esempio, quanto segue genera una chiave cache di
UserToken__apiAccessToken__
<value_of_client_id>:
<CacheKey> <Prefix>UserToken</Prefix> <KeyFragment>apiAccessToken</KeyFragment> <KeyFragment ref="request.queryparam.client_id" /> </CacheKey>
Utilizzi l'elemento <CacheKey>
insieme a <Prefix>
e <Scope>
. Per ulteriori informazioni, vedi Utilizzo delle chiavi cache.
Elemento <CacheLookupTimeoutInSeconds>
Specifica il numero di secondi dopo i quali una ricerca di cache non riuscita verrà considerata un fallimento della cache. In questo caso, il flusso riprende lungo il percorso "cache-miss".
<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>
Predefinita: |
30 |
Presenza: |
Facoltativo |
Tipo: |
Integer |
Elemento <CacheResource>
Specifica la cache in cui devono essere archiviati i messaggi. Ometti questo elemento per utilizzare la cache condivisa inclusa. Devi specificare un CacheResource
per nome se vuoi poter
cancellare amministrativamente le voci contenute nella cache. Per ulteriori informazioni, consulta l'articolo sull'API Caches.
<CacheResource>cache_to_use</CacheResource>
Predefinita: |
N/A |
Presenza: |
Facoltativo |
Tipo: |
String |
Elemento <CacheKey>/<KeyFragment>
Specifica un valore che deve essere incluso nella chiave cache, creando uno spazio dei nomi per le richieste corrispondenti alle risposte memorizzate nella cache.
<KeyFragment ref="variable_name"/> <KeyFragment>literal_string</KeyFragment>
Predefinita: |
N/A |
Presenza: |
Facoltativo |
Tipo: |
N/A |
Può essere una chiave (un nome statico da te fornito) o un valore (una voce dinamica impostata facendo riferimento a una variabile). Tutti i frammenti specificati combinati (più il prefisso) sono concatenati per creare la chiave cache.
<KeyFragment>apiAccessToken</KeyFragment> <KeyFragment ref="request.queryparam.client_id" />
Utilizzi l'elemento <KeyFragment>
insieme a <Prefix>
e <Scope>
. Per ulteriori informazioni, vedi Utilizzo delle chiavi cache.
Attributi
Attributo | Tipo | Predefinita | Obbligatorio | Descrizione |
---|---|---|---|---|
riferimento | string | No |
La variabile da cui ottenere il valore. Non deve essere utilizzato se questo elemento contiene un valore letterale. |
Elemento <CacheKey>/<Prefix>
Specifica un valore da utilizzare come prefisso della chiave cache.
<Prefix>prefix_string</Prefix>
Predefinita: |
N/A |
Presenza: |
Facoltativo |
Tipo: |
String |
Utilizza questo valore anziché <Scope>
quando vuoi specificare un tuo valore anziché un valore enumerato <Scope>
. Se definito, <Prefix>
antepone il valore chiave cache per le voci scritte nella cache. Il valore di un elemento <Prefix>
sostituisce il valore di un elemento <Scope>
.
Utilizzi l'elemento <Prefix>
insieme a <CacheKey>
e <Scope>
. Per ulteriori informazioni, vedi Utilizzo delle chiavi cache.
Elemento <EscludiErrorResponse>
Attualmente, per impostazione predefinita, questo criterio memorizza nella cache le risposte HTTP con qualsiasi codice di stato possibile. Ciò significa che sia le risposte di successo che quelle di errore vengono memorizzate nella cache. Ad esempio, le risposte con codici di stato 2xx e 3xx vengono memorizzate nella cache per impostazione predefinita.
Imposta questo elemento su true
se non vuoi memorizzare nella cache le risposte di destinazione con codici di stato di errore HTTP. Se questo elemento è vero, verranno memorizzate nella cache solo le risposte con codici di stato da 200 a 205. Questi sono gli unici codici di stato HTTP che Apigee conteggia come
"successi" e non puoi modificare questa associazione.
Per una discussione sui pattern di Response Cache in cui questo elemento è utile, consulta Introduzione agli antipattern.
<ExcludeErrorResponse>true</ExcludeErrorResponse>
Predefinita: |
false |
Presenza: |
Facoltativo |
Tipo: |
Booleano |
Elemento <ExpirySettings>
Specifica quando deve scadere una voce della cache. Se presente, <TimeoutInSeconds>
esegue l'override di <TimeOfDay>
e <ExpiryDate>
.
<ExpirySettings> <TimeOfDay ref="time_variable">expiration_time</TimeOfDay> <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds> <ExpiryDate ref="date_variable">expiration_date</ExpiryDate> </ExpirySettings>
Predefinita: |
N/A |
Presenza: |
Obbligatorio |
Tipo: |
N/A |
Elemento <ExpirySettings>/<ExpiryDate>
Specifica la data in cui una voce della cache deve scadere. Utilizza il modulo mm-dd-yyyy
.
Se presente, l'elemento di pari livello di questo elemento, <TimeoutInSeconds>
, sostituisce
<ExpiryDate>
.
<ExpirySettings> <ExpiryDate ref="{date_variable}">expiration_date</ExpiryDate> </ExpirySettings>
Predefinita: |
N/A |
Presenza: |
Facoltativo |
Tipo: |
String |
Attributi
<ExpiryDate ref="" />
Attributo | Descrizione | Predefinita | Presenza | Tipo |
---|---|---|---|---|
riferimento |
La variabile da cui ottenere il valore. Non deve essere utilizzato se questo elemento contiene un valore letterale. |
N/A | Facoltativo | String |
Elemento <ExpirySettings>/<TimeOfDay>
L'ora del giorno in cui una voce della cache dovrebbe scadere. Utilizza il modulo hh:mm:ss
.
Se presente, l'elemento di pari livello di questo elemento, <TimeoutInSeconds>
, sostituisce
<TimeOfDay>
.
Inserisci l'ora nel formato HH:mm:ss, dove HH rappresenta l'ora nel formato a 24 ore. Ad esempio, 14:30:00 per le 14:30 del pomeriggio.
Per l'ora del giorno, le impostazioni internazionali e il fuso orario predefiniti variano a seconda di dove viene eseguito il codice (che non è noto quando si configura il criterio).
<ExpirySettings> <TimeOfDay ref="time_variable">expiration_time</TimeOfDay> </ExpirySettings>
Predefinita: |
N/A |
Presenza: |
Facoltativo |
Tipo: |
String |
Attributi
Attributo | Descrizione | Predefinita | Presenza | Tipo |
---|---|---|---|---|
riferimento | Variabile con il valore dell'ora di scadenza. | N/A | Facoltativo | Stringa |
Elemento <ExpirySettings>/<TimeoutInSec>
Il numero di secondi dopo il quale una voce della cache deve scadere.
Elemento <ExpirySettings>/<TimeoutInSeconds>
Il numero di secondi dopo il quale una voce della cache deve scadere. Se presente, questo elemento sostituisce gli elementi di pari livello, <TimeOfDay>
e <ExpiryDate>
.
<ExpirySettings> <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds> </ExpirySettings>
Predefinita: |
N/A |
Presenza: |
Facoltativo |
Tipo: |
String |
Attributi
Attributo | Descrizione | Predefinita | Presenza | Tipo |
---|---|---|---|---|
riferimento | Variabile con il valore di timeout. |
N/A
|
Facoltativo | String |
Elemento <Scope>
Enumerazione utilizzata per creare un prefisso per una chiave cache quando non viene fornito un elemento <Prefix>
nell'elemento <CacheKey>
.
<Scope>scope_enumeration</Scope>
Predefinita: |
"Esclusiva" |
Presenza: |
Facoltativo |
Tipo: |
String |
L'impostazione <Scope>
determina una chiave cache che viene anteposta in base al
valore <Scope>
. Ad esempio, una chiave cache assumerebbe il seguente formato quando
l'ambito è impostato su Exclusive
:
orgName__envName__apiProxyName__deployedRevisionNumber__proxy|TargetName__ [
serializedCacheKey ].
Se un elemento <Prefix>
è presente in <CacheKey>
, sostituisce un valore dell'elemento <Scope>
. I valori validi includono le enumerazioni
seguenti.
Utilizzi l'elemento <Scope>
insieme a <CacheKey>
e <Prefix>
. Per ulteriori informazioni, vedi Utilizzo delle chiavi cache.
Valori accettabili
Valore ambito | Descrizione |
---|---|
Global |
La chiave cache viene condivisa tra tutti i proxy API di cui è stato eseguito il deployment nell'ambiente. La chiave della cache è anteposta nel formato orgName __ envName __. Se definisci una voce |
Application |
Il nome del proxy API viene utilizzato come prefisso. La chiave cache è anteposta nel formato orgName__envName__apiProxyName. |
Proxy |
Come prefisso viene utilizzata la configurazione ProxyEndpoint. La chiave cache viene anteposta nel formato orgName__envName__apiProxyName__deployedRevisionNumber__proxyEndpointName . |
Target |
Come prefisso viene utilizzata la configurazione TargetEndpoint. Chiave cache anteposta nel formato orgName__envName__apiProxyName__deployedRevisionNumber__targetEndpointName . |
Exclusive |
Predefinita. Si tratta del tipo più specifico e, di conseguenza, presenta il rischio minimo di collisioni degli spazi dei nomi all'interno di una determinata cache. Il prefisso può essere di due tipi:
Chiave cache anteposta nel formato orgName__envName__apiProxyName__deployedRevisionNumber__proxyNameITargetName Ad esempio, la stringa completa potrebbe essere simile alla seguente: apifactory__test__weatherapi__16__default__apiAccessToken. |
Elemento <SkipCacheLookup>
Definisce un'espressione che, se restituisce true in fase di runtime, specifica che la ricerca nella cache deve essere saltata e la cache deve essere aggiornata. Vedi anche
Video sull'utilizzo del criterio ResponseCache sull'utilizzo di SkipCacheLookup
.
<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>
Predefinita: |
N/A |
Presenza: |
Facoltativo |
Tipo: |
String |
Dall'esempio seguente, se la variabile bypass-cache è impostata su true in un'intestazione in entrata, la ricerca nella cache viene saltata e la cache viene aggiornata.
<SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>
Elemento <SkipCacheCache>
Definisce un'espressione che, se restituisce true in fase di runtime, specifica che una scrittura nella cache deve essere saltata. Guarda anche questo
video sull'utilizzo di SkipCachePopulation
.
<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>
Predefinita: |
N/A |
Presenza: |
Facoltativo |
Tipo: |
String |
Ad esempio, quanto segue ignora la scrittura nella cache se il codice di stato della risposta è 400 o superiore:
<SkipCachePopulation>response.status.code >= 400</SkipCachePopulation>
Elemento <UseAccettaHeader>
Imposta su true
per aggiungere la chiave cache di una voce della cache di risposta con i valori delle
intestazioni della risposta Accept.
Apigee utilizza le intestazioni delle richieste Accept
, Accept-Encoding
, Accept-Language
e Accept-Charset
per calcolare la chiave cache. Questo approccio impedisce ai client di ottenere un tipo di media che non ha richiesto.
Ad esempio, considera se due richieste provengono dallo stesso URL, dove la prima richiesta accetta gzip e la seconda no. La prima richiesta verrà memorizzata nella cache e la voce memorizzata nella cache (probabilmente) sarà una risposta compressa in formato gzip. La seconda richiesta leggerà il valore memorizzato nella cache e potrebbe quindi restituire una voce compressa con gzip a un client che non è in grado di leggere il file gzip.
Per ulteriori informazioni, consulta Configurazione di una chiave cache.
<UseAcceptHeader>false</UseAcceptHeader>
Predefinita: |
false |
Presenza: |
Facoltativo |
Tipo: |
Booleano |
Elemento <UseResponseCacheHeaders>
Imposta true
per considerare le intestazioni delle risposte HTTP quando imposti la "durata" (TTL) della risposta nella cache. In questi casi, Apigee considera i valori delle seguenti intestazioni di risposta, confrontando i valori con quelli impostati da <ExpirySettings>
quando imposta la durata (TTL):
Cache-Control s-maxage
Cache-Control max-age
Expires
Per ulteriori dettagli, consulta Impostare la scadenza delle voci di cache.
<UseResponseCacheHeaders>false</UseResponseCacheHeaders>
Predefinita: |
false |
Presenza: |
Facoltativo |
Tipo: |
Booleano |
Note sull'utilizzo
La dimensione massima per ogni oggetto memorizzato nella cache è 256 kB. (Per informazioni dettagliate su come Apigee elabora la cache, consulta Informazioni interne della cache.)
Tramite la configurazione nel criterio ResponseCache, puoi fare in modo che Apigee includa intestazioni delle risposte HTTP nell'impostazione della scadenza delle voci della cache e delle chiavi cache. In questa sezione viene descritto che puoi utilizzare il criterio con le intestazioni per gestire la scadenza e le chiavi cache della cache.
Per saperne di più su come Apigee gestisce le intestazioni delle risposte con il criterio ResponseCache, consulta Supporto per le intestazioni delle risposte HTTP.
Impostazione della scadenza delle voci della cache
Come con il criterio compileCache, puoi impostare la scadenza (la sua durata) di una voce della cache di risposta utilizzando
l'elemento <ExpirySettings>
. Nel criterio ResponseCache puoi anche consentire ad Apigee
di prendere in considerazione le intestazioni delle risposte, se presenti.
Per utilizzare le intestazioni delle risposte, devi impostare il valore dell'elemento <UseResponseCacheHeaders>
su
true. Con questa impostazione, Apigee prende in considerazione le intestazioni delle risposte, le confronta con il valore impostato da <ExpirySettings>
e poi utilizza il valore più basso tra i due. Quando
considerano le intestazioni delle risposte, Apigee sceglie il valore disponibile come descritto
di seguito:
Ad esempio, immagina che una risposta venga memorizzata nella cache con i seguenti valori:
- Nessun valore
Cache-Control s-maxage
- Un valore
Cache-Control max-age
pari a 300 - Una data
Expires
tra tre giorni - Un valore
TimeoutInSeconds
<ExpirySettings>
pari a 600.
In questo caso, per il TTL verrà utilizzato il valore Cache-Control
max-age
perché è inferiore al valore <ExpirySettings>
e non è presente alcun valore Cache-Control s-maxage
(che ha la precedenza su max-age
).
Configurazione di una chiave cache
Come per i criteri della cache per uso generico, come il criterio compileCache, con
ResponseCache utilizzi gli elementi <CacheKey>
e <Scope>
per configurare la creazione di chiavi cache per le voci della cache. Con ResponseCache puoi anche rendere le chiavi cache più significative facendo aggiungere le intestazioni di risposta Accetta ai valori delle chiavi.
Per informazioni generali sulla configurazione delle chiavi cache, consulta la sezione Utilizzo delle chiavi cache. Per
informazioni sull'utilizzo delle intestazioni Accept, consulta <UseAcceptHeader>
.
Informazioni sulla crittografia della cache
Apigee e Apigee hybrid (versione 1.4 e successive): i dati della cache e KVM sono sempre criptati.
Variabili di flusso
Le seguenti variabili di flusso predefinite vengono compilate quando viene eseguito un criterio ResponseCache. Per ulteriori informazioni sulle variabili di flusso, consulta Riferimento per le variabili di flusso.
Variabili | Tipo | Autorizzazione | Descrizione |
---|---|---|---|
responsecache.{policy_name}.cachename |
String | Sola lettura | Restituisce la cache utilizzata nel criterio |
responsecache.{policy_name}.cachekey |
String | Sola lettura | Restituisce la chiave utilizzata |
responsecache.{policy_name}.cachehit |
Booleano | Sola lettura | True se l'esecuzione del criterio è riuscita |
responsecache.{policy_name}.invalidentry |
Booleano | Sola lettura | True se la voce della cache non è valida |
Codici di errore
Questa sezione descrive i messaggi di errore e le variabili di flusso che vengono impostati quando questo criterio attiva un errore. Queste informazioni sono importanti per sapere se stai sviluppando regole di errore per un proxy. Per scoprire di più, consulta gli articoli Cosa devi sapere sugli errori relativi alle norme e Gestione degli errori.
Prefisso codice di errore
N/A
Errori di runtime
Questo criterio non genera errori di runtime.
Errori di deployment
Questi errori possono verificarsi quando esegui il deployment di un proxy contenente questo criterio.
Nome errore | Causa | Correggi |
---|---|---|
InvalidTimeout |
Se
l'elemento <CacheLookupTimeoutInSeconds> del criterio ResponseCache viene impostato su un numero negativo,
il deployment del proxy API non va a buon fine. |
build |
InvalidCacheResourceReference |
Questo errore si verifica se l'elemento <CacheResource> in un criterio ResponseCache è impostato su un nome che non esiste nell'ambiente in cui viene eseguito il deployment del proxy API. |
build |
ResponseCacheStepAttachmentNotAllowedReq |
Questo errore si verifica se lo stesso criterio ResponseCache è associato a più percorsi di richiesta all'interno di qualsiasi flusso di un proxy API. |
build |
ResponseCacheStepAttachmentNotAllowedResp |
Questo errore si verifica se lo stesso criterio ResponseCache è collegato a più percorsi di risposta all'interno di qualsiasi flusso di un proxy API. |
build |
InvalidMessagePatternForErrorCode |
Questo errore si verifica se l'elemento <SkipCacheLookup> o <SkipCachePopulation>
in un criterio ResponseCache contiene una condizione non valida. |
build |
CacheNotFound |
Questo errore si verifica se la cache specifica menzionata nel messaggio di errore non è stata creata su un componente specifico dell'processore di messaggi. | build |
Variabili di errore
N/A
Esempio di risposta di errore
N/A
Schema
Ogni tipo di criterio è definito da uno schema XML (.xsd
). Come riferimento, su GitHub sono disponibili gli schemi dei criteri.