Introduction

Due to the progression of B2B scenarios a new entity has been introduced - customer. Up to and including version 7.3, the term customer was incorrectly used. It was equivalent to user, and the corresponding cartridge bc_customer dealt with users. Now customers can be recognized as containers for users. An individual B2C customer contains only one user. A B2B customer may contain zero, one or many users. The contents of bc_customer was moved to bc_user, and bc_customer is now filled with different artifacts.

Customers are classified by type. The customer type is a simple property but it determines the structure of the customer. For example SMB customers must support fields for taxation ID, company name, etc. New customer types can be added programatically.

Have a look at the Cookbook - Customers for related questions.

Glossary

Customer-Related API Changes

As the meaning of the term customer has changed (up to and including 7.3 the customer represented a user), the API of bc_customer and bc_customer_orm is not valid anymore. Within a refactoring process, bc_customer and bc_customer_orm were renamed/moved into bc_user and bc_user_orm. Artifacts that have the word "customer" in its name were renamed. Wherever the word "customer" did appear inside an artifact it was renamed as well.

To support B2B business scenarios new fields were added in BasicProfile, BasicAddress and StaticAddress:

Customer Types

The customer type is a property that is required for any customer. The customer type is not only a classification but it also defines the internal structure of the customer. During the customer creation, the system creates various low-level artifacts (e.g., records in the database through the ORM layer) depending on the customer type. The figure below illustrates the flow on customer creation.

It is possible to enable/disable the login for customers of specific customer types for an application type. This can be done by using the intershop.application.login property in share/system/config/apps/<application-type>/customerslogin.properties. Only customers that belong to one of the customer types added there can log in for applications of the configured application type. By default login is enabled for private customers in applications of type intershop.B2CWebShop and for SMB customers in applications of type intershop.SMBWebShop.

The processing of customers and customer data should be performed only through the BO layer ( bc_customer). All implementation details are hidden in the implementation cartridge (ORM based implementation bc_customer_orm). In order to be able to create new customer types and to use the BO layer, a knowledge of bc_customer is required. The cartridge is described below.

bc_customer Details

This section describes details about the artifacts contained in bc_customer.

CustomerBO and its Extensions

The next figure shows the most important interfaces in the bc_customer cartridge.

The CustomerBO interface is the basic container for customer data. Depending on the customer type, different business object extensions are available on the customer side. For example, the SMB customers may return an instance of the CustomerBOCompanyCustomerExtension. The same extension is not available in CustomerBO s that represent individual customers. Based on the availability of the different extensions, different UI artifacts may be shown, for example.

The following extensions of CustomerBO are available out of the box:

The obvious question with this design is how do the CustomerBO instances know which extension is available? The information is conveyed through the implementations of the CustomerType interface, which is described below.

CustomerSegmentBO

The next figure shows the interfaces for a group of customers.

The CustomerSegmentBO interface defines a customer segment - a group of customers. It is managed by the CustomerSegmentBORepository. The repository itself manages the lifecycle of customer segment BO instances. For each assignment of content (CMS, promotions, shipping rules, prices), a customer segment is used.

CustomerType Interface

The customer type interface describes a customer type. Customer types are wired to a CustomerTypeProvider by the componentization framework, and they have no other form of persistence. The following methods are available within the interface:

public interface CustomerType
{
    public String getCustomerTypeID();
    public String getLocalizationKeyForName();
    public boolean isApplicableExtension(String extensionID);
}

The first two methods, getCustomerTypeID() and getLocalizationKeyForName(), are used for internal identification of the customer type and for displaying customer types to the end users. The last method decides which extension (described in the previous sections) is available for a customer. For example, here is the definition for the SMB customer type:

	<instance name="SMB_Customers" with="CustomerType" scope="app">
		<fulfill requirement="customerTypeID" value="SMB" />
		<fulfill requirement="localizationKeyForName" value="customertype.name.SMB_Customers" />
		<fulfill requirement="applicableExtensionID" value="GroupCustomer" />
		<fulfill requirement="applicableExtensionID" value="CompanyCustomer" />
	</instance>

This definition implies that for customers with the type SMB, applicable extensions besides CustomerBODetailsExtension include the CustomerBOCompanyCustomerExtension and the CustomerBOGroupCustomerExtension. By default, the core product defines two customer types - individual and SMB. The next table shows the applicability of the extensions for each customer type.

Retrieval of CustomerBORepository

The customer BO repository may be retrieved in the context of the storefront applications directly from the ApplicationBO, e.g., ApplicationBO:Repository("CustomerBORepository"). Since both the users and the customers live in the anonymous organization, special application domain relations were added in the APPLICATIONDOMAINRELATION table.

Persistence of Customers

Each customer has a customer profile in BasicProfilePO. This profile is used as bridge to legacy functionality such as address handling. You can easily spot the customer profile by checking the type code of each customer profile assignment, if it is equal to 3 (three) then this is the customer's profile. This relation however, cause unnecessary iteration over profile assignments of customer when common functionality such as addresses is required. To increase the performance CustomerPO was denormalized with direct reference to customer's profile. However, it is not modeled as relation, but dependency. This means that resolving of the customer's profile is realized by using the ProfileMgr, instead of ORM relation.

bc_user Details

This section describes details about the artifacts contained in bc_user.

UserBO and UserBORepository

The next figure shows the interfaces in the bc_user cartridge.

