Out of the box, the B2B direct business model in WebSphere Commerce 5.5 supports two buyer organizations: Buyer A Organization and Buyer B Organization. Implicitly, the model assumes that if you add buyer organizations, they are added at store development time, not dynamically. The facilities for dynamic buyer organization creation do exist. This article describes a layout that facilitates such a configuration.
This article has three parts:
- Configuring the store model, including MemberRegistrationAttributes and default organization layout.
- Creating a buyer organization.
- Creating a user under the new buyer organization.
The business model configuration includes laying out your organizational structure and setting up the dynamic role assignment. This section assumes that the B2B direct business model has already been deployed. You should be familiar with the B2B direct model as described in WebSphere Commerce V5.5 Sample Store Guide.
The proposed approach is that you create a Buyer Organization to act as a container for all your real buyer organizations. Your organizational layout looks like the following:
o=root organization |-- o=default organization |-- o=seller organization |-- o=buyer a organization |-- o=buyer b organization |-- o=buyer organization |-- o=mybuyer1 organization |-- o=mybuyer2 organization ... ....
You can create the organization "o=Buyer Organization,o=Root Organization" using the Organization Administration Console. For more details, see "Creating an organization" in the online help. Name the organization "Buyer Organization", and make the Root Organization its parent.
The next step is to create the roles in your new buyer organization. Ensure that the new Buyer Organization has all of the same roles as the default, "Buyer A Organization". The roles are:
- Procurement Buyer
- Procurement Buyer Administrator
- Buyer (buy-side)
- Buyer Approver
- Buyer Administrator
You can add these roles to the new Buyer Organization using the Organization Administration Console. This step is also documented in "Creating an organization" in the online help. By configuring your new organization to support these roles, you can later grant administrators in the system any of these roles for this organization. Since roles are inherited by granting a role at this container organization, you can effectively grant the role in any buyer organization created as a descendant of this organization. You are also specifying which roles to make available to the buyer organizations created as children of this container organization.
When a new user is registered, roles are assigned in the system based on the following criteria:
- Type of registration.
- Organization under which the user is registering.
- Store to which the user is registering.
These rules are defined in the
MemberRegistrationAttributes.xml file. For more
details, see "MemberRegistrationAttributes.xml" in the online help. With
the organization layout defined above, you can now specify that any user
registering under any child organization of the Buyer Organization is
granted the "Registered Customer" role in the store to which they are
registering. This configuration is done by adding the following code
snippet to the
UserRoles section in
<User registrationType="UserRegistration" memberAncestor="o=Buyer Organization,o=Root Organization" storeAncestor="o=Root Organization"> <Role name="Registered Customer" roleContext="storeOwner" DN="o=Seller Organization,o=Root Organization"/> </User>
A user registers with the system using the normal registration flow (registrationType = "UserRegistration"), and that user is registering to an organization that is a descendant of the organization "=Buyer Organization,o=Root Organization". The store to which the user is registering is owned by a descendant of "o=Root Organization". Grant the role of "Registered Customer" in the organization that owns the store if the store is a descendant of "o=Seller Organization,o=Root Organization". When a user registers to one of the buyer organizations in your system, they are given the role of "Registered Customer" in the store to which they are registering. You can use the same approach to grant other roles in the store.
For contract purposes, you also want to specify that your buyer
organizations represent business entities, which allow them to participate
in contracts. This is done by modifying
MemberRegistrationAttributes.xml by adding the
following line to the
<Organization registrationType="" memberAncestor="o=Buyer Organization,o=Root Organization" storeAncestor="o=Root Organization"> </Organization>
This gets checked on at each organization registration. When an organization is registered as a descendant of "o=Buyer Organization,o=Root Organization", and to any store under "o=Root Organization" (that is, to any store in the system), assign the BusinessEntity flag to this organization. This business entity flag is captured internally as a MemberAttribute in the MBRATTRVAL table. With this flag set, the organization represents a customer and can participate in contracts.
With the organization structure set up, all that is left is to restart the server to ensure that the configuration changes are picked up.
Now that the store is setup to handle the creation of buyer organizations, the next step is to create one or more buyer organizations.
Follow the same process as above for creating the Buyer Organization container. Give the new organization any name and ensure that you specify the "Buyer Organization" as the parent.
The list of roles available to the new buyer organization is the list that was assigned to the buyer organization container object created above. When setting up the new organization, configure all of these available roles to grant administrators any of these roles in your new organization.
At this point, decide whether or not you want to enable approvals for your new organization. Approvals mean that any new user registering under your new organization needs to be approved before they can shop at the store. By default, approvals are enabled. However, the approval group (the individuals with the authority to approve or reject the new registrations) is the site admin user until you change it.
To enable approvals:
Find your new buyer organization in the Organization Administration Console, and choose Approvals. Add the approval group as shown in Figure 1.
Figure 1. Approvals feature in the Organization Administration Console
This sets up the user registration approvals for your new organization. By clicking OK, you create a member group for the users that you want to act as approvers for this organization. When a new user tries to register with the system, his or her registration is in pending approval state until one of these administrators logs on to the administration console and approves the registration request.
To disable approvals:
Disabling approvals is a similar process. Notice in Figure 1, there is an approval option to Disable Inherited User Registration Approvals. Choose this option instead of the User Registration Approvals and you disable approvals at this organization.
Final comment on approvals:
The approach outlined above is the most common because you do not want registered users under a buyer organization to shop until they have been approved. However, due to the inherited nature of user registration approvals, there are other configuration options to consider.
You can disable approvals site-wide by removing the User Registration Approvals from the Root Organization. Alternatively, you can disable user registration approvals for all of your buyer organizations by adding the Disable User Registration Approvals at the Buyer Organization container organization. Another option is to enable approvals at your Buyer Organization container organization instead of at the individual buyer. This way, any user registering to any buyer is approved by the same group of administrators.
You need to create a user to manage the new buyer organization by using the Organization Administration tools. For more details, see "Creating a user" in the online help. The new user is created with the new buyer organization as the parent, and you can give it a name.
Use the Organization Administration Console to grant the new buyer administrator roles in the new buyer organization. Remember that in WebSphere Commerce, users play " a role in an organization". You can grant the user any of the roles defined for the new buyer organization. For more details, see "Assigning roles" in the online help.
The last step is to make the buyer administrator a member of the new buyer organization's approval group. Remember that the approval group is the list of users who get an email notification when a new user tries to register to the buyer organization, and who have the rights to approve or reject their registration. Also remember that the approval group for your new organization was created above, when the user registration approvals was enabled for your organization.
To add your administrator to the approval group, go to the users page in
the Organization Administration console. Select your administrator and
choose member groups. On the include page, find the member group with the
UserRegistrationApprovals -- <your buyer organization name>.
Add your user to that group.
Now that you have your environment setup, go to the B2B direct store, and register a new user. Specify as parent the new buyer organization that you created above. If approvals have been enabled, you see a message stating that your registration request is pending for approval. The administrative user that you setup above receives an email notification that there is a registration request pending approval. The administrator can go to the Administration console and approve or reject the request.
You can also create new accounts for this organization. Because the
businessentity flag has been set for your new
buyer organization, this organization shows up in the list of available
organizations to participate in new accounts.
This article explained how to configure the B2B direct business model to support dynamic buyer organization creation. You can leverage the configuration to quickly and easily create the buyer organizations at development time or runtime.
We would like to thank Anthony Tjong for his inspiration and guidance in the writing of this article.
Howard Borenstein is a software developer at the IBM Toronto Lab in Toronto, Ontario, Canada. He is the lead developer of the Business Relationship Management component of WebSphere Commerce. Howard has worked at IBM for 14 years, and has experience in user interface and Web application development, application development tools, and commerce applications. He has a Bachelor of Applied Science degree from the University of Toronto, Canada.