Video Screencast Help
Scheduled Maintenance: Symantec Connect is scheduled to be down Saturday, April 19 from 10am to 2pm Pacific Standard Time (GMT: 5pm to 9pm) for server migration and upgrades.
Please accept our apologies in advance for any inconvenience this might cause.

Expanding Servicedesk 7.5 - Part 2 – Defining Classification & Service Queues from within Email Monitor

Created: 26 Jul 2013 • Updated: 26 Jul 2013 | 12 comments
Language Translations
TGiles's picture
+4 4 Votes
Login to vote

ServiceDesk has the ability to process email messages and automatically generate incidents for technicians to work. This is very helpful in allowing end-users the ability to quickly send an email documenting a problem, and have a trouble ticket automatically created as a result.

In ServiceDesk 7.5, the email monitoring application is a user-editable process. This provides some flexibility to modify the project to accommodate specific needs.

Problems

One of the difficult things that users, especially those in larger environments experience is that incidents created from the Email Monitor program come in with no classification information or routing to specific service queues for proper handling. Some companies have taken a tactic of creating static classification or service queue mappings inside the monitor project. This works, however this still requires the technician to make further modifications to the incident to make sure the set information is correct. It also requires that the project must be modified if a change to these mappings is required.

Also, the ability to classify an incoming incident, based on the target email address, and to assign the email to a specific service queue does not exist in the out of box product, without some substantive customization.

Solution

In a two part series of articles, we will describe how this is done. The first article will explain how the ability to support multiple email boxes, from differing email host servers can be generated and maintained. The second article will outline how to configure the data mappings to accommodate classifying the incident and assigning to a Service Queue, based on the email address the message was sent to.

This article covers the configuration of the classification and service queue routing. You may use the following link to read the first article.

Expanding Servicedesk 7.5 - Part 1 - Monitoring Multiple Emails with a Single Email Monitor Application

The RoutingClassification.zip file attached to this article contains the three necessary files needed to make SD.Email.Monitor set the classification & service queue information for each incident it creates. The three files contained in the zip file are as follows:

  1.  RoutingClassification.model: The model that contains all the components needed to make this modification. This model can be imported and left as a linked model, or if you prefer you can use its contents to simply create an embedded model inside SD.Email.Monitor.
  2. Incoming_Email_Process.pfl - The application profile that was created to contain the names of the data mapping tables for routing and classification
  3. ExportedDataMapping.xls - The definition file for the two data mapping tables created for classification & routing. These tables contain sample test data from my internal test server, so they will need to be updated to meet your environmental needs.

This completes the small overview. Lets move to getting it installed.

Installation and Configuration

Changes to the ServiceDesk Server

The Incoming_Email_processing.pfl & ExportedDataMapping.xls files need to be imported into the Process Manager portal before we make changes to the SD.Email.Monitor project.

Installing the Application Profile

  1. Log into the Process Manager portal with an Administrator account.
  2. Go to Admin->Data->Application Properties
  3. Click on the Import Profile Definition button.
  4. Click Choose File and select the Incoming_Email_Processing.pfl file
  5. Click Import.

image001_3.png

Installing the Data Mapping Tables

  1. Log into the Process Manager portal with an Administrator account.
  2. Go to Admin->Process Automation
  3. Click on the Chevron next to Incident Management.
  4. Click on the Service Dashboard button.
  5. Click Manage Data Mapping
  6. Click on the Import Data Mapping button.
  7. Click Choose File and select the ExportedDataMapping.xls file
  8. Click Import.

image002_1.png

Once you've imported the data mappings you will need to make sure you update them to reflect the values that will be found in your environment.

image003_4.png

As this modification was designed to be added to the SD.Email.Monitor-Multiple project the data mapping examples show the different e-mail addresses that are being monitored. Make sure that the information you supply in the data mapping match exactly the service queue names and the e-mail addresses. If they do not the mapping will fail in the project.

Please note that the model provided is only checking against a single key data mapping. If you wish to define both key1 & key2 values a slight modification will need to be made to the model. I'll explain that modification later when I go over the components in the model.

Modifying the SD.Email.Monitor-Multiple project

  1. Open SD.Email.Monitor-Multiple project in Workflow Designer
  2. In the Project view on the left right click on SD.Email.Monitor-Mulitple and choose Import Model
  3. Select the RoutingClassification.model file and choose Open. If you wish to use an embedded model instead of a linked model see instructions under Using an embedded model, instead of a linked model.

image004_0.png

  1. Now open the ProcessMessage model and insert a Linked Model component between the 'Format Plain Text emails' & 'Submit Incident Ticket' components.

image005_2.png

  1. Open the Linked Model component and set the Component Model Name to Routing & Classification.
  2. Set the Start Mapping as follows:
    1. Incident: Incident
    2. EmailMessage: EmailMessage
  3. Set the Return Mapping as follows:
    1. Incident: Incident

image006_0.png

Using an embedded model, instead of a linked model

  1. Import the model as described above.
  2. Open the newly imported model & copy all the components inside the model.
  3. Now open the ProcessMessage model and insert an Embedded Model component between the 'Format Plain Text emails' & 'Submit Incident Ticket' components.

image007_0.png

  1. Right-click on the new model & choose Edit Component.
  2. Click on the ellipses for Output data.
  3. Click Add.
  4. Create an output object called Incident with a Type IncidentTicket and click OK.
  5. Click on the ellipses for Embedded Model.
  6. Delete the default Start & End components.
  7. Paste in the copied components from the imported model.
  8. Double-click on the End component and confirm the Mapping for Incident is Incident.
  9. Remove the imported model.

You are now ready to test the modified project.

Comments 12 CommentsJump to latest comment

