I was once asked why I would created a little application that would do nothing more than what could be done with a simple SmartIcon. When I created SOTU - my Remote Console Command utility, it's v0.1 release was a simple utility that - yes - was an extended version of what you could do with a simple SmartIcon. v0.2 gave you the option to configure a simple Sidebar Widget, and allow you to issue Remote Console Commands to your Domino servers with even greater ease. With SOTU v0.3, you won't even have to fire up your laptop!

Simply point your mobile device's WAP browser to sotu.nsf/mobile, and you will be presented with a simple WAP-enabled Form:

From here, you can select the Server and enter a console command. Click the Issue Command button, which submits the request via POST to a simple Domino Agent which uses the SOTU Script Library and issues the remote console command.

Once properly executed, the browser is redirected to sotu.nsf/mobile, and can quickly see the response (if any) from the Remote Console Command via a pseudo-embedded View at the bottom of the mobile Form.

Quick Tip: For you Blackberry users, you can use Showtime to create a simple Channel Push icon for your Admin team and quickly deploy this application just in time for Lotusphere!

Here's a quick icon set that I used for my team - both a standard and an updated icon, shown respectively:

See how I tie things in (eventually)?!

Also, v0.3 has no error handling in the mobile.engine which handles the request... and for good reason. If you get an Agent Done response form the Agent... then something's broken, and it's more than likely a permissions issue with the Remote Console security stuff (which can be changed on the Server Document). The Remote Console Command will be issued by the server, so make sure you have everything from a security side setup or you'll likely see something like this on the server console/log:

When it rains it pours as they say, and I was faced with several issues at once this week:

1. While planning to upgrade Mail Databases to ND8, we found that certain Design Elements - mostly Agents and Views - had the "Prohibit design refresh or replace to modify" checked... which would be problematic as we need to remove some of these elements. What makes this better is that - since the customer has used multiple mail templates - there's no logic to who has these flagged Design Elements. So we have a possible handful of possible duplicated Design Elements where the $Flags NotesItem contains "P".
2. Had a "project champion" contact me, asking for an Excel report of various information from her Lotus Notes Application. Simple enough, as I built EEE into the application... but then she went on to inform me that the status levels were completely wrong, but that they needed to be correct in the report. This results in several thousand NotesDocuments where the status NotesItem is just plain wrong, and the only way to know what it should be is to evaluate several different conditions (ie., this is this while that is not that, etc.).
3. A workflow application - which is the bastardized "upgrade" of some hellspawn requisitions review and approval process - hiccups more often than it works anymore. This leaves me having to go in and push certain NotesDocuments through the constantly-fluxing routing process through direct NotesItem manipulation. I hate this application, as well as lament for the loss of accumulated hours of my life spent smacking it around.

And this was Monday. Monday morning actually.

I started thinking to myself about just what I could do to address the Mail Database Design Elements, the FUBAR'ed NotesDocuments whose status was truly a mystery, the bain-of-my-existence workflow application, work on my abs, clean the Augean stables, and cure Cancer while finding time to spend with my family between Football practices, Cheerleading practices, piano lessons, Lotusphere Abstract Submissions (due Friday, btw...), and all of the other things that keep me busy 27 hours out of the day.

So... I had an idea! What if I could logically control the NotesItems of NotesDocuments in remote Domino Applications? I could write a simple configuration-based utility application that would allow me to define a Domino Application, define a collection of Design Elements or NotesDocuments, and configure a NotesItems maintenance engine - all built on my freeware/tip jar-ware application UI. I could use this utility application to remove the "P" from the $Flags NotesItem in my Mail Database Design Elements, apply some user-supplied and developer-entered logic to update the status NotesItem on some NotesDocuments, and could potentially allow me to provide a given application administrator with an API into controlled-push of a stalled NotesDocument through a workflow application. Not too sure what it's going to do about cancer or cattle-cleaning... but they can't all be gems.

So with my idea, I grabbed a pad and pencil, and started mapping out a simple architecture outline via some napkin-development, and I came up with the following:

I had my utility application - which I'm calling MixMaster - which uses a Job document to access the target NotesDatabase and get a handle on defined-criteria target collection. Now, for that collection, I'm using a NotesNoteCollection, which allows me to access both NotesDocuments and Design Elements, and using a defined selection formula via the Job document's criteria NotesItem.

Once I have my target NotesDatabase collection (represented in the above diagram as a single document - Document), I grab the the defined Evaluation documents (which are children NotesDocuments of the given Job document), each containing notesitem and formula NotesItems. We'll Evaluate the formula defined in the formula NotesItem against the target NotesDocument (or Design Element, which I'll render as... a NotesDocument - ta-da!), and save the result to the target NotesDatabase NotesDocument NotesItem defined in the notesitem NotesItem. Yikes...

So outside of some bells and whistles - including a simple Sidebar-ready Form - that's pretty much it! Of course, if you're like me... you're interested more in the working-example application, video tutorial, and something that you can rip apart. Fair enough - and expect to see that tomorrow!

Thought I would discuss a few things that I'm looking to deliver in the next-round releases of the freeware/tipjar-ware that I've been putting out lately:

• SOTU
  
  • Better response logging - this is a must have as far as I'm concerned
  • Allowing type-in command or Command Document selection based on User Roles
  • Locking down Servers or Commands with Reader fields
  • Web Browser Front End
  • Mobile Browser Front End
• xCopy
  
  • Schedule Engine
  • xCopy Logic Engine
  • xCopy Job Collections - the ability to say run this assigned collection of Jobs
  • Better Transaction Logging
  • Multi-OS Support
• Zephyr
  
  • HTML-based Email Bodies
  • Optional in-line Formula evaluations
  • Schedule Engine
  • Porting of the current notification engine to a tighter, custom Class-based architecture
• MatchMaker
  
  • Create View-Free Data Architecture
  • Configuration-based "at will" data relationship indexing.
  • Crawler and Indexing Schedule Engine
• Junction Lite
  
  • Freeware/Open Source version of Clearframe's Junction - a configurable data conduit/middleware utility.
• E.T. - this one's new on the list as of today...
  
  • Cisco WebDialer plug-in for Lotus Notes
  • Right-click Menu click-to-dial via Widget
  • Phonepad Sidebar Widget

If anyone has any suggestions, requests, etc. - please let me know in the comments.

Two weeks ago (hey, I can totally understand the schedule, Bruce) Tim and I were fortunate enough to be invited on the Taking Notes Podcast to discuss Freeware, Shareware, Guiltware/"Tip Jar"-ware, and "for-profit" IBM/Lotus Notes and Domino Product offerings. Outside of me bringing down the collective IQ of the assembled cast, I think it was a great show.

In a podcasting cross-pollination experiment, we bring Chris Toohey and Tim Tripcony on the show -- you know them from the YellowCast podcast for Lotus Notes developers -- to talk about the pros and cons of developing Notes applications for free. Or trying to make a small profit on them.

For those of you interested, check out Taking Notes: Episode 86, which should appear on something called Eye Tunes sometime soon enough (damn toys...).

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!