04. 08. 2016 Benjamin Gröber Uncategorized

Advanced Service Dispatcher

bild

Der Service Dispatcher ist ein nützliches Tool um Tickets dem richtigen Kompetenzzentrum (Queue) zuzuweisen. Dies erfolgt anhand des ausgewählten Ticket-Service und des Unternehmens (Kunde) welche das Ticket erstellt hat.
Der neue Advanced Service Dispatcher erlaubt nun die volle Kontrolle über die Ausführungsreihenfolge zu übernehmen und nach zusätzlichen Bedingungen zu filtern. Zusätzlich können nun Regular Expressions auf die Filter für Ticket-Service und dynamische Felder angewandt werden. Dadurch kann die maximal benötigte Anzahl von Service Dispatchern auf ein Minimum reduziert werden.

Nach dynamischen Feldern filtern

Eines der interessantesten neuen Features ist die Möglichkeit, nach dem Wert eines ausgewählten dynamischen Feldes zu filtern. Dies ermöglicht mehrere neue Strategien, um Service-Dispatcher zu erstellen. Eine Möglichkeit besteht darin das Dispatching von Tickets über ein dynamisches Feld überhaupt erst zuzulassen. Hierfür wird ein dynamisches Feld z.B. „Dispatch“ mit zwei Auswahlmöglichkeiten (ja/nein) definiert.  Jene Tickets wo das dynamische Feld auf „Ja“ steht werden automatisch dem im Dispatcher konfigurierten Kompetenzzentrum zugewiesen und wir haben unser Ziel erreicht.

dyn_field

Eine weitere Herangehensweise kann sein, nach bereits bestehenden dynamischen Feldern wie z.B. „Kategorie“ zu filtern und somit die -Granularität zu erhöhen (z.B. pro Kategorie ein Dispatcher). Da die Konditionen der dynamischen Felder Reguläre Ausdrücke sind, können unterschiedliche Werte eines dynamischen Feldes in einem Service-Dispatcher gruppiert werden. (e.g. ^Incident|^Service\sRequest or ^\[01\d+\]\sBusinessApplication was mehreres einschließt wie  ‘[01X] BusinessApplication::NextLevel’ wobei X für jede beliebige Zahlenserie steht)

*Bitte beachten Sie, dass Sie bei der Verwendung von Regulären Ausdrücken die folgenden Zeichen “escapen” müssen, um korrekte Ergebnisse zu erhalten..
\ . [ ] { } ( ) * + – ? ^ $ |

Die Wahl der richtigen Dispatching-Strategie

Mit den neuen Möglichkeiten, die Services durch Regular Expressions oder den anfragenden Unternehmen zuzuweisen, ist es möglich, einen Service-Dispatcher für jede Queue, jeden Service und jeden Kunden zu definieren. Meiner Erfahrung nach ist in den meisten Fällen nur eine sehr begrenzte Anzahl von Service-Dispatchern notwendig, da Tickets von verschiedenen Kunden, jedoch in Bezug auf denselben Service, meist sowieso in die selbe Queue gehören.

Die Erfahrung hat auch gezeigt, dass das System sehr ordentlich und übersichtlich bleibt, wenn wir nur von einer Source-Queue „[N] Dispatcher“ ausgehen und dabei die Ausnahmen zuerst abarbeiten und dann den ganzen großen Rest in wenigen einfachen Service-Dispatchern den jeweiligen Queues zuweisen.

Beispiel

{Vereinfachte Situation}

Kunden: Company1, Company2 und Company3
Services: Hardware::Malfunction, Hardware::Replacement, Hardware::ServiceRequest
Queues: [N]Dispatcher, [0]ServiceDesk, [0]ServiceDesk::External
Alle Tickets zu einem Hardware Service sollen der Queue [0]ServiceDesk zugewiesen werden, außer jene vom Kunden Company1 da dieser Hardware eines Drittanbieters beziehen.

Die Service Regular Expression könnte so aussehen: ^Hardware

Variante A: Wir können alle Tickets (aller Kunden) der Queue [0]ServiceDesk zuweisen.
Dann einen zweiten Dispatcher mit Source-Queue [0]ServiceDesk erstellen
und alle Tickets vom Kunden Company1 der Queue[0]ServiceDesk::External
zuweisen. In diesem Fall haben wir jedoch mehrere Source-Queues.

Dies ist durchaus möglich, bei diesem Vorgehen wird aber sehr bald der Verlauf der Tickets nicht mehr genau nachvollziehbar bzw. verwirrend sein. Bei mehreren Wiederholungen laufen wir Gefahr in einer Endlosschleife zu enden.

Variante B: Es ist sehr viel übersichtlicher und daher empfehlenswert, zwei Service Dispatcher mit einer einzigen Source-Queue zu definieren [N]Dispatcher.
Der erste Dispatcher für Company1 und ^Hardware Service an [0]ServiceDesk::External
Der zweite Dispatcher für <ANY> Kunden und ^Hardware Service an [0]ServiceDesk.

Benjamin Gröber

Benjamin Gröber

R&D Software Architect at Wuerth Phoenix
Hi, my name is Benjamin, and I'm Software Architect in the Research & Development Team of the "IT System & Service Management Solutions" Business Unit of Würth Phoenix. I discovered my passion for Computers and Technology when I was 7 and got my first PC. Just using computers and playing games was never enough for me, so just a few months later, started learning Visual Basic and entered the world of Software Development. Since then, my passion is keeping up with the short-lived, fast-paced, ever-evolving IT world and exploring new technologies, eventually trying to put them to good use. I'm a strong advocate for writing maintainable software, and lately I'm investing most of my free time in the exploration of the emerging Rust programming language.

Author

Benjamin Gröber

Hi, my name is Benjamin, and I'm Software Architect in the Research & Development Team of the "IT System & Service Management Solutions" Business Unit of Würth Phoenix. I discovered my passion for Computers and Technology when I was 7 and got my first PC. Just using computers and playing games was never enough for me, so just a few months later, started learning Visual Basic and entered the world of Software Development. Since then, my passion is keeping up with the short-lived, fast-paced, ever-evolving IT world and exploring new technologies, eventually trying to put them to good use. I'm a strong advocate for writing maintainable software, and lately I'm investing most of my free time in the exploration of the emerging Rust programming language.

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive