dominoGuru.com

Your Development & Design Resource

Match Maker - The Pseudocode!

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!


About the author: Chris Toohey

Thought Leadership, Web & Mobile Application Development, Solutions Integration, Technical Writing & Mentoring

A published developer and webmaster of dominoGuru.com, Chris Toohey specializes in platform application development, solutions integration, and evangelism of platform capabilities and best practices.



More from dominoGuru.com


dominoGuru.com is powered by IBM Notes Domino XPages & hosted by Prominic.NET

Contact Us

Use our Contact / Feedback form or one of these email addresses:

Creative Commons License

Except where otherwise noted, dominoGuru.com by Chris Toohey is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.