User registration and post registration flow

UserRegistrationAdd flow

• Calls an empty task command called PreUserRegistrationAddCmd. The responseProperties contains the new userId and addressId parameters. Store Developers can override the command to perform more operations.
• Updates the record of the current guest customer in the USERS table and changes the registration type from 'G' (guest) to 'R' (registered) and populates the DN.
• Creates a record in the USERREG table. If the authentication mode is LDAP, the logonId field in the USERREG table stores the DN of the user. The logon password is only stored on the LDAP server, not in the USERREG table. The user's position in the membership hierarchy is stored in MBRREL table.
• If one or more fields that are related to the USERPROF, BUSPROF or USERDEMO tables are specified, a new record is created in these tables; otherwise, no record is created.
• A self address (also called a registration address, with the selfAddress field set to '1' and the nickname the same as the logonId) is created. Each user can have only one self address. To find the selfAddress, use the AddressAccessBean.findSelfAddressByMember(Long memberID).
• If the logonPassword is changed, the URL calls the AuthenticationPolicyCmd task command to verify or update a user's credentials.
• Calls the ProcessParentMemberCmd task command to validate the parentMember. If the parentMember is null, the default parent is the Default Organization (that is, the orgEntityId = -2000). If the parentMember is not null, it can take two different types of values:
• Encrypted orgEntityId (that is, using "wcs_encrypt -e orgentityId")
• DN of the organization or organizational unit (such as "o=Default Organization or o=Root Organization").
• Calls the ProcessProfileTypeCmd task command to determine and validate the profileType. If the profileType is not specified, and the parentMember is not specified or if it is the Default Organization, by default, the profileType is set to 'C' and a B2C user is created. If the profileType is not specified and the parentMember is not the Default Organization, by default, the profiletype is set to 'B' and a B2B user is created.
• Calls the AuthenticationPolicyCmd task command to verify or update a user's credentials.
• If preferredCurrency is not specified, the default is the preferred currency in command context.
• If a new address needs to be created but the addressType is not specified, the default is 'SB' (shipping and billing address).
• Checks the required registration information parameters.
• Calls the AuditUserRegistrationCmd task command to check more parameters. Store Developers need to add new code to the AuditUserRegistrationCmd task command if they want to customize the check.
• Calls the SetCurrencyPrefCmd task command to set preferred currency to command context.
• Calls the UserRegistrationRoleAssignCmd task command to assign roles during self-registration. This command requires customization needs to be overridden by a Store Developer to enable role assignment during self-registration.
• If the authentication mode is 'LDAP', a user entry is created on the LDAP server.
• Calls an empty task command called PostUserRegistrationAddCmd. Store Developers can overwrite it to perform more operations.
• If the command fails, the UserRegistrationErrorView view command is called. Upon successful completion, the specified URL is called.
• Reads the MemberRegistrationAttributes.xml file. Specifically, it reads the <UserRoles> element and applies the roles that have a qualifier of registrationQualifier="UserRegistration".
• Applies the roles that have the qualifier 'UserRegistration'. The MemberRegistrationAttributes.xml file lists the default roles that the customer plays (for example, a registered customer in the store to which they are registering). The Site Administrator can configure this file to assign roles that are based on the organization to which the user registers and the store from which they are registering. More roles can be applied using the Organization Administration Console.

Note: WebSphere Commerce does not support the concurrent login of two or more users that log in using the same user ID. For example, consider the scenario where two users at a company regularly share an account at a store. Suppose that the first user is on the store's payment page, and just before the user submits their order, the second user logs in. The following is what takes place:

1. Browser one ... User 1 logs in as user "xyz"; adds an item to the shopping cart.
2. Browser two ... User 2 logs in as user "xyz" as well, and goes to the shopping cart page and then proceeds to checkout.
3. Browser one ... User 1 clicks checkout, but is informed that they are logged off.
4. Browser two ... User 2 completes the checkout, as normal.

Another scenario is when businesses use a common user ID for their employees to shop at a B2B store. Only one user should use the common user ID at a time, or each user should be set up with their own user ID. Otherwise, one of the users are likely unable to complete their transaction.

You can enable multiple logon support to allow for the same authenticated user to use the site from multiple browsers or locations. By enabling this support, two or more users can log on using the same user ID.

UserRegistrationUpdate flow

• Note that the parent member and the profile type of the user cannot be changed.
• Calls an empty task command called PreUserRegistrationUpdateCmd. Store Developers can overwrite it to change the input to the command.
• Updates the record of the current registered user in the USERS table.
• If the authentication mode is 'LDAP', a user information may also be updated on the LDAP server.
• If the authentication mode is 'LDAP', the logonId cannot be changed.
• If one or more fields related to the USERPROF, BUSPROF or USERDEMO tables are specified, updates each of these tables. If there is no record, creates a new record in these tables.
• If one or more fields related to the ADDRESS table are specified, the self address (also called the registration address, with the selfAddress field set to '1') will also be updated. The old address will be marked as 'T' (temporary) and a new record will be created in the ADDRESS table. If this user does not have self address, a new self address will be created.If the logonPassword has been changed, calls the AuthenticationPolicyCmd task command to verify or update a user's credentials.
• Checks required registration information parameters.
• Calls the AuditUserRegistrationCmd task command to check additional parameters. Store Developers need to add new code to the AuditUserRegistrationCmd task command if they want to customize the check.
• Calls the SetCurrencyPrefCmd task command to set preferred currency to command context.
• When LDAP is used, the user is created in both the database and on the LDAP server. The authentication information is stored only in database, but all other information is replicated back to the database.
• Calls an empty task command called PostUserRegistrationUpdateCmd. Store Developers can overwrite it to perform additional operations.
• If the command fails, the UserRegistrationErrorView view command is called. Upon successful completion, the specified URL is called.
• When the user is created using this command, the system assigns roles based on the MemberRegistrationAttributes.xml file. When choosing the roles to assign, the system uses the following information: the RegistrationType of 'UserRegistration', the member ancestor tree for the user, and the store to which the user is registering.