HTML5, CSS3, jQuery, JSON, Responsive Design...

Domino sequential numbering, quick and dirty

Michael Brown   October 29 2010 06:23:28 AM
In a distributed environment like Domino, sequential numbering should be avoided whenever possible.  Still, there's always customers/users that insist upon having it.

This is for a Change Request web app that I was working on.  The existing version made use of a WebQuerySave LotusScript agent to generate the number, by looking it up from a profile document and then incrementing the value on the profile document and resaving it.

I thought that the profile document approach was as good as any, but I don't like WebQuerySave agents.  They are are a major bottleneck, especially if the Agent Manager's tied up with something else, in which case, your app may have to sit and spin for a while.  So I thought I'd see if I could do the same thing just using some computed form fields.  Here's what I came up with.

You'll need to setup a profile document, called "frmProfSeqNumber", in my example.  This profile document contains several fields, the main one, of course, holds the sequential number itself and is called "SeqNumber" in my example.  There's an additional field, "SeqIncrementIndex" to hold the increment (normally 1) and also a field called "SeqNumberWidth" to hold the width that you want for a text version of the sequential field.  For my own app, the customer wanted the format to be "CR00001", "CR00002" and so on.   Of course, I have to allow for what happens after I've allocated "CR99999".  (Honestly, I've seen sequential numbering apps that were actually about to come to a grinding halt because the original developer simply hadn't allowed for such a possibility!).

You'll have to set up an action/agent that will allow you to edit the profile document to do the one-time setup of its initial values.  My own such agent is Actions->Admin->Edit Sequential Number Profile, referred to in the field comments below.

Now on to Change Request form itself.  There's two fields, "ChangeReqNo" (computed numeric) and "ChangeReqNoText" (computed text).  The latter computes off the former and so must come after it on the form.  Here's the formula code, with comments:

ChangeReqNo
REM {Looks up incremental number from the frmProfeSeqNumber profile doc.
Increments that number by one and stores it on this field, as long as this field doesn't have such a number already.
Also, writes the incremented number back to the profile doc.  Click on Actions->Admin->Edit Sequential Number Profile to edit that
profile doc direction};

@If(@IsDocBeingSaved & ChangeReqNo = "";
   @Do (
           varLastNumber := @GetProfileField("frmProfSeqNumber"; "seqNumber");
           varIncrement := @GetProfileField("frmProfSeqNumber"; "SeqIncrementIndex");
           varNewNumber := varLastNumber + varIncrement;
           @SetProfileField("frmProfSeqNumber"; "seqNumber"; varNewNumber);
           varNewNumber
           );
   ChangeReqNo)



ChangeReqNoText
REM {Takes the number from the ChangeReqNo field and formats as text,
pre-fixed by a number of leading zeroes. The number of zeroes is looked up from the frmProfSeqNumber
profile doc. The code checks first to see if the number isn't already as wide as (or wider) than the number of
zeroes to be pre-fixed.
Click on Actions->Admin->Edit Sequential Number Profile to edit that profile doc direction};

@If(@IsDocBeingSaved & ChangeReqNoText != "";
   @Do (
           varNumberWidth := @GetProfileField("frmProfSeqNumber"; "SeqNumberWidth");
           "CR" + @If(@Length(@Text(ChangeReqNo)) >= varNumberWidth;
                                 @Text(ChangeReqNo);
                      @Right(@Repeat("0"; varNumberWidth) + @Text(ChangeReqNo); varNumberWidth)
                           )
   );
   ChangeReqNoText)

Comments

1Erik Brooks  10/29/2010 8:08:06 AM  Domino sequential numbering, quick and dirty

FYI - WebQuerySave (and WebQueryOpen) agents run in the HTTP process, not the agent manager. I.E. even if the Amgr is full running a bunch of scheduled agents, your WQS/WQO agents will always run.

Also, they haven't really been a performance drain (and especially not anything as simple as an incrementing number) since 5.0.7+ as long as you're using the "run web agents concurrently" option in the server doc.

I'm not trying to downplay your solution, just letting you know that web agents aren't as evil as people think.

About