Il classico Service Dispatcher serve per assegnare i ticket al loro corretto centro di competenza (coda/queue), grazie ad un primo sguardo al servizio del ticket (service) e al cliente che ha aperto il ticket.
Il nuovo Advanced Service Dispatcher permette di utilizzare ulteriori campi come filtro e garantisce un controllo totale sull’ordine di esecuzione. Oltre a questo è possibile adesso utilizzare Regular Expression Matching per i Servizi e i campi dinamici. In questo modo è possibile avere un set minimo necessario di Service Dispatcher.
Filtrare per valori di campi dinamici
Una delle funzionalità più interessanti è la possibilità di filtrare per il valore di un determinato campo dinamico, il che permette di applicare diverse strategie per la creazione dei Service Dispatcher. Abbiamo la possibilità di permettere/negare il dispatching per certi ticket tramite un dynamic field il quale potrebbe essere chiamato per esempio “dispatch” e che può contenere i due possibili valori si/no. Se tutti i ticket che devono essere “dispatched” contengono in questo campo un “si”, abbiamo già raggiunto il nostro obiettivo.
Un’altra strategia potrebbe essere di filtrare per un campo dinamico già presente nel Ticket, come per esempio la categoria (Category). Siccome le condizioni del Dynamic Fild sono Regular Expressions, noi possiamo raggruppare facilmente multipli valori di un campo dinamico in un unico Service Dispatcher (per esempio: ^Incident|^Service\sRequest oppure ^\[01\d+\]\sBusinessApplication, potranno matcharsi con qualsiasi serie numerica X ‘[01X] BusinessApplication::NextLevel’)
*ricorda che lavorare con Regular Expressions obbliga fare l´”escaping” dei seguenti caratteri: \ . [ ] { } ( ) * + – ? ^ $ |
Segliere una strategia di creazione
Grazie alla possibilità di abbinare servizi con Regular Expressions e di applicare un Service Dispatcher a tutti i clienti, è ora possibile arrivare a un singolo Service Dispatcher per Destination Queue, Service e Company. Personalmente trovo che nella maggior parte dei casi sia necessario solo un set molto limitato di Service Dispatcher, in quanto molto spesso i ticket aperti da aziende diverse ma con lo stesso servizio devono finire nella stessa coda.
La nostra esperienza ha mostrato che il sistema diventa più semplice se si inizia con una sola Source Queue ‘[N] Dispatcher’, trattando per prima le eccezioni, e per ultimo inviare il resto dei ticket con pochi Service Dispatcher alle rispettive Destination Queues.
Esempio
{Situazione semplificata}
Clienti: Company1, Company2 e Company3
Servizi: Hardware::Malfunction, Hardware::Replacement, Hardware::ServiceRequest
Queues: [N]Dispatcher, [0]ServiceDesk, [0]ServiceDesk::External
Ogni ticket con service Hardware deve essere spostato nella coda [0]ServiceDesk tranne la Company1 in quanto utilizzano Hardware di una terza parte.
La Service Regular Expression quindi si può presentare così: ^Hardware
Alternativa A: Possiamo spostare tutti i ticket di ogni cliente su [0]ServiceDesk
E creiamo un secondo Service Dispatcher con il Source Queue [0]ServiceDesk
che sposta solo i ticket della Company1 nella Queue [0]ServiceDesk::External
Così abbiamo però multiple Source Queues.
Ovviamente l´utilizzo di molteplici Source Queue diventa velocemente ingestibile e potrebbe avere come rovescio il crearsi di un loop infinito.
Alternativa B: Per tale motivo suggerisco di creare due Service Dispatcher con Source Queue [N]Dispatcher.
Una per la Company1 e ^Hardware Service a [0]ServiceDesk::External
La seconda <ANY> company e ^Hardware Service a [0]ServiceDesk.
Benjamin Gröber
Author
