When considering how to automate something, it’s often worth thinking about whether or not you can change the process a little first.
An example that often comes up is the need to automate the retrieval and processing of a particular email message. Many people will already have a manual process that involves, not surprisingly, their email client, e.g. Outlook. They’ll have a filter set up that moves the email they want to look at into a specific folder. Then they’ll take each of the emails in that folder in turn and do whatever it is they need to do to them, such as pull out some information and put it in an Excel file or database or something.
The user’s first thought when he decides to automate something like this is to have Macro Scheduler manipulate Microsoft Outlook to find the email and parse it.
That’s all very well, and is certainly achievable but it does add a rather awkward obstacle into the mix that needs to be navigated around: Outlook.
Look at what we actually want to do. We have some form of email that gets sent, and we want to parse it and perform some action based on it. Outlook just happens to be what we are currently using to read that email. We’re using it because we’re human and Outlook was designed for humans. But it isn’t the only way to read email. The email exists quite happily without it. We could use a different email client. Or remove the need for an email client altogether.
Macro Scheduler can retrieve email directly from a POP3 server, download the email messages to files and then process them. So we can remove Outlook – or any other email client – from the process entirely.
“Wait”, I hear you say, “What about my other email? I don’t want Macro Scheduler messing up my Facebook notifications, birthday reminders, blog updates and work emails” (notice the order of priority there). Well, don’t worry about that, there are several options. Macro Scheduler’s POP3 commands can be set to leave emails on the server and we could set the script up to search the downloaded email and look for only the pertinent messages.
But Ideally we have control at the sending end. We could set up a dedicated email account which these emails get sent to. That simplifies selecting which email needs to be processed. If that is not possible what about creating a new email account (it could be a free webmail account if you don’t have control over your own mail server) and then set up your filtering rule in Outlook, or whatever client you normally use, to forward the desired emails to that email account? This means the only emails in that account are the ones Macro Scheduler should process, thus simplifying the script which now needs only to collect all email in the mail box and can delete it afterwards.
Of course you can take this concept of removing obstacles as far as you like and in the most ideal world whatever it is that sends emails and whatever it is you want the information extracted from those emails inserted into would have a more direct form of communication between each other. But the world is not always ideal and we don’t always have control over the entire sequence of events. At least consider removing unnecessary obstacles from the part of the process you do have control over.
Retrieving and parsing email is just one example. The concept of simplifying a process applies elsewhere too. E.g. moving and copying files using Windows Explorer: instead of automating Windows Explorer by sending keystrokes and mouse events, use the built in file handling commands; pulling data out of a database: don’t automate your database query tool’s front end, access the data directly using SQL; Getting data from an Excel file: no need to try and manipulate Excel via user simulation, you can query the data directly; and so on.
When you sit down and automate a manual process some of the steps in that process might be things you can replace or skip altogether.
