Query del contatore

Questo articolo contiene i seguenti argomenti:
casm173
Questo articolo contiene i seguenti argomenti:
La tabella del database, Cr_Stored_Queries definisce le query memorizzate. Queste query, molto simili alle query SQL, possono essere utilizzate per personalizzare i campi del contatore dei nodi nell'area Contatore delle interfacce di amministrazione e Web. I campi contatore indicano il numero di record che soddisfano la query. Ad esempio, possono indicare il numero di tipi diversi di Richieste sono state assegnate all'utente collegato.
Ciascun utente può personalizzare i campi del contatore visualizzati (come descritto nella Guida in linea). Tuttavia, è necessario che l'amministratore di sistema definisca i diversi tipi di Richieste che possono essere inclusi in tali campi del contatore come query memorizzate.
I calcoli del contatore risulteranno errati se i valori delle query del database sono nulli. Ad esempio, se la query del contatore specifica che assignee.organization = xyz, e in un record un campo assignee è vuoto (NULL), il record non rientrerà nel calcolo del contatore.
Query memorizzate per l'utente collegato
Due dei campi che devono essere definiti nella finestra Dettagli query memorizzata sono Clausola Where e Etichetta. Entrambi questi campi possono contenere espressioni personalizzate per l'utente collegato. Le query memorizzate fanno riferimento a oggetti e attributi invece che a nomi di tabelle e colonne. Una query memorizzata, personalizzata per l'utente collegato, è composta da due parti:
  • L'oggetto (ad esempio cr per una richiesta)
    Di solito è specificato a sinistra del segno di uguale (=). La sintassi di questa parte della query memorizzata è:
    att_name[.att_name...].SREL_att_name
Una query memorizzata ha sempre un tipo, che è il nome dell'oggetto su cui viene eseguita e fornisce il contesto per la query. Nella sintassi precedente, il primo nome_attr deve essere il nome di un attributo dell'oggetto context.
  • L'utente collegato (l'istanza dell'oggetto cnt per l'utente)
    Deve essere specificato a destra del segno di uguale (=) se i ticket devono essere selezionati in base a un attributo dell'utente collegato. La sintassi di questa parte della query memorizzata è:
    @
    nome_attr
    [.
    nome_attr
    ...].
    nome_attr_SREL
Per ulteriori informazioni sugli oggetti e gli attributi, consultare la sezione Comandi di riferimento di CA Service Desk Manager.
Sintassi per l'oggetto cr
Usare questa sintassi se il riferimento è all'oggetto richiesta (cr):
att_name[.att_name...].SREL_att_name
Questo esempio identifica l'ubicazione della persona assegnata per gestire un ticket. Il nome dell'oggetto è stato omesso in quanto il tipo della query memorizzata implica l'oggetto cr:
[email protected] AND active=1
  • Assegnatario
    È l'attributo nell'oggetto richiesta associato al campo assignee nella tabella corrispondente. Ad esempio, l'attributo assignee è definito nell'oggetto cr con SREL agt, che significa che fa riferimento al factory agt. Il factory agt è parte della definizione dell'oggetto cnt.
  • location
    È l'attributo nell'oggetto cnt associato al campo c_l_id nella tabella Contatto. L'attributo location è definito nell'oggetto cnt con SREL loc, che significa che fa riferimento all'oggetto loc.
