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


USERS
This table contains all users of the WebSphereCommerce system: registered users, guest users, and generic users.
USERREG
This table stores user authentication information.
USERREPROF
This table contains basic registered user profile information.
USERDEMO
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

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.

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


Tables Involved

MBRGRP
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.
MBRGRPDESC
This table contains locale specific information for the entries in the MBRGRP table.
MBRGRPTYPE
This table stores intended usages that can be associated with member groups.
MBRGRPMBR
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.
MBRGRPCOND
This table stores the conditions for an implicit member group.
MBRGRPUSG
This table allows a member group to be associated with multiple member group types (or multiple intended usages).

Other Tables involved:

BUSPROF
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.
MEMBER
Stores the list of members (participants) of the WebSphereCommerce system. A member is a user, an organizational entity or a member group.
MBRATTR
This table contains the custom member attributes available to be assigned to users and organizations.
MBRATTRVAL
This table contains the custom member attributes available to be assigned to users and organizations.
ATTRTYPE
This table holds the type identifier for attributes.
MBRREL
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.
ROLE
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.
MBRROLE
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.
MEMBRAUCT
This table describes the relationship between a member and an auction.
BUYSUPMAP
This table is used to register the buyer organization using procurement systems with supplier organizations.
ORGENTITY
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.
ADDRESS
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). 


ADDRBOOK
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.

Member Subsystem Commands

LogonCmdImpl
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

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)

UserRegistrationAddCmdImpl
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.


UserRegistrationUpdateCmdImpl
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.

OrgEntityAddCmdImpl
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.

OrgEntityUpdateCmdImpl
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.

AddressAddCmdImpl

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".

AddressDeleteCmdImpl
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.

AddressUpdateCmdImpl 

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.


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

AdminResetPasswordCmdImpl
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.


ResetPasswordCmImpl
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.


RunAsUserSetInSessionCmdImpl
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.

RestoreOriginalUserSetInSessionCmdImpl
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.

BuyerRegistrationAddCmdImpl
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


BuyerUserRegistrationUpdateCmdImpl
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.

ResellerRegistrationAddCmdImpl
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:
UserRoles
Defines the roles that a user would automatically receive in an organization during registration.
OrganizationRoles
Defines defines the roles that an organization would automatically receive during registration.
BusinessEntities
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.
RegistrationParents
Defines where to create new users or organizations for a particular registration type.




10 comments:

  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...?

    ReplyDelete
  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...?

    ReplyDelete
  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


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

    ReplyDelete
  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 ..

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

    ReplyDelete
  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.

    ReplyDelete