Site Server and E-Commerce - 20 Dec 1999

Editor's Note: This column builds on the columns in the November and December issues. This column assumes that you've built a Membership server, mapped that server to the default Web site on port 80, created a virtual directory called Membership, and configured the Membership Directory Manager (MDM) to look at port 1003, where your Lightweight Directory Access Protocol (LDAP) server is running.

Last month, I showed you how to create a user named Tim in the Directory Service (DS). I also showed you how to add the password, first name, last name, and email address attributes to that user. Remember that when you added those attributes and their values, you had about 50 attributes to choose from. Those attributes are the default attributes of the Members container.

If none of the default attributes hold the type of data about a user you want to store, you can create custom attributes. You can manually create attributes with the Microsoft Site Server Service Admin Microsoft Management Console (MMC). You can also programmatically create attributes with Active Server Pages (ASP) or any other programming language that supports an interface to Microsoft Active Directory Service Interfaces (ADSI).

Using the MMC
Suppose you want to create an attribute called productPage. You want to use this attribute to programmatically keep track of how often a user views, or touches, a product page in your commerce site.

To add a custom attribute, open the MMC and expand Membership Directory Manager. Click the plus sign next to ou=Admin, then click cn=Schema. The Schema container holds all the attributes available to the DS, not just the attributes available to the Members container. Right-click cn=Schema, and choose New Attribute to launch the New Attribute Wizard. Click Next to move off the opening splash page.

The New Attribute Wizard prompts you to enter the common name (CN), display name, and description of the attribute you want to add. As Screen 1 shows, type productPage in the Name box and Product Page in the Display name box. In the Description box, you can enter a short description of the attribute's purpose. Leave the Multi-valued check box blank. (I'll cover multivalued attributes in a future column.) Click Next.

The wizard asks you to specify the type of persistent data (e.g., string, integer, binary) that you want the attribute to hold. You want the productPage attribute to hold an integer, so select Integer, and click Next.

The wizard prompts you to specify string syntax constraints, such as the maximum string length. Because productPage will contain integers rather than strings, leave the default option of None selected. Click Finish to complete the process. If you scroll down the attributes in the Schema container, you can see the productPage attribute you just added.

After you add the productPage attribute to the Schema container, you need to make it available to the Members container. Scroll down the list of attributes in the Schema container until you find cn=member. As Screen 2 shows, the icon for this object differs from most of the icons for the other attributes. That icon identifies the cn=member as a container. Double-click that container to obtain the Properties page.

Select the Class Attributes tab. The Class Attributes tab lists all the attributes available in the Members container. Click Add to obtain a list of all the possible attributes you can add to that container. Scroll down, and choose the productPage attribute you created. Click OK to add this attribute to the list in the cn=member Properties page. Click OK again to complete the process.

To make sure the productPage attribute is available, go to the MMC and click the plus sign next to Membership Directory Manager. Click ou=Members, then double-click either cn=Administrator or cn=Tim. Select Add Attribute, and check for the productPage attribute.

Building a Membership server in Site Server and adding custom attributes can be quite a time-consuming process. In a future column, I'll show you how to create a Windows Scripting Host (WSH) script that both builds a Membership server quickly and adds custom attributes. You simply execute this WSH script from the command line.

Using ASP with AUO
As I showed you last month, you can use Active User Object (AUO) to identify the currently authenticated user and retrieve various attribute values of that user. You can also use AUO to assign new or change existing attribute values. For example, the script AUOwrite.asp in Listing 1 identifies the currently authenticated user, retrieves several of the user's attributes, then adds values to those attributes whether they have existing data or not. In addition, the code increments the productPage attribute.

Like AUOdisplay.asp in last month's column, AUOwrite.asp instantiates the AUO object, assigns the instance to the objAUO variable, and uses a series of Response.Write statements to write several attribute values of the currently authenticated user to a Web page. Unlike AUOdisplay.asp, AUOwrite.asp then uses the assignment (=) operator to assign new values to the street, city, state, and zip code attributes. AUOwrite.asp also increments the productPage attribute. You increment the productPage attribute with two statements that use the AUO object. The first statement