Clausola WHERE
L'esempio seguente mostra un valore che può essere codificato in una clausola WHERE:
[email protected] AND active=1
Dato che il tipo di query memorizzata è una richiesta, questa query seleziona tutte le richieste attive in cui l'ubicazione dell'assegnatario è la stessa dell'utente collegato.
Etichetta
Gli attributi dell'oggetto cnt possono essere inclusi in etichette allo stesso modo in cui vengono inclusi nelle clausole WHERE. Ecco un esempio dell'uso di un attributo nell'oggetto cnt in un'etichetta:
@cnt.location.name Calls
Questa etichetta include il nome di una posizione, ad esempio, Phoenix, in cui Phoenix sostituisce @cnt.location.name quando l'etichetta viene visualizzata in una finestra. L'etichetta verrà visualizzata come Chiamate Phoenix.
Parola chiave IN
La parola chiave IN consente a una query memorizzata di fare riferimento a due o più tabelle senza creare un'unione Questo potrebbe produrre notevoli efficienze nell'esecuzione della query. Viene codificata nel modo seguente:
SREL_att_name IN ( value1 [, value2 [,...]] )
Ad esempio, una query di una richiesta potrebbe essere codificata così:
category.sym IN (\'Soft%\', \'Email\')
Si ottiene la clausola SQL WHERE seguente:
category IN (SELECT persid FROM prob_ctg WHERE sym LIKE 'Soft%' OR sym = 'Email')
Uno degli utilizzi della clausola IN è evitare i prodotti cartesiani. Ad esempio, la query seguente genera un prodotto cartesiano estremamente inefficiente:
assignee.last_name LIKE 'MIS%' OR group.last_name LIKE 'MIS%'
Usando la parola chiave IN, la query non crea un prodotto cartesiano; infatti non crea nessuna unione, come illustrato dall'esempio seguente:
assignee.last_name IN 'MIS%' OR group.last_name IN 'MIS%'
Le parentesi che in genere racchiudono l'elenco dei valori nella parte destra della clausola IN possono essere omesse se nell'elenco è presente un solo valore. Analogamente, è opportuno evitare le unioni nelle partizioni dati convertendo una partizione dati, come illustrato di seguito:
assignee.last_name LIKE 'Smith' to: assignee = U'374683AA82ACE34AB999A042F3A0BA2E'
dove:
  • U
    indica che il valore è un UUID.
  • '374683AA82ACE34AB999A042F3A0BA2E'
    I 32 caratteri racchiusi tra apici indicano la rappresentazione come stringa di un UUID esistente.
Questo impedisce l'unione sebbene supponga una perdita in CA. Con la clausola IN, la stessa partizione può essere scritta nel modo seguente, con la CA della prima versione e quasi la stessa efficienza della seconda versione:
assignee.last_name IN 'Smith'
CA SDM supporta l'applicazione della clausola IN negli elenchi QREL o BREL. Ad esempio, se si desidera trovare tutte le richieste in cui gli asset siano i padri di un altro asset specifico (con ID 374683AA82ACE34AB999A042F3A0BA2E), la clausola WHERE appropriata sarà:
affected_resource.[parent]child_hier.child IN (U'374683AA82ACE34AB999A042F3A0BA2E')
La prima parte della clausola,
affected_resource
, è uno SREL (chiave esterna) dell'oggetto cr (richiesta) che punta alla tabella Network_Resource. La parte
child_hier
è l'elenco degli oggetti hier che puntano alle relazioni gerarchiche. L'ultima parte,
child
, costituisce la prima parte della clausola WHERE per la query secondaria IN. La parte
374683AA82ACE34AB999A042F3A0BA2E
è il valore della chiave esterna che deve corrispondere a
child
.
[parent]
specifica il valore restituito dalla query secondaria. Poiché il valore id è una rappresentazione come stringa di un UUID, deve essere indicato come tale e scritto così: U’374683AA82ACE34AB999A042F3A0BA2E’.
Di seguito è riportato un esempio del codice SQL effettivamente generato, che restituisce tutte le richieste in cui l'Asset è il padre di un Asset specifico:
SELECT Call_Req.id FROM Call_Req WHERE Call_Req.affected_rc IN (SELECT hier_parent FROM Asset_Assignment WHERE hier_child = U'374683AA82ACE34AB999A042F3A0BA2E')
Per eseguire query su più padri, è possibile specificare un elenco separato da virgole nella parte () dell'SQL, come mostrato nell'esempio seguente:
affected_resource.[parent]child_hier.child IN (U'374683AA82ACE34AB999A042F3A0BA2E', U'374683AA82ACE34AB999A042F3A0BA2E')
Il nome dell'attributo tra parentesi quadre ([]) è usato per creare la parte SELECT della clausola secondaria. La notazione con parentesi quadre non è usata per le query memorizzate fornite con Unicenter Service Desk 6.0, come illustrato in questo esempio:
(assignee = @cnt.id OR group.group_list.member IN (@cnt.id)) AND active = 1
Se non si usa la notazione con le parentesi quadre, il sottosistema SQL presuppone che il nome dell'attributo sia il primo simbolo nella parte con la notazione a punti. In questo caso, l'oggetto group_list contiene l'attributo 'group'. Se fosse richiamato da un'altra parte, l'analisi della clausola WHERE non riuscirebbe! La clausola equivalente con le parentesi quadre è illustrata di seguito:
(assignee = @cnt.id OR group.[group]group_list.member IN (@cnt.id)) AND active = 1
Non è possibile estendere la notazione a punti. Ad esempio, il caso seguente non è valido:
affected_resource.[parent]child_hier.child.name IN ('chicago1')
Query basate sulla priorità
Nel database la tabella Priority ha due colonne: sym ed enum. Gli utenti vedono i valori della colonna sym. L'applicazione invece vede i valori della colonna sym in base ai valori della colonna enum. Attualmente, i valori sym predefiniti da 1 a 5 hanno i rispettivi valori enum invertiti.
Esempio
Simbolo
Enumerazione
1
5
2
4
3
3
4
2
5
1
Pertanto, quando si scrive una query memorizzata e si fa riferimento al valore 5, in effetti si sta cercando la priorità 1, a meno che non si usi .sym per specificare l'attributo da cercare.
Non cambiare i valori di enumerazione predefiniti assegnati dal prodotto. Se si aggiungono nuovi valori sym, è sufficiente proseguire dal valore enum più alto.
Query basate sul tempo
Per creare query basate sul tempo, è possibile usare periodi di tempo. Un periodo di tempo può essere relativo alla data corrente. Ad esempio, un periodo di tempo potrebbe fare riferimento a oggi, ieri, la settimana scorsa o il mese scorso. Un periodo di tempo ha un nome, ad esempio OGGI o IERI. In una query memorizzata è possibile fare riferimento a un periodo di tempo usando una delle due funzioni incorporate:
  • StartAtTime (
    nome-periodo
    )
    In questo modo si fa riferimento all'inizio dell'intervallo definito dal periodo di tempo.
  • EndAtTime (nome-periodo)
    In questo modo si fa riferimento alla fine dell'intervallo definito dal periodo di tempo.
Le regole della sintassi per le query memorizzate richiedono che il nome del periodo sia racchiuso tra apici e che ogni apice sia preceduto da una barra rovesciata. Ad esempio, per fare riferimento all'inizio della settimana scorsa, specificare:
StartAtTime(\'PAST_WEEK\')
Il trascorrere del tempo rende necessario aggiornare periodicamente una query memorizzata che contiene un riferimento a un periodo di tempo. Ad esempio, l'intervallo descritto da "ieri" cambia a mezzanotte. Nella finestra Dettagli periodo, è possibile specificare Ora di avvio, Ora di fine e Ora di attivazione degli aggiornamenti.
Ora di avvio
Ora di avvio specifica l'inizio del periodo di tempo in termini assoluti o relativi. La tabella seguente descrive i campi nella sezione Ora di avvio della finestra Dettagli periodo:
  • Anno
    Un anno esplicito, ad esempio 2000, o un anno relativo, ad esempio + 1 (anno successivo) o - 1 (anno precedente)
  • Mese
    Un mese esplicito da 1 (gennaio) a 12 (dicembre) o un mese relativo, ad esempio + 1 (mese successivo) o - 1 (mese precedente)
  • Giorno
    Un giorno esplicito da 1 a 31 o un giorno relativo, ad esempio +1 (domani) o –1 (ieri)
  • Ora
    Un'ora esplicita da 0 a 24 o un'ora relativa, ad esempio +1 (ora successiva) o –1 (ora precedente)
  • Minuti
    Un minuto esplicito da 0 a 59 o un minuto relativo, ad esempio +1 o –1
Ora di fine
Ora di fine specifica la fine del periodo di tempo in termini assoluti o relativi. I campi Ora di fine della finestra Dettagli periodo sono uguali ai campi Ora di avvio della stessa finestra.
Ora di attivazione
Il campo Ora di attivazione specifica quando la clausola WHERE di una query memorizzata contenente un riferimento al periodo di tempo viene creata nuovamente e la query memorizzata viene aggiornata. L'ora di attivazione deve essere relativa all'ora corrente, come descritto nella tabella seguente:
  • Anno
    Deve essere un anno relativo da –1 (anno precedente) a +36 (fra 36 anni).
  • Mese
    Deve essere un mese relativo da –1 (mese precedente) a +11 (fra 11 mesi).
  • Giorno
    Deve essere un giorno relativo da –1 (ieri) a +31 (fra 31 giorni).
  • Ora
    Deve essere un'ora relativa da –1 (ora precedente) a +23 (fra 23 ore).
  • Minuti
    Devono essere minuti relativi da +9 (fra 9 minuti) a +59 (fra 59 minuti).