Before we look at the agent that actually manages the groups, there's one other thing to look at. This is the PostDocumentDelete code in the Database Script. This is used to detect the deletion of Group definitions. It asks whether the actual Group itself is to be deleted from the Directory. The Lotuscript code for this can be seen at http://www.component-net.com/dp-extras/dp-200106-1.html.

The agent
The core of the application is the agent that actually processes the groups. This agent can be run by hand or on schedule. One proviso, however, is that the database is physically resident on a server. This is because the agent and other code that looks at the directory assumes that it will operate on the Names.NSF that's found on the same machine as the database itself. The code of the agent can be found at http://www.component-net.com/dp-extras/dp-200106-2.html.

Let's look at some of it's features I've numbered the lines of the code so that it's easy to call out interesting features.

First, you'll see running though it that all messages are logged to a NotesLog database (see Initialize, lines 12-14, for example). This feature of Notes isn't commonly used, but it's very useful for background agents; it keeps all the messages together and out of the Domino server log, making them easier to find and trace. From the developer's point of view, it's also very easy to use. The only thing you have to do before running any code is to create the actual agent log database, using the Lotus ALog4.ntf template, and give it the same filename as used on theNotesLog.OpenNotesLog call. I recommend the use of NotesLog databases for applications with background agents and in places where some sort of audit trail of actions is required. It's a real neat and easy way to keep track of what's happened.

Initialize lines 15-19 get hold of all the Active group definitions. Then the For loop starting at line 20 starts processing each of these. Line 30 calls the CheckDNAB sub to check if the group exists in the directory and to see whether the owner field contains the GroupOwner value from the Group definition form. If the group doesn't exist in the directory, the call to CreateGroup at line 31 gets it created. Then we use CheckDNAB again to read it back and set values in the indicator fields DNABGroupFound and DNABOK. The sub CreateGroup is modeled on the Group form in the Domino Directory and is intended to mimic the fields and values that are created when Groups are created by hand.

So by the time the agent gets to line 37 in sub Initialize, the group exists in the directory, and we're ready to go. The key to the whole process is the sub RulesProcess, which turns the set of rules for this group into a NotesDatabase.Search formula and then executes it.

At line 5 it starts the search formula off with Select Form = "Person", and then loops through the set of rules for the group. At lines 8-10, the current rule is connected with an And or an Or with any previous one. Once we have checked in lines 13-16 that the rule specified actually exists, at line 30 we start building a formula for this rule. If the comparison is not case-sensitive, we put both sides of the comparison in uppercase. Also note that we use @Contains and @Left to perform the operators Contains and Startswith in the operator list we saw in Figure C. Lines 57-61 handle the rule having a second part, and if so, lines 62-85 handle the second part of the rule as we've already seen. It's quite neat here using the debugger to watch how the search string is being built up.