Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione
Documentazione di Apigee X. Informazioni
Questo argomento fa riferimento alle metriche, alle dimensioni e ai filtri di Analytics. Per maggiori informazioni relative, consulta la panoramica di API Analytics.
Questo argomento mostra i nomi delle metriche e delle dimensioni così come vengono visualizzati nell'interfaccia utente e in base alle tue esigenze. per utilizzarle nelle chiamate API.
- I nomi delle UI vengono visualizzati quando crei i report personalizzati.
- Utilizza i nomi specifici dell'API quando ottieni metriche o crei un di un report o di aggiornare 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 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 una soglia relativamente bassa numero di transazioni nel periodo di tempo, il numero medio di transazioni secondi potrebbe sembrare pari a zero nei report personalizzati dell'interfaccia utente se il numero è inferiore a due posizioni decimali. Sintassi dell'API: |
Successo della cache | cache_hit | somma |
Il numero di richieste API riuscite che utilizzano la cache delle risposte al posto della la risposta desiderata dal servizio di destinazione. Sintassi dell'API: |
Conteggio elementi cache L1 | ax_cache_l1_count | media, min, max |
Restituisce il numero di elementi nella cache L1 (in memoria) per transazione su una determinata
periodo di tempo. Ad esempio, se scegli Sintassi dell'API: |
Errori relativi ai criteri | policy_error | somma |
Il numero totale di errori dei criteri nel periodo di tempo specificato. In genere gli errori dei criteri si verificano in base alla progettazione. Ad esempio, il criterio Verify API Key genera un errore quando nella richiesta viene passata una chiave API non valida e un criterio di arresto dei picchi genera un errore se il numero di chiamate API supera il limite definito nel criterio. Quindi... questa metrica è utile per individuare potenziali aree problematiche nelle API. Ad esempio: Le metriche policy_error, raggruppate in base alla dimensione developer_app, potrebbero aiutarti a scoprire Una chiave API o un token OAuth sono scaduti per una determinata app. o potresti scoprire che un proxy API specifico sta generando molti errori Spike Arrest, che ti portano a scoprire che il limite di arresto dei picchi del proxy non tiene conto di un aumento del traffico generato dalle festività. In Analytics viene registrato un errore relativo ai criteri solo se l'errore provoca un errore del proxy API.
Ad esempio, se l'attributo La dimensione Nome criterio in caso di errore (ax_execution_fault_policy_name) è utile per gli errori dei criteri di raggruppamento per nome del criterio. Un errore della destinazione (ad esempio 404 o 503) non viene conteggiato come un errore del criterio. Quelli vengono conteggiati come errori del proxy API (is_error). Sintassi dell'API: |
Errori del proxy | is_error | somma |
Il numero totale di errori dei proxy API nel periodo di tempo specificato. Proxy l'errore può verificarsi in caso di errore di un criterio o 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 dell'API: |
Latenza di elaborazione richieste | request_processing_latency | media, min, max |
La quantità di tempo (media, minima o massima), in millisecondi, richiede a Edge di elaborare le richieste in entrata. L'ora 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 in base al proxy API, app sviluppatore, regione e così via. Sintassi dell'API: |
Dimensioni della richiesta | request_size | somma, media, min, max |
La dimensione del payload della richiesta ricevuto da Edge, espressa in byte. Sintassi dell'API: |
Cache delle risposte eseguita | ax_cache_executed | somma |
Il numero totale di volte in cui un criterio Response Cache è stato eseguito nel periodo specificato punto. Poiché il criterio Response Cache è collegato in due posizioni in un proxy API (una volta e una nella risposta), di solito viene eseguita due volte in una chiamata API. Una cache "get" e "put" della cache ciascuna viene conteggiata come un'esecuzione. Tuttavia, l'esecuzione della cache di risposta è pari a 0 se
Nello strumento Trace,
puoi fare clic sull'icona Response Cache in una chiamata API eseguita e visualizzare
Sintassi dell'API: |
Latenza di elaborazione delle risposte | response_processing_latency | media, min, max |
La quantità di tempo (media, minima o massima), in millisecondi, richiede a Edge di elaborare le risposte dell'API. L'ora inizia quando il proxy API riceve la risposta del servizio di destinazione e termina quando Apigee inoltra la risposta all'originale chiamante. Utilizzando dimensioni diverse, puoi esaminare le latenze di elaborazione delle risposte in base all'API proxy, regione e così via. Sintassi dell'API: |
Dimensione della risposta | response_size | somma, media, min, max |
La dimensione del payload di risposta restituito al client, byte. Sintassi dell'API: |
Errori target | target_error | somma |
Il numero totale di risposte 5xx dal servizio di destinazione. Questi sono servizi di destinazione non causati da Apigee. Sintassi dell'API: |
Tempo di risposta target | target_response_time | somma, media, min, max |
La quantità di tempo (somma, media, minima o massima) in millisecondi, affinché il server di destinazione risponda a una chiamata. Questa metrica indica le prestazioni dei server di destinazione. L'ora 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 (utilizzando il valore ad esempio), la chiamata non raggiungerà mai il servizio di destinazione e nessun target vengono registrate le metriche del tempo di risposta. Sintassi dell'API: |
Tempo totale di risposta | total_response_time | somma, media, min, max |
La quantità di tempo (somma, media, minima o massima) in millisecondi, da quando Edge riceve una richiesta da un client a quando Edge restituisce la risposta al client. Il tempo include l'overhead di rete (ad esempio il tempo impiegato da bilanciatori del carico e router per svolgere il loro lavoro), le richieste di elaborazione latenza, latenza di elaborazione della risposta e tempo di risposta target (se la risposta viene pubblicata) dal servizio di destinazione anziché dalla cache). Utilizzando dimensioni diverse, puoi esaminare le latenze di elaborazione per proxy API, app sviluppatore, regione e così via. Sintassi dell'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 nel modo più significativo per te. Sintassi dell'API: |
Dimensioni
Le dimensioni ti consentono di visualizzare le metriche in raggruppamenti significativi. Ad esempio, visualizzare il traffico totale i conteggi diventano molto più efficaci quando li visualizzi per ogni app sviluppatore o proxy API.
Di seguito sono riportate le dimensioni predefinite fornite da Apigee. Inoltre, puoi creare i tuoi proprie dimensioni, come descritto in Analizzare i contenuti dei messaggi delle API utilizzando 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 degli sviluppatori che effettuano le chiamate devono essere associate a una o più API prodotti contenenti proxy API, che i proxy chiamati devono verificare chiave o token OAuth inviato con la chiamata API. La chiave o il token è associato a un'API prodotto. Per ulteriori informazioni, vedi Per prima cosa: come generare dati di analisi completi. Se i criteri sopra indicati non sono soddisfatti, verrà visualizzato il valore "(not set)". Vedi anche Che cos'è il valore dell'entità di analisi "(not set)" significa?. |
Chiave cache | ax_cache_key |
La chiave contenente il valore Cache delle risposte a cui è stato eseguito l'accesso. Per ulteriori informazioni Come è strutturata la chiave per la cache delle risposte, consulta la sezione Criterio della cache di risposta. Nello strumento Trace,
Quando selezioni un criterio Cache risposte che ha letto o scritto nella cache,
può vedere questo valore nella variabile di flusso |
Nome cache | ax_cache_name |
Il nome della cache contenente le chiavi/valori utilizzati dal criterio Response Cache, con prefisso orgName__envName__. Ad esempio, se l'organizzazione è "foo", il è "test", l'ambiente di test e il nome della cache è "myCache", ax_cache_name è foo__test__myCache. Nello strumento Trace,
quando selezioni un criterio Cache delle risposte, puoi vedere questo valore nel
|
Origine cache | ax_cache_source |
Il livello della cache ("database L1" in memoria o "L2") da cui la cache delle risposte era recuperato. Questa dimensione mostra anche "CACHE_MISS" quando la risposta è stata inviata la destinazione anziché la cache (e la cache delle risposte è stata aggiornata con la risposta della destinazione); o quando una chiave cache nella richiesta non è valida. Le chiavi cache sono limitate a Deve avere una dimensione di 2 kB. Nello strumento Trace,
quando selezioni il criterio Cache risposte, puoi vedere questo valore nel
Per ulteriori informazioni sui livelli della cache, consulta Interna della cache. |
ID client | client_id |
La chiave utente (chiave API) dell'app sviluppatore che effettua le chiamate API, se vengono passate nella richiesta come chiavi API o incluse nei token OAuth. Per ottenere questa dimensione, i proxy che ricevono chiamate devono essere configurati per verificare per una chiave API o un token OAuth validi. Le app sviluppatore ricevono chiavi API, che possono essere utilizzate per Generare token OAuth quando le app sono registrate in Edge. Per ulteriori informazioni, vedi Per prima cosa: come generare dati di analisi completi. Se i criteri precedenti non sono soddisfatti, verrà visualizzato il valore "(not set)". Consulta anche Che cosa rende il valore dell'entità di analisi "(not set)" significa?. |
App sviluppatore | developer_app |
L'app per sviluppatori registrata Edge che effettua chiamate API. Per ottenere questa dimensione, le app devono essere associate a uno o più prodotti API contenenti i proxy API chiamati, che devono verificare la presenza di una chiave API o Token OAuth inviato con la chiamata API. La chiave o il token identifica l'app sviluppatore. Per Per saperne di più, consulta la sezione Innanzitutto: come generare dati di analisi completi. Se i criteri precedenti non sono soddisfatti, verrà visualizzato il valore "(not set)". Consulta anche Che cosa rende il valore dell'entità di analisi "(not set)" significa?. |
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, che devono verificare la presenza di una Chiave API o token OAuth inviato con la chiamata API. La chiave o il token identifica lo sviluppatore dell'app. Per ulteriori informazioni, consulta la sezione Operazioni preliminari: come generare dati di analisi completi. Se i criteri precedenti non sono soddisfatti, verrà visualizzato il valore "(not set)". Consulta anche Che cosa rende il valore dell'entità di analisi "(not set)" significa?. |
ID sviluppatore | sviluppatore |
L'ID sviluppatore univoco generato da Edge sotto forma di 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, che devono verificare la presenza di Chiave API o token OAuth inviato con le chiamate API. La chiave o il token identifica sviluppatore. Per ulteriori informazioni, consulta la sezione Operazioni preliminari: come generare dati di analisi completi. Se i criteri sopra indicati non sono soddisfatti, verrà visualizzato il valore "(not set)". Consulta anche Che cosa rende il valore dell'entità di analisi "(not set)" significa?. |
Ambiente | produzione | L'ambiente perimetrale in cui viene eseguito il deployment dei proxy API. Ad esempio, "test" o "prod". |
Codice di errore in caso di errore | ax_edge_execution_fault_code |
Il codice di errore dell'errore. Ad esempio:
|
Nome flusso in caso di errore | ax_execution_fault _flow_name |
Il flow 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 usare nell'API di gestione è ax_execution_fault_flow_name, senza interruzione di riga. Se non si sono verificati errori, viene visualizzato il valore "(not set)". |
Risorsa di flusso | flow_resource | Utilizzo esclusivo di Apigee. Se vuoi saperne di più, leggi questo post della scheda Community. |
Stato del flusso in caso di errore | ax_execution_fault _flow_state |
Il nome del flusso proxy API indica che hanno generato errori, ad esempio "PROXY_REQ_FLOW" o "TARGET_RESP_FLOW." Tieni presente che il nome completo da usare nell'API di gestione è 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 del gateway è utile per distinguere le metriche in Situazioni con TPS elevate in cui altre dimensioni come organizzazione, ambiente e timestamp sono identiche in tutte le chiamate. |
Organizzazione | organizzazione | L'organizzazione Edge in cui viene eseguito il deployment dei proxy API. |
Nome del criterio in caso di errore | ax_execution_fault _policy_name |
Il nome del criterio che ha generato un errore e causato l'esito negativo della chiamata API. Tieni presente che il nome completo da usare nell'API di gestione è ax_execution_fault_policy_name, senza interruzione di riga. Se un criterio genera un errore, ma l'attributo principale del criterio |
Proxy | apiproxy | Il nome della macchina (non il nome visualizzato) di un proxy API. |
Percorso di base proxy | proxy_basepath |
Il BasePath configurato sul proxyEndpoint del proxy API. Il percorso di base non include il dominio e la 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 variabile di flusso |
Suffisso percorso proxy | proxy_pathsuffix |
Il percorso della risorsa aggiunto al percorso di base del proxy API. Ad esempio, se un proxy API
L'URL di base è Se non viene utilizzato nessun percorso, il valore è vuoto. Il valore viene memorizzato anche nella variabile di flusso |
Revisione proxy | apiproxy_revision | Il numero di revisione del proxy API che ha gestito le chiamate API. Ciò non corrisponde necessariamente indica l'ultima revisione di un proxy API. Se un proxy API ha 10 revisioni, l'8° è attualmente possibile eseguire il deployment della revisione. Inoltre, un'API può essere soggetta a più revisioni purché 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 dell'attributo Tieni presente che quando utilizzi prodotti per il routing come Akamai per acquisire i veri indirizzi IP dei client,
l'IP del client viene passato 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 dalla destinazione può essere sovrascritto con come Assign Message e Raise Fault, (Assegna messaggio), per questo motivo, questa dimensione può essere diversa dal Codice risposta target (target_response_code). |
Host virtuale | virtual_host | Il nome dell'host virtuale
Chiamata API effettuata. Ad esempio, le organizzazioni hanno due
host virtuali per impostazione predefinita: default (http) e secure (https). |
In entrata/client | ||
Indirizzo IP client | client_ip | Indirizzo IP del sistema che contatta il router, ad esempio il client originale.
(proxy_client_ip) o su un bilanciatore del carico. Quando ci sono più IP nella
X-Forwarded-For , 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 del sistema operativo 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 utilizzarlo come seconda visualizzazione in dettaglio dimensione con Famiglia sistema operativo (ax_ua_os_family) per visualizzare le versioni dei sistemi operativi. |
IP client proxy | proxy_client_ip |
L'indirizzo IP del client chiamante, archiviato in |
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 dei client vengono passati a Edge nell'intestazione HTTP Per determinare l'indirizzo IP del client originale, a cui si accede tramite |
Percorso richiesta | request_path |
Il percorso della risorsa (escluso il dominio) al servizio di destinazione, esclusa la query parametri. Ad esempio, il target di esempio Apigee |
URI della richiesta | request_uri |
Il percorso della risorsa (escluso il dominio) al servizio di destinazione, inclusa la query parametri. Ad esempio, il target di esempio Apigee |
Richiedi verbo | request_verb | Il verbo della richiesta HTTP nelle richieste API, ad esempio GET, POST, PUT, DELETE. |
User agent | useragent |
Il nome dello user agent, o agente software, utilizzato per effettuare la chiamata API. Esempi:
|
Famiglia di user agent | ax_ua_agent_family | La famiglia dello 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" "Raccolta", e così via. |
Versione user agent | ax_ua_agent_version |
La versione dello user agent. È utile utilizzarlo come seconda visualizzazione in dettaglio dimensione con Famiglia user agent (ax_ua_agent_family) per ottenere la versione della famiglia di agenti. |
In uscita/Destinazione | ||
Percorso di base target | target_basepath |
Il percorso della risorsa (escluso il dominio) al servizio di destinazione, esclusa la query
definito nel parametro Ad esempio, supponiamo che un proxy API chiami il seguente target: <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> In questo esempio, il valore target_basepath è Se il target fosse questo: <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net</URL> </HTTPTargetConnection> target_basepath è nullo. Nello strumento Tracce, quando
seleziona l'icona AX alla fine del diagramma di flusso,
|
Host di destinazione | target_host | L'host del servizio di destinazione. Ad esempio, se un proxy API chiama
http://mocktarget.apigee.net/help , il valore di 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 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. Il valore "null" indica che la richiesta non ha mai raggiunto il servizio di destinazione. Ciò si verifica quando la risposta viene fornita dal criterio Response Cache o si verifica un errore nella richiesta e l'elaborazione dei dati. È diverso dal codice di stato della risposta (response_status_code). |
URL di destinazione | target_url |
L'URL completo del servizio di destinazione definito nel 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 è possibile eseguire l'override dell'URL anche durante l'elaborazione proxy API con
In proxy concatenamento e quando si utilizza lo script target (Node.js), il valore target_url nel proxy di chiamata è nullo. |
X inoltrato per | x_forwarded_for_ip | L'elenco di indirizzi IP nell'intestazione Per determinare l'indirizzo IP del client originale, a cui si accede tramite |
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. Per 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 al formato di 24 ore, l'ora a due cifre in cui sono state effettuate le chiamate API. Ad esempio: Chiamate API effettuate nell'ora tra le 22:00 e le 23:00, il valore di ax_hour_of_day è 22. Il valore dell'ora è nel fuso orario 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 Europa/Dublino. |
Settimana del mese | ax_week_of_month | La settimana numerica del mese. Ad esempio, per le chiamate API effettuate durante la terza settimana di mese, la settimana_del_mese è 3. |
Località | ||
Città | ax_geo_city | La città da cui sono state effettuate le chiamate API. |
Continente | ax_geo_continent | Il codice a 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 della regione geografica, ad esempio STATE-COUNTRY. Ad esempio: WA-US per Washington-Stati Uniti. |
Regione | ax_dn_region | Il nome del data center Apigee in cui viene eseguito il deployment dei proxy API, ad esempio us-east-1. |
Monetizzazione | ||
Crea messaggio ignora transazione | x_apigee_mint_tx_ignoreMessage | Flag che specifica se ignorare i messaggi relativi alla monetizzazione. Impostato su 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. Quando definisci i filtri, utilizza nomi in stile API per le metriche e le dimensioni.
Restituisce le metriche per i proxy API con libri dei nomi o musica:
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 le 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 codice di risposta target pari a 200 [Codice del corso]:
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 dei 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 stringa corrisponde a quello fornito. |
not like |
Restituisce false se il pattern stringa corrisponde al pattern fornito. |
similar to |
Restituisce true o false a seconda che il suo pattern corrisponda alla stringa specificata. È
simile a like , tranne per il fatto che interpreta il pattern utilizzando
definizione di un'espressione regolare. |
not similar to |
Restituisce false o true in base alla corrispondenza del pattern con la stringa specificata. È
simile a not like , tranne per il fatto che interpreta il pattern utilizzando
la definizione standard di un'espressione regolare. |
and |
Ti consente di utilizzare "and" per includere più di un'espressione di filtro. Il filtro include dati che soddisfano tutte le condizioni. |
or |
Consente di utilizzare "or" della logica per valutare diverse possibili espressioni di filtro. Il filtro include i dati che soddisfano almeno una delle condizioni. |