I've had the opportunity lately to work with Hummingbird's Document Management (DM) system on one of my projects at Mimsware. In particular I was tasked to install, configure, and learn about their Automated Email Management (AEM) system in a test environment. What is AEM? It is basically a plugin for MS Exchange that makes it possible for all emails in an organization to be automatically archived into the Hummingbird DM system according to flexible rules that you define. The goal for some organizations will be to make legal compliance of email retention automatic, and any necessary legal discovery very easy, especially important in a government organization with open record laws. Other organizations may also be interested in simply making email work like all other documents, so that one document management system can be used to store and search all types of documents in the organization.
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 188.8.131.52 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.
The Atlanta Code Camp was today, so I finally got to give my LINQ and O/R Mapping talk that I've been preparing.
I tried to have minimal slides so that I could do a deep dive into real code, but I still went a little too long. The slides look great on my own PC, and in fact they're mostly some I stole straight from other LINQ presentions. But the overhead I was using made the text nearly unreadable for some reason, which made me take longer on the slides. It also made some of the standard VS color syntax unreadable, with the work-around being to select that code. I small the same problem with another speaker in the same room, so I guess it was the projector, but very frustrating.
In the end I still got to hopefully show a fair amount of LINQ to SQL, but I had really hoped to show more. I also made sure I gave a glimpse at SqlMetal and LINQ to Entities, but both of those were meant to be just glimpses. Finally, I briefly demoed my new "real" example application written with LINQ to SQL which is included in my download. This example shows off my own POCO objects with an external XML Mapping file, instead of the ugly code gen with attributes. Its also a "real" app that consumes the LINQ to SQL with WinForms grids, drop-down filtering, and create, update, and delete.
Note that it assumes the May 2006 CTP, but I'll update it to the next one when it comes out, hopefully next month. Its also nearly identical to my existing "real" example app downloads that I have for my own ORMapper and NHibernate.
You may remember me posting about joining Mimsware as a software consultant here in Atlanta a couple of months ago. Well first let me say that things are going well and that I really enjoy working with Mimsware, and of course I highly recommend them if you're in the Atlanta area. But it was pointed out by Wim in the comments that Mimsware's website looked like Microsoft's website back in the year 2000. Well I'm happy to report that Dave Mims took that comment to heart and made updating the Mimsware site a priority -- so take a look now. Its also worth noting that Dave did already know that it really needed updating, but it had just never been a priority until Wim's comment.
Registration for Atlanta Code Camp 2007 on January 20th is now open. Space is limited and fills up fast, so do NOT delay registering -- it's free. Thanks to Jim Wooley for putting this together this year.
I'll be presenting a session titled "Linq and O/R Mapping" that will be lots of real code and very little powerpoint. If you've seen the standard Linq sessions already, or even if not, but you've been wanting more then this is for you. I'm not going to waste any time on Linq to Objects or Xml, although those are cool in their right -- I will focus purely on Linq to Sql, and to a lesser extend Linq to Entities or Datasets. Do you want to see a real application built using Linq to Sql? That's what I plan to do, and I'll do it several ways so you can experience the possibilities. For instance, should we use SqlMetal, the GUI Designer, or do our own thing with xml mappings instead of attributes? What if you want to include some relationships, use some stored procs, and even some inheritance? We shall cover all of those possibilities and more -- you will NOT be disappointed since this will not be just another slide deck or sample series based on what's already available. In fact, I would actually challenge you to find any other "real" sample that includes all of these with xml mappings, but you won't find it since it doesn't exist. I hope you get that I'm excited about this, as these technologies have definitely matured past my initial criticisms. And even if you can't make it for some reason, I'll post at least some version of my sample app after the event is over for all to see.