January 2007 - Posts

Hummingbird DM AEM: Automated Email Management

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 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.
Posted by PaulWilson | with no comments

LINQ to SQL "Real" Example App Available

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.
Posted by PaulWilson | 2 comment(s)
Filed under: , , , ,

Breaking News: Future Version of .NET Framework to Run on the Mac

 

Breaking News: Microsoft is working on having a version of the framework that will run on the Mac!  That's right -- Rory broke this story just the other day in his interview with Scott Guthrie.

First, a little bit of background, which although not secret has largely went unnoticed so far.  Hopefully you've heard of WPF/E, which is a subset of WPF that runs in the brower, even Firefox and Safari.  So far the first CTP is largely focused on the cool graphics capabilities and supporting media.  But even in this first CTP the XAML can be programmed against on the client-side using JavaScript, even with Ajax.  But its also already been discretely said that in the future WPF/E will also contain a small cross platform subset of the CLR.  That will mean that we will also be able to use C# or VB on the client-side to program against WPF/E!  And that will be true even in Firefox and Safari on the Mac -- and this is old news that simply hasn't been widely talked about.

Mike Harsh as early as March 23, 2006 said:

So what is WPF/E?  It is a cross-platform, cross-browser web technology that supports a subset of WPF XAML.  WPF/E also has a friction-free install model and the download size we’re targeting is very small.  WPF/E supports programmability through javascript for tight browser integration.  The WPF/E package also contains a small, cross platform subset of the CLR and .NET Framework that can run C# or VB.NET code.  Yes, we are bringing C# programming to the Mac.

And Joe Stegman said this just last month:

To be clear, "WPF/E" is independent of the .NET Framework.  In a future version, we'll support a small cross platform CLR based execution engine that will run on both Windows and Apple OS X (everything we do from a runtime perspective works on both Windows and Apple OS X).  In general, our tools are dependent on Windows but with the current version of "WPF/E", you can develop using a text editor and deploy on any web server.  When we support the small CLR, compiling/debugging will require Windows (and so will our designer tools) but running/deployment will still work cross platform.

And then Scott said this in the interview at the 9 minute mark:

Scott: And overtime we'll also support a managed programming language, uh framework, against WPF/E as well.  So in addition to using JavaScript, you'll be able to use C#, uh
Rory: You mean, even for the other?
Scott: Yeah even for the Safari and Mac.

But what Scott said in this interview with Rory went beyond the small CLR for WPF/E in the browser.  Instead Scott said that they were also looking at a version of this that would run outside of the browser, even on the Mac!  Listen to this interview and its pretty clear that Scott was probably not intending to announce this until Mix.  Rory was also quite suprised and wondered if he needed to remove this from the video.  But Scott said he could keep it and acknowledged that this was probably the first time this was publicly talked about.  Rory was of course very excited to be the one to get this scoop out of Scott.  :)

So here's what Scott said in the interview at the 23:45 mark:

Rory: Is there any possibility of eventually having a framework that runs outside the browser?
Scott: Yea, yea, that's definitely something we're looking at is, uh, kind of what we call the in-browser experience and kind of the out-of-browser experience.  And so that's something we'll talk more about at mix, uh
Rory: And that stuff's secret now? Cause I don't mean to bring up something that's secret.
Scott: No, no, well that's something, uh, that we haven't talked about publicly yet. But that's certainly a scenario we're thinking about.
Rory: Do I have to get that out of the video?
Scott: No, you can keep that.
Rory: I can keep that? Is this like the first time anyone's heard it?
Scott: Probably, yeah.

Just having the ability to use our favorite .NET language and a subset of the CLR inside the browser to target an incredibly rich graphics platform like WPF/E is huge to me, but if we're not even restricted to the browser -- wow!  For instance, Keith Elder already has a post on his blog where he considers some of the possibilities, and that's just one person thinking out loud.  Of course right now the first CTP is still very much cool graphics and media, but this is a very strategic start.  Why?  Because this is focusing on what isn't easily possible any other way, and its getting the big media players involved.  And if the big media players use it then you can bet that everyone will be downloading the plugin just like they do now for Flash.  Most users aren't going to care about the .NET part, but once its ubiquitous, then we will also be able to take advantage of it.

So there you go -- its just a matter of time before there will be a small CLR version of the .NET framework everywhere, with your favorite .NET language of course!

Posted by PaulWilson | 12 comment(s)
Filed under: , , , , ,

Personal Blog about Paul Wilson and My Family

Sorry for this post, but my personal blog which tells all about Paul Wilson and my family needs some google juice.
Posted by PaulWilson | with no comments

Mimsware Website Updated due to Blog Comment

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.

Posted by PaulWilson | 1 comment(s)

Atlanta Code Camp 2007 Registration is Open

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.

Posted by PaulWilson | with no comments
Filed under: , , , ,
More Posts