Concept - Classification Catalogs (valid to 7.6)

1 Introduction

Intershop 7 (IS7) provides out-of-the-box support for two standard classification mechanisms: eCl@ss and UN/SPSC.

This concept discusses the implementation of classification catalogs with reference to eCl@ss. The implementation of UN/SPSC is based on the same mechanisms.

Many of the complexities of eCl@ss do not arise using UN/SPSC.

The Intershop Commerce Suite 7 system also allows to create custom classification catalogs (e.g., ServiceTypes, ProductTypes) and eventually provides some system classification catalogs.

The nature of a classification catalog is specified by its assignment to a given classification system.

2 Classification Systems

A classification system is a system of rules defining the behavior of the classification. This behavior is calculated by taking the values of the parameters coming with each classification system. Such a single system has the following parameters which determine the classification behavior:

  • levels - The number of classification levels (level of nesting)
  • groupIDHierarchy - A flag indicating that the classification group IDs are in hierarchical order, i.e., the ID of a classification group (which is a classification category) defines the position in the classification system.
  • multipleAssignments - A flag indicating whether products can be assigned to multiple groups (which are classification categories) of the classification system.
  • leafAssignments - A flag indicating whether products can be assigned to leaf groups (which are classification categories) of the classification system only.
  • inheritanceEnabled - A flag indicating whether predefined attributes of a group are inherited from parent groups.

By default, four classification systems with their properties and values are available:

Classification Systems

The diagram shows that for different classification systems different nesting levels are possible. This value indicates the number of the meaningful levels, not the max level. Because a classification catalog shares the similar behavior with a standard catalog, somebody can create a classification category structure with more than 10 or 15 levels of nested subcategories but for a given classification system Levels defines the number of levels which are sufficient to describe and structure a business segment.

For both, eCl@ss and UNSPSC systems, level names were defined to describe each level of the classification system, resp. a business sector.

eCl@ss defines the following levels:

  • Level 1: Segment
  • Level 2: Main Group
  • Level 3: Group
  • Level 4: Commodity

UNSPSC defines the following levels:

  • Level 1: Segment
  • Level 2: Family
  • Level 3: Class
  • Level 4: Commodity
  • Level 5: Business Function

In IS7 UN/SPSC classification has classifications up to 4th level. This means that IS7 does not support UNSPSC classifications with Level 5 - Business Function by default.

3 eCl@ss Classification Catalog

3.1 Overview

eCl@ss is a standard for information exchange between business partners.

It is very important in scenarios where catalog aggregation between multiple organizations is a key success factor for cost savings. Without compatible catalogs, catalog maintenance becomes a costly business.

eCl@ss is characterized by a 4-level hierarchical classification system consisting of numeric codes (similar to UN/SPCS). Two digits represent a hierarchy level. This basically splits the 8-digit code in 4 parts: segment, main group, group and commodity class.

A full 8-digit code always uniquely identifies a leaf in the categorization tree. The figure below shows a sample for segment 29 ("Home technology").

A standard keyword register extends the plain categorization tree and provides users with better search capabilities. Each commodity class (i.e., each leaf in the categorization tree) is associated with a set of keywords describing the type of items (i.e., products) that belong to the category. Since the eCl@ss standard committee maintains the keyword registry, a search based on these keywords provides better search results than a plain full-text search.

Most of the commodity classes are also associated with attribute lists that define the attributes of the items of that particular category. The attribute lists contain the attribute names as well as possible value sets. The attribute sets for commodity classes basically provide meta-data for the items/products contained in a category.

The classification search uses different aspects of the classification theory and covers the following eCl@ss-related requirements:

  • Hierarchical Search
    With an eCl@ss categorization in place, users need a tight integration into standard catalog search. In addition to all other product related search criteria (e.g., keyword, price, …), a user would want to limit the search to a specific eCl@ss sub-tree. Users will first select the eCl@ss segment of the product being searched. Once the segment is selected, the system needs to present the possible groups within that segment (eCl@ss groups available within the eCl@ss segment, then eCl@ss subgroups available within the selected eCl@ss group and finally eCl@ss commodity class available within the selected eCl@ss subgroup).

    A user could also search products by only specifying prefixes of the eCl@ss ID (e.g., only segment and group). This way all products with the given prefix in the eCl@ss ID will be matched.

  • Code Search
    Expert users are likely to know the eCl@ss codes for products they buy on a regular basis. The system supports direct search for products by a full or partial eCl@ss code.
  • Keyword Search
    Given the standardized eCl@ss keyword registry, users would want to use that vocabulary to search for eCl@ss categories that contain products denoted by the keyword.

    eCl@ss keyword search identifies eCl@ss categories and no products. Actual products can be navigated based on the category result set.

    Keyword search is implemented using full-text search on the "LongDescription" attribute of the catalog categories. No further database joins are required for keyword resolution since all keywords associated with a classification category are mapped to a single category attribute.

  • Attribute List Search
    Once a user narrowed his search to an eCl@ss commodity class (i.e., the 4th level of the hierarchy) the system should support further refinement by using the eCl@ss attribute lists. Search masks should be extended to show the attribute sets of products within the selected eCl@ss category. This will help searching for particular products in case of extremely large product repositories (i.e., where a single eCl@ss category contains hundreds of products). Based on these requirements, the implementation uses the standard category hierarchy for modeling the full eCl@ss classification tree. Each catalog category carries the name, description and ID of the corresponding eCl@ss category.
    To implement the attribute list search, the eCl@ss attribute lists and value ranges are mapped to the product type concept. Since attribute lists are only attached to commodity classes (i.e., the leaves of the classification tree) we do not need a real product type hierarchy but just a flat list of product types - each identified by the eCl@ss ID of the corresponding catalog category.

