Profile Definitions

Article
11/12/2009

A profile definition is a set of characteristics that define any business-related item, such as a user, a company, or a business process. If your site developer used a Solution Site to build your site, you should have the following five sample profile definitions:

Address
BlanketPOs (purchase orders)
Organization
Targeting Context
User Object

Before you create new profile definitions, first determine where the profile data will be stored in the database, and add the appropriate table and columns for the data. For example, assume the business manager requests a new profile definition named Music, and wants to store the following profile properties: First Concert, Last Concert, Favorite CD, and two more properties that are not yet determined. You determine that the best place to store this data is in a new table named Music, in a new SQL Server database named Arts. To create the Music profile definition, you do the following:

Use SQL Server Enterprise Manager to:
1. Create the SQL Server database named Arts.
2. Create the Music table in the Arts database, and add columns for the five data members that are to be stored there.
Use the Profiles resource to:
1. Map to the new data source, Arts. You only need to perform this step once. After you have mapped a new data source to the Profiles resource, you do not need to do so again.
2. Create a data object named Music and map it to the Music table in the Arts database.
3. Create data members named First Concert, Last Concert, Favorite CD, Placeholder1, and Placeholder2, and map them to the appropriate columns in the Music table.
The following figure illustrates how elements in a SQL Server database, the Profiles resource, and a profile definition map to each other.

For detailed instructions about using the Profiles resource to extend your profiles schema, see Running the Profiles Resource.

After you create the profile definition and the properties, the business manager can use the Profile Definition Designer module in Business Desk to add First Concert, Last Concert, and Favorite CD to the definition. To perform this step, the business manager maps these properties to the data members you created, so you need to provide the data member names. If you want to map the properties to the data members, you can do so by using Commerce Server Manager.

At a later date, when the business manager determines other information to collect by using the Music profile definition, the business manager can use the Profile Definition Designer module to create two new properties and map them to the placeholder data members you created in the Music table.

The Commerce Server Solution Sites include the following sample profile definitions: Address, BlanketPOs (purchase orders), Organization, User Object, and Targeting Context. In the User Object profile definition, five unnamed properties are included so you can add properties to the User Object profile definition without extending your database. For a list of properties included with each profile definition, see Sample Profile Definitions.

Profile Definition Keys

You must define one or more keys for every valid profile definition. You can identify unique, primary, join, and hashing keys by examining the Key type property in the Advanced Attributes section in the Profile Definition Designer module of Business Desk or in the profile definition of the Profiles resource in Commerce Server Manager.

Unique Key

A unique key indicates that the value of this property is unique for all members. You map an attribute that is specified as a unique key to a unique field in a SQL Server database or to a unique attribute in a Lightweight Directory Access Protocol (LDAP) source.

Every profile definition property marked as a key has the Unique Key**attribute turned on. Only properties of string or numeric data types can be marked as keys. A profile definition can have any number of keys, although from a performance and memory perspective, it is better to have as few keys as possible.

All core profile object management operations in the Profiling System (CreateProfile, GetProfile, GetProfileByKey, DeleteProfile, DeleteProfileByKey) work with key members only. The Profiling System does not guarantee the uniqueness of properties that are marked as unique keys. Instead, it relies on constraints on objects in the underlying data stores (tables for relational databases or classes for directory stores) to implicitly enforce uniqueness.

Primary Key

A primary key indicates that the value of this property is unique for all members. You map an attribute that is specified as a primary key to a primary field in a SQL Server database or to a unique attribute in an LDAP source. The primary key is used to relate profiles created with embedded profile definitions.

Every profile definition must have exactly one unique key property marked as a primary key. You should mark the profile property most commonly used to operate on profile object instances as the primary key.

A primary key is identified by a red "P" or a green "D" (for a dual primary and join key) that precedes the property in the Profile Designer module of Business Desk or in the profile definition of the Profiles resource in Commerce Server Manager.

Join Key

A join key relates multiple data stores through a common property in the Profile Service. To edit a property that is defined as a join key that has been used to collect data, you must delete the database columns containing the join key data. After you delete the database columns, you must migrate the old data into the new database columns. Commerce Server 2002 does not support modifying the join key property when you have persisted data.

Every profile definition must have exactly one unique key property marked as a join key. For optimal performance, you should also mark the primary key on the profile definition as the join key. If you do not provide a value for the join key property when you create the profile object, then the Profiling System automatically generates a value for this member.

A join key is identified by a blue "J" or a green "D" (for a dual primary and join key) that precedes the property in the Profile Designer module of Business Desk or in the profile definition of the Profiles resource in Commerce Server Manager. The Profiling System uses the join key property to assemble profile object fragments stored in multiple data stores. Join key property values are replicated across all data stores.

Ee797370.note(en-US,CS.20).gif Note

After the join key property has been committed to the underlying stores, it cannot be updated.

Hashing Key

Every profile definition can have one unique key property marked as the hashing key. The profile aggregation layer uses the hashing key property to hash a profile object to a unique partition within a data source. The presence of a hashing key property is the only way to indicate that instances of a profile definition will be stored across multiple partitions of a data source. The absence of this property results in all profile instances being stored in the default partition.

You should mark the join key on the profile definition as the hashing key. For optimal performance, you should mark the same property as the primary key, the join key, and the hashing key.

You can identify a hashing key by examining the Advanced Attributes/Hashing key in the Profile Designer module of Business Desk or in the profile definition of the Profiles resource in Commerce Server Manager.

Ee797370.note(en-US,CS.20).gif Notes

After the profile object has been committed to the underlying stores, the hashing key property value cannot be updated.
For partitioned ANSI SQL stores only, profile object retrieval operations based on a non-hashing key and the GetInfo method of the ProfileObject object could fail. However, this is not true for LDAP version 3-compliant stores.