Match Maker - The Pseudocode!

08/15/2008 03:59 PM by Chris Toohey

I am constantly telling people (and constantly being reminded through the day-to-day) that I "married up" when I was lucky enough to marry my wife. Shirley is one of those amazing people that not only puts up with me (which makes her a saint), but that enables me to be a better person just being around her.

I've gotta tell ya... I find that I've "married up" with my circle of friends. I've not only got a more firm footing on Match Maker as a result of several IM conversations and a phone call with Tim today, but there's something coming down the pipe that will knock the fillings out of your teeth - an all-star team (and me - ftw?!) working on the next "sliced bread" solution.

But back to Match Maker. I'm slightly modifying the data architecture of Match Maker - pushing for a more globally useful approach instead of a source database/document approach - which should allow some amazing functionality. Simply put... (get ready for some pseudocode-babble):

1. You define an Application Profile - which is a simple NotesDocument that lists the Server, NotesDatabase, and it's "status".
2. You then define a Relationship Profile - which consists of the following NotesItems:
   

   hash	Simple "user-defined" formula - ie., field1 + "_" + field2 + "_" + field3
   app_source	Selected "source" Application Profile.
   app_source_criteria	Evaluated simple "user-defined" formula used to limit the Source Application's NotesDocumentCollection.
   app_target	Multi-value selected "target" Application Profiles
   aoo_target_criteria	Evaluated simple "user-defined" formula used to limit the Target Application's NotesDocumentCollection(s).

3. Now, Match Maker will run on all "active" Relationship Profiles:
   
   1. Evaluate and get a handle on the Source NotesDocumentCollection via the Source Criteria.
   2. Get a handle on the first Source NotesDocument.
   3. Evaluate the hash formula against the Source NotesDocument.
   4. Check for an existing Relationship Document for the evaluated hash. If none exist, create one and set it's DocumentUNID to @Password(evaluated hash)
   5. Evaluate and get a handle on the Target NotesDocumentCollection via the Target Criteria.
   6. Loop through the Target NotesDocumentCollection, updating the Relationship Document match NotesItem with the following: AppProfileKey^targetDocUNID
   7. If you've gotten this far - save the Relationship Document and move on to the next Source NotesDocument in the Source NotesDocumentCollection.

So, let's say I want to find matching documents to each email in my Inbox, across my CRM Contacts Database, Helpdesk Database, and Projects Database solutions. Instead of (heaven forbid it!) modifying those target NotesDatabases or running time-consuming searches in real-time against 3 different databases, all I'll need to do is set a Relationship Profile with a hash of from + "_CHP". To grab the NotesDocumentCollections of matching documents, I just simply do a MatchMakerDB.getDocumentByUNID and feed it the evaluated hash (from + "_CHP").

Simple and immediate. It's almost finished - still playing around with a few things - but it'll be a pretty sweet (and hopefully useful) multi-database meta index utility for those of you who find yourself needing such a thing!