Persistence of Users

The next figure shows the persistence layer. Currently there is no distinction between business and "system" users. Therefore, the persistence layer for users and user related objects is defined in the core.

Import and Export

The import and export of users is enhanced. Customers are now part of it and they are the root container for users. In addition, the new properties of SMB customers are a part of the export, like the taxation ID, company name etc.

B2B Functionality via Extensions

The bc_customer and bc_user cartridges provide only a business API for processing customers and customer data. The actual implementation of customer specific functionality (e.g., ad-hoc UI in the storefront application for managing B2B details) should be achieved using extension points. The following figure illustrates the idea in the ISML layer.

The idea is that the functionality in the base cartridge is available to both the SMB and the B2C users. Within a specific cartridge, visible only to the SMB app, there are added extensions that will be active only when the SMB app is browsed. The same applies to the B2C scenario. The "base" cartridge is sld_ch_b2c_app. This cartridge defines the extension points. The actual extension implementations are in the app_sf_webshop_smb cartridge.

E-Mail Handling

A new attribute has been added to the user's profile, called e-mail. Although the attribute is not mandatory for all customer types, there are some that require it. Individual customers are one of those types, as well as the users of a group, or SMB ones. The administrator's ability to set a password for given users was revoked, and that is why this field became vital with regard to the login capabilities.

With the introduction of the customer's profile, there are now three locations were the e-mail related attribute is available. These are:

• Customer's profile
• User's default address' e-mail
• Credentials - reminder e-mail

The reminder e-mail, which is part of the customer's (or a customer's users') credentials, is kept for compatibility and flexibility purposes. The reference application does not use it anymore.

The e-mail address stored with the customer's profile is used for any password-related e-mail activity. This includes:

• When a customer is created, a password retrieval will be sent.
• When a customer is activated (its status is changed from disabled to enabled), another password retrieval will be sent.
• When a customer triggers the "Forgotten password" functionality, a password reminder e-mail will be sent.

The e-mails can be managed in two locations:

• Self-registration in the storefront
• Creation of a customer in the Commerce Management application

Self-Registration in the Storefront

The customer is forced to use the e-mail as login. Therefore, with the registration, this e-mail is also propagated to the profile and the reminder e-mail. In the storefront, a customer may register with or without specifying address details, and using the address e-mail field is unsafe.

Creating a Customer in the Commerce Management Application

When customer is created in the Commerce Management application, the login and profile's e-mail attributes are shown as separate attributes, and their values may differ. The profile's e-mail address is propagated to the credential's reminder e-mail.

Importing Legacy Users

By splitting the user to customer and user, now there are two formats that are supported for user import - a legacy one and a new one. When the legacy format is imported, the following fallback applies in order to populate the profile's e-mail:

1. Get the e-mail from the default address
2. Get and test if the login is an e-mail
3. Get the credentials reminder e-mail

Following the order in this list, whichever imported attribute condition is met first, this attribute is used.

New Names of Existing Objects

By introducing customers, a number of objects were introduced or renamed. This change affects objects on almost every application layer. The renaming can be summarized as follows:

The term consumer was renamed to customer, whenever it appears in the application.

The term consumer group was renamed to customer segment.

Now, instead of assigning a consumer to consumer group one will assign a customer to customer segment. There are some exceptions, though. The identifiers of customer segments are unique across a given domain and they are often used in custom projects to attach or modify certain aspects to/of the platform. For this reason, these identifiers are kept unchanged and thus, one will encounter a customer segment with, for example, the ID IG_RegisteredUsers or IG_NewUsers. The same applies to the price lists: The price list for all customers will still have the ID AllConsumersPriceList.

Nevertheless, all texts throughout the sales channel applications do not mention the name consumer or consumer group anymore.

Customer Segments

The table below lists the implicit customer segments available in the system. The segments are listed with its old name and description, i.e., when they were called consumer group. In addition, the two new implicit segments for individual and SMB customers are there as well.

Relation Between Customers and Customer Segments

As explained in persistence of customer, every customer has a profile assignment. In order to persist the relation between a customer and a segment, a persistent assignment is created between the customer's profile itself and the corresponding user group, backing up the segment implementation.

That relation is enhanced for the group customers. In order for their users to get the full functionally of the storefront, like promotions, prices, CMS content, depending on the segments, all of their users are assigned.

Customers and Promotions

Promotions for customers are realized via another segment assignment to a specific user group called target group (find more information in Overview - Promotions). Therefore, in order to keep this functionality, the customer's profile is assigned to the above mentioned target group, as with segments, in case where the customer is of group type and all customer's users share the same assignment. It is persisted both for the customer's profile and the user's profile.

Orders and Customers

By introducing  customers another attribute is added to the orders and baskets - they are now aware of the customer that placed the order. If an individual customer checks out the basket, the user is the same as the customer. That is not the case if a user of a business customer does so. They buy on behalf on someone else, and that someone else is persisted when the order is placed. However, when moving the user to another customer, the reference at the order should be updated to correspond with the new assignment. This behavior has been introduced because of the possibility of "new customer self registration". As a consequence, some customers may need to be merged, their users may need to be moved to a single customer, and duplicate customers may need to be deleted.

Useful Pipelines and Pipelets

This table lists the pipelines, used for implementing the new introduced customer:

This table lists the pipelets, used for implementing the new introduced customer: