Workflow Components: Activities

This chapter discusses the following:

Introduction to Activities

An activity represents an action in a workflow. An activity is located within a scope and is of one of the following types:

A manual activity has to be performed by a manual action of the engineer using the Web Client GUI. The activity is displayed as Workflow activity in the Web Client (provided at least one of the roles of the engineer has the Execute permission (please refer to the ConSol CM Administrator Manual, section Role Administration, for a detailed explanation). In the Process Designer, the activity is marked by the hand/manual icon.

Figure 39: ConSol CM Process Designer - Manual activity in workflow

Figure 40: ConSol CM Web Client - Manual activity

An automatic activity is performed automatically by the system and is not displayed in the Web Client. In the Process Designer, an automatic activity is not marked by any special icon.

Figure 41: ConSol CM Process Designer - Automatic activities

Properties of an Activity

In order to display and edit the properties of an activity, mark the activity in the Process Designer.

Figure 42: ConSol CM Process Designer - Activity

The Properties Editor will be opened for this activity.

Figure 43: ConSol CM Process Designer - Properties of an activity

An activity can have the following properties:

Process Logic of Activities

This is the process logic of activities:

  1. When a ticket has passed through an activity it always waits behind this activity (and not before the next one!).
  2. When a ticket has passed through an activity, it checks if one of the potential subsequent activities is an automatic activity. If yes, the ticket passes through this automatic activity as well. This is why there can only be one automatic activity in a process step.
  3. The ticket passes automatically through (automatic) activities as long as there are new automatic activities. It comes to a halt as soon as there is/are one or more manual activities where engineer interaction is required.
  4. If one or more of the following manual activities have a precondition script, this script is executed in order to decide if the activity has to be displayed in the Web Client GUI or not.
  5. If the engineer selects the activity in the Web Client GUI, the script of the activity is executed.
  6. If there is a postActivityScript, this script is executed immediately after the execution of the activity script.
  7. The ticket waits behind the manual activity. If the following activity is located in a new scope, the ticket will not enter the new scope. It always waits behind the old activity and not before the new one!

In case the activity has an ACF, the Business Logic of ACFs also has to be considered.

A ticket always waits behind the last activity which has been executed and not before the new one!!

Examples for Activities

Example 1: Precondition for Displaying Activity "Inform team lead"

In case the ticket has been opened by a VIP contact, i.e. a contact where the boolean field vip is true, the team lead should be informed. If it is no VIP, the activity should not be offered. The Data Object Group Field vip which is part of the customer data model is checked for this purpose.

Figure 44: ConSol CM Process Designer - Workflow activities (one with precondition script)

// Get the main contact of the ticket. The unit object (can be a customer or a company) is provided;

// here it has to be a customer, i.e. a contact:

 

Unit contact = ticket.mainContact

 

// Check the Custom Field "vip" of the main contact. (see next image)

// If it is set to true, return true, i.e. the condition is TRUE.

// Else return false, i.e. the condition is FALSE:

 

if (contact.get("vip")) {

return true

} else {

return false

}

Code example 2: Precondition script - Activity should only be displayed for VIP customers

Figure 45: ConSol CM Admin Tool - Data Object Group Field "vip" (CM version 6.9)

Figure 46: ConSol CM Web Client - Precondition: Return value TRUE

Figure 47: ConSol CM Web Client - Precondition: Return value FALSE

Example 2: Send an E-Mail to the Main Contact When a Ticket Has Been Opened

When a ticket has been opened, an e-mail should be sent to the main contact of the ticket.

Figure 48: ConSol CM Process Designer - Automatic activity where receipt note is sent

// Get the main contact of the ticket:

def mycontact = ticket.mainContact

 

// Get the value of the Custom Field "email" of the main contact:

def mycontact_e = mycontact.get("email")

 

// Use as text the e-mail template with name "receipt_notice_ServiceDesk".

// Can be located in the Template Designer or in the Admin-Toool.

// Usually e-mail templates are stored in the Template Designer:

def text = workflowApi.renderTemplate("receipt_notice_ServiceDesk")

 

// Get the reply-to address for the e-mail.

// This is stored in the system property "cmweb-server-adapter","mail.reply.to":

def replyto = configurationService.getValue("cmweb-server-adapter","mail.reply.to")

 

// Build the string for the ticket subject.

// Keep in mind that the regular expression which defines the ticket identifier has to be in this subject.

// Otherwise, an e-mail cannot be assigned to the correct ticket.

def subj = "Your request has been received: ticket (" + ticket.getId() + ")"

 

//Send out the e-mail

workflowApi.sendEmail(contact_e,subj,text,replyto,null)

Code example 3: Script for automatic activity where receipt note is sent, variant 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 example 4: Script for automatic activity where receipt note is sent, variant 2

Example 3: Assign the Ticket to the Current Engineer

The ticket should be assigned to the engineer who executes the activity New IT ticket.

Figure 49: ConSol CM Process Designer - Workflow activity where engineer should be assigned

Figure 50: ConSol CM Web Client - Ticket passed through activity where engineer was assigned

// Get the engineer who is executing the activity:

def curr_eng = workflowApi.getCurrentEngineer()

 

// Assign the ticket to the current engineer

ticket.setEngineer(curr_eng)

Code example 5: Script for assigning ticket to current engineer

Make sure that you always use the correct engineer object!

The current engineer is the engineer who is logged in, who is executing the current activity. You can get the object by using one of the following methods.

Using workflowApi: 

// Java notation

def curr_eng = workflowApi.getCurrentEngineer()

// Groovy notation

def curr_eng = workflowApi.currentEngineer

Using engineerService :

// Java notation:

def curr_eng = engineerService.getCurrent()

//Groovy notation

def curr_eng = engineerService.current

The ticket engineer is the person who is (at this point of time) the ticket owner and responsible for the ticket. You can get the object by using the following method:

//Java notation

def tic_eng = ticket.getEngineer()

//Groovy notation

def tic_eng = ticket.engineer