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
- 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 IBM internal use. - 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)
- 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 IBM 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:
- 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
- Run the following command:
https://myhostname/webapp/wcs/stores/servlet/UserRegistrationAdd/UserRegistrationAdd?logonId=user1&logonPassword=letme5in&logonPasswordVerify=letme5in&URL=/&color_null_a_null=blue
- 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