« Increase the Height of Blogsphere's Web Editor | Main| Domino Developer Opening at Major Institution in Washington DC »

Sending OpenLog Output To Current Database Instead of Central DB

QuickImage Category


I'm pointing out this capability because I heard recently about a case where OpenLog had to be removed from an environment because it wasn't "approved" software.  It was working fine, of course, but that's beside the point.  Don't get me wrong, I can understand and appreciate the need to be somewhat conservative about what goes into a production environment. But this decision was incredibly shortsighted for a number of reasons, starting with how much easier it would have been to just test it than to "rip and recreate".

To change the default behavior of OpenLog and avoid the need to deploy a separate database, you simply need to modify a single Lotusscript constant in the OpenLogFunctions script library.  The effect will be to write all the log entries to the current database instead of a central one.  You'll then just need to copy the LogEvent form and a view or two from the Openlog template into your database, and no one needs to know you didn't just write it yourself for that application.  Here's where you make the change:

A picture named M2

One of the things I've been struck by in the 10+ years of doing Notes/Domino consulting is just how many poorly designed applications have made it into production.  It often seems that as long as something was developed "in-house", even if it has a crappy UI and even if it crashes the servers regularly, it is deemed more worthy than a highly-regarded and well-designed application available externally.  Setting aside that irony, what makes this a flawed decision is that very few moderately complex "in-house" Notes applications are built without code drawn from several outside sources.  The fact is that Notes developers are constantly pulling code off of the LDD Forums, the Sandbox, the OpenNTF code bin, blogs, et. al. and dropping it into their "in-house" applications, and no one is the wiser.  In some cases the code is substantial enough (an entire script library for example) that the origins are typically referenced in a comment block somewhere, but a lot of smaller bits go in with no attribution.  I am quite sure that the same practice is common in every programming discipline, simply because most smart people learned long ago that re-inventing the wheel is an incredible waste of time.

So how should an enterprise determine what can be labeled "approved code"?  Every enterprise needs to set its own priorities in this area, but any "good" policy needs to understand what the real risks are.  

It doesn't take a tremendous amount of research to discover that OpenLog is being used without any problem in countless enterprises and is an example of extremely well-written code.  Rejecting the deployment of such a database as too risky while allowing all the other external code embedded within other databases fails to recognize the basic inconsistency of that policy.  The reality is it's far easier to trace the origins of a complete, intact, and distinct database like OpenLog than it is to trace the origins for any of the myriad subelements within countless applications that were pulled from who knows where.  Combine that fact with the actual purpose of OpenLog, and its clear that it is far riskier NOT to use OpenLog than it is to do so.

Your Host

KevinPettitt.jpg
Kevin Pettitt View Kevin Pettitt's profile on LinkedIn

Tools I Use

Idea Jam

Subscribe to This Blog

 Full Posts  Comments

MyYahoo
netvibes Add to Netvibes

Contact

Hosted by

OpenNTF

Disclaimer

This site is in no way affiliated, endorsed, sanctioned, supported, nor blessed by Lotus Software nor IBM Corporation, nor any of my past or future clients (although they are welcome to do so). The opinions, theories, facts, etc. presented here are my own and in no way represent any official pronouncement by me on behalf of any other entity.

© 2005-2017 Kevin Pettitt - all rights reserved as listed below.

Creative Commons License
Unless otherwise labeled by its originating author, the content found on this site is made available under the terms of an Attribution / NonCommercial / ShareAlike