Hummingbird DM AEM: Automated Email Management
I was able to get AEM working effectively, but there were also several aspects of the installation and configuration that were not documented well, or which required a lot of trial and error, so I want to share some of the lessons learned. We are using DM version 5.1.0.5 SR6, so that is what I installed for AEM to begin with, but at least on my system it would not start up successfully after an apparent successful install, so I had to use patch SR6 MR2. I suppose some will say that you should always use the latest version, but a Hummingbird installation is a very complex beast, so once you have something in place that works for you, its a big deal to update everything. Luckily in this case I was able to only install the new version for just AEM and leave the rest of the DM system on the current version, but even that was something that had to be thoroughly tested, and there may still be some unknowns.
Once I had it installed it quickly became a very long and involved process to configure things correctly, but most of this was documented and in most other cases the log was sufficient. I think the biggest problem is that everything is too configurable and that there are no smart defaults, and yet for this type of system there are a lot of defaults that just seem to be obvious. For instance, they provide a default email profile, with fields to store the from, to, cc, bcc, received date, and send date, but none of these are configured for you so you have to specify both the profile and every one of these fields. We also had some other custom fields that had to be set, and of course I would expect that to be my task, but I just don't see why they can't have the standard email fields defaulted to begin with. But ignoring my custom fields for now, which were very easy to figure out with their log's help, here is what I determined to be the optimal set of profile values for the standard email fields:
PROFILE=(DEF_MPROF), TYPE_ID=(EMAIL), ABSTRACT=(%s), EMAIL_FROM=(%f), EMAIL_TO=(%t), EMAIL_CC=(%h"cc"), EMAIL_BCC=(%h"bcc"), EMAIL_RECEIVED=(%h"datereceived"), EMAIL_SENT=(%h"date")
The Type Id might be something else for someone else, since this was a custom type that I created myself, but I also think it just makes good sense to define an Email type to best differentiate email documents. The Abstract value, which is used for the document description, and wasn't documented anywhere that I could find, may also be something that you may want to set differently -- I've simply set it to the subject. On the other hand, all of the other values seem non-debateable to me since of course you want the from value set to the from address, and so one for the to, cc, bcc, received date, and sent date. I should point out though that they do not document the dates anywhere, which seems to be an important oversight since these are pretty standard email fields, but I was able to figure out the sent date myself since it is a normal email header. The received date on the other hand is very simple once you know what to do, but it took support a while to get this one found for me, and the received email header is quite involved so it was not something I could figure out myself.
At this point I had it all installed and configured so that I could successfully send and receive emails and see them captured and stored in Hummingbird DM according to the rules that I had setup. But there were still a few other problems that became apparent in testing -- the first being that email attachments were not getting profiled separately, which was an option that I had specified I wanted enabled during the installation. It turns out that the installation program did not set a registry value correctly, and support was able to identify this pretty quickly, but I'm still not sure why this wasn't set correctly by the installation program. I should also point out that this registry setting, and many others, are well documented, including some that have to be manually set since they do not have options in the installation, like full-text search.
And that left me with everything working correctly with the exception of one advertised feature that was unable to work in my case, although its also a feature that we can probably do without for the time being. The advertised feature is that you can specify folder names that don't yet exist and AEM will automatically create them on the fly, which I can see some shops wanting to better organize emails by sender or receiver or some other dynamic criteria. My understanding on this issue, after many discussions with support, is that this feature does work in environments that do not have custom fields of their own added to the default profile form, but its our customizations that are causing it not to work. Of course it does beg the question of how they never accounted for this situation before, since I would bet just about every Hummingbird setup involves some customizations, which they also strongly encourage by the way. Oh well, its now on their list to fix, and its probably something we can live without for now, but hopefully by documenting here, along with my other lessons learned, I can save someone else out there some time.