Introduction to the Installation Toolkit
The NaSS Installation Toolkit is a database that is deployed as a part of the Domino 7.0.2 install kit. When an organization decides they want to deploy NaSS the administrator or developer uses the Installation Toolkit to facilitate this deployment. The Installation Toolkit contains the "source" templates for all of the NaSS use cases, as well as a great deal more information.

One of the more useful types of information stored in the Installation Toolkit is a list of all of the design elements that make up each of the NaSS scenarios. These "Design Element docs" are sorted and categorized in a variety of ways, such as by template, by featureset, by design element type, and so on. Here's a peek at couple of the views:

You can view the NaSS design elements by Featureset...

... or by the type of design element

These documents can be used to easily determine what elements are a part of each featureset in NaSS.

Now, as you can imagine, these documents are not created manually - these documents are automatically generated by an agent. This can be very useful, especially in situations where you are integrating NaSS with customized versions of the mail or personal address book templates. This agent not only identifies the featureset(s) to which the element belongs, but it also determines such things as the type of element (e.g. form, view, LotusScript or Formula agent, etc.) and whether the element is a new element or is a modified version of an existing element from the base template.

This code is one of the many coding techniques I'll be covering in the coming weeks.

But the documentation of the NaSS elements isn't the only thing in the Installation Toolkit - it also includes a useful feature known as the Template Builder wizard.

The Template Builder Wizard
As I mentioned earlier the deployment of the NaSS feature presented some new challenges for us. When we were coming up with our options to make it easier, we entertained the idea of releasing all of the various permutations of featureset combinations as a series of templates - and then quickly realized that this would create dozens of templates since we now have eight featuresets. So, I wanted to come up with something different. It had to be flexible, since we knew we would be creating additional featuresets. It had to be easy to understand, so that people could modify and extend it as needed. And it had to be simple to use out of the box - the people most likely to be using it would be administrators, not developers. Taking all of this into consideration, I came up with the Template Builder wizard.

The Template Builder wizard is a simple process that is accessed from the About document of the Installation Toolkit (there is also a button to make access easier in all of the views). The About document has a brief explanation of the database and the Template Builder wizard, and explains what is about to happen.



The first step in the Template Builder wizard allows the user to select the scenario(s) that will be deployed.


The second step of the Template Builder wizard allows the administrator to specify the default settings for the SAP account in their user's Account document.


This feature was added because we figured that one of the areas that would generate quite a bit of support calls for the customer would be the settings for the SAP Account document. For SAP accounts you have to specify more than just a server name and username/password. SAP accounts require the following information:

• Server DNS/IP
• Username
• Password
• Employee ID
• System Name
• System Number
• Client Number
• Language Code

As you can imagine, most users won't know this stuff past their user name and password - so the system has been designed to allow the administrator to specify the "other" stuff as default values for the user. When the user's Personal Address Book database design is updated with the NaSS design, and the user composes an SAP Account document, the values specified in Step 2 will automatically appear as default values.

This is another kewl code technique that I will explain in the coming weeks - and it wasn't as simple as it looks.

The third step of the Template Builder wizard allows the user to specify some areas that administrators often like to modify for their Notes/Domino template environment.


You can change the database title, design template name (the name used by databases to inherit from this template), and file name for each production template being created. Additionally you can specify where (i.e. what directory) the production templates will be stored on an accessible local or mapped drive. Incidentally you will only have database options for templates that are being deployed - so if, for instance, you weren't deploying either of the HR Self Service scenarios, then those tabs would be hidden.

Notice that we're changing the Design Template name (the name used to inherit from this template). If you check, this is a read-only property in LotusScript; however in this code I give you a way to change this property very easily, and we'll cover that as well sometime soon.

Once you click Finish the following steps happen:

1. The appropriate source templates are detached and placed in the specified directory
2. The Title, design template name, and file name are changed to the desired values
3. The design elements for the scenarios that are not being deployed are removed from the templates

This yet another technique that will be covered in the upcoming weeks. I'll show you how I identify the design elements to be removed, and then how I get a handle to them and delete them.

Special Mention
I would like to take this moment to mention a special person involved in the creation of this database - Marina Bodik of IBM/Lotus. She is on the template team, and stepped in to help me with the coding effort for this database. I threw a bunch of new ideas, concepts, and code at her, and she absorbed and used it in a very efficient and elegant way. In short, she made this possible, and deserves to be recognized for it.

Conclusion
Hopefully I've whet your appetite for some kewl code over the next few weeks. Some of this will be some old techniques used in new ways, and some of it will (hopefully) be completely new to you. We'll begin diving in next week with the code that generates the Design Element docs.

See you then!

Rock
**If you pick up a starving dog and make him prosperous, he will not bite you; that is the principal difference between a dog and a man.