Product Documentation

Definizione Regole

Regole


Le regole per far scattare gli eventi degli SLA avanzati si configurano all’interno del dettaglio di un evento dei livelli di servizio:

 

 Innanzitutto vanno specificati i tipi di modifica che fanno scattare l’evento, la scelta può variare tra:

 

Per quanto riguarda gli SLA sui ticket:

  • Cambio gruppo in carico
  • Cambio priorità
  • Cambio stato ticket
  • Cambio tipo ticket
  • Chiusura attività
  • Chiusura intervento
  • Chiusura ticket
  • Creazione attività
  • Creazione intervento
  • Creazione ticket
  • Inoltro ticket
  • Presa in carico ticket

 

Per gli SLA sulle attività:

  • Cambio stato attività
  • Creazione attività
  • Inoltro attività

 

Mentre per gli SLA su interventi:

  • Cambio stato intervento
  • Creazione intervento
  • Inoltro intervento

 

La regola serve per definire quale deve essere la condizione del ticket, dell’attività o dell’intervento per far scatenare l’evento.

Gli oggetti su cui si possono valutare le condizioni sono Ticket e TicketModification per i ticket, TaskTaskModification per le attività, Action e ActionModification per gli interventi,

TicketModification rappresenta una riga di TABChiamateModifiche, TaskModification una riga di TABPersonaleAttivitaProspettoModifiche mentre ActionModification una riga di TABInterventiModifiche.

Di seguito alcune regole per la sintassi delle ServiceLevelRules:

  • Le valutazioni si baseranno solo sui campi degli oggetti Ticket e TicketModification per i ticket, Task e TaskModification per le attività, Action e ActionModification per gli interventi e andranno scritti come:
  • Ticket.NomeCampo o TicketModification.NomeCampo
  • Task.NomeCampo o TaskModification.NomeCampo
  • Action.NomeCampo o ActionModification.NomeCampo

Tutti i campi sono definiti nell'helper relativo alla build di HDA 6 installata che può essere richiesto a PAT.

  • Le proprietà possono essere valutate anche in modo nested, ad esempio Ticket.Site.Active = "true"
  • I valori da comparare di tipo stringa vanno racchiusi tra doppi apici (es.: Ticket.IDTicketStatus =“S1”)
  • Sono ammesse parentesi
  • Sono ammessi tutti gli operatori di confronto: “=, <, >, <>, <=, >=”
  • Le varie regole possono essere messe in OR, in AND o in NOT
  • Si possono definire dei confronti con l’operatore LIKE con le seguenti sintassi:

Per valutare se un campo contiene un determinato pattern

  • Ticket.NomeCampo.Like(“%Pattern%”)

Oppure per valutare se un campo inizia con un determinato pattern:

  • Ticket.NomeCampo.Like(“Pattern%”)

Oppure per valutare se un campo finisce con un determinato pattern:

  • Ticket.NomeCampo.Like(“%Pattern”)

I confronti tra stringhe sono CASE SENSITIVE, perciò la regola

Ticket.Site.CompanyName.Like(“%ROSSI%”) darà risultato diverso da

Ticket.Site.CompanyName.Like(“%rossi%”), si può ovviare a questo inconveniente utilizzando l’operatore ToUpper() in questo modo:

Ticket.Site.CompanyName.ToUpper().Like(“%ROSSI%”) oppure

Ticket.Site.CompanyName.ToUpper() = “ROSSI”

  • Si possono far eseguire dei blocchi SQL all’interno delle regole utilizzando l’operatore

EXECSQL{Query SQL} un esempio di blocco SQL: Ticket.IDResource IN (EXECSQL{SELECT IDTecnico FROM TABPersonale WHERE ISNULL(Administrator, 0) =1})

  • Esiste l’operatore IsInWorkHour che verifica se l’ora che gli viene passata come parametro corrisponde al workhour del livello di servizio, per applicare la funzione alla data di apertura del ticket bisognerà scrivere: IsInWorkHour(Ticket.Date; Ticket; WorkHour), mentre per applicarla all’ora in cui è scattato l’evento: IsInWorkHour(TicketModification.Date; Ticket; WorkHour) nel primo caso, al verificarsi dell’evento, viene verificato se l’ora in cui è stato aperto il ticket corrisponde all’orario lavorativo del livello di servizio, in caso affermativo applicherà il livello di servizio. Si può associare tale funzione ad altre condizioni con gli operatori logici, es.: Ticket.IDTicketStatus = “S1” AND IsInWorkHour(TicketModification.Date;Ticket; WorkHour) da notare che i parametri sono separati dal punto e virgola “;” (E’ una regola del componente flee) e gli ultimi due parametri devono SEMPRE essere Ticket e WorkHour
  • Esiste l’operatore IsInCalendar che verifica se una certa data soddisfa delle determinate regole. 
    Ad esempio, per inserire una regola che verifica se l’evento è scattato tra gennaio e settembre la regola sarà: IsInCalendar(TicketModification.Date; "DATECOMPARISON"; "--/01/----"; "--/09/----"; "") 
    oppure per verificare se il ticket è stato aperto in agosto: 
    IsInCalendar(Ticket.Date; "DATECOMPARISON"; "--/08/----"; "--/08/----"; ""). 

    Il primo parametro contiene la data da comparare, il secondo parametro è il tipo di confronto e va lasciato fisso a “DATECOMPARISON”, per ora l’unico implementato è questo, le date vanno inserite a lunghezza e posizioni fisse: i primi due caratteri per il giorno, e secondi due per il mese, i terzi quattro per l’anno, il separatore è libero. Per non specificare una parte della data vanno inseriti i trattini “--“ , l’ultimo parametro per ora va lasciato vuoto “”, servirà in futuro per passare dei parametri ai nuovi tipi di confronto.
    • Le regole possono essere definite anche sulle Caratteristiche definendo il campo completo su cui si va ad eseguire la verifica tra parentesi angolari “<Ticket.Characteristics.CharacteristicName>”, “<Task.Characteristics.CharacteristicName>”, “<Action.Characteristics.CharacteristicName>”, al posto di CharacteristicName andrà messo o il nome o l’id della caratteristica, ad esempio se si vuole costruire una regola sulla caratteristica del ticket denominata “NumerazioneCliente” bisognerà scrivere: <Ticket.Characteristics.NumerazioneCliente> = “Numerazione” 
      Si possono anche verificare caratteristiche degli oggetti collegati all’oggetto di base, come ad esempio

“<Ticket.OwnerGroup.Characteristics.SecondoLivello>”

  • Si può utilizzare l’operatore IN separando i vari elementi da considerare con la virgola, ad esempio:

Ticket.IDResourceOrGroup IN (“G1C”, “G2C”, “G3C”)