Beyond The Yellow Bubble

As many of you may know, information about when an agent last ran is buried inside a special field inside the Agent Design Note called $AssistRunInfo.  So far I have been unable to find a way to programatically access the contents of this field.  As a way around this issue I have added a new LogAgentRun method to the DominoDatabaseDesign class which can assist in tracking when all the agents in a database last ran without access to the Designer client and manually inspecting the agents logs of each agent.   This method locates the Agent design document and stores a date/time value in a new field ($LastRun).  For this to work each agent must now call this method to allow tracking of this information.  It then becomes possible to create a view that displays all agents in the current database and display the date/time the agent last ran.  This column has been added to the Design\Agents view in the .DominoFramework 1.0 scheduled for release at OpenNTF on June 30.

 '/**
 ' * Log agent having run in the agent document
 ' * @param Source  Name of agent
 ' * @param RunTime Date/time agent ran
 ' */  
 Sub LogAgentRun(Source As String,RunTime As NotesDateTime)
  Dim Agent     As NotesAgent
  Dim AgentDoc    As NotesDocument
  Dim DesignCollection As NotesNoteCollection
  
' Locate agent document in current database
  
  Set Agent = iDB.GetAgent(Source)
  If (Agent Is Nothing) Then Exit Sub
  Set DesignCollection = iDB.CreateNoteCollection(False)
  Call DesignCollection.Add(Agent)
  Set AgentDoc = iDB.GetDocumentByID(DesignCollection.GetFirstNoteID)
  If (AgentDoc Is Nothing) Then Exit Sub
  
' Update special framework field to hold run time
  
  Call AgentDoc.ReplaceItemValue("$LastRun",RunTime)
  Call AgentDoc.Save(False,False)
 End Sub

Every view design document contains a field $Index storing information about the designated use of view indices.  The following are some of the values this field holds:-

1. /M - Index refreshed manually
2. /0 - Index refreshed automatically (i.e every time the view is opened)
   
3. /R=nnnn  - Index updated automatically at most nnnn (seconds)
4. none of the above - Index refreshed automatically after it has been used for the first time
5. /B - Requires designer level access or above to create the view index (e.g. prevent others from rebuilding views via Shift F9)
6. /C - ??? (does anyone know?)
   

The 1.0 Release of the .Domino Framework contains a view that uses the above to display information about all the views in the current database without the need for the Designer client.

One of the projects I am presently working on involves designing a process that would allow Non-Notes developers to take over the release process for deploying new version of high impact Notes applications into production.  The key challenge is to simplify the process so that it can be easily executed without detailed knowledge of how Notes works.  Teamstudio's BuildManager is an excellent third party solution for this.  Unfortunately we were looking to design a  solution without this product.

The solution developed involved extending the .Domino Framework with some additional tools that would allow an application developer to define the build process as LotusScript code within the application.

The following are steps in the release process which can now be automated using the .Domino Framework:-

1. Remove Design Prohibitions on design elements.  This ensures the existing production code is completely replaced with the version of code that was developed and/or tested in QA.
2. Remove template links set for individual design elements.  Again, this is important to ensure the code deployed into production is the same as that developed/tested and not coming from another template.
3. Refresh Database Design: Refreshes the database using a template on a pre-configured (deployment) server
4. Compile LS: Ensures no errors exist in the LotusScript missed during development and also ensure none of those nasty issues remain where some design elements have been compiled with an older version of the code.
5. Sign Database: Allows all design elements to be signed by a special process ID that has the necessary rights to allow the code to execute on the production server (e.g. Restricted Agents)
6. Enable Agents: Ensures that specific agents have been enabled to run on a paricular server

When the build method is invoked a dialog box displays information about the database and the list of steps to be executed.  The user has the option to deselect steps they do not wish to execute this time (e.g. bypass compiling LS code).  The selected steps are then executed on order. 

Most of the code to implement the above is included as part of the DominoDatabaseDesign class (Contained within the Domino.Reflection namespace).  This class includes a Build method which contains a default set of steps that are to be executed.  The Build method also accepts a custom list of steps to be executed.  This can be achieved by creating your own database class which extends the DominoDatabaseDesign class and passes the custom parameters to the DominoDatabaseDesignClass.  Typically this would all be wrapped in a Build agent which can be triggered via an entry in you application's outline that is visible only to those who perform new releases.

 '/**
 ' * Generate a new build of the database
 ' * @param BuildSteps  Overides the default build steps that can be executed
 ' */   
 Sub Build(Byval BuildSteps As Variant)
Try:
  On Error Goto Catch
  Select Case Typename(Buildsteps)
  Case "OBJECT"
   BuildSteps =  Split(ENUM_BUIILD_STEP__REMOVE_PROHIBIT + "," + _
   ENUM_BUIILD_STEP__REMOVE_TEMPLATE_LINKS + "," + _
   ENUM_BUIILD_STEP__REFRESH_DESIGN + "," + _
   ENUM_BUIILD_STEP__RECOMPILE_LOTUSSCRIPT + "," + _   
   ENUM_BUIILD_STEP__SIGN_DATABASE + "," + _
   "Enable Agent aArchive" + "," + _
   ENUM_BUIILD_STEP__REFRESH_VERSION,",")
  Case "STRING ()"
  Case Else
   Exit Sub
  End Select
  Call DominoDatabaseDesign..Build(BuildSteps)
  Exit Sub
