Latest Weblog

I've been playing around with Jott later - which allows me to dial into a (free to setup and use) account, and either leave myself a simple message or send that message to one of my contacts. The coolest part - it doesn't send an audio clip of my voicemail, but rather transcribes (and pretty damned accurately I might add) your message into text.

It's pretty slick, and something that I've been using to take mental notes over the past few days.

Today - while playing around - I saw that you have the ability to basically create a contact in Jott that is basically a conduit to a Web Service! This means, with the addition of a few Domino Design Elements, I could easily create an alternate publishing source for content on this 'blog.

The Jott Developers Guide gives a pretty simple overview of exactly how this is done, and it looks like it will allow integration with any HTTP POST-enabed solution (and thankfully Domino allows POST!).

I'll play around with this over the next few days - around some major data architecture tweaks to Match Maker to get it juuuuuuuuuuuuust right - and report back my findings, as well as some code, for those interested.

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!

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!

A better description, and a MUCH smoother process overall, v0.2 of xCopy comes with the following enhancements from the original:

• xcopy via Java Agents and Script Libraries
• Transaction Log documents via Java Agents and Script Libraries.
• Can now handle multi-thread large file xcopies.

And that's about it! Not a major release from a feature perspective, but certainly a major overhaul as I've ported the actual functional Agents from LotusScript to Java... with Tim's help of course!

New/first-time xCopy downloaders just download, sign, and go! v0.1 users: download, sign, change to a Design Template, change the extension from .NSF to .NTF, and run Replace Design!

If you have a need to either manually or automatically copy defined files to a defined target location, this is the app for you! If not, download it if for nothing other than a very simple example of Java Agents and Script Libraries. Feedback and feature requests appreciated.

Weblog Archives