Thema mit Navigation öffnen

Aktivitäten

Einführung in Aktivitäten

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.

Manuelle Aktivitäten

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 32: ConSol CM Process Designer - Manuelle Aktivität im Workflow

Abbildung 33: ConSol CM Web Client - Manuelle Aktivität

Automatische Aktivitäten

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 34: ConSol CM Process Designer - Automatische Aktivitäten

Bereichsaktivitä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 35: ConSol CM Process Designer - eine Bereichsaktivität (verfügbar in den Bereichen "Vorgang in Arbeit im Serviceteam" und "Wiedervorlage"

Eigenschaften einer Aktivität

Aktivitäten haben folgende Eigenschaften:

Abbildung 36: ConSol CM Process Designer - Eigenschaftseditor

Eigenschaften:

Prozesslogik von Aktivitäten

Folgende Prozesslogik gilt für Aktivitäten:

Sofern die Aktivität ein ACF hat, muss auch die Geschäftslogik von ACFs berücksichtigt werden.

Hinweis zu Bereichsaktivitäten

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.

Wenn das Ticket durch die Ausführung einer Bereichsaktivität vorübergehend seinen Bereich verlässt, werden die Trigger wiederhergestellt, wenn das Ticket danach in den Bereich zurückläuft.

Beispiele für Aktivitäten

Beispiel 1: Bedingung für die Anzeige der Aktivität Teamleitung informieren

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 Teamleitung informieren nicht angezeigt werden. Dafür wird das Kundenfeld vip, das zum Kundendatenmodell gehört, geprüft.

Abbildung 45: 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 46: ConSol CM Admin Tool - Kundenfeld "vip"

Abbildung 47: ConSol CM Web Client - Bedingung: Rückgabewert TRUE

Abbildung 48: ConSol CM Web Client - Bedingung: Rückgabewert FALSE

Beispiel 2: Senden einer E-Mail an den Hauptkontakt, wenn das Ticket erstellt wurde

Wenn ein Ticket erstellt wurde, soll automatisch eine E-Mail an den Hauptkontakt des Tickets gesendet werden.

Abbildung 49: 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

Beispiel 3: Zuweisen des Tickets an den aktuellen Bearbeiter

Das Ticket soll dem Bearbeiter zugewiesen werden, der die Aktivität Neues IT-Ticket durchführt.

Abbildung 50: ConSol CM Process Designer - Workflow-Aktivität, bei der der Bearbeiter zugewiesen werden soll

Abbildung 51: 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

Beispiel 4: Verwenden einer Bereichsaktivität

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 52: Eine Bereichsaktivität, die während des gesamten Lebenszyklus verfügbar ist, da sie sich im globalen Bereich befindet

CM/ ist eine geschützte Marke der ConSol Consulting & Solutions Software GmbH