cvegajr's picture

I am getting the following error - [ProfileProperties].incoming_email_processing_email_routing". I would to know how to fix and also does the project need to be recompiled after step 12. logentry.png

 

 

0
Login to vote
TGiles's picture

As with any project you will need to publish it to the server onces you've made your changes and confirmed everything is working properly.

From the error it appears the data mapping tables didn't get imported correctly.

+1
Login to vote
matt_bollinger's picture

I was receiving the same error as cvegajr. It worked for me after I added Incoming Email Processing to the Application Properties for the project (put a checkmark in the box). It wasn't checked by default:

ApplicationProperties.jpg

Once I added it and saved the project, the error cleared.

The clue for me was editing the Log Entry Text (in the Create Log Entry component that was giving the error).  The text contained [ProfileProperties].incoming_email_processing_email_routing, but I didn't see that in the list of values.

Best Wishes,

Matt

+1
Login to vote
matzebru's picture

Great articles Tylor! Are these enhancements you detail in Part 1 and 2 going to be part of the "Apollo" release this fall?

Thanks

- Bruce

 *** If a forum post solves your problem, please flag it as a solution. If you like an article or forum post, vote it up. ***

0
Login to vote
TGiles's picture

The upcoming Apollo release will contain enhancements that allows for the Routing & Classification part explained above without the need to modify the project like we have done here. As far as handling the multiple e-mail boxes our modifications have been provided to development for evaluation.

+2
Login to vote
MPowers's picture

The project is pretty good, but I have some issues with it now that we've put it into place.

This doesn't account for multiple email addresses in the To: field. Emails with multiple email addresses in the EmailMessage.To field are not checking the multiple values and are just going to the Default Incident Queue. It doesn't check the other fields like CC either.

I think it may be a good idea to have another model before the Routing and Classification model happens that checks the To and CC, compares it to the emails listed in the data mapping table, saves that to new variable that is then checked in the Routing and Classification model.

Any ideas/pointers in how best to accomplish something like this, or if there is a better way, please let me know.

Thanks

0
Login to vote
TGiles's picture

You are right the project was not designed to deal with e-mails that contained multiple to addresses or if the e-mail address was in the CC line. However this is easy to rememdy. If you think about how the project is designed you already know the e-mail address of the e-mail being processed. 

The project will run through all e-mails in a specific e-mail inbox before moving onto the next inbox. You simply have to pass the inbox name to the ProcessMessage model and use that to perform your routing. Of course you will also have to update your routing tables to make sure that they contain the same values to properly route.

+1
Login to vote
matt_bollinger's picture

I found the same thing.  Since the GetEmails model is running for a specific mailbox, you can use the mailbox itself for routing instead of trying to operate on CC, BCC, or for multiple addresses in the To field.  In other words, it doesn’t matter how the message arrived in the mailbox if you route based on the mailbox.

We're using POP, so I inserted a “Copy Data Element to New Location” component just after the Get Single Message Component in the Get Emails model.  (Note: Copy Data Element to New Location is in the AssignDataComponent class, but I didn’t find it in a search for “assign”; search for “copy” instead.)  I have it configured as data type: text, input: CurrentEmailBox.EmailUserName, output: SingleEmailMessage.ToName.

I modified the two “Match” components in the Routing & Classification model to use [EmailMessage.ToName]  as input, and then set my data mapping to use the Box User Name (as entered from the Service Catalog > Administrative Services > Managed Monitored Email Boxes).

Best Wishes,

Matt Bollinger

0
Login to vote
MPowers's picture

Thanks for your help and prompt replies. I was able to test it the way you described successfully. 

I did have to change my routing around a bit, as I was planning to forward emails and distribution groups to one colleciton mailbox and have this sort it all out, but this works just the same. 

Thanks again!

0
Login to vote
Heman's picture

I have just implemented this model in Email Monitor - Multi, but I am getting "'sessionId' is empty" issues on the following componants:

Get EmailToQueue Data Mapping ID

Match Email.To address to EmailToQueue mapping

Get EmailToClassification Data Mapping ID

Match Email.To address to EmailToClassification mapping

out of the box the sessionid is set to Constant Value. does anyone know what needs to be?

 

0
Login to vote
MPowers's picture

If you are talking about the Configuration tab, under Inputs, with key1, mappingid, and sessionID... mine is set as "ouPutGlobalSessionID", which is a process variable.

0
Login to vote
Heman's picture

Yes, and thanks, I have set it this and now not getting the errors. but getting new errors:-

[WorkflowTasks] Error loading task.
Client: IP=fe80::b854:9c2d:1c46:ee70%12 HostName=fe80::b854:9c2d:1c46:ee70%12 Browser=Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.5477)
System.Exception: taskID is null
   at LogicBase.Ensemble.WorkflowTasks.WorkflowTasks.GetTaskByID(String sessionID, String taskID) in c:\build\projects\WF75_SDSP1_Apollo\ensemble\LogicBase.Ensemble\WorkflowTasks\WorkflowTasks.asmx.cs:line 1280

and

[Reports] Error saving process permission.
Client: IP=fe80::b854:9c2d:1c46:ee70%12 HostName=fe80::b854:9c2d:1c46:ee70%12 Browser=Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.5477)
System.Exception: Permission for 'Support' already exists.
   at LogicBase.Ensemble.Reports.ServiceCore.ReportLogProcessPermission.AddNew(String sessionID, ReportLogProcessPermission[] permissions, Boolean performMapping) in c:\build\projects\WF75_SDSP1_Apollo\ensemble\LogicBase.Ensemble\Reports\DataLayer\ReportLogProcessPermission.cs:line 216

not sure if this is related.

0
Login to vote