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