Match Maker - Coming Soon!

08/14/2008 01:49 PM by Chris Toohey

One of the soon to be downloadable, open source applications that I'm working on is named Match Maker. This application, simply put, records document relationships in and outside of the current NotesDatabase container. Using ol' Darth Balls's Creating Primary Keys via @Password hashing, I'm creating a simple configurable utility that allows multi-to-multi document relationships for documents both in a single NotesDatabase and across multiple defined NotesDatabases.

Wha? Yeah... that might take some explaining. So here's a diagram (a pretty picture!) giving you a quick overview of what I'm getting at here:

The intended result of Match Maker is simple - I want a (possible) cross-database NotesDocumentCollection of all documents that I arbitrarily say are connected to each other. See - most people do this today by sharing a common key across multiple databases, and then hitting a View or running a db.Search/FTSearch for documents where said common key matches their query. Now that's fine (arguably) for new development efforts, how can we achieve this functionality - the cross-database relationships - on production applications that I don't want to have to change the design of in order to implement extended functionality? Well, this is where Match Maker comes in.

In Match Maker:

• you define your Application Profiles
  - basically a one-to-one document for each NotesDatabase you want to interact with - including Server names since this can technically go cross-servers, etc.)
• you define your Relationship Profile
  - a source application and as many target applications as you choose to select.
• you then define, in your Relationship Profile, your match criteria
  - fieldname1 = "blah" & fieldname2 = "foo", etc.

Match Maker will pretty much do the rest - it will run a scheduled query into the target applications based on your match criteria. When it finds a match, it adds the target NotesDatabase and DocumentUniqueID of any matching documents to the Relationship document. So now that you've got this list of matches....

Each Match Maker Relationship Profile's DocumentUniqueID is keyed using Nathan's technique - so grabbing the NotesDocumentCollection for matches will be as immediate as hashing some criteria from the UI elements that matches the scheme of the Relationship Profile...

For an example, say I have a simple Helpdesk application that's not tied into a 3rd-party Notes-based CRM solution. I would typically have to hack around both my Helpdesk and CRM solutions in order to make them work together (and possibly void 3rd-party support contracts in doing so...). With Match Maker, I can tell it to run Relationship Documents for all Active tickets where the caller matches supplied criteria (perhaps a high-profile customer, a customer with an elevated SLA, or simply certain VIPs or PITAs).

Now, instead of running what could be a costly search into that CRM solution, I could run a single MatchMakerDB.getDocumentByUNID(key), where key is something like @Password("CRMapp_SLAlookup" + caller). Since Match Maker runs configurable queries on a schedule, you're really going to benefit from the near-instant getDocumentByUNID and Match Maker returning a NotesCollection that you can then process to your specific needs!

Okay - enough talk, back to finishing off the v0.1 code and getting this out for you to play with ASAP!