The eCl@ss catalogs reference products that belong to the catalog category using the unique 8-digit classification ID. All products that are supposed to be part of an eCl@ss catalog contain an attribute with the eCl@ss ID, making it possible to implement catalog browsing without the need for explicit category/product bindings (i.e., ProductCategoryAssignment). This makes the eCl@ss view completely independent of the underlying product repository and therefore eases import and update processes significantly.


An explicit assignment between product type instances and catalog categories is not necessary. Instead, the assignment is done using the numeric eCl@ss ID that is stored at the category side as well as at the product type side.

3.3 eCl@ss Filtering

Standard eCl@ss catalogs are very extensive. The full tree contains thousands of categories. However, a single supplier will most likely only provide products for a small subset of the product categories provided by the eCl@ss standard. A user browsing such a sparsely populated catalog would have significant problems to identify the catalog categories that actually hold products. Therefore, features are provided that filter the standard eCl@ss classification tree such that only the categories actually populated are shown during catalog browsing.

To reduce manual and visual interaction of the catalog administrator with the standard classification catalogs, real time category filtering has been implemented. Real time means that the filtering takes place whenever a user browses the catalog. This approach ensures that a catalog administrator does not need to maintain standard classification catalogs manually.

The standard classification basically remains a dynamic view on the existing offer repository. On a conceptual level, the filtering is done by counting the product instances that belong to a given catalog category. A category is shown if and only if the category itself or one of its sub categories contain products. At database level, the implementation is based on a materialized view that provides the product counts for the populated catalog categories. The result of this materialized view is a kind of virtual database table that contains the product counts per domain and eCl@ss category in a highly optimized form. Implementing real time filtering based on the materialized view is fairly straightforward. We only need to merge the catalog category with the corresponding row in the materialized view.

The materialized view contains much less rows than the actual product table. The necessary database join will therefore be pretty cheap. The materialized view needs to be configured such that it can be updated explicitly.

4 System Classification Catalogs

System Classification Catalogs are used to handle special products like warranties, proxy products for customizations, gift wraps and other types. Such types of catalogs are prepared from the system and there is no option to manually create a new system classification structure. That is why they are system catalogs - available for use only, given by the system with prepared sub categories defining special product types and classification attributes when needed.

Unlike a standard classification, the system classification could not be shared to a sales or partner channel using the standard Commerce Management application's functionality. Instead, this operation is done during the setup of the system, e.g., database initialization. The purpose of shared system classification catalog is to provide the above mentioned special product types not only on system or master level, but also at channel and application level. Thus products derived from a source repository will have consistent types when shared or syndicated to another repository and the appropriate category assignment is preserved.

Example for such a system classification is the "Service Types" catalog with the following category hierarchy and corresponding classification attributes:

Service Types catalog structure

In this structure only "Dependent Warranty" classification category has specific attributes used to characterize the products which have assignment to this category. No specific attributes are needed for the rest of categories in such a demo scenario.

5 Classification Attributes

5.1  Classification Attribute Pages

Classification attributes can be added to local and system classification catalogs and categories. These attributes are automatically assigned to all products that use the respective classification category and their values can be defined in the Classification tab of the assigned product. Such an attribute can be created in Classification attributes tab of given catalog or category. The following picture shows classification attribute creation page:

For successful attribute creation the mandatory fields (marked with red asterisk) must be filled. The name of the attribute is always localizable. The value range and default value can also be localizable. If there are already defined values for one locale the values for the other locale(s) should be defined as well. Use the language select box to select one of the valid languages. Specify the attribute type in the Data Type field. At the moment 6 types are available - String, Double, Integer, Multiple Strings, Multiple Doubles and Multiple Integers. When multiple data type is used the different values must be separated by a pipe symbol |. The general purpose of classification attributes is their assignment to a product. When a product is assigned to a classification catalog - category and this category contains attributes, after the assignment these attributes will be added to the product as well. If the attributes do not have a value they will not be displayed in product attributes list. Product Classification catalog cannot be assigned to a product, only sub-categories that are on the last level of the hierarchy. In the Intershop Commerce Management application there are 3 places where product <-> classification category assignment process can be done.

  • Product Page
    In product page - Classifications tab the respective product can be assigned to a selected catalog. The following picture shows where the product can be classified using the available classification catalogs. There are standard classification catalogs such as UN/SPSC and eCl@ss, but the selected product can also be assigned to custom classification catalogs using the red framed Assign links.

The assignment can be done only if the catalog contains subcategories. Classification attributes can be localized, so their values can be viewed and edited in other languages if required. Product classification typically consists of two steps:

  1. Assign the product to exactly one leaf category of the selected classification catalog.
  2. Define valid attribute values for the classification attribute set provided by the selected leaf category.

    The picture above shows the page where product can be classified. By the combo boxes (framed red) can be selected classification categories. The value of classification attribute is editable, but a change here reflects only the assigned product attribute. The original classification attribute of the category is not changed.

  3. Click Apply to confirm the classification. The attribute (if it has a value) can be found in product attributes list, as the next picture shows.

  • Edit Selected Products page
    Another place where products can be assigned to classification categories is Edit Selected Products page in product list, as the following picture depicts.

The assignment here is a few steps process:

  1. Select the respective radio button and click Next>>.
    A new page - Step 2: Assign Products to Classification Catalog Category - Select Classification Catalog is displayed.
  2. Select a  classification catalog and click Next>>.
  3. Select the classification category and click Next>>.
  4. The page Step 4: Assigning Products to Classification Catalog Category  (Service Types / Customization SKU) - Confirm action shows to which subcategories of the classification catalog the product will be classified.
    Click Finish to start the batch process that performs the classification.



  • Category Page
    The third place where products can be assigned to classification categories is Category Page page of selected catalog. Only categories on the last level of the hierarchy can be assigned to a product. As the following picture depicts the products are assigned to Car Audio category that is on last third level of catalog-category tree: Product Types -> Audio -> Car Audio. All Car Audio classification attributes with values will be assigned to the products in the list.

    Optional: Use the Add button to assign additional products. The picture above the red framed section shows the product list of classified products. Here the user also can sort, delete and edit these products.

5.2 Implementation

The following UML diagram provides a high-level view on the implementation of product types and product attributes.
ProductAttribute interface extends ProductAttributeEnumeration interface. The connection between ProductAttribute and ProductType is productTypeID.

ProductType - ProductAttribute Object model2

The main database tables responsible for classification attributes are: ProductType, ProductAttribute and ProductAttribute_AV. When new classification category is created a new record is added to CatalogCategory table. After creation of a classification attribute new rows are added to ProductType, ProductAttribute and ProductAttribute_AV tables. The values (if exists) of new attribute will be added also to ProductAttribute_AV table with name - defaultValue and enumerationValues.

The object responsible for ProductType is com.intershop.beehive.xcs.internal.producttype.ProductTypePO that implements com.intershop.beehive.xcs.capi.producttype.ProductType interface. The pipelets responsible for ProductType object data operations are: GetProductType, CreateProductType, UpdateProductType and RemoveProductType placed in bc_mvc cartridge. A product type cannot be removed, if:

  1. It is the basic product type of the system domain.
  2. It has any sub-product types.
  3. It has any assigned products.

The following code block shows an example how new ProductType can be created.

Create ProductType Example
ProductTypeMgr productTypeMgr = (ProductTypeMgr) 
String iD = "";/** ProductType name, this parameter is mandatory and must be unique or an Exception will be thrown **/

ProductType parentProductType;
Domain owningDomain; /** domain is mandatory for product type creation **/

ProductType productType = null;
            productType = productTypeMgr.createProductType(iD.trim(), 
        catch(ProductTypeNameNotUniqueException ex)

The following code block shows an example how ProductType can be extracted, updated and removed.

Get/Update/Remove ProductType example
ProductTypeMgr productTypeMgr = (ProductTypeMgr) NamingMgr.getInstance().lookupManager(ProductTypeMgr.REGISTRY_NAME);


// Get ProductType by name
String productTypeDomainName = "";
String productTypeName = "";
Domain domain = domainMgr.getDomainByName(productTypeDomainName);
ProductType productType = this.productTypeMgr.getProductTypeByName(productTypeName, domain);


// Get ProductType by UUID
String productTypeUUID = "";
ProductType productType = this.productTypeMgr.getProductTypeByUUID(productTypeUUID);

// Update ProductType section
String iD = "";
String displayName = "";
Boolean defaultFlag = true;//false
LocaleInformation locale;

productTypeMgr.changeProductTypeName(productType, iD.trim(), productType.getDomain());

productType.setDisplayName(displayName.trim(), locale);


// Remove ProductType section


The object responsible for ProductAttribute is com.intershop.beehive.xcs.internal.producttype.ProductAttributePO that implements com.intershop.beehive.xcs.capi.producttype.ProductAttribute.ProductAttribute interface. The pipelets responsible for ProductAttribute operations are: GetProductTypeAttribute, CreateProductTypeAttribute, UpdateProductTypeAttribute and RemoveProductTypeAttribute placed also in bc_mvc cartridge. The ProductType object is created for a specific domain name and category name, after that a new ProductTypeAttribute object will be created.

The following code block shows how new ProductAttribute can be created.

Create ProductTypeAttribute Example
ProductTypeMgr productTypeMgr = (ProductTypeMgr) 

Boolean localizedFlag;/** Mandatory parameter **/
Integer valueType;/** Mandatory parameter **/
String iD;/** Mandatory parameter **/

ProductType productType;/** Mandatory parameter **/
        ProductAttribute productTypeAttribute = null;
            productTypeAttribute = productTypeMgr.createProductAttribute(
        catch(ProductAttributeNameNotUniqueException ex)


The next code block contains examples how ProductAttribute can be taken, updated and removed.

Get/Update/Remove ProductTypeAttribute example
// Get ProductAttribute section
String iD;/** Mandatory parameter **/
ProductType productType;/** Mandatory parameter **/
ProductAttribute pa = productType.getProductAttribute(iD.trim());
// Update ProductAttribute section
ProductAttribute productTypeAttribute;/** Mandatory parameter **/

Iterator valueRangeIterator;
Object defaultValue;
String displayName;
Boolean orderRequiredFlag;
String unit;
Integer valueType;
Boolean localizedFlag;
Boolean enumerationFlag;
String iD;/** Mandatory parameter **/
LocaleInformation locale;

productTypeAttribute.setDisplayName(displayName.trim(), locale);
productTypeAttribute.setDefaultIntegerValue((Integer)defaultValue, locale); 

// Remove ProductAttribute section
ProductTypeMgr productTypeMgr = (ProductTypeMgr) 
ProductAttribute productTypeAttribute;

In a ISML template the following code can be used to extract the product attributes of specific product type object:

Product Type Attributes
<isloop iterator="ProductType:CustomProductAttributes" alias="PTA">
           <td class="table_detail e s top"><a href="..." class="table_detail_link"><isprint value="#PTA:DisplayName(Locale)#"></a>&#160;</td>
           <td class="table_detail e s top"><a href="..." class="table_detail_link"><isprint value="#PTA:Name#"></a>&#160;</td>
           <td class="table_detail e s top">
              <isif condition="#PTA:ValueType EQ '4'#">
              <iselseif condition="#PTA:ValueType EQ '5'#">

ProductType object from the code snippet above is determined by UUID or Name (category name) and domain. CustomProductAttributes are determined by createCustomProductAttributesIterator() method of ProductType object. This method returns an iterator on all custom ProductAttributes (ProductAttributes which are not part of the BasicProductType like the ProductAttributePO for the product attribute name).

6 Sharing

With catalog sharing, sales or partner organizations can distribute classification catalogs to sales channels. The catalogs are not copied to the target channels but remain in the parent organization's master repository. Only the standard classification catalogs can be shared, the system classification could not be shared to a sales or partner channel using the standard Commerce management application's functionality. Instead, this operation is done during the setup of the system, e.g., database initialization. The purpose of sharing is to provide special product types not only on system or master level, but also at channel and application level. Thus products derived from a source repository will have consistent types when shared or syndicated to another repository and the appropriate category assignment is preserved.

The picture bellow depict how a classification catalog can be shared to a channel.

  1. In tab Channels of the catalog select the channel and click New.
  2. Click Delete to unshare the catalog from the selected channel.
  3. Following picture shows the list with all channels that can be assigned (shared) to the respective classification catalog. If the catalog is already shared to all available channels then the list is empty.
  4. The classification catalogs displayed on the next picture are shared to the channel. Here the assigned catalogs cannot be edited, only viewed and removed (the icons framed red). The deletion of a catalog from the channel does not remove it from the database, but only unshare the catalog.


The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources
Support Tickets