Profiling System

You can use the Commerce Server Profiling System to aggregate data from multiple data stores such as Active Directory (Lightweight Directory Access Protocol (LDAP) version 3.0), and SQL Server.

By using the Profiling System you can store data in the data store that is most appropriate for the usage profile.

• Directory services are usually optimized for read-only operations, because of inherent security features.
• SQL Server is optimized equally well for read and write operations, but has fewer inherent security features.
• You should use Active Directory to store data that is mostly static throughout a visit to your site, or data that must be secured with ACLs.
• Use SQL Server to store data that is volatile throughout a visit.

For example, Active Directory is based on a hierarchical LDAP model, which is excellent for fast, single-item retrieval. Attributes stored in Active Directory are easily available to other applications that might be running in the data center. Examples of attributes that might best be stored in Active Directory are User Name, Address, and City.

In contrast, Commerce Server-specific attributes that are volatile, such as date of last purchase, should be stored in a SQL Server database, to take advantage of the capacity of SQL Server to handle high rates of updates. Data availability can vary significantly, depending on what combination of data stores you use to maintain the data.

To generate a large-scale, highly available Profiles database, you should use a hash-based partition cluster of servers running SQL Server based on Windows Clustering. Hashing assigns a user to a particular Profiles partition.

The following figure shows how you might set up a hash-based partition cluster of SQL Server servers. Each Profiling System server is running Windows Clustering.

The following figure shows Windows Clustering in an active-passive configuration with a shared disk.

Note

• If you use the partitioned architecture described in this section, you should create partitions before you begin. If you add partitions after your site contains user data, you will have to remove and restore user data to be sure that it is stored in the correct partition.

The Profiling System opens a database connection, reads configuration information, and builds a profile configuration cache from that information. Connections to the database are pooled and have built-in retry logic if a connection is lost.

Access to the Profiling System is initiated in the Application_OnStart function in Global.ASA. Subsequently, the Web application accesses the Profiles database and underlying profile data stores through the Profiling System, Profile objects, and the OLE DB Provider for Commerce Server (using Active Directory objects). The Profiling System single-point-of-failure dependencies are:

• The AppConfig object (to find the Profiles database connection string).
• The Administration database.
• The Profiles database (to find schema, site terms, and expressions information).
• SQL Profile data stores.
• Active Directory LDAP data stores.
• LDAP data stores.
• Third-party OLE DB/ODBC data stores.

See Also

Running the Profiles Resource

Business Desk Profiles

Copyright © 2005 Microsoft Corporation.
All rights reserved.