Workflow-Komponenten: 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.

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"

Eigenschaften einer Aktivität

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:

Prozesslogik von Aktivitäten

Folgende Prozesslogik gilt für Aktivitäten:

  1. Wenn ein Ticket eine Aktivität durchlaufen hat, wartet es nach dieser Aktivität (nicht vor der nächsten Aktivität!).
  2. Wenn ein Ticket eine Aktivität durchlaufen hat, überprüft es, ob eine der möglichen Folgeaktivitäten eine automatische Aktivität ist. Wenn ja, durchläuft es auch diese automatische Aktivität. Deshalb kann es nur eine automatische Aktivität in einem Prozessschritt geben.
  3. Das Ticket läuft automatisch durch (automatische) Aktivitäten, solange es neue automatische Aktivitäten gibt. Es hält an, sobald es eine oder mehrere manuelle Aktivitäten gibt, für die eine Aktion des Bearbeiters erforderlich ist.
  4. Wenn eine oder mehrere der folgenden manuellen Aktivitäten ein Bedingungsskript haben, wird dieses Skript ausgeführt, um zu entscheiden, ob die Aktivität im Web Client angezeigt wird oder nicht.
  5. Wenn der Bearbeiter die Aktivität im Web Client auswählt, wird das Skript der Aktivität ausgeführt.
  6. Wenn es ein postActivityScript gibt, wird das Skript sofort nach der Ausführung des Aktivitätsskripts ausgeführt.
  7. Das Ticket wartet nach der manuellen Aktivität. Wenn sich die folgende Aktivität in einem neuen Bereich befindet, tritt das Ticket nicht in den neuen Bereich ein. Es wartet immer nach der alten Aktivität und nicht vor der neuen Aktivität!

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.

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 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

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 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

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 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

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