Arbeiten mit Ticket-Ticket-Relationen
Einleitung
Relationen zwischen Tickets können Ihnen helfen, Ihren Geschäftsprozess sehr effizient zu modellieren.
ConSol CM bietet drei Arten von Relationen:
- Einfache Ticketrelationen
Nicht hierarchisch, einfache Referenz. Jedes Ticket kann eine beliebige Anzahl an Referenzen haben.
Eine einfache Ticketrelation kann von einem Bearbeiter im Web Client hergestellt werden oder von einem Programmierer über die ConSol CM-Programmierschnittstelle.
In beiden Fällen kann eine Referenz nur zwischen zwei vorhandenen Tickets hergestellt werden. - Master-Slave-Relationen
Hierarchisch. Ein Master-Ticket kann mehrere Slave-Tickets haben. Ein Slave-Ticket hat immer genau ein Master-Ticket.
Diese Struktur kann von einem Bearbeiter im Web Client hergestellt werden oder von einem Programmierer über die ConSol CM-Programmierschnittstelle.
Eine Master-Slave-Relation kann nur zwischen zwei vorhandenen Tickets hergestellt werden, d. h. beide Tickets müssen zuerst existieren und dann kann eine Master-Slave-Relation hergestellt werden, um sie zu verbinden. - Parent-Child-Relationen
Hierarchisch. Ein Parent-Ticket kann mehrere Child-Tickets haben. Ein Child-Ticket hat immer genau ein Parent-Ticket.
Diese Struktur kann nur über die ConSol CM-Programmierschnittstelle hergestellt und verändert werden.
Eine Parent-Child-Relation kann zwischen vorhandenen Tickets hergestellt werden. Zudem kann ein neues Child-Ticket während des Prozesses erstellt werden.
Abbildung 156: ConSol CM-Relationstypen
In diesem Abschnitt wird nicht erklärt, wie man Ticketrelationen im Web Client erstellt. Dies ist detailliert im ConSol CM Benutzerhandbuch beschrieben. Im vorliegenden Abschnitt zeigen wir Ihnen, wie man Relationen über die Programmierschnittstelle, in Workflow-Skripten, herstellt.
In der ConSol CM-Workflow-API wird der Referenztyp durch die Klasse (enum) com.consol.cmas.common.model.ticket.TicketRelationType abgebildet. Diese hat drei Werte:
- REFERENCE
- MASTER_SLAVE
- PARENT_CHILD
Einfache Ticketrelation ohne Hierarchie
Dieser Relationstyp kann hilfreich sein, wenn Sie Referenzen erzeugen möchten, die Ihnen helfen, die mit einem Ticket verbundenen Tickets einfacher zu finden als in einer Suche.
Beispiele für Anwendungsfälle sind:
- Wenn ein neues Ticket erstellt wird, möchten Sie sehen, ob es andere offene Tickets des gleichen Kunden gibt. Wenn ja, erstellen Sie eine Relation zwischen den Tickets. Auf diese Weise kann ein Bearbeiter schnell von einem offenen Tickets des Kunden zum nächsten wechseln.
- Wenn ein neues Ticket für eine bestimmte Hardware-Kategorie erstellt wird, möchten Sie Referenzen zu allen anderen Tickets des gleichen Hardware-Typs herstellen.
Dieser Relationstyp kann entweder mit dem Web Client oder der Programmierschnittstelle hergestellt und geändert werden. Eine Relation des Typs REFERENCE kann also innerhalb eines Workflow-Skripts hergestellt werden und dann von einem Bearbeiter im Web Client geändert werden, sofern dieser die erforderlichen Zugangsberechtigungen hat.
Beispiel: Erstellen einer einfachen Relation zwischen zwei Tickets
workflowApi.addRelation(TicketRelationType.REFERENCE, "This is a very important relation", pSourceTicketId, pTargetTicketId)
Code-Beispiel 71: Erstellen einer Ticketrelation des Typs REFERENCE mit der workflowAPI
Syntax: Suchen aller referenzierten Tickets
ConSol CM-Versionen 6.10.4.0 und höher
List<Ticket> mytickets = workflowApi.getReferencedTickets()
Master-Slave-Relationen
Dieser Relationstyp kann hilfreich sein, wenn Sie eine Hierarchie zwischen einer bestimmten Anzahl an vorhandenen Tickets erzeugen möchten. Denken Sie daran, dass dieser Relationstyp sowohl im Web Client als auch über die Programmierschnittstelle hergestellt werden kann. An dieser Stelle wird allerdings nur der Programmieransatz erklärt.
Beispiele für Anwendungsfälle sind:
- In einer Firma gibt es mehrere Projekte, die jeweils durch ein Ticket abgebildet werden. Wenn die Entscheidung getroffen wird, eines der Projekte in ein übergreifendes Programm zu integrieren (das ebenfalls durch ein Ticket abgebildet wird), klickt der Projektmanager auf die Workflow-Aktivität In Programm integrieren. Dabei muss das richtige Programm ausgewählt werden (z. B. in einem ACF). Im Skript der Workflow-Aktivität In Programm integrieren wird das Programmticket als Master-Ticket des aktuellen Projekttickets gesetzt.
- In einem Service-Team werden verschiedene Produkte verwaltet. Für jedes Produkt gibt es ein Produktticket. Wenn ein neues Service-Ticket erstellt wird, klickt der Bearbeiter auf die Aktivität Produkt setzen, mit der er das verknüpfte Produkt aus einem Drop-down-Menü auswählen kann. Im Workflow-Skript der Aktivität Produkt setzen wird das Service-Ticket automatisch als Slave des Produkttickets gesetzt.
Eine Master-Slave-Relation kann entweder mit dem Web Client oder der Programmierschnittstelle hergestellt und geändert werden. Eine Relation des Typs MASTER_SLAVE kann also innerhalb eines Workflow-Skripts hergestellt werden und dann von einem Bearbeiter im Web Client geändert werden, sofern dieser die erforderlichen Zugangsberechtigungen hat. Verwenden Sie die Struktur Parent-Child, wenn Sie sicherstellen möchten, dass kein Bearbeiter die Tickethierarchie verändern kann.
Beispiel: Erstellen einer Master-Slave-Relation zwischen zwei Tickets
//in this script the project ticket (= current ticket) is set as slave ticket to
// the program ticket which becomes the master
// fetch the program ticket ID. The ID of the program ticket is already stored
// in a CF in the project (=current) ticket
def progTicketId = ticket.get("ReferencesFields.ProgramTicketId")
// fetch ID of current ticket (which will become the slave)
def mySlaveProjectId = ticket.id
workflowApi.addRelation(TicketRelationType.MASTER_SLAVE, "Slave Ticket: This project is part of the program indicated in the master ticket", progTicketId, mySlaveProjectId)
Code-Beispiel 72: Erstellen einer Ticketrelation des Typs MASTER_SLAVE unter Verwendung von workflowAPI
Syntax: Finden aller Slave-Tickets
ConSol CM-Versionen 6.10.3.x und niedriger
// the ticket can be set, might be current ticket or another ticket
List<Ticket> mytickets = workflowApi.getTargetTickets(myTicket.getId(), TicketRelationType.MASTER_SLAVE)
Code-Beispiel 73: Version A: Finden aller Ziel-Tickets (hier: alle Slave-Tickets)
// used for current ticket
List<Ticket> mytickets = workflowApi.getTargetTickets(TicketRelationType.MASTER_SLAVE)
Code-Beispiel 74: Version B: Finden aller Ziel-Tickets (hier: alle Slave-Tickets)
ConSol CM-Versionen 6.10.4.0 und höher
List<Ticket> mytickets = workflowApi.getSlaveTickets()
Code-Beispiel 75: Finden aller Slave-Tickets des aktuellen Tickets
Syntax: Finden des Master-Tickets
ConSol CM-Versionen 6.10.4.0 und höher
def mticket = workflowApi.getMasterTicket()
Code-Beispiel 76: Finden des Master-Tickets des aktuellen Tickets
Parent-Child-Relationen
Dieser Relationstyp kann hilfreich sein, wenn Sie eine Hierarchie zwischen einer bestimmten Anzahl an Tickets erzeugen möchten, die nicht manuell verändert werden kann.
Beispiele für Anwendungsfälle sind:
- Ein Projekt soll von einem Projektmanagement-Ticket verwaltet werden, das das Parent-Ticket ist. Alle Aufgaben innerhalb des Projekts werden als Child-Tickets abgebildet. Diese Struktur wird beim Einrichten des Projekttickets automatisch von einem Workflow-Skript erstellt.
- Es ist eine Systemmigration geplant, die ein Parent-Ticket verwendet. Für jede Komponente, die migriert werden muss, wird ein Child-Ticket erstellt. Diese Struktur wird beim Einrichten des Projekttickets automatisch von einem Workflow-Skript erstellt.
Der Relationstyp PARENT_CHILD kann nur über die Programmierschnittstelle hergestellt und geändert werden. Daher kann eine Relation dieses Typs in einem Workflow-Skript hergestellt werden und danach nur durch andere Skripte geändert werden.
Beispiel 1: Erstellen eines neuen Child-Tickets als Child des aktuellen Tickets
// this script creates a ticket for a task which will be child ticket
// of a project ticket (which will be the parent)
// create a new ticket, which will become the task (=child) ticket
Ticket newTask = new Ticket()
// fetch the subject of the parent-to-be ticket, i.e. of the current ticket
def subj = ticket.subject
// or longer: def subj = ticket.getSubject()
// set the subject of the new task (= child) ticket
newTask.setSubject("New Task for project " + subj)
// put the task (= child) ticket into the tasks queue
def tasksQueue = queueService.getByName("Tasks")
newTask.setQueue(tasksQueue)
// Initially, the new task ticket will not have an engineer
newTask.setEngineer(null)
// define the ticket text, i.e. the first comment in the new task ticket
def taskTicketText = "Please work on this task asap"
// the contact for the new task ticket should be the same as the one for the project ticket:
def taskContact = workflowApi.getPrimaryContact()
//create PARENT_CHILD relation between project (parent) and task (child)
workflowApi.createChildTicket(newTask, taskTicketText, taskContact)
Code-Beispiel 77: Erstellen eines Child-Tickets
Beispiel 2: Finden des Parent-Tickets eines Tickets
def my_parent = workflowAPI.getParentTicket()
Code-Beispiel 78: Finden des Parent-Tickets eines Tickets
Beispiel 3: Finden aller Child-Tickets eines Tickets
// only works for current ticket:
List<Ticket> my_childtickets = workflowApi.getChildTickets()
Code-Beispiel 79: Finden aller Child-Tickets eines Tickets
Beispiel 4: Finden aller Brother-Tickets (andere Child-Tickets) des gleichen Parent-Tickets
// only works for current ticket:
List<Ticket> my_brothers = workflowApi.getBrotherTickets()
Code-Beispiel 80: Finden aller Brother-Tickets eines Child-Tickets
Wichtige Methoden für die Arbeit mit Ticketrelationen
Beachten Sie folgende Regeln bei der Arbeit mit Ticketrelationen:
- Bei MASTER_SLAVE-Relationen ist der Master immer die Quelle.
- Bei PARENT_CHILD-Relationen ist der Parent immer die Quelle.
- Bei einfachen REFERENCE-Relationen ist die Quelle das Ticket, aus dem die Relation erstellt wird.
WorkflowApi-Methoden
Die folgenden Methoden sind Methoden der Klasse WorkflowContextService, die implizit als Objekt workflowApi in Workflow-Skripten verfügbar ist.
|
Methode von workflowApi (workflowContextService) |
Erklärung |
|---|---|
|
Ticket createChildTicket(Ticket pTicket, String pTicketText, Unit pCustomer) |
Erstellt ein neues Child-Ticket. Queue und Ticketfelder müssen richtig gesetzt werden. |
|
List<Ticket> getChildTickets() |
IntSet, das die Ticketobjekte der Child-Tickets des aktuellen Tickets enthält. |
|
List<Ticket> getBrotherTickets() |
IntSet, das die Ticketobjekte der Brother-Tickets des aktuellen Tickets enthält. |
|
Ticket getParentTicket() |
Ticket-Objekt des Parent-Tickets oder null, wenn das aktuelle Ticket kein Parent-Ticket hat. |
|
List<Ticket> getTargetTickets(TicketRelationType pType) |
Ruft eine Liste mit Ticket-Objekten ab, zu denen das aktuelle Ticket Relationen eines bestimmten Typs hat. Für diese Relationen ist das aktuelle Ticket das Quellticket. |
|
List<Ticket> getTargetTickets(long pTicketId, TicketRelationType pType) |
Ruft eine Liste mit Ticket-Objekten ab, zu denen das aktuelle Ticket Relationen eines bestimmten Typs hat. Für diese Relationen ist das mit pTicketId angegebene Ticket das Quellticket. |
|
List<Ticket> getSourceTickets(TicketRelationType pType) |
Ruft eine Liste mit Ticket-Objekten ab, zu denen das aktuelle Ticket Relationen eines bestimmten Typs hat. Für diese Relationen ist das aktuelle Ticket das Zielticket. |
|
List<Ticket> getSourceTickets(long pTicketId, TicketRelationType pType) |
Ruft eine Liste mit Ticket-Objekten ab, zu denen das aktuelle Ticket Relationen eines bestimmten Typs hat. Für diese Relationen ist das angegebene Ticket das Zielticket. |
|
boolean hasTargetTickets(TicketRelationType pType) |
Prüft, ob das Ticket Zieltickets hat. Prüft, ob es Relationen gibt, bei denen dieses Ticket das Quellticket ist. |
|
boolean hasTargetTickets(long pTicketId, TicketRelationType pType) |
Prüft, ob das angegebene Ticket Zieltickets hat. Prüft, ob es Relationen gibt, bei denen dieses Ticket das Quellticket ist. |
|
boolean hasSourceTickets(TicketRelationType pType) |
Prüft, ob das Ticket Quelltickets hat. Prüft, ob es Relationen gibt, bei denen dieses Ticket das Zielticket ist. |
|
boolean hasSourceTickets(long pTicketId, TicketRelationType pType) |
Prüft, ob das angegebene Ticket Quelltickets hat. Prüft, ob es Relationen gibt, bei denen dieses Ticket das Zielticket ist. |
|
void changeSourceTickets(TicketRelationType pType, long pTargetTicketId, List<Long> pSourceTicketIds) |
Für das Zielticket (z. B. ein Child-Ticket) werden die Relationen eines angegebenen Typs (z. B. PARENT_CHILD) entfernt. Für den gleichen Relationstyp wird eine neue Relation mit den angegebenen Quelltickets erstellt. |
|
void changeTargetTickets(TicketRelationType pType, long pSourceTicketId, List<Long> pTargetTicketsIds) |
Für das angegebene Quellticket werden alle Relationen des angegebenen Typs entfernt. Für die Liste der angegebenen Zieltickets werden neue Relationen des angegebenen Typs erstellt. |
|
void removeRelation(TicketRelationType pType, long pSourceTicketId, long pTargetTicketId) |
Entfernt die Ticketrelation zwischen zwei Tickets mit dem angegebenen Typ. |
|
void addRelation(TicketRelationType pType, String pComment, long pSourceTicketId, long pTargetTicketId) |
Fügt eine Relation des angegebenen Typs zwischen Ticket sourceTicketId und targetTicketId hinzu. |
|
Ticket getMasterTicket() |
Verfügbar ab CM-Version 6.10.4.0 Gibt das Master-Ticket des aktuellen Tickets zurück. |
|
List<Ticket> getSlaveTickets() |
Verfügbar ab CM-Version 6.10.4.0 Gibt eine Liste aller Slave-Tickets des aktuellen Tickets zurück. |
|
List<Ticket> getReferencedTickets() |
Verfügbar ab CM-Version 6.10.4.0 Gibt eine Liste aller Tickets zurück, die eine einfache Referenzrelation zum aktuellen Ticket haben. |
Tabelle 1: Wichtige Methoden von workflowAPI für die Arbeit mit Ticketrelationen
TicketRelationService Methods
Wenn Sie im Admin Tool mit Skripten arbeiten (die dann aus einem Workflow-Skript aufgerufen werden), ist workflowApi nicht verfügbar. Sie können Methoden der Klasse TicketRelationService, die als Singleton ticketRelationService verfügbar ist, verwenden.
| Methode von ticketRelationService | Erklärung |
|---|---|
| List<TicketRelation> getByTicket(Ticket pTicket, TicketRelationDirection pTicketRelationEnd, TicketRelationType... pRelationType) | Ruft eine Liste aller Ticketrelationen für ein angegebenes Ticket ab, eingeschränkt durch die Richtung der Relation (ANY|SOURCE|TARGET) und den Relationstyp (MASTER_SLAVE|PARENT_CHILD|REFERENCE ) |
| Set<TicketRelation> getByTickets(Set<Ticket> pTickets, TicketRelationDirection pTicketRelationEnd, TicketRelationType... pRelationType) | Ruft den Satz aller Ticketrelationen für einen angegebenen Satz an Tickets ab, eingeschränkt durch die Richtung der Relation (ANY|SOURCE|TARGET) und den Relationstyp (MASTER_SLAVE|PARENT_CHILD|REFERENCE ) |
Tabelle 2: Wichtige Methoden von TicketRelationService für die Arbeit mit Ticketrelationen
Beispiel mit Methoden aus workflowApi und ticketRelationService
// use wflApi:
println 'Displaying slave tickets from wfl script ...'
List<Ticket> slave_tics = workflowApi.getSlaveTickets()
slave_tics?.each(){ st ->
log.info ' Slave Ticket is now ' + st.getId() + ' -- ' + st.getSubject()
}
Code-Beispiel 81: Beispielskript, zeigt IDs und Namen der Slave-Tickets an, Workflow-Version
// DisplaySlaveTickets.groovy
// use in AT:
import com.consol.cmas.common.service.*
import com.consol.cmas.common.model.ticket.TicketRelation
import com.consol.cmas.common.model.ticket.TicketRelationDirection
import com.consol.cmas.common.model.ticket.TicketRelationType
println 'Displaying slave tickets from AT script ...'
def ticket = workflowApi.getTicket()
List<TicketRelation> t_rel = ticketRelationService.getByTicket(ticket, TicketRelationDirection.ANY, TicketRelationType.MASTER_SLAVE)
t_rel?.each(){ tr ->
log.info 'Source ticket is now ' + tr.sourceTicket.id + ' -- ' + tr.sourceTicket.subject
log.info 'Target ticket is now ' + tr.targetTicket.id + ' -- ' + tr.targetTicket.subject
}
Code-Beispiel 82: Beispielskript, zeigt IDs und Namen der Slave-Tickets an, Admin-Tool-Skriptversion
scriptExecutionService.execute("DisplaySlaveTickets.groovy")
Code-Beispiel 83: Aufrufen des obigen Admin-Tool-Skripts aus einer Workflow-Aktivität