Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. info
Questo argomento è un riferimento per metriche, dimensioni e filtri di analisi. Per maggiori informazioni sull'utilizzo di questi parametri, consulta la panoramica dell'API Analytics.
Questo argomento mostra i nomi delle metriche e delle dimensioni così come vengono visualizzati nell'interfaccia utente e come devi utilizzarli nelle chiamate API.
- Vedrai i nomi dell'interfaccia utente quando crei report personalizzati.
- Utilizza i nomi specifici dell'API quando recuperi le metriche, crei una definizione di report o aggiorni una definizione di report.
Metriche
Di seguito sono riportate le metriche API che puoi recuperare nei report personalizzati e nelle chiamate API di gestione.
| Nome dei report personalizzati | Nome da utilizzare nell'API di gestione | Funzioni | Descrizione |
|---|---|---|---|
| Media transazioni al secondo | tps | Nessuno |
Il numero medio di transazioni, ovvero richieste proxy API, al secondo. Tieni presente che se hai un numero relativamente basso di transazioni nel periodo di tempo, il numero medio di transazioni al secondo potrebbe sembrare pari a zero nei report personalizzati dell'interfaccia utente se il numero è inferiore a due cifre decimali. Sintassi API: |
| Successo della cache | cache_hit | somma |
Il numero di richieste API riuscite che utilizzano la cache delle risposte anziché la risposta del servizio di destinazione. Sintassi API: |
| Conteggio elementi cache L1 | ax_cache_l1_count | media, min, max |
Restituisce il numero di elementi nella cache L1 (in memoria) per transazione in un determinato
periodo di tempo. Ad esempio, se scegli Sintassi API: |
| Errori delle norme | policy_error | somma |
Il numero totale di errori delle norme nel periodo di tempo specificato. Gli errori relativi alle norme in genere si verificano intenzionalmente. Ad esempio, il criterio Verifica chiave API genera un errore quando nella richiesta viene passata una chiave API non valida, mentre un criterio Spike Arrest genera un errore se il numero di chiamate API supera il limite definito nel criterio. Pertanto, questa metrica è utile per trovare potenziali punti critici nelle tue API. Ad esempio, le metriche policy_error, raggruppate in base alla dimensione developer_app, potrebbero aiutarti a scoprire che una chiave API o un token OAuth è scaduto per una determinata app oppure potresti scoprire che un proxy API specifico genera molti errori Spike Arrest, il che ti porta a scoprire che il limite di Spike Arrest del proxy non tiene conto di un aumento del traffico durante le festività. Un errore di policy viene registrato in Analytics solo se l'errore comporta l'errore del proxy API.
Ad esempio, se l'attributo La dimensione Nome norma in caso di errore (ax_execution_fault_policy_name) è utile per raggruppare gli errori delle norme in base al nome della norma. Un errore di destinazione (ad esempio 404 o 503) non viene conteggiato come errore delle norme. Questi vengono conteggiati come errori del proxy API (is_error). Sintassi API: |
| Errori proxy | is_error | somma |
Il numero totale di volte in cui i proxy API non sono riusciti nel periodo di tempo specificato. L'errore del proxy può verificarsi quando una policy non va a buon fine o quando si verifica un errore di runtime, ad esempio un errore 404 o 503 dal servizio di destinazione. La dimensione Proxy (apiproxy) è utile per raggruppare gli errori del proxy API per proxy. Sintassi API: |
| Latenza di elaborazione delle richieste | request_processing_latency | media, min, max |
La quantità di tempo (media, minima o massima), in millisecondi, necessario a Edge per elaborare le richieste in entrata. Il conteggio del tempo inizia quando la richiesta raggiunge Edge e termina quando Edge inoltra la richiesta al servizio di destinazione. Utilizzando dimensioni diverse, puoi esaminare le latenze di elaborazione delle richieste per proxy API, app per sviluppatori, regione e così via. Sintassi API: |
| Dimensione della richiesta | request_size | somma, media, min, max |
Le dimensioni del payload della richiesta ricevuto da Edge, in byte. Sintassi API: |
| Cache delle risposte eseguita | ax_cache_executed | somma |
Il numero totale di volte in cui una policy di Response Cache è stata eseguita nel periodo di tempo specificato. Poiché la policy Response Cache è collegata in due punti di un proxy API (una volta nella richiesta e una volta nella risposta), in genere viene eseguita due volte in una chiamata API. Un'operazione "get" e un'operazione "put" della cache vengono conteggiate come un'esecuzione ciascuna. Tuttavia, l'esecuzione della cache delle risposte è 0 se l'elemento
Nello strumento di tracciamento,
puoi fare clic sull'icona della cache delle risposte in una chiamata API eseguita e visualizzare la
Sintassi API: |
| Latenza di elaborazione della risposta | response_processing_latency | media, min, max |
La quantità di tempo (media, minima o massima), in millisecondi, necessaria a Edge per elaborare le risposte API. Il conteggio del tempo inizia quando il proxy API riceve la risposta del servizio di destinazione e termina quando Apigee inoltra la risposta al chiamante originale. Utilizzando dimensioni diverse, puoi esaminare le latenze di elaborazione delle risposte per proxy API, regione e così via. Sintassi API: |
| Dimensioni risposta | response_size | somma, media, min, max |
Le dimensioni del payload della risposta restituito al client, in byte. Sintassi API: |
| Errori target | target_error | somma |
Il numero totale di risposte 5xx dal servizio di destinazione. Si tratta di errori del servizio di destinazione non causati da Apigee. Sintassi API: |
| Tempo di risposta target | target_response_time | somma, media, min, max |
La quantità di tempo (somma, media, minimo o massimo), in millisecondi, impiegato dal server di destinazione per rispondere a una chiamata. Questa metrica indica il rendimento dei server di destinazione. Il conteggio del tempo inizia quando Edge inoltra una richiesta al servizio di destinazione e termina quando Edge riceve la risposta. Tieni presente che se una chiamata API restituisce una risposta dalla cache (ad esempio utilizzando la policy Cache delle risposte), la chiamata non raggiungerà mai il servizio di destinazione e non verranno registrate metriche sul tempo di risposta della destinazione. Sintassi API: |
| Tempo di risposta totale | total_response_time | somma, media, min, max |
La quantità di tempo (somma, media, minimo o massimo), in millisecondi, dal momento in cui Edge riceve una richiesta da un client a quello in cui Edge invia la risposta al client. Il tempo include l'overhead di rete (ad esempio, il tempo necessario ai bilanciatori del carico e ai router per svolgere il proprio lavoro), la latenza di elaborazione delle richieste, la latenza di elaborazione delle risposte e il tempo di risposta del target (se la risposta viene fornita dal servizio di destinazione anziché dalla cache). Utilizzando dimensioni diverse, puoi esaminare le latenze di elaborazione per proxy API, app per sviluppatori, regione e così via. Sintassi API: |
| Traffico | message_count | somma |
Il numero totale di chiamate API elaborate da Edge nel periodo di tempo specificato. Utilizza le dimensioni per raggruppare i conteggi del traffico nei modi più significativi per te. Sintassi API: |
Dimensioni
Le dimensioni consentono di visualizzare le metriche in raggruppamenti significativi. Ad esempio, visualizzare i conteggi del traffico totale diventa molto più efficace se li visualizzi per ogni app sviluppatore o proxy API.
Di seguito sono riportate le dimensioni fornite da Apigee pronte all'uso. Inoltre, puoi creare le tue dimensioni, come descritto in Analisi dei contenuti dei messaggi delle API mediante analisi personalizzate.
| Nome dei report personalizzati | Nome da utilizzare nell'API di gestione | Descrizione |
|---|---|---|
| Entità Apigee | ||
| Token di accesso | access_token | Il token di accesso OAuth dell'utente finale dell'app. |
| Prodotto API | api_product |
Il nome del prodotto API contenente i proxy API chiamati. Per ottenere questa dimensione, le app per sviluppatori che effettuano le chiamate devono essere associate a uno o più prodotti API che contengono i proxy API e i proxy chiamati devono verificare la presenza di una chiave API o di un token OAuth inviato con la chiamata API. La chiave o il token è associato a un prodotto API. Per saperne di più, consulta Prima di tutto: come generare dati di analisi completi. Se i criteri precedenti non vengono soddisfatti, vedrai il valore "(not set)". Vedi anche Che cosa indica un valore dell'entità di analisi "(not set)"? |
| Chiave cache | ax_cache_key |
La chiave contenente il valore della cache delle risposte a cui è stato eseguito l'accesso. Per ulteriori informazioni su come viene creata la chiave per la cache delle risposte, consulta le norme sulla cache delle risposte. Nello strumento di tracciamento,
quando selezioni una policy di cache delle risposte che legge o scrive nella cache, puoi
visualizzare questo valore nella variabile di flusso |
| Nome cache | ax_cache_name |
Il nome della cache contenente le chiavi/i valori utilizzati dal criterio Response Cache, con il prefisso orgName__envName__. Ad esempio, se l'organizzazione è "foo", l'ambiente è "test" e il nome della cache è "myCache", ax_cache_name è foo__test__myCache. Nello strumento di tracciamento,
quando selezioni una policy della cache delle risposte, puoi visualizzare questo valore nella
|
| Origine cache | ax_cache_source |
Il livello di cache ("L1" in memoria o "L2" database) da cui è stata recuperata la cache delle risposte. Questa dimensione mostra anche "CACHE_MISS" quando la risposta è stata fornita dalla destinazione anziché dalla cache (e la cache delle risposte è stata aggiornata con la risposta della destinazione) o quando una chiave della cache nella richiesta non è valida. Le chiavi della cache sono limitate a 2 kB. Nello strumento di tracciamento,
quando selezioni il criterio della cache delle risposte, puoi visualizzare questo valore nella
Per saperne di più sui livelli di cache, consulta Elementi interni della cache. |
| ID client | client_id |
La chiave utente (chiave API) dell'app per sviluppatori che effettua le chiamate API, passata nella richiesta come chiavi API o inclusa nei token OAuth. Per ottenere questa dimensione, i proxy che ricevono chiamate devono essere configurati per verificare la presenza di una chiave API o di un token OAuth validi. Le app per sviluppatori ricevono chiavi API, che possono essere utilizzate per generare token OAuth, quando le app vengono registrate in Edge. Per saperne di più, consulta Prima di tutto: come generare dati di analisi completi. Se i criteri precedenti non vengono soddisfatti, vedrai il valore "(not set)". Vedi anche Che cosa indica un valore dell'entità di analisi "(not set)"? |
| App per sviluppatori | developer_app |
L'app per sviluppatori registrata su Edge che effettua chiamate API. Per ottenere questa dimensione, le app devono essere associate a uno o più prodotti API che contengono i proxy API chiamati e i proxy devono verificare la presenza di una chiave API o di un token OAuth inviato con la chiamata API. La chiave o il token identifica l'app sviluppatore. Per maggiori informazioni, vedi Prima di tutto: come generare dati di analisi completi. Se i criteri precedenti non vengono soddisfatti, vedrai il valore "(not set)". Vedi anche Che cosa indica un valore dell'entità di analisi "(not set)"? |
| Email sviluppatore | developer_email |
L'email degli sviluppatori registrati su Edge la cui app ha effettuato le chiamate API. Per ottenere questa dimensione, gli sviluppatori devono avere app associate a uno o più prodotti API che contengono i proxy API chiamati e i proxy devono verificare la presenza di una chiave API o di un token OAuth inviato con la chiamata API. La chiave o il token identifica l'app dello sviluppatore. Per ulteriori informazioni, consulta Prima di tutto: come generare dati di analisi completi. Se i criteri precedenti non vengono soddisfatti, vedrai il valore "(not set)". Vedi anche Che cosa indica un valore dell'entità di analisi "(not set)"? |
| ID sviluppatore | sviluppatore |
L'ID sviluppatore univoco generato da Edge nel formato org_name@@@unique_id. Per ottenere questa dimensione, gli sviluppatori devono avere app associate a uno o più prodotti API contenenti i proxy API chiamati e i proxy devono verificare la presenza di una chiave API o di un token OAuth inviato con le chiamate API. La chiave o il token identifica lo sviluppatore. Per saperne di più, consulta Prima di tutto: come generare dati di analisi completi. Se i criteri precedenti non vengono soddisfatti, vedrai il valore "(not set)". Vedi anche Che cosa indica un valore dell'entità di analisi "(not set)"? |
| Ambiente | produzione | L'ambiente Edge in cui vengono implementati i proxy API. Ad esempio, "test" o "prod". |
| Codice di errore | ax_edge_execution_fault_code |
Il codice di errore. Ad esempio:
|
| Nome del flusso in caso di errore | ax_execution_fault _flow_name |
Il flusso denominato in un proxy API che ha generato un errore. Ad esempio, "PreFlow", "PostFlow" o il nome di un flusso condizionale che hai creato. Tieni presente che il nome completo da utilizzare nell'API Management è ax_execution_fault_flow_name, senza interruzione di riga. Se non si sono verificati errori, vedrai il valore "(not set)". |
| Risorsa di flusso | flow_resource | Solo per l'utilizzo di Apigee. Se ti incuriosisce, consulta questo post della community. |
| Flow State on Error | ax_execution_fault _flow_state |
Il nome degli stati del flusso del proxy API che hanno generato errori, ad esempio "PROXY_REQ_FLOW" o "TARGET_RESP_FLOW". Tieni presente che il nome completo da utilizzare nell'API Management è ax_execution_fault_flow_state, senza interruzione di riga. |
| ID flusso gateway | gateway_flow_id | Man mano che le chiamate API si spostano attraverso Edge, ogni chiamata riceve il proprio ID flusso gateway. Esempio: rrt329ea-12575-114653952-1. L'ID flusso gateway è utile per distinguere le metriche in situazioni con TPS elevato in cui altre dimensioni come organizzazione, ambiente e timestamp sono identiche in tutte le chiamate. |
| Organizzazione | organizzazione | L'organizzazione Edge in cui vengono implementati i proxy API. |
| Nome della norma in caso di errore | ax_execution_fault _policy_name |
Il nome della policy che ha generato un errore e causato l'esito negativo della chiamata API. Tieni presente che il nome completo da utilizzare nell'API Management è ax_execution_fault_policy_name, senza interruzione di riga. Se un criterio genera un errore, ma l'attributo radice del criterio |
| Proxy | apiproxy | Il nome macchina (non il nome visualizzato) di un proxy API. |
| Percorso di base proxy | proxy_basepath |
BasePath configurato in ProxyEndpoint del proxy API. Il percorso di base non include la parte di dominio e porta dell'URL del proxy API. Ad esempio, se l'URL di base di un proxy API è https://apigeedocs-test.apigee.net/releasenotes/, il percorso di base è /releasenotes. Il valore viene memorizzato anche nella |
| Suffisso percorso proxy | proxy_pathsuffix |
Il percorso della risorsa aggiunto al percorso di base del proxy API. Ad esempio, se l'URL base di un proxy API è Se non viene utilizzato alcun suffisso del percorso, il valore è vuoto. Il valore viene memorizzato anche nella |
| Revisione proxy | apiproxy_revision | Il numero di revisione del proxy API che ha gestito le chiamate API. Non si tratta necessariamente dell'ultima revisione di un proxy API. Se un proxy API ha 10 revisioni, è possibile che sia attualmente in corso il deployment dell'ottava revisione. Inoltre, è possibile eseguire il deployment di più revisioni di un'API a condizione che le revisioni abbiano percorsi di base diversi, come descritto in Deployment dei proxy nell'interfaccia utente. |
| IP client risolto | ax_resolved_client_ip |
Contiene l'indirizzo IP del client di origine. Il valore della dimensione Tieni presente che quando utilizzi prodotti di routing come Akamai per acquisire i veri indirizzi IP dei client, l'IP client viene trasmesso a Edge nell'intestazione HTTP Il valore della dimensione
|
| Codice di stato della risposta | response_status_code | Il codice di stato della risposta HTTP inoltrato da Apigee al client, ad esempio 200, 404, 503 e così via. In Edge, il codice di stato della risposta della destinazione può essere sovrascritto con norme come Assegna messaggio e Genera errore, motivo per cui questa dimensione può differire da Codice di risposta della destinazione (target_response_code). |
| Host virtuale | virtual_host | Il nome dell'host virtuale a cui è stata effettuata la chiamata API. Ad esempio, le organizzazioni hanno due
host virtuali per impostazione predefinita: default (http) e secure (https). |
| Inbound/Client | ||
| Indirizzo IP client | client_ip | Indirizzo IP del sistema che raggiunge il router, ad esempio il client originale
(proxy_client_ip) o un bilanciatore del carico. Quando nell'intestazione
X-Forwarded-For sono presenti più IP, questo è l'ultimo IP elencato. |
| Categoria dispositivo | ax_ua_device_category | Il tipo di dispositivo da cui è stata effettuata la chiamata API, ad esempio "Tablet" o "Smartphone". |
| Famiglia di sistemi operativi | ax_ua_os_family | La famiglia di sistemi operativi del dispositivo che effettua la chiamata, ad esempio "Android" o "iOS". |
| Versione sistema operativo | ax_ua_os_version |
La versione del sistema operativo del dispositivo che effettua la chiamata. È utile utilizzarla come seconda dimensione di analisi in dettaglio con Famiglia di sistemi operativi (ax_ua_os_family) per visualizzare le versioni dei sistemi operativi. |
| IP client proxy | proxy_client_ip |
L'indirizzo IP del client chiamante, memorizzato nella variabile di flusso
|
| IP client di riferimento | ax_true_client_ip | Quando utilizzi prodotti di routing come Akamai per acquisire i veri indirizzi IP dei client,
gli IP client vengono passati a Edge nell'intestazione HTTP Per determinare l'indirizzo IP client originale, a cui si accede tramite la dimensione |
| Percorso richiesta | request_path |
Il percorso della risorsa (senza includere il dominio) al servizio di destinazione, esclusi i parametri di query. Ad esempio, la destinazione di esempio Apigee |
| URI della richiesta | request_uri |
Il percorso della risorsa (senza includere il dominio) al servizio di destinazione, inclusi i parametri di query. Ad esempio, la destinazione di esempio Apigee |
| Verbo della richiesta | request_verb | Il verbo di richiesta HTTP nelle richieste API, ad esempio GET, POST, PUT, DELETE. |
| User agent | useragent |
Il nome dello user agent o del software agent utilizzato per effettuare la chiamata API. Esempi:
|
| Famiglia di user agent | ax_ua_agent_family | La famiglia dell'user agent, ad esempio "Chrome Mobile" o "cURL". |
| Tipo di user agent | ax_ua_agent_type | Il tipo di user agent, ad esempio "Browser", "Browser mobile", "Libreria" e così via. |
| Versione dello user agent | ax_ua_agent_version |
La versione dell'user agent. È utile utilizzarla come seconda dimensione di "drill-down" con Famiglia user agent (ax_ua_agent_family) per ottenere la versione della famiglia di agenti. |
| In uscita/Destinazione | ||
| Percorso di base di destinazione | target_basepath |
Il percorso della risorsa (senza includere il dominio) al servizio di destinazione, esclusi i parametri di query, definito in Ad esempio, supponiamo che un proxy API chiami la seguente destinazione: <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> In questo esempio, target_basepath è Se il target fosse questo: <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net</URL> </HTTPTargetConnection> target_basepath sarà null. Nello strumento di tracciamento, quando
selezioni l'icona AX alla fine del diagramma di flusso, la
|
| Host di destinazione | target_host | L'host del servizio di destinazione. Ad esempio, se un proxy API chiama
http://mocktarget.apigee.net/help, il target_host è
mocktarget.apigee.net. |
| Indirizzo IP di destinazione | target_ip | L'indirizzo IP del servizio di destinazione che restituisce la risposta al proxy API. |
| Codice di risposta del target | target_response_code |
Il codice di stato della risposta HTTP restituito dal servizio di destinazione al proxy API, ad esempio 200, 404, 503 e così via. Un valore "null" indica che la richiesta non ha mai raggiunto il servizio di destinazione. Ciò si verifica quando la risposta viene fornita dalla norma Response Cache o quando si verifica un errore nell'elaborazione della richiesta. È diversa dalla dimensione Codice di stato della risposta (response_status_code). |
| URL target | target_url |
L'URL completo del servizio di destinazione definito in TargetEndpoint di un proxy API. <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> In questo esempio, target_url è
Tieni presente che l'URL può essere sostituito anche durante l'elaborazione del proxy API con la
variabile di flusso Nel proxy chaining e quando si utilizzano destinazioni script (Node.js), target_url nel proxy chiamante è null. |
| X Forwarded For | x_forwarded_for_ip | L'elenco degli indirizzi IP nell'intestazione Per determinare l'indirizzo IP client originale, a cui si accede tramite la dimensione |
| Ora | ||
| Giorno della settimana | ax_day_of_week | L'abbreviazione di tre lettere del giorno della settimana in cui sono state effettuate le chiamate API. Ad esempio, lun, mar, mer. |
| Mese | ax_month_of_year | Il mese numerico in cui sono state effettuate le chiamate API. Ad esempio, "03" per marzo. |
| Ora del giorno | ax_hour_of_day |
In base a un orologio di 24 ore, l'ora a due cifre in cui sono state effettuate le chiamate API. Ad esempio, per le chiamate API effettuate nell'ora tra le 22:00 e le 23:00, ax_hour_of_day sarà 22. Il valore dell'ora è in UTC. |
| Fuso orario | ax_geo_timezone | I nomi comuni dei fusi orari da cui sono state effettuate le chiamate API, ad esempio America/New_York ed Europe/Dublin. |
| Settimana del mese | ax_week_of_month | La settimana numerica del mese. Ad esempio, per le chiamate API effettuate nella terza settimana di un mese, ax_week_of_month è 3. |
| Località | ||
| Città | ax_geo_city | La città da cui sono state effettuate le chiamate API. |
| Continente | ax_geo_continent | Il codice di due lettere del continente da cui sono state effettuate le chiamate API. Ad esempio, NA per il Nord America. |
| Paese | ax_geo_country | Il codice di due lettere del paese da cui sono state effettuate le chiamate API. Ad esempio, US per gli Stati Uniti. |
| Regione geografica | ax_geo_region | Il codice con trattino per la regione geografica, ad esempio STATO-PAESE. Ad esempio, WA-US per Washington-Stati Uniti. |
| Regione | ax_dn_region | Il nome del data center Apigee in cui vengono implementati i proxy API, ad esempio us-east-1. |
| Monetizzazione | ||
| Mint Transaction Ignore Message | x_apigee_mint_tx_ignoreMessage | Flag che specifica se ignorare i messaggi relativi alla monetizzazione. Imposta false per tutte le organizzazioni di monetizzazione. |
| Stato transazione Mint | x_apigee_mint_tx_status | Stato di una richiesta di monetizzazione, ad esempio riuscita, non riuscita, non valida o nessuna. |
Filtri
I filtri ti consentono di limitare i risultati alle metriche con caratteristiche specifiche. Di seguito sono riportati alcuni filtri di esempio. Utilizza nomi in stile API per metriche e dimensioni quando definisci i filtri.
Restituisce le metriche per i proxy API con il nome books o music:
filter=(apiproxy in 'books','music')
Restituisce le metriche per i proxy API con nomi che iniziano con "m":
filter=(apiproxy like 'm%')
Restituisce le metriche per i proxy API con nomi che non iniziano con "m":
filter=(apiproxy not like 'm%')
Restituisce metriche per le chiamate API con codici di stato della risposta compresi tra 400 e 599:
filter=(response_status_code ge 400 and response_status_code le 599)
Restituisce le metriche per le chiamate API con codice di stato della risposta 200 e un codice di risposta di destinazione 404:
filter=(response_status_code eq 200 and target_response_code eq 404)
Restituisce le metriche per le chiamate API con un codice di stato della risposta 500:
filter=(response_status_code eq 500)
Restituisce le metriche per le chiamate API che non hanno generato errori:
filter=(is_error eq 0)
Di seguito sono riportati gli operatori che puoi utilizzare per creare filtri per i report.
| Operatore | Descrizione |
|---|---|
in |
Includi nell'elenco |
notin |
Escludi dall'elenco |
eq |
Uguale a == |
ne |
Non uguale a != |
gt |
Maggiore di > |
lt |
Meno di < |
ge |
Maggiore o uguale a >= |
le |
Minore o uguale a <= |
like |
Restituisce true se il pattern della stringa corrisponde al pattern fornito. |
not like |
Restituisce false se il pattern della stringa corrisponde al pattern fornito. |
similar to |
Restituisce true o false a seconda che il pattern corrisponda alla stringa specificata. È
simile a like, ma interpreta il pattern utilizzando la definizione di espressione regolare
dello standard SQL. |
not similar to |
Restituisce false o true a seconda che il pattern corrisponda alla stringa specificata. È
simile a not like, tranne per il fatto che interpreta il pattern utilizzando la definizione di espressione regolare dello standard SQL. |
and |
Consente di utilizzare la logica "e" per includere più di un'espressione di filtro. Il filtro include i dati che soddisfano tutte le condizioni. |
or |
Consente di utilizzare la logica "OR" per valutare diverse espressioni di filtro possibili. Il filtro include i dati che soddisfano almeno una delle condizioni. |