Defining custom attributes for member URLs

The steps on this page describe how to define custom attributes for member URLs

About this task

Custom attributes for the OrgEntityAdd, OrgEntityUpdate, UserRegistrationAdd, and UserRegistrationUpdate URLs can be defined using the MBRATTR and MBRATTRVAL database tables, as follows:

  • The MBRATTR table supports the definition of custom attribute types.
  • The MBRATTRVAL table is where the values for these custom defined attribute types get persisted.

To define a custom member attribute:

Procedure

  1. Add the entry to the MBRATTR table. The columns of the MBRATTR table are as follows:
    Column name Description
    MBRATTR_ID Primary key of this MBRATTR table.
    ATTRTYPE_ID Type of the member attribute; foreign key to the ATTRTYPE table.
    NAME Name of the member attribute.
    DESCRIPTION Description of the member attribute.
    OPTCOUNTER Reserved for HCL internal use.
  2. Assume that you want to create a new attribute called corporateemail. This would be a string representing the user's internal e-mail account. You can create the entry in the MBRATTR table as follows: 
    
insert into MBRATTR (MBRATTR_ID, ATTRTYPE_ID, NAME, DESCRIPTION)
values (1,'STRING','corporateemail',NULL)
  3. Now that you have the custom attribute, you can use it in the registration flow. The values for these attributes are stored in the MBRATTRVAL table. The type of the attribute will dictate what columns get filled.
    Column name Description
    MBRATTRVAL_ID Primary key for this table.
    STOREENT_ID The store entity to which this attribute value for this member applies.
    MEMBER_ID The member to which this attribute value applies. Foreign key to the MEMBER table.
    ATTRTYPE_ID Type of the member attribute value. Foreign key to the ATTRTYPE table.
    MBRATTR_ID The attribute that this value is associated with. Foreign key to the MBRATTR table.
    FLOATVALUE If the type of the attribute value is FLOAT, then this column will hold the attribute value. If the type is not FLOAT then this column will be NULL.
    INTEGERVALUE If the type of the attribute value is INTEGER, then this column will hold the attribute value. If the type is not INTEGER then this column will be NULL.
    STRINGVALUE If the type of the attribute value is STRING, then this column will hold the attribute value. If the type is not STRING then this column will be NULL.
    DATETIMEVALUE If the type of the attribute value is TIMESTAMP, then this column will hold the attribute value. If the type is not TIMESTAMP then this column will be NULL.
    OPTCOUNTER Reserved for HCL internal use.

Results

Using custom attributes in the registration flow

Refer to the links below for descriptions of, and information about how to add custom attribute to the command request for, the UserRegistrationAdd or UserRegistrationUpdate commands. You must first ensure that the attributes are defined in the MBRATTR table; then you can use them by adding parameters to the request in the following format:

& attributeName_storeId_action_number=value

Where:

attributeName
Matches the NAME column in the MBRATTR table.
storeId
The STOREENT_ID of the store (from the STOREENT table). "null" can be used to specify that the attribute is store independent.
action
Can be either a (for add), r (for replace) or d (for delete).
number
An attribute that can be used if you want to store multiple values for the same attribute.
Example 1: Corporate e-mail

The first example is the corporate e-mail attribute that was created earlier. To add a corporate e-mail value, add the following parameter:

&corporateemail_null_a_null=myemail

This creates an entry in the MBRATTRVAL table with the value myemail in the STRINGVALUE column.

Example 2: Corporate e-mail, store specific

The second example uses the same attribute, but now we store it in a store dependent way. This is useful if you want to capture different values for the same attribute, depending on the store:

&corporateemail_10001_a_null=myemail

This would again create an entry in the MBRATTRVAL table with the value myemail in the STRINGVALUE columnf, but would also add the store identifier 10001 to the STOREENT_ID column.

Example 3: Corporate e-mail, multi-valued

The third example again builds on the previous example, but supporting multiple values for the same attribute:

&corporateemail_10001_a_1=myemail&corporateemail_10001_a_2=myemail2

This creates two entries in the MBRATTRVAL table, the first storing myemail in the STRINGVALUE column, the second storing myemail2 in the STRINGVALUE column.

The following is an example showing how the custom attribute blue is populated in the database:

  1. After adding the attribute color to the MBRATTR table, the following information is available from the MBRATTR table:
    • MBRATTR_ID: -28
    • ATTRTYPE_ID: STRING
    • NAME: color
  2. Run the following command:

    https://myhostname/webapp/wcs/stores/servlet/UserRegistrationAdd/UserRegistrationAdd?logonId=user1&logonPassword=letme5in&logonPasswordVerify=letme5in&URL=/&color_null_a_null=blue

  3. After running the command, the attribute value blue is populated in the MBRATTRVAL table:
    • MBRATTRVAL_ID: 10001
    • MEMBER_ID: -2
    • ATTRTYPE_ID: STRING
    • MBRATTR_ID: -28
    • STRINGVALUE: blue