Catch:
  Stop
  Exit Sub
  
 End Sub

Future enhancements will include options to build a new version in CIAO, copy/update data documents from the deployment database (e.g keyword documents), and copy/update profile documents.

By using the above it becomes possible to automate the entire build process down to opening the production database and running the Build agent.

As most members of the yellowverse probably know by now, IBM have announced the first (closed) beta release of Notes 8.5.1.  I don't know about you but for me (as a Notes developer) this probably represents the single most important release of Notes since Notes R5.  I don't have a copy (yet), but I defintely want Santa to place one under my Christmas tree well before Christmas day.

What makes it so important?  While IBM marketing seem to be placing greater emphasis on the extension to mobile devices such as iPhone, there are three little items that get a brief mention:-

1. Eclispe-based editor for LotusScript:  The power of Eclipse is finally being released for LotusScript programmers.  While we still are not seeing any major enhancements to the LotusScript language this new editor promises to provide dramatic productivity improvements to those of us that spend all day writing LotusScript code.  This is especially true for OOP where it has been a real pain to maintain large Class libraries.
   
2. Eclipse based editor for Java:  I am not a big user of Java, but I have a lot of respect for what the language can do.  If you do program in Java then I am sure you are going to appreciate having a full-featured Java edited inside DDE.  After all, Eclipse was built on/for Java!  The real holly grail for Java developers (Java UI classes) seems to have been pushed back to 8.5.2 (or later)
   
3. XPages for Notes Client: There has been a lot of excitement in the yellowverse about Xpages and the way this new design element promises to transform the way we develop Web applications in Domino.  My excitement has been not as great as my focus is largely on application development for the Notes client.  Based upon the limited information I have, Xpages for the Notes client is probably the single biggest enhancement to Notes client development outside of Forms, Views, and LotusScript.  I am surprised more has not been spoken about  XPages for Notes until now.  The following are some of the reasons why I expect Notes developer to scramble to convert applications to use this design element almost exclusively:-
   
1. Dual Multi Client Development: Ever since Notes 4.5, Lotus has sought to provide a way to support a thick and thin client in a single application.  The potential of this has never been fully relaised due to limitations with the existing design element that has often lead to two applications existing inside the one NSF.  We have probably all struggled with the challenges of needing large amounts of client specific code to make this work.  While Xpages still needs to evolve I expect it will reduce the complexity considerably in making an application look/feel the same on  a wide range of clients that include Notes, Web browsers, and mobile devices.
2. Application Configuration: One of the really cool features of Xpages is that almost everything is configurable as a formula.  IBM have now opened Pandora's box for all those things you have wanted to change dynamically but never could (e.g. column title for a view, disabling an edit control)
   
3. Source Code For Design Elements: Xpages can be viewd/edited as either a visual design or source code.  The source code is a great addition if you want to do a mass change (e.g. change all references of Arial to your favorite font).  It also means we can send the entire design element as a piece of text to another developer and not have to enclose it inside an NSF for transportation.  And we can probably use XSLT safely to automatically apply design standards and best practices
   
4. Multiple Data Sources: Unlike Forms, an Xpage is not restricted to displaying data from a single Notes document.  This opens up the capability to consolidate data from multiple documents/sources without the need to use @DBLookup etc.  And while the initial versions of XPages only support data inside NSFs,  the groundwork seems to have been laid for a later expansion to bring in data from other sources such as XML and SQL databases.  I typically back myself to develop an application in Notes 3-4 times faster than I could develop the application in an environment such as .Net (even after I took the .Net classes!).  But I have always been constrained that my Notes application cannot compete with the sheer speed of SQL Server, ORACLE etc for high volume applications.  Nor can I provide relational capabilities such as JOINs which are often sought as part of an application's requirements.  Give me the ability to bring SQL data into my Notes application and the sky is the limit.  In a difficult economy why would a company want to spend so much money building a  front end to an ORACLE database using C# or Java when they could do it in Notes for so much less?
   

Thanks IBM... we now have a classy client (8.0.0) that runs a little faster (8.0.2) that has dramatically reduced the cost of ownership (8.5.0) and now will allow developers to build 21st century applications for both the Web client (8.5.0) & (soon) Notes client (8.5.1).  Every Notes client developer should be pushing IBM to provide more information and to gain access for your organizations to the 8.5.1 betas.  In 2-3 years time we will most likely be developing Notes applications in a radically different way than we are today.  8.5.1 is the release that will start us down that path and we need to prepare for that transition.

Update: The following entry from a Design Partner (i.e. someone in the know  - wink wink) is not inconsistent with the above suggestions.