intVisits = objAUO.productPage

casts the variant that the AUO object returns into an integer. The second statement

objAUO.productPage = intVisits + 1

increments the value by one and writes the data to the DS.

Because you're making changes to the DS (i.e., providing values for empty attributes), you need to use the SetInfo method to write those changes to the DS. SetInfo writes changes from the Property cache to the DS. (For more information about using AUO in ASP code, see Robert Howard, Site Server 3.0 Personalization and Membership, Wrox Press, 1998.)

You can use Microsoft Visual InterDev, Microsoft Notepad, or another editor to create AUOwrite.asp. After you create this script, follow these steps to run it:

If you apply AUOwrite.asp to a real product page on your commerce site, you can gather information about how often users visit that page and act on that information. For example, suppose a user visits the same product page five times in 3 days. After you gather that information with ASP, you can easily capture that data in the DS programmatically with the AUO object. You can also easily have the Web page automatically render a message such as We've noticed that you looked at this product five times in 3 days. If we offer you 10 percent off, will you buy it right now? Click Yes to proceed.

Using ASP with ADSI
Although the AUO object is powerful and easy to use, it's slow. The more simultaneous membership authentications you have on your site, the slower the AUO object becomes. One way to achieve better DS performance with ASP is to use ADSI.

Whereas AUO is a COM object that lets you manipulate the DS, ADSI is a standard for manipulating the DS. ADSI inherited most of its syntax from the X.500 standards. As the script Enumerator.asp in Listing 2 shows, you use the GetObject method to bind anonymously to the DS to create an instance of the object.

When you use GetObject, you hard-code a unique path, or ADsPath, to the object you want. The ADsPath consists of several components. Take, for example, the ADsPath

"LDAP://thucknt4:1003/o=huckaby/ou=members"

The first component is the namespace. You need to specify a namespace because ADSI supports LDAP and many types of directories. In this case, the namespace is LDAP://.

After the namespace, you specify the name of the server that hosts the DS containing the object. In this example, the server is a Windows NT Membership server named thucknt4. The colon and number that follow the server name specify the server's port number. (This port number is also the port that the LDAP server talks on.) If you're using Windows 2000's (Win2K's) Active Directory (AD), you don't need to supply the port number that the LDAP server runs on. Win2K resolves all AdsPaths to domain names, and the DNS server handles the resolution.

The ADsPath's next component is the root node, which is the first entity in the DS. In this case, the root node is /o=huckaby.

You can easily determine the root node, server name, and port number by right-clicking Membership Directory Manager in the MMC's treeview and choosing Properties. As Screen 4, page 12, shows, the resulting dialog box specifies this information.

The remaining components in an ADsPath specify the object's unique location in the DS. In this example, /ou=members denotes that the object you want to instantiate is the Members container. This example has only one segment to the unique location. Depending on what you want to enumerate, you might have to include more segments. For example, if you want to enumerate the attributes of the user Tim that resides in the Members container, you need to specify the ADsPath

"LDAP://thucknt4:1003/o=huckaby/ou=members/cn=tim"

If your DS isn't so flat, the AdsPath might look something like

"LDAP://thucknt4:1003/o=huckaby/ou=extranet/ou=USA/ou=   California/ou=members/cn=tim"

The rest of the code in Enumerator.asp is straightforward. The outer For Each...Next loop iterates each member of the Members container. The inner For Each...Next loop iterates each attribute of each member. (For more information about using ADSI in ASP code, see Steven Hahn, ADSI ASP Programmer's Reference, Wrox Press, 1998.)

You can use Visual InterDev, Notepad, or another editor to create Enumerator.asp. After you create this script, follow these steps to execute it:

The Choice Is Yours
To add custom attributes to the DS, you can use the MMC to manually add attributes and their values. However, this process is time-consuming. The alternative is programmatic manipulation of the DS with either the AUO object or ADSI. Although ADSI is more difficult to use than AUO because of its syntax, ADSI offers the advantage of increased performance and better control of your DS. Next month, I'll delve deeper into how to use ADSI with ASP and show you how to add users to membership groups.