Websphere Commerce Member Subsystem

Organization Structure
B2C Direct Business Model
B2C Direct Business model consist of root organization, default organization and seller organization. Root organization and Default organization are created during instance creation. Seller organization and B2C organization are created during store publish process.

B2C Organization Structure

Root organization
All organizations in the business become child of the root organization.
Default organization
All of the online users are owned by the default organization. The default organization is a child of the Root Organization.
Seller organization
A seller organization is created to own all the stores (Retailer)
B2C organization
A B2C organization owns a single store (Retailer). 

B2B Direct Model
B2B Direct Business model consist of root organization, default organization, seller organization and buyer organization. Root organization and Default organization are created during instance creation. Buyer organization, Seller organization, and B2B organization are created during store publish process.

B2B Orgnization Structure

Root organization
All organizations in the business become child  of the root organization.
Default organization
Customers who do not register as part of a buyer organization belong to the default organization.
Buyer organization
Customers in B2B direct businesses as buyers are represented by a buyer organization in the B2B organization structure. Individual users, who belong to buyer organizations, must register under their respective organization.
Seller organization
A seller organization is created to own all the organizations that own stores .A child organizational unit (ou), B2B organization, is created under the seller organization to own the individual store (Business).

IBM WCS Member Subsystem
Member can be a user, a group of users (member group), or an organizational entity (which can be an organization, such as "Google" or a unit within an organization, such as "Google Ads Division"). Member subsystem provides services like authentication, registration, profile management, accescontrol and session management.

Different Types of Users

Generic User 
A user who browses the catalog and didn’t do any operation which will uniquely identify the user like add an item to cart is called generic user. Generic user will share a common user ID across system. The generic user (-1002) is a common user that is used for operations that are not specific to a particular member. For example, for operations such as displaying a category or product, the user is allowed to execute the commands using the generic user id, minimizing resource usage.

The creation of new guest users is controlled by the isGeneric method of the ControllerCommand interface. This method returns a Boolean value which specifies whether or not the command can be invoked by the generic user. By default, this method returns a value of false. That is, the invoker must be either a registered customer or a guest customer. If your new controller command can be invoked by generic users or does not fetch or create resources associated with a user, you should override this method to return a value of true.

A command that can be invoked by a generic user (isGeneric = true) is the ProductDisplay command, since it is not necessary to create a new user object for browsing. An example of a command for which a user must be either a guest or registered user (isGeneric = false) is the OrderItemAdd command.

The below custom controller command that overrides the isGeneric() method to allow the execution of the command by generic users:

