Eine Aktivität stellt eine Aktion im Workflow dar. Eine Aktivität befindet sich in einem Bereich und hat einen der folgenden Typen:
Mit manuellen und automatischen Aktivitäten können Sie einen relativ strengen Geschäftsprozess modellieren, in dem der Bearbeiter für das Ticket einem der vorgegebenen Pfade folgen muss. Mit Bereichsaktivitäten können Sie flexiblere Prozesse modellieren und das CM-System für Case Management vorbereiten, bei dem ein Bearbeiter je nach Bedarf dynamisch reagieren kann.
Eine manuelle Aktivität muss durch eine manuelle Aktion des Bearbeiters im Web Client erfolgen. Die Aktivität wird im Web Client als Workflow-Aktivität angezeigt (sofern mindestens eine der Rollen des Bearbeiters die Berechtigung Ausführen hat (siehe ConSol CM Administratorhandbuch, Abschnitt Rollenverwaltung). Im Process Designer ist die Aktivität mit dem Icon Hand gekennzeichnet.
Abbildung 40: ConSol CM Process Designer - Manuelle Aktivität im Workflow
Abbildung 41: ConSol CM Web Client - Manuelle Aktivität
Eine automatische Aktivität wird automatisch vom System durchgeführt und nicht im Web Client angezeigt. Im Process Designer ist eine automatische Aktivität nicht mit einem speziellen Icon gekennzeichnet.
Abbildung 42: ConSol CM Process Designer - Automatische Aktivitäten
Eine Bereichsaktivität befindet sich in einem Bereich und hat keine eingehenden Verbindungen aus anderen Aktivitäten. Im Web Client ist eine Bereichsaktivität so lange verfügbar, wie sich das Ticket innerhalb des Bereiches befindet. Dies gilt auch für alle untergeordneten Bereiche. Eine Bereichsaktivität kann Folgeaktivitäten haben (dann führt sie zu einer Prozess-Exception), oder eine Aktivität ohne Folgeaktivitäten sein (dann führt sie zu einem Interrupt). Weitere Informationen über Interrupts und Exceptions finden Sie im Abschnitt Interrupts und Exceptions).
Beachten Sie, dass ein Ticket einen Bereich nicht unbedingt verlässt, wenn die "letzte" Aktivität in diesem Bereich ausgeführt wurde. Weitere Informationen zu diesem Thema finden Sie im Abschnitt Aktivitäten.
Abbildung 43: ConSol CM Process Designer - eine Bereichsaktivität (verfügbar in den Bereichen "Vorgang in Arbeit im Serviceteam" und "Wiedervorlage"
Der Eigenschaften-Editor ist für das Element geöffnet, das im Hauptarbeitsbereich ausgewählt wurde. Er enthält komponentenspezifische Parameter. Einige allgemeine Parameter sind für alle Komponenten sichtbar, manche sind nur für einen bestimmten Komponententyp vorhanden.
Abbildung 44: ConSol CM Process Designer - Ausgewählte Aktivität im Workflow
Abbildung 45: ConSol CM Process Designer - Eigenschaften-Editor
Eigenschaften:
Abbildung 46: ConSol CM Process Designer - Lokalisierung für Bezeichnungen
Abbildung 47: ConSol CM Process Designer - Lokalisierte Beschreibung einer Aktivität
Abbildung 48: ConSol CM Web Client - Lokalisierte Beschreibung einer Aktivität als Mouseover
Abbildung 49: ConSol CM Process Designer - Eigenschaften-Editor: Standard-Overlays und ein kundenspezifisches Overlay
Abbildung 50: ConSol CM Web Client - Ticket-Icons mit Overlays
Wenn es für einen Anwendungsfall nicht ausreicht, ein Overlay mithilfe der Overlay-Gültigkeit zu setzen oder zu entfernen, können Sie ein Workflow-Skript verwenden. Details dazu finden Sie im Abschnitt Arbeiten mit Overlays.
Wichtiger Hinweis zu Kundenfeldern
Wenn Sie mit Kundenfeldern arbeiten, d. h. mit Datenfeldern, die Kundendaten enthalten, sollten Sie daran denken, dass möglicherweise die Datenmodelle von unterschiedlichen Kundengruppen berücksichtigt werden müssen, wenn ein Workflow für Queues verwendet wird, denen mehr als eine Kundengruppe zugewiesen ist!
Dies bezieht sich auf den im Admin Tool unter Ticketprotokoll für die Aktivitätskonfiguration definierten Wert. Je nach Aktivitätstyp wird einer der folgenden Parameter verwendet:
Abbildung 51: ConSol CM Web Client - Sichtbarkeitslevel im Ticketprotokoll
Für Kunden freigeben
Boolean. Nur für manuelle Aktivitäten verfügbar. Wenn aktiviert (d. h. auf true gesetzt), wird die Aktivität als Workflow-Aktivität im ConSol CM-Portal CM/Track angezeigt. Die Aktivität wird in CM/Track angezeigt, wenn keine Bedingung vorhanden ist oder das Bedingungsskript true zurückgibt. Wenn ein ACF (Aktivitätsformular) für die Aktivität gesetzt ist, wird dieses ebenfalls angezeigt. Ein Beispiel für ein ACF in CM/Track finden Sie im Abschnitt ACFs in CM/Track.
Abbildung 52: ConSol CM Process Designer - Zwei Aktivitäten, die in CM/Track für Kunden angezeigt werden sollen ("für Kunden freigegeben")
Abbildung 53: CM/Track (d. h. Kundenperspektive) - Zwei Aktivitäten, die in CM/Track für Kunden angezeigt werden ("für Kunden freigegeben")
Folgende Prozesslogik gilt für Aktivitäten:
Sofern die Aktivität ein ACF hat, muss auch die Geschäftslogik von ACFs berücksichtigt werden.
Eine Bereichsaktivität hat keine eingehenden Verbindungen, kann aber Folgendes haben:
Wenn eine Bereichsaktivität ausgeführt wurde, hängt die neue Position des Tickets von der Workflow-Topologie ab:
Ein Ticket wartet immer nach der letzten Aktivität, die ausgeführt wurde, und nicht vor der nächsten Aktivität!
Das ist zum Beispiel bei der Definition von Sichten relevant: Es ist wichtig zu wissen, dass das Ticket möglicherweise noch nicht in den nächsten Bereich gelaufen ist, weil es noch nach der vorherigen Aktivität im aktuellen Bereich wartet.
Falls ein Ticket von einem VIP-Kontakt geöffnet wurde, d. h. von einem Kontakt, bei dem das Boolean-Feld vip auf true gesetzt ist, soll die Teamleitung informiert werden. Wenn er kein VIP ist, soll die Aktivität nicht angeboten werden. Dafür wird das Kundenfeld vip, das zum Kundendatenmodell gehört, geprüft.
Abbildung 54: ConSol CM Process Designer - Workflow-Aktivitäten (eine mit Bedingungsskript)
import com.consol.cmas.core.server.service.*
import com.consol.cmas.common.model.customfield.meta.UnitDefinitionType
def ticket = workflowApi.ticket
// fetch main contatc of the ticket
def maincontact = ticket.getMainContact()
def unit_type = maincontact.definition.type
log.info 'vipCheck: Unittype is ' + unit_type
log.info 'vipCheck: Unittype class is ' + unit_type.getClass()
if(unit_type == UnitDefinitionType.COMPANY) {
log.info 'No vipCheck for comapnies possible! Returning false ... '
return false
} else if (unit_type == UnitDefinitionType.CONTACT){
// fetch e-mail address of the man contact. The data object group field has to be addressed using data object group name:data object group field name
def vip_field
def custgroup = maincontact.customerGroup.name
log.info 'vipCheck: Customergroup is now ' + custgroup
switch(custgroup) {
case "Reseller": vip_field = "vip_person";
break;
case "DirectCustomers": vip_field = "vip_dircust"
break;
case "MyCustomerGroup": vip_field = "vip"
break;
case "OurPartnerCompanies": vip_field = "vip_partners"
break;
case "RetailCustomers": vip_field = "retail_vip"
break;
}
def vip_value = maincontact.get(vip_field)
log.info 'VIP is now ' + vip_value
if (vip_value){
return true
} else {
return false
}
}
Code-Beispiel 2: Bedingungsskript: Aktivität sollte nur für VIP-Kunden angezeigt werden
Abbildung 55: ConSol CM Admin Tool - Kundenfeld "vip" (CM-Version 6.9)
Abbildung 56: ConSol CM Web Client - Bedingung: Rückgabewert TRUE
Abbildung 57: ConSol CM Web Client - Bedingung: Rückgabewert FALSE
Wenn ein Ticket erstellt wurde, soll automatisch eine E-Mail an den Hauptkontakt des Tickets gesendet werden.
Abbildung 58: ConSol CM Process Designer - Automatische Aktivität, bei der eine Empfangsbestätigung gesendet wird
Skript in Workflow-Aktivität Eingangsbestätigung senden:
log.info'Calling SendReceiptNotice script ...'
scriptExecutionService.execute("SendReceiptNotice.groovy")
Skript SendReceiptNotice.groovy im Admin Tool:
import com.consol.cmas.common.model.mail.Mail
import com.consol.cmas.common.util.MailHeadersUtil;
import com.consol.cmas.core.server.service.*;
import static com.consol.cmas.common.util.TemplateUtil.TICKET_SUBJECT_TEMPLATE_NAME;
import com.consol.cmas.common.model.customfield.meta.UnitDefinitionType
// create new mail object
def mail = new Mail()
def ticket = workflowApi.getTicket()
// fetch main contatc of the ticket
def maincontact = ticket.getMainContact()
def unit_type = maincontact.definition.type
log.info 'Mailscript: Unittype is ' + unit_type
log.info 'Mailscript: Unittype class is ' + unit_type.getClass()
if(unit_type == UnitDefinitionType.COMPANY) {
println 'No email address for company; no receipt notice sent.'
return
} else if (unit_type == UnitDefinitionType.CONTACT){
// fetch e-mail address of the man contact. The data object group field has to be addressed using data object group name:data object group field name
def toaddress_field
def custgroup = maincontact.customerGroup.name
switch(custgroup) {
case "Reseller": toaddress_field = "email";
break;
case "DirectCustomers": toaddress_field = "dir_cust_email"
break;
case "MyCustomerGroup": toaddress_field = "email"
break;
case "OurPartnerCompanies": toaddress_field = "email"
break;
case "RetailCustomers": toaddress_field = "retail_customer_email"
break;
}
def toaddress = maincontact.get(toaddress_field)
if (!toaddress){
log.info 'No email address found for contact, no receipt notice sent.'
} else {
// put the e-mail TO address into the Mail object
mail.setTo(toaddress)
// fetch the REPLY TO address, theis is stored in a system property
def replyaddress = configurationService.getValue("cmweb-server-adapter","mail.reply.to")
// put the e-mail REPLY TO address into the Mail object
mail.setReplyTo(replyaddress)
// build e-mail text using a template which is stored in the Template Designer
def text = workflowApi.renderTemplate("Acknowledgement_of_receipt")
// put the e-mail text into the Mail object
mail.setText(text)
// create the subject of the e-mail, the ticket number with the correct Regular Expression
// has to be set for correct recognition of incoming e-mails for the ticket
// ****** alternative solutions for PD manual! *****
// solution 1:
// def ticketname = ticket.getName()
// def subject = "Your case has been registered as Ticket (" + ticketname + ")"
// solution 2: (needs import of TemplateUtil.TICKET_SUBJECT_TEMPLATE_NAME
def subject = templateService.merge(TICKET_SUBJECT_TEMPLATE_NAME, [ticketName:ticket.name])
// put the subject into the Mail object
mail.setSubject(subject)
// Mail should use the e-mail script which is configured for the queue
mail.useDefaultScript()
// send out the e-mail and register status
def attList = new ArrayList<AttachmentEntry>()
def collection = new HashSet<MailEntry>()
def mailStatus = true;
try {
mail.send();
} catch (Exception e){
mailStatus = false;
}
} // end if (!toaddress){
} // end of else if (unit_type.equals('COMPANY')){
Code-Beispiel 3: Skript für automatische Aktivität, bei der eine Empfangsbestätigung gesendet wird, Variante 1
// all lines of code identical to variant 1 except for the last line:
new Mail().setSubject( subj ).setTo( contact_e ).setReplyTo( replyto ).setText( text ).setTicketAttachments( null ).send()
Code-Beispiel 4: Skript für automatische Aktivität, bei der eine Empfangsbestätigung gesendet wird, Variante 2
Das Ticket soll dem Bearbeiter zugewiesen werden, der die Aktivität Neues IT-Ticket durchführt.
Abbildung 59: ConSol CM Process Designer - Workflow-Aktivität, bei der der Bearbeiter zugewiesen werden soll
Abbildung 60: ConSol CM Web Client - Ticket hat die Aktivität, bei der der Bearbeiter zugewiesen wird, durchlaufen
// Get the engineer who is executing the activity:
// Java Style is possible: def curr_eng = workflowApi.getCurrentEngineer()
// we use Groovy style here:
def curr_eng = workflowApi.currentEngineer
// alternative would be:
// def curr_eng = engineerService.current
// Assign the ticket to the current engineer
// Java style is possible:
ticket.setEngineer(curr_eng)
// groovy alternative would be:
// ticket.engineer = curr_eng
Code-Beispiel 5: Skript zum Zuweisen des Tickets an den aktuellen Bearbeiter
Stellen Sie sicher, dass Sie immer das richtige Bearbeiterobjekt verwenden!
Der aktuelle Bearbeiter ist der Bearbeiter, der angemeldet ist und die aktuelle Aktivität durchführt. Sie können das Objekt mit einer der folgenden Methoden abrufen.
Mit workflowApi:
// Java notation
def curr_eng = workflowApi.getCurrentEngineer()
// Groovy notation
def curr_eng = workflowApi.currentEngineer
Mit engineerService:
// Java notation:
def curr_eng = engineerService.getCurrent()
//Groovy notation
def curr_eng = engineerService.current
Der Ticketbearbeiter ist die Person, der das Ticket (zu diesem Zeitpunkt) zugewiesen ist und die für das Ticket verantwortlich ist. Sie können das Objekt mit der folgenden Methode abrufen:
//Java notation
def tic_eng = ticket.getEngineer()
//Groovy notation
def tic_eng = ticket.engineer
Die Bereichsaktivität Problem an Teamleitung weiterleiten soll während des gesamten Lebenszyklus des Tickets verfügbar sein. Bei problematischen Tickets kann der Bearbeiter eine Art Abkürzung verwenden: Das Ticket muss nicht den gesamten Prozess durchlaufen sondern kann in eine spezielle Teamleiter-Queue verschoben werden, wo sich ein Teamleiter um das Ticket kümmert.
Abbildung 61: Eine Bereichsaktivität, die während des gesamten Lebenszyklus verfügbar ist, da sie sich im globalen Bereich befindet