Understanding Attributes
Attributes enable you to extend the information stored for an object without modifying that object's base table. This is valuable when you want to capture information about a subset of object instances. For example, you might need to capture the color and size attributes for certain types of products, but not for all products. Because these attributes are relevant only for some products, you do not want to add them as fields to the base table itself.
This section discusses:
Attribute-enabled objects.
Attribute architecture.
Implementation considerations.
Objects must be configured to accept attributes. You can define an unlimited number of attributes for any object that is configured to accept attributes.
The list of attribute-enabled objects are case, company, consumer, external order capture, installed product, lead, marketing campaign, opportunity, order capture line, product, contact (representative), and site.
When you define an attribute, you establish the field label, the type of field (edit box or drop-down list box), the default value, any data validation rule, and drop-down items if applicable. You also associate it with an attribute group.
You associate attribute groups with PeopleSoft CRM objects. When you make this association, you optionally define the conditions under which the attributes are used.
For example, suppose you want to enter dimensions for products in a certain setID. (If you had wanted to enter dimensions for all products, you probably would have used PeopleSoft Application Designer to modify the product table instead of using attributes.) You would do the following:
Create an attribute group called Dimensions.
Create attributes for height, length, and width and associate them with the Dimensions attribute group.
Associate the Dimensions attribute group with the Product object and set up conditional logic to ensure that these attributes are used only for products in the specified setID.
Assuming that you have not associated any other attribute groups with products, the system behaves as follows:
When you view a product from the specified setID, the Product - Attributes page has three fields: Height, Length, and Width.
When you view a product from a different setID, the Product - Attributes page does not have any fields.
While you can use attributes to add data elements without changing the underlying data model, attributes also affect performance, your ability to upgrade, reporting, and usability in the following ways:
Because attributes appear in a separate attribute table and are not fields on the base table, there is additional SQL and logic for capturing and retrieving attribute data.
There is also additional SQL and PeopleCode for processing the attribute rules, conditions, and page rendering logic.
Attributes do not fall under the normal upgrade capabilities that are provided with PeopleTools.
Although attributes share many characteristics with fields, they are not considered PeopleTools objects. Therefore, you cannot use standard upgrade facilities that are provided by PeopleTools, such as the Upgrade Copy or Upgrade Compare process, to upgrade attribute data from one database to another. To migrate attributes, you extract the data from the source database and move it to the target database, which is usually accomplished through Data Mover or similar tools. PeopleSoft CRM, however, does not deliver facilities for migrating attribute data.
Because attribute data elements are in a separate attribute table (distinct from the base table), it can be difficult to incorporate attribute information into reports.
Usability may be limited because attributes can only reside on a separate page within the transaction.
For example, a product attribute must appear on the Product - Attributes page; it cannot be placed on the Product Definition page. However, you can customize the system to display attributes on a page with non-attribute data elements. In addition, attributes can only be displayed in a name, value pair format.
Performance issues occur if you have too many attributes in the system.
Don't use attributes because they are easier to create than standard PeopleTools fields. Use attributes only if the data elements are truly dynamic in nature, or if they apply to certain instances of an object only.
The decision to add attributes to your application should be based on how applicable the data objects are to instances of the object. If the data elements apply to a significant number of instances of the object, then it may be better to add a field to the table using PeopleSoft Application Designer. If the data elements apply to a much smaller percentage of the objects, then attributes may be the solution.