public class ExtendedProductDisplayCmdImpl extends ProductDisplayCmdImpl  implements ProductDisplayCmd
public void performExecute() throws ECException {
public boolean isGeneric() {
//This command can be run by a generic user
return true;

Guest User 
A Generic user becomes Guest User when add an item to the cart  and hence a unique temporary id needs to be associated to the user. Once the user session is over,the existing guest user id is of no use for further user sessions. GuestUser is a user with unique userId whose REGISTERTYPE will be  'G' in USERS Table.

If your database is being populated with users which have no associated orders, it is possible that the catalog pages (such as CategoryDisplay and ProductDisplay) are forcing the creation of new ids as users navigate the site.

Registered User
When the same user registers REGISTERTYPE for the same userId will be changes to 'R' in  USERS Table .In addition additional records are created in  profile specific tables like USERREG, ADDRESS, USERPROF, USREDEMO .

A registered user has a unique logon ID and password, and is required to provide some profile data for registration purposes. The user would typically have the Registered Customer role in the current store's organization. Other roles can be automatically assigned during registration by configuring the MemberRegistrationAttributes.xml file. If the user is assigned the Site Administrator role, its registration type would be changed to "S" (Site Administrator). If the user is later assigned any other administrative role, like Customer Service Representative, the user's registration type would change to "A" (Administrator)

Tables Involved

This table contains all users of the WebSphereCommerce system: registered users, guest users, and generic users.
This table stores user authentication information.
This table contains basic registered user profile information.
This table stores demographics information for users.

Member groups

Member group consists of grouping of members like users,oraganizatios or other member groups.
Two types of member groups exits
1. Implicit Member Group
2. Explicit Member Group

Tables Involved

This table stores member groups defined in the WebSphere Commerce system. A member group is a group of members. Membership is restricted to users within a member group.
This table contains locale specific information for the entries in the MBRGRP table.
This table stores intended usages that can be associated with member groups.

This table allows a member group to be associated with multiple member group types (or multiple intended usages).

Explicit Member Group 
Explicit member group is formed by explicitly exclude certain users although they satisfy the criteria. Explicit member group members may or may not have common attributes.
Note: A member group can belong to both implicit and explicit at a time

This table contains members that are explicitly included or excluded from a member group. This works in conjunction with the implicit inclusion rules that are specified by MBRGRPCOND table. If both implicit and explicit criteria are specified, the following algorithm is used to evaluate if a member belongs to a member group: Explicit exclusion takes first precedence, then explicit inclusion, and then finally implicit inclusion.

Implicit Member Group 

An implicit member group contains users that share common attributes and are therefore considered members of a specific member group. An implicit member group specifies criteria on attributes that users must satisfy in order to be considered as members of that member group.

This table stores the conditions for an implicit member group.

Other Tables involved:

This table stores business profile information for a user. It is populated by the user registration commands. It is intended to be populated for users with profile type (USERS.PROFILETYPE) of "B", signifying that this is business user.
Stores the list of members (participants) of the WebSphereCommerce system. A member is a user, an organizational entity or a member group.
This table contains the custom member attributes available to be assigned to users and organizations.
This table contains the custom member attributes available to be assigned to users and organizations.
This table holds the type identifier for attributes.
This table stores member hierarchy relationships (ancestors and descendants) of organizational entities and registered users. Note that member groups are not part of the member hierarchy.
This table stores the roles defined in WebSphere Commerce. Once a role is created, you cannot change the name or description of a role using a graphical user interface tool.
This table stores role assignment for members. Each member can play one or more roles in the WebSphere Commerce system. When a member is assigned a role, the orgEntity for which the member plays that role can also be specified.
This table describes the relationship between a member and an auction.
This table is used to register the buyer organization using procurement systems with supplier organizations.
This table contains information on organizational entities (OrgEntities). An OrgEntity is either an organization or an organization unit. Authorization domains are also stored in this table.
This table stores the addresses of users or organizations in the WebSphere Commerce system. The addresses can be the members' own addresses or for their friends, associates, or clients, and so on. Some columns here replace columns used in previous versions.

Important columns in ADDRESS table are as follows
1.ISPRIMARY - A user or organization can have multiple addresses of the same address type (ADDRTYPE column). For example, a user may have multiple shipping addresses. The isPrimary column can be used to mark one of these shipping addresses as being the primary one. This may be useful when populating a drop down list of available shipping addresses as one of them can be chosen as the default option in the drop down list. Valid values are 1 (primary address) or 0 (non-primary address).
2.ADDRESSTYPE -Types of address are: S ( ship to), B ( bill to), and SB (both ship to and bill to). If this is unspecified when creating a new address, the business logic will default to SB.
3.SELFADDRESS- Specifies the address that is associated with the registration of the user or organization. Valid values are 1 (the address is the registration address) or 0 (the address is not the registration address). A user or organization can have only one permanent self-address. An example of an address that is not a self-address would be an alternate shipping address or an address of a friend or relative.
4.STATUS- Specifies the status of the address. Valid values are P (permanent or current) and T (temporary or historical). 

This table contains information about an address book. An address book is a container for addresses owned by a member. A member can only have one address book.

Personalization ID
When a customer visits the site for the first time as a generic user (without logging into the site), a unique personalization ID is placed in their WC_PERSISTENT cookie. This cookie is used to persist user ID, personalization ID (if enabled), language ID, and currency for each store ID visited in the session.

The personalization ID remains the same throughout the session as long as WC_PERSISTENT cookie is present. If this customer becomes a guest user, the personalization ID is associated with their guest member ID. If the customer becomes a registered user, the personalization ID is associated with the registered member ID. If the customer leaves the site as a guest user, and later returns to the site, they are assigned a new guest member ID. However, the same personalization ID is now associated with the previous guest user ID, and the new guest user ID.Since personalization ID can be used for generic or guest users, it allows merchandiser to configure marketing activities for generic and guest user.

Enabling Personalization ID

By default personalization id is switched off in WCS. if your USERS table you will notice that personalizationid column is null, this indicates personalizationid is switched off.

select PERSONALIZATIONID from users;

To enable personalization id in toolkit. edit the instance.xml file


search for "<PersonalizationId  display="false" enable="false"/>" , 
change the value of enable to true and save and restart the WCS instance.


If  this is configured, a newpersonalizationID will be created in WC_PERSISTENT cookie when the user logs off. By default, it is not configured and the personalizationID will still be the same as the registered user who tries to logoff.

To enable it, need to add "logoffRefresh="true"" element in instance xml. See the following:

 <PersonalizationId display="false" enable="true"  logoffRefresh="true"/>

Migrate Guest Orders Event Listener for guest user  where  persistent session is enabled

When persistent sessions enabled and a guest shopper adds an item to their shopping cart, a guest user is created. If the shopper closes and then opens their web browser again, they can still view the item within the shopping cart. When the shopper adds another item to their cart, or performs an action that is not allowed with persistent sessions, a new guest user is created. With second guest user created, the enablement of the event listener determines the shopping cart contents. If enabled, the  first guest user shopping cart is migrated to second  user and the contents of the cart are merged. This migration provides the shopper with a consistent shopping experience without the shopper knowing that a second guest user session is created.

GuestUserOrderResetEventListener has a migrateOrders() method.This method migrates the pending order of the previous guest user to the current guest user.It calls the GuestUserOrderResetCmd to perform the following steps.
Set the member_id of the orders and order items to the new guest user. Clears out sensitive data of the order.

<component compClassName="com.ibm.commerce.order.event.GuestUserOrderResetEventListener"      enable="true" name="Migrate Guest Orders Event Listener">
      <property display="false">                <start enabled="true"/>


Member Subsystem Commands

This command helps to login a user into a site or store. User should have role in current stores organization and users account should be an approved one and is enabled. If the credentials are valid and LDAP mode is used then roles specified in MemberRegistrationAttributes.xml will be assigned to user. AccountLockoutPolicyCmd will be called in the case of non LDAP authentication to update policy information of user which includes account lockout policy and password policy.

If the user is authenticated successfully then user’s resources are migrated from guest to register. MigrateUserEntriesCmd migrates resources owned by one user to another. The mandatory resources that are migrated are Addresses, Current Orders, Interest Items, Order Items, Orders, and Order templates. It migrates the guest user's shopping cart also. There is a migrateOrder method in the MigrateUserEntriesCmdImpl class which does the job. All that this method does in change the member id of the guest user's orders and orderitems to the registered user's information. But it does not do anything if the logged in user has a previous shopping cart. In that case user's past order has been deleted and order items have been migrated to the new migrated order.

If the mode used is not LDAP and if the password invalidation feature is enabled and the password is in expired state user will be redirected to change password screen.

Note: Web Sphere Commerce does not support the concurrent logon of two or more users that log in using the same user ID( till wcs7  fix pack 8)


LogoffcmdImpl will logs of current user .This command clears the session of the current user, and begins a new session as the generic user. By default this commands deletes persistent session while logs off(remember Me=false).If persistent session is enabled and rememberme=true even after log off user will be able to see the shopping cart(but not order history or address)

This command is used to register a guest or a generic user .If the parent organization of user requires registration approval, user will be allowed to login only after getting the approval. Default Organization (B2C business model) does not require user registration approval. Information for new users is stored in the MEMBER, USERS, USERREG, MBRREL, MBRROLE, USERPROF, BUSPROF, USERDEMO, ADDRESS, and ADDRBOOK database tables.

This command is used to update the registration information of a registered user. . If the current user is a guest customer, this command will call the UserRegistrationAdd command to register a new user. Information for users is stored in the MEMBER, USERS, USERREG, ADDRESS, ADDRBOOK, MBRREL, USERPROF, BUSPROF, USERDEMO, and ADDRESS database tables.

This command registers a new organization or organizational unit.This command registers a new organization or organizational unit. Information for new organizations or organizational units are stored in the MEMBER, ORGENTITY, MBRREL, and ADDRESS database tables.

This command updates information about an organization or organizational unit.This command updates information about an organization or organizational unit. If orgEntityId parameter is not specified, OrgEntityAdd command will be called to add a new organization or organizational unit. Information for the organizations or organizational units are stored in the MEMBER, ORGENTITY, MBRREL, ADDRESS and ADDRBOOK database tables.


This command adds a new address entry for a user or organization.When an address is created, its status is marked with a "P", meaning "permanent", and indicating the current address. When an address is updated, a new record of the address is created with the updates. The new record is marked with a "P" and the earlier record is marked with a "T", meaning "temporary", and indicating the historical address.When an address is deleted with the AddressDelete command, its status is marked with a "T".

This command deletes an address for a user.If address exists, the address is marked as temporary or historical (that is, STATUS=T). The command then returns a success page defined by the URL parameter. If the address already has status T, the success page is returned regardless.


This command updates the address entry for a user. If the addressId parameter is not provided, the AddressAdd command is called to add a new address. The nickname cannot be updated. Inserts a new address into the ADDRESS table with the specified nickname. The old address is marked as temporary, and the new address is marked as permanent.

This command determines whether a user has at least one permanent address.

This command is used by Administrators, to reset the password of a registered user (if the registered user has forgotten his or her current password). The new password is then randomly generated by the system and then an e-mail will be send to the registered user.

This command is used by Registered users and administrators to update their own passwords. Registered users who want to log on but have forgotten their password. They use this command to reset their password without logging in.A randomly generated password is e-mailed to the guest customer.

User who is doing this command should have register type as “A” and should swith to a user of type “R”.This command allows administrators with the required authority to run subsequent commands in the same session under a specified customer's identity.

This command resets the session for subsequent commands so they revert back to the original administrator user ID after an administrator has established the runAsUser value in the session by running the RunAsUserSetInSession command.

This command creates a registration record for a Buyer, which includes an organization and a user.After the Buyer is registered, the Buyer can only log onto the system after approval. By default approval is turned on. Information for new users are stored in the MEMBER, USERS, USERREG, MBRREL, USERPROF, BUSPROF, USERDEMO, and ADDRESS database tables.A B2B direct or B2B indirect user can be created by specifying the profileType to have a value of 'B' and may need to be approved.Thus, the BuyerRegistrationAdd URL first calls the ResellerRegistrationAdd URL, which in turn calls the OrgEntityAdd URL and the UserRegistrationAdd URL

This command  is used to register a B2B user, or update the registration profile of a registered B2B user. If the current user is a guest customer, this command will call the UserRegistrationAddPreApproval command to register a new user. If the user is a currently logged on registered user, the UserRegistrationUpdate command will be invoked to update the registration profile. Information for users are stored in the MEMBER, USERS, USERREG, MBRREL, USERPROF, BUSPROF, USERDEMO, and ADDRESS database tables.

This URL is used in business indirect scenarios. It registers a new organization and creates a new user whose parent is the newly created organization. The new reseller organization and reseller administrator are placed in pending approval state. After the reseller is registered, the reseller cannot log on until the Site Administrator provides approval. Information for new users are stored in the ADDRESS, BUSPROF, MBRREL, MEMBER, ORGENTITY, USERDEMO, USERPROF, USERREG, and USERS database tables.

MemberRegistrationAttributes XML
The MemberRegistrationAttributes.xml configuration file specifies attributes that should automatically be assigned to users and organizations during user and organization registration and some authentication scenarios(For e.g.: SSO). The XML files is located in C:\IBM\WCDE_ENT70\workspace\WC\xml\member directory. This file might be overwritten when a store is published, but a back file is kept in the same directory.

This file is divided into four main sections:
Defines the roles that a user would automatically receive in an organization during registration.
Defines defines the roles that an organization would automatically receive during registration.
Defines which organizations should automatically be defined as business entities when they are created. A business entity is an organization that can have business accounts.
Defines where to create new users or organizations for a particular registration type.


  1. Hi,
    We have option to delete orgnizations but not users.. is there any option to delete users...?
    If we deleted an orgnization, the users of that org will be deleted...?

  2. Hi,
    We have option to delete orgnizations but not users.. is there any option to delete users...?
    If we deleted an orgnization, the users of that org will be deleted...?

  3. If you create an organization org1 under root organization and if you have a user under it ,when you remove the organization MBRREL table will be updated for that user to organization relationship. In this case for org1.But user will be still be a child of root organization in MBRREL table and user data won't be deleted.If you want to remove user records you can use DBCLEAN utility or by running SQL.

    Using DBCLEAN

    For registered Users

    /dbclean.sh -object user -type registered -instancexml WebSphere/WebSphereCommerce/instances/demo/xml/demo.xml -db CD040302 -commit 500 -max 8000 -check_object_only yes

    For Guest Users

    /dbclean.sh -object user -type guest -instancexml WebSphere/WebSphereCommerce/instances/demo/xml/demo.xml -db CD040302 -commit 500 -max 8000 -check_object_only yes

  4. How do you check whether user is logged in or not?

  5. First get the userID from the Command Context <> If its "R" then You need check if SessionContext is part of HttpSessionContext or not
    (SessionContext instanceof HttpSessionContext) then u can return true if you get the session ..

  6. getCommandContext().getUser().getRegisterType()

  7. hey deepak,

    Ur post is very good.
    I am a beginner , i understood the flow and commands, ut when try to implement it in code , i got many problems.
    Do you have any posts for practical session also.

  8. Hi Deepak..
    Thanks for the great information you shared above. Keep sharing such interesting and helpful articles with us. 

    Local business listing sites india

  9. • I very much enjoyed this article. Nice article thanks for given this information. I hope it useful to many Peopledata since Online Training