Part 4 – Creating the Incident via the Remedy Email Engine
Back here I started this whole overview on automating Remedy using the Remedy Email Engine. Part 2 and Part 3 followed.
Here in Part 4 we are going to get to the meat of it. Up to this point we have done all the work necessary to get emails into our system and into our custom email processing form.
So now what?
Creating an Incident from an Email
Now we are at the best part – creating a new Incident. Since we’ve already processed/formatted everything this part is very straight forward. Examine this image:
Push to Incident (click for full image)
One of my most major complaints about Remedy is that you can not open the field mappings box to see more than a few lines….that said…the mappings in this case are very simple.
In previous versions of BMC Remedy Help Desk you would simply push the value to the form. With the advent of BMC Remedy Incident Management you can no longer do it. Well, you CAN do it – it’s just not very fun. Instead, we are going to use the built-in interface for creating Incidents. The advantage here is the number of fields we need to map is quite minimal.
In short, we are pushing from our current processing form to the HPD:IncidentInterface_Create form. The mappings are as follow:
- Status – New (List value)
- Description – $Subject$ (email subject line)
- Assigned Support Organization = “My Organization” (a valid support organization – you can hold this in your configuration form and do multiples if you want to get fancy)
- Last Name – “Caller” (Static value in my case due to unpredictable callers. This could easily be looked up and configured to a real/existing person’s information)
- First Name – “Unknown” (Static value in my case due to unpredictable callers. This could easily be looked up and configured to a real/existing person’s information)
- z1D_Action – CREATE (Mandatory field value to create an Incident)
- Service Type – User Service Restoration (List value)
- Detailed Description – This one gets complicated. There are carriage returns inserted below everywhere you see a & sign. I had to replace them to make everything happy on the web: (((((((((((( “To: ” + $To:$) + ” & “) + “From: “) + $From:$) + ” &”) + “Date: “) + $Create Date$) + ” &”) + “Subject: “) + $Subject:$) + ” &”) + “Message:”) + $Message Body$
- Urgency – 4-Low (List value)
- Impact – 4-Minor/Localized (List value)
- Reported Source – Email (List value)
- Assigned Group – “Support” (Configuration value or static depending on your needs)
- Assigned Support Company – “My Company” (The appropriate company to go with the support group)
When this push fields happens an Incident is created – and that’s it. In our case the agent then goes on to examine the email and respond to the customer appropriately. The agent may also update the Caller/Contact information with a real caller. They can do this either by selecting an existing one or creating a new profile for the caller.
If this is done the caller will even get updates to the Incident via email (if configured correctly). This brings up to our next concern – how do we update Incidents via email? That is in part 5.
Part 2 – Technical/Architecture considerations for the Remedy Email Engine
Technical Considerations of automating service with the BMC Remedy Email Engine
This is a continuation of a previous post which can be found here.
There are a few technical considerations that must be addressed before you get down into the dirt creating this type of integration.
Email Server Protocol
Many Remedy customers - especially at smaller companies – don’t have to worry about this. By far the most popular implementation of BMC Remedy products with small to mid-market companies is the following configuration (versions notwithstanding):
- BMC Remedy AR Server on Windows
- Microsoft SQL Server on Windows
- Assorted tools, etc, also running on Windows
Often these are all on the same server – and there is simply nothing wrong with that. If you have a call center processing a few hundred calls a day this is more than enough to sustain your service management practice. And as it stands this makes automating the Remedy Email Engine very simple – you can run the BMC Remedy Email Engine and use the MAPI protocol to communicate with Exchange. You can literally configure this and have it up and running in mere minutes. I’ve done this many times myself.
However – this does not apply to everyone. I typically work with large customers like the US Federal Goverment (civilian agencies) and Fortune 500 companies.
Many of these customers are taking thousands of calls per day and consequently are using more robust hardware. Typically this is something similar to the following configuration:
- BMC Remedy AR Server on Solaris
- Oracle 9/10 on Solaris (remote server)
- Assorted tools (running on the AR Server)
- Other remote mid-tier servers, etc
- MS-Exchange running on Windows servers completely separate from the AR Servers
Here’s the problem. MAPI is strictly a Windows protocol used to send and recieve email. You can not use the MAPI protocol to check email from a Solaris server running the BMC Remedy Email Engine.
Of course – there are other protocols – specifically POP3- which works on nearly every platform and operating system. It was after all the original protocal used in most internet-based email applications and is still popular today. POP3 is only used to receive email from an email account so that only gives us half of the equation.
And of course – there’s even a problem with that. It is not considered secure. Since I often work at sites that needs security in all aspects of the system we had to get special wavers AND an entire separate exchange server for our email accounts that were accessed through POP3. Along with that came security requirements that restricted access to those email servers for any IP except our BMC Remedy Email Engine server. All of this tooks numerous forms, meetings, phone calls, etc.
So the lesson here is simple: Don’t assume that setting up the Remedy Email Engine is going to be simple just because it is technically a breeze. Security and policy considerations can be quite restrictive.
On the “sending email” from the BMC Remedy Email Engine we did luck out on the project though – the customer maintained a corporate “outbound” email server that was used for all automatic sending of emails and did so with few security restrictions. You will have to investigate the rules for your organization but if you are on Solaris and using Exchange (or a similar combination) the only real option for sending email is SMTP. The ways to do this are too numerous to bother listing but they all qualify as “easy”.
Accepting/Sending emails outside your domain
There are two policy issues you will also want to consider before you begin coding.
First, will you accept email from outside your domain? It’s fairly easy to immediately delete every incoming email that’s not from MYCOMPANY.COM – but is it safe? If your CEO is working from home and uses his Gmail account (I have literally seen this one happen) to request support do you want to ignore it? Maybe – it depends on your corporate policy. You also may have to deal with fighting spam if you are accepting emails from the entire world.
Second, will you send emails outside your domain? If you are requesting any type of sensitive information (however YOU define it…) you may want to limit how far out in the world you are willing to send emails. Or just for the sake of efficiency, company policy, etc.
It is better to decide both of these items up front.
Fighting Internal Spam
Another consideration is how to deal with internal spam. Nearly every company I have worked with has company-wide (or at least site-) email distribution lists that are used for things like “It’s Karl’s birthday! Come and get cake!” or other public announcements. Naturally you don’t want these to generate Incidents.
The best way to do this is to prevent the email account from being included in that sort of thing from the beginning. That is impossible for many organizations however and that means you should have a plan “B” to deal with internal spam. Here are some suggestions in no particular order:
- Allow agents to immediately close Incidents that are obvious spam without working on them
- Pros – No additonal coding
- Cons – It’s sort of a tradition in call centers for management to not trust agents to immediately close things ever.
- Code for the known/likely internal spam types
- Pros – It’s easy to predict the daily “Company Update” email
- Cons – There could be N^100000 of these; also, they could change at any time
- Tag messages withtext and look for it in workflow
- Pros - Very easy to do with form-launched or other pre-formatted emails, templates, replies, etc
- Cons – The “better mousetrap” has never beaten the “more stupid user” scenario
There are many multiple ways of dealing with this and it’s likely every organization will need to do their own planning.
Next, we’ll get on with the actual technical bits. Go on – read part 3 of this series!
-William Rentfrow, Principal Consultant, StrataCom Inc
Remedy Development Best Practices
In response to:
** Hi folks. Just wondering what practices some developers are using for custom code and enhancing ootb workflow. IE, field ID’s in a non reserved range, New workflow easily identified perhpaps by the company name etc. My real big dillemma is modifying existing workflow. Does anyone have some best practices for modifying existing workflow so that in the event of an upgrade pitfalls can be avoided or at least anticipated?
William Rentfrow
Principal Consultant, StrataCom Inc.
715-410-8056 C
715-592-5185 O