T-Shirt News and Articles by "Got The Tee Shirt Corporation"

Been There Done That Got The Tee Shirt

Subscribe to Been There Done That Got The Tee Shirt: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Been There Done That Got The Tee Shirt: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


T-Shirt News and Articles Authors: Dynatrace Blog, PagerDuty Blog, Peter Silva, VictorOps Blog, Henn Idan

Related Topics: Online Shopping, T-Shirt News and Articles

Online Shopping: Article

Extending the Product Catalog

Extending the Product Catalog

As more and more companies focus on providing higher levels of personalization in the products and services they offer, it's only natural that their online channels offer this same level of personalization. WebLogic Portal includes product catalog components capable of flexibly managing hierarchies of products and services. By default, products in the catalog are defined using standard Dublin Core attributes. This default configuration is sufficient to support most types of products sold over the Internet - books, hardware, camaras, etc.

However, certain types of products require that customers select from among desired options before the products can be purchased. We can group these "configurable" products into three main categories based on their configuration needs:

  • Light product configurations: Products that have a small number of simple, mandatory configurable attributes. Product pricing is normally not affected by the options selected (e.g., T-shirts defined by color and size).
  • Heavy product configurations: Products defined by multiple attributes or product options. Depending on the options selected, pricing and delivery may be affected (e.g., insurance policies or telecommunications services).
  • Product bundles: Products composed of component products, each with its own attributes (e.g., desktop computers or automobiles).

    Although the product catalog does not provide any OOTB components to support configurable products, we will attempt to illustrate how the catalog can easily be extended to support such products. We will use the T-shirt example to illustrate our solution. Later, we will discuss design strategies for heavy product configurations and product bundles.

    We identified several goals in the solution design. First, the solution had to provide an acceptable level of performance for the users wanting to purchase configurable items. Second, any new components should integrate not only with the catalog, but also with the order process, discount, and campaign components. Third, new functionality should not require changes to existing components, thereby minimizing future migration problems. Finally, administrators should be able to easily manage configurable items within the catalog hierarchy as a single item.

    Item Configurators
    In order to support light product configurations, we added a new component to the product catalog - item configurators. An item configurator represents a list of options that can be assigned to a product. In the T-shirts example, both color and size would be item configurators.

    Figure 1 shows the component model representing the item configurators and the options associated with each configurator. Each component is represented in the database by a table of the same name. Instead of directly accessing the configurator components, we have created a Business Manager component called the ItemConfiguratorMgr. This component is responsible for providing configurator information to calling objects. The ItemConfiguratorMgr uses WebLogic Portal's Cache Framework to optimize access to the data. This framework also allows us to monitor the use of the product configurators.

    We recommend that you name item configurators with reuse in mind. In the T-shirt example, if you don't expect the list of T-shirt colors to be reused for other items, you should name the color configurator explicitly for T-shirts. On the other hand, the list of T-shirt sizes will probably be identical to other types of shirts. Therefore, the size configurator should be given a more generic name in order to promote reuse.

    Creating Configurable Items
    Now that we have created our two item configurators - color and size - we need to tie them to our T-shirts. This is accomplished by first creating a generic T-shirt item using the standard catalog administration screens. Since this generic item will not be shown directly to the customer, you should make sure that the visible flag is not checked.

    Next, we need to associate the configurators with the item. In addition to the standard Dublin Core attributes, WebLogic Portal facilitates the creation of custom item attributes, grouped into Catalog Structures. We have created a new Catalog Structure called ConfigurableItems, containing the following properties:

  • Configurator1...n: Ordered list of configurator IDs 1 through n. We created three configurators as the maximum number of configurators associated with any one product. If more configurators are desired, they can be added through the EBCC and synchronized with the instance of WebLogic.
  • GeneratorClass: Full name of class used to generate the various item configurations. We have provided a ConfigurableItemGenerator class to be used by default.

    The GeneratorClass is the key to our solution. This class will generate new item SKUs based on the order of the listed configurators for a given item. The format of the generated SKUs will be the base item SKU plus a hyphen-separated list of the corresponding options in the order defined by the ConfigurableItems structure.

    Going back to the T-shirt example, let's say we've created two configurators - T-Shirt Colors (ID=101) and Shirt Sizes (ID=102). We've also created a T-Shirt product item in the catalog with a SKU of 1001. Using our new ConfigurableItems Catalog Structure, we assign Configurator1 to 101 (colors) and Configurator2 to 102 (sizes). The class ConfigurableItemGenerator will create a new product for each combination of configurators. That is, if there are 8 colors and 4 sizes of T-shirts, the ConfigurableItemGenerator will create 32 new T-shirt items. The SKU associated with small, red T-shirts, for example, would be (1001-RD-S). Figure 2 shows an example configuration for our T-shirts.

    Our ConfigurableItemGenerator can create distinct image names for each configured item. The "isVisual" attribute of the ItemConfigurators is used to determine which configurators will be used in generating image names. In our example, color is a visual configurator, but size is not. Therefore, only color will be used to generate the image name. If the base T-shirt product has an image URL of "images/tshirt.jpg", all red T-shirts will have "images/tshirt-RD.jpg" as their image URL. Likewise, if there are no visual configurators assigned to an item, all configured items will inherit the base item's image URL.

    The ConfigurableItemGenerator also adds the keywords associated with each ItemConfigurator to the generated items. These keywords are added to the list of keywords associated with the base item.

    Each generic item can have a custom GeneratorClass that defines the process of generating configurable items. By allowing you to assign a different GeneratorClass to each item, we have attempted to make the solution as flexible and pluggable as possible.

    Managing Configurable Items
    In order to effectively manage configurable items, we need to add two new options to the Catalog Management administration page (see Figure 3):

  • Item Configurators: Add, delete, search, and modify configurators
  • Configurable Items: Generate, delete, and manage configurable items

    These items will have a look-and-feel that is very similar to the current category and item administration pages.

    Clicking on the Item Configurators page link brings you to a list of current item configurators. Administrators will be able to edit the information associated with a particular configurator or delete it from the database. The Create Item Configurator button brings the administrator to a form where he or she can create new configurators.

    Clicking on the Configurable Items page brings you to a list of management tasks for managing configurable items in batch. First, you can view the list of generic items that have an associated GeneratorClass for creating configurable items. For each item, the administrator will have the ability to generate configured items, delete generated items, etc.

    Much of the administration of Configurable Items will be accomplished using the standard administration pages. For example, to create a generic item you can use the standard item create page to create the non-visible item. Then simply edit the ConfigurableItems properties associated with the product and add the desired GeneratorClass and one or more Configurators.

    Similarly, configurable products can be assigned to a category using the "Modify Items Assigned to Category" page. Here we made a slight change to the category_add_ remove_items.jsp that checks added items to see if they have an associated GeneratorClass. If so, it also adds all generated items. Once all items have been assigned to the category, individual items can be unassigned using the same page.

    User Navigation
    Our solution does not require any changes to the user interface of the catalog. As you navigate through the hierarchy of categories and items, all the newly generated items will appear under their assigned categories. The search engine will also find any generated items that meet the search criteria.

    However, in many cases it won't be desirable to show all combinations of configurable items as separate products. In these cases, we recommend that the configurable product be assigned to a dedicated category. Creating such a category will allow you to create and assign a custom layout that, instead of presenting a list of all generated items, presents the generic item information and the associated configurator options. Once the user selects the desired configurator options, the page automatically places the corresponding generated product in the user's shopping cart. Once you design a custom layout JSP, you can associate it with the dedicated category via the category attribute "Display JSP URL".

    Creating a dedicated category offers an additional benefit, namely the ability to treat the configured products as a single entity when creating product discounts. Discounts can be offered on either individual products or products within a single category. Our dedicated category approach makes it easy to create a discount that requires the purchase of one or more products of any configuration from the category.

    Benefits of this Approach
    Our support for configurable products is based primarily on automating the process of generating new SKUs for each combination of configuration options available for a given product. We believe that this solution meets the objectives set out at the start of this article:

  • End-user performance: Although this solution increases the total number of items in the catalog, the end user still benefits from the optimized cache of the Catalog Manager in navigating through the catalog.
  • Integration with other Portal components: Since we have not touched the Catalog Manager nor the Shopping Cart in our implementation, all integration points among the components should be intact.
  • Migration to future Portal versions: Since we have not altered any core portal components (only a few minor changes to JSPs), we have minimized the risk of losing functionality in future versions of WebLogic Portal.
  • Easy administration: While there will always be ways to automate and facilitate administration tasks, we have provided a set of easy-to-use, integrated admin screens that should prevent configurated product generation from getting out-of-hand.

    This example was built by extending the example wlcsDomain that comes with WebLogic Portal 7.0 sp2. It is published on http://dev2dev.bea.com as an unsupported example.

  • More Stories By Monte Kluemper

    I got my first taste of Java while investigated technology options for a telco client. That was in 1996. I loved the simplicity of the 1.0 JDK and have been dedicated to the technology ever since. I have worked with such distinguished App Servers as NetDynamics, JAM (Prolifics), PowerBuilder/J, NAS, and Oracle App Server, before dedicating myself to WebLogic in 1999..

    Even though my daily work is increasingly less technical, I still dedicate part of each week to working directly with new versions of the WebLogic Platform. Lately, I have been specializing in WebLogic Portal and its integration with WebLogic Server.

    Since the beginning of 2001, I have given more than two dozen conference presentations, in both English and Spanish, in Barcelona, Lisbon, Madrid, Munich, and Warsaw covering J2EE technologies and WebLogic products. I am also increasingly responsible for speaking with journalists and analysts in Spain and Portugal.

    Important statistics:

    B.S. Indiana University 1991
    8 years client-server and Java consulting with EDS
    3 years as BEA WebLogic presales consultant

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.