Home
User Guide
The information contained in this section applies to WebSphere Commerce Version 8. The documentation also applies to all subsequent releases and modifications until otherwise indicated in a newer section.WebSphere Commerce is a single, unified e-commerce platform that offers the ability to do business directly with consumers (B2C), directly with businesses (B2B), and indirectly through channel partners (indirect business models). WebSphere Commerce is designed to be a customizable, scalable, and high availability solution that is built to leverage open standards. It provides easy-to-use tools for business users to centrally manage a cross-channel strategy. Business users can create and manage precision marketing campaigns, promotions, catalog, and merchandising across all sales channels.
Developing
The topics in the Developing section describe tasks performed by an application developer.
Presentation layer
WebSphere Commerce uses Java Server Pages (JSP) to implement the view layer of the Model-View-Controller (MVC) design pattern. The view layer is in charge of retrieving data from the database through the use of data beans and formatting it to meet the display requirements. The view layers determines whether the request is sent to a browser or streamed out as XML. JSP files present a clean separation between data content and presentation.
Customizing promotions
Customizing promotions can involve the customization of the promotion business user tools and the underlying promotion engine, which features a clean architecture supporting rich functionality, as well as a wide array of customization possibilities.
Promotion engine customization
You can customize the promotion engine if your customization scenario is not already supported by the existing promotion engine function.
Customization scenarios
You can customize various aspects of the promotions component, from creating a new promotion type to changing the way the agenda builder selects potentially applicable promotions for evaluation.
Overview of creating a new promotion type using existing promotion elements
Add a custom promotion type to WebSphere Commerce Accelerator by reusing elements of the default promotions to simplify your customization. This can save a lot of time compared with implementing something entirely new.
Custom promotion types
The promotion authoring tools included in WebSphere Commerce Accelerator are responsible for building a promotion XML document using all of the building blocks available, and saving the promotion in the promotion persistence storage. This includes any additional data that is needed for integration with the environment in which the promotion executes.
Custom conditions
Custom conditions can be created and used to build a promotion. You can create your own custom promotion conditions to ensure that your available promotion types meet your business needs.

User Guide
The information contained in this section applies to WebSphere Commerce Version 8. The documentation also applies to all subsequent releases and modifications until otherwise indicated in a newer section.WebSphere Commerce is a single, unified e-commerce platform that offers the ability to do business directly with consumers (B2C), directly with businesses (B2B), and indirectly through channel partners (indirect business models). WebSphere Commerce is designed to be a customizable, scalable, and high availability solution that is built to leverage open standards. It provides easy-to-use tools for business users to centrally manage a cross-channel strategy. Business users can create and manage precision marketing campaigns, promotions, catalog, and merchandising across all sales channels.
- Planning
  Creating a custom implementation of a WebSphere Commerce store requires a significant amount of planning. From gathering client needs, to deploying the live solution, much work is needed to successfully deploy a custom client store. Use the resources in here to help you plan every phase of store creation.
- Installing
  Review the following sections for information about installing the WebSphere Commerce product, associated maintenance, and WebSphere Commerce enhancements.
- Migrating
  Before you migrate to WebSphere Commerce Version 8.0, review this information to help plan and execute your migration.
- Deploying
  The topics in this section describe how to publish stores to either a test or production environment, and how to deploy customized code.
- Operating
- Integrating
  Topics in the Integrating category highlight the tasks that are commonly performed for using WebSphere Commerce in combination with other products.
- Administering
- Tutorials
  WebSphere Commerce provides many tutorials to help you customize and understand your WebSphere Commerce instance and stores.
- Samples
- Developing
  The topics in the Developing section describe tasks performed by an application developer.
  - Functional architecture
    Functional architecture provides both the set of patterns used to implement the business functionality and the frameworks in which these business functions execute.
  - Persistent object model
    WebSphere Commerce deals with a large amount of persistent data. There are numerous tables defined in the current database schema. Even with this extensive schema, however, you might need to extend or customize the database schema for your particular business needs.
  - Presentation layer
    WebSphere Commerce uses Java Server Pages (JSP) to implement the view layer of the Model-View-Controller (MVC) design pattern. The view layer is in charge of retrieving data from the database through the use of data beans and formatting it to meet the display requirements. The view layers determines whether the request is sent to a browser or streamed out as XML. JSP files present a clean separation between data content and presentation.
    - WebSphere Commerce Struts framework
      Struts is a well documented, mature and popular framework for building front ends to Java applications. To address concerns in software applications, it uses a Model-View-Controller (MVC) architecture: The Model represents the business or database code, the View represents the page design code, and the Controller represents the navigational code.
    - Spring framework
      The Spring Framework is a lightweight, open source programming and configuration model for developing Java based enterprise applications. This framework is used in WebSphere Commerce for building and configuring Management Center, including the managing of URL requests from Management Center to retrieve and process object data.
    - Management Center
      The IBM Management Center for WebSphere Commerce framework is the foundation for WebSphere Commerce business user tooling. The business objects that are managed with Management Center are defined by the individual components that make up Management Center. The Management Center framework uses these definitions to provide the features that you can use to find, create, modify, and delete the defined business objects. If you plan to customize the Management Center, ensure that you understand the framework and all of the components that make up Management Center.
    - Developing Commerce Composer assets
      Enrich the capabilities of the Commerce Composer tool by developing your own widgets and templates, and extending other features and functions to suit your business needs.
    - Customizing promotions
      Customizing promotions can involve the customization of the promotion business user tools and the underlying promotion engine, which features a clean architecture supporting rich functionality, as well as a wide array of customization possibilities.
      - Promotions customization: Management Center
        If the default promotion types that are supplied with the Management Center do not meet your business needs, you can create custom promotion types. Business users can then use the custom promotion types in the Management Center Promotions tool to create promotions for the store.
      - Promotion engine customization
        You can customize the promotion engine if your customization scenario is not already supported by the existing promotion engine function.
        Promotion organization
        Promotions are owned by stores. They can be uniquely identified by the store they belong to, their name, version and revision. Promotions are organized into Promotion Groups, which are also owned by stores. Each promotion belongs to one, and only one, promotion group. Optionally, a promotion can be associated with a campaign.
        Promotion lifecycle
        A business user creates a promotion in the inactive state. From that point forward, the promotion can be activated, modified, and deleted.
        XMLizable interface and component model
        While learning about the architecture and design of the promotion engine, you will repeatedly encounter objects that implement the XMLizable interface. This is a fundamental interface that serves as the basis for the component model the promotion engine employs.
        Black box view of the promotion engine's architecture
        At the core of the promotion component is the promotion engine. The promotion engine is surrounded by three sets of APIs: the persistence management APIs, the dependency management APIs, and the Runtime APIs.
        Promotion engine components
        The promotion engine comprises a series of configurable components. All of these configurable components are specified in a configuration XML file, WCSPromotionEngineConfig.xml. The promotion engine is configured per WebSphere Commerce instance; it is not possible to have different configurations for stores in the same instance.
        Promotion anatomy
        A promotion is defined as an interface within the promotion engine, which means that different implementations of a promotion can be supplied by the developer who customizes the promotion engine. A default implementation is supplied for the interface, which follows a pattern-based model. This topic explains the model.
        Raising customer awareness of promotions
        Advertising promotions and rendering adjustments when promotions are applied to an order are not part of the core promotion infrastructure; other WebSphere Commerce mechanisms perform these functions.
        Customization scenarios
        You can customize various aspects of the promotions component, from creating a new promotion type to changing the way the agenda builder selects potentially applicable promotions for evaluation.
        Customizing promotion organization
        If the default promotion groups (order level, product level and shipping) do not meet your business needs, you can customize your promotion organization. Specifically, you can create custom groups that are different from the default groups so that promotions in the new groups are governed by different policies. This customization should occur during store setup. This process includes incorporating the new promotion groups in an invocation template, and associating policies to these new groups.
        Customizing the agenda builder
        If you want to change the default logic that selects potentially applicable promotions for evaluation, or to improve system performance by screening promotions prior to evaluation to reduce the number of promotions to be evaluated at runtime, you can customize the agenda builder. A WebSphere Commerce instance has only one agenda builder. Customizations apply to all stores in the same instance.
        Customizing the promotion sequence builder
        If the current sequence building rules for promotion evaluation do not meet your business requirements, you can customize the sequence builder. A WebSphere Commerce instance has only one sequence builder. Customizations apply to all stores in the same instance.
        Configuring the promotion engine for a custom sequence builder
        You can configure the promotion engine to use a customer sequence builder.
        Custom promotion policies
        The promotion engine is configured with a set of default promotion policies that enforce rules related to promotion exclusivity, combining promotions, redemption limits, and so on. If the default set of promotion policies do not satisfy your business needs, you can implement custom promotion policies.
        Customizing the promotion code manager
        You can customize how the promotion engine resolves promotion codes to promotions. In addition, you can customize how promotion codes are applied so that a single field in a shopping cart accepts only one promotion code. This means that when multiple promotion codes exist for an order, only the promotion code entered most recently will be applied to the order while all others will be deleted. Without customization, all the promotion codes will be accumulated and will be applied in total.
        Customizing external entity dependencies
        The external entities of the promotion component might not expose sufficient attributes to support your promotions. In this case, you must introduce additional attributes.
        Customizing persistence management
        The promotion engine's persistence management implementation consists of seven persistence managers for seven types of objects.
        Overview of creating a new promotion type using existing promotion elements
        Add a custom promotion type to WebSphere Commerce Accelerator by reusing elements of the default promotions to simplify your customization. This can save a lot of time compared with implementing something entirely new.
        Custom promotion types
        The promotion authoring tools included in WebSphere Commerce Accelerator are responsible for building a promotion XML document using all of the building blocks available, and saving the promotion in the promotion persistence storage. This includes any additional data that is needed for integration with the environment in which the promotion executes.
        Custom filters
        Custom adjustments
        Custom conditions
        Custom conditions can be created and used to build a promotion. You can create your own custom promotion conditions to ensure that your available promotion types meet your business needs.
        Custom promotion implementations
        Example: Promotion engine configuration XML file
        The configurable components of the promotion engine are specified in a configuration XML file, WCSPromotionEngineConfig.xml. The configuration file is stored in the /WC_installdir/instances/instance_name/xml/PromotionEngineConfiguration/ directory.
        Example: runtime promotion XML
        The runtime promotion XML is the name that is given to the XML representation of a promotion type. The promotion engine uses the runtime promotion XML to evaluate the promotion on the storefront.
        Purchase condition XML definition
        The purchase condition defines what customers must have in their shopping cart before they qualify for a promotion. If the order qualifies, the purchase condition defines the applicable reward. The purchase condition XML is part of the runtime promotion XML, which the promotion engine uses to evaluate promotions during the shopping flow.
        Example: XML representation of a purchase condition
        The runtime promotion XML is the name given to the XML representation of a promotion type. The purchase condition element is a key fragment of the full runtime promotion XML; it defines the purchase condition and reward for a given promotion.
        Example: Adjustment XML fragments
        Reviewing the XML representation of some common adjustments in the runtime promotion XML for a promotion type can help you understand how to customize an adjustment.
        Example: Filter XML fragments
        Reviewing the XML representation of some common filters in the runtime promotion XML for a promotion can help you understand how to customize a filter.
        Promotion DTD example
        The Promotions tool is not shipped with a DTD for the runtime promotion XML; however, this model DTD provides a perspective of what a promotion definition might look like.
        Default promotion policies
        The Promotions component has various default promotion policies, each with a default XML representation.
        Example: Adding support for a custom promotion type
    - Working with the promotions component configuration file
      Some Management Center components, like the promotions component, have customizable configuration files. These files contain properties that control certain component features.
    - Customizing marketing
      You can customize marketing features and objects to better meet the business needs of your site. For example, you can customize e-Marketing Spots, customer segments, activities, activity components, such as triggers, targets and actions, and more. Customization is supported for the Marketing tool in Management Center and for the storefront to display e-Marketing Spots.
    - Customizing price rules
      You can customize price rules to suit the business needs of your site. For example, you can create a new condition or action for business users to add to price rules. Customization is supported for both the Price Rule Builder tool user interface in the Catalog Filter and Pricing tool, and for the pricing services.
    - Customizing store preview
      You can customize store preview to add enhancements that help business users work more efficiently. These enhancements include the click-to-edit function and in-context preview function.
    - Customizing content versioning
      The content versioning feature is enabled for some objects in the Catalogs tool in Management Center. You can add or remove content versioning support for existing objects and custom objects by customizing both Management Center and WebSphere Commerce server.
    - Customizing the infrastructure component
      Customizing the infrastructure component provides you the ability to change configurable properties for Management Center and Search Engine Optimization (SEO) functionality.
    - Developing JSP pages
      To create JSP pages for WebSphere Commerce, you should have Rational Application Developer skills and JSP skills. You should also be familiar with JSTL.
    - WebSphere Commerce JSP programming best practices
      This section offers the following selection of JSP programming best practices, which promote development of reusable and easily maintainable JSP pages within the WebSphere Commerce store development framework:
    - JSP pages and data beans
      A data bean is a Java bean that is used within a JSP page to provide dynamic content. A data bean normally provides a simple representation of a WebSphere Commerce entity bean. The data bean encapsulates properties that can be retrieved from or set within the entity bean. As such, the data bean simplifies the task of incorporating dynamic data into JSP pages.
    - WebSphere Commerce useBean tag
      The useBean tag instantiates a WebSphere Commerce data bean and automatically populates it for you. A new programming direction has also been undertaken with our starter stores that now use the JavaServer Pages Standard Tag Library (JSTL) to perform view logic, instead of Java code. At the same time, business logic has been moving into data beans. The combination of these steps allows for less Java code in a JSP page.
    - Search engine optimization (SEO)
      You can use one of the following solutions to optimize your store for search engine results.
    - Double-click handling in WebSphere Commerce
      The purpose of double-click handling in WebSphere Commerce is to prevent processing the same request twice to ensure data integrity within the system. When processing certain URL requests, such as OrderItemAdd, the double-click feature of WebSphere Commerce will identify whether the request from the online shopper is currently being processed and blocks the current request if that is the case.
  - Controller layer
    The Controller layer is the conductor of operations for a request. It controls the transaction scope and manages the session related information for the request. The controller first dispatches to a command and then calls the appropriate view processing logic to render the response.
  - Business logic layer
    The business logic layer is the business components that provide OAGIS services to return data or start business processes. The presentation layer uses these OAGIS services to display data, or to invoke a business process. The business logic provides data required by the presentation layer. The business logic layer exists because more than just fetching and updating data is required by an application; there is also additional business logic independent of the presentation layer.
  - Persistence layer
    The interaction between the business objects and persistence layer is isolated in an object called the Business Object Mediator. Business object document (BOD) commands interact with the Business Object Mediator to handle the interaction with the logical objects and how they are persisted.
  - Business model information model
    A business model, a representation of the business processes used throughout the site, provides a sample commerce solution which includes an organization structure, default user roles and access control policies, one or more starter stores, administration tools, and business processes that demonstrate best practices. A business model can be customized to support business requirements and scenarios. WebSphere Commerce provides sample business models that show some common commerce solutions. These business models are created by setting up an organization hierarchy structure, access control policies, stores, and contracts that help satisfy the necessary business requirements.
  - Business models
    Before starting to develop your site with WebSphere Commerce, you need to determine the business model supported by WebSphere Commerce that best represents the purpose of your site. Usually sites created with WebSphere Commerce will be implemented based on of one of these business models.
  - Store data information model
    Store data is the information that is loaded into the WebSphere Commerce Server database, which allows your store to function. The URL Registry Entries and View Registry Entries packages are included in the diagram, but they are not database assets. These entries are presentation configuration (that is, struts actions and forwards) that must be deployed. URL registry entries are shown in the diagram to illustrate the entire store data information model. To operate properly, a store must have the data in place to support all customer activities. For example, in order for a customer to make a purchase, your store must contain a catalog of goods for sale (catalog data), the data associated with processing orders (tax and shipping data), and the inventory to fulfill the request (inventory and fulfillment data).
  - Customizing WebSphere Commerce
    You can extend the WebSphere Commerce product to fit your business needs. This topic describes the prerequisite skills and required knowledge that you need to customize business logic. After you have the required knowledge, use WebSphere Commerce Developer to take tutorials that guide you step-by-step through various customization scenarios.
  - WebSphere Commerce development environment
    WebSphere Commerce Developer is the development toolkit for customizing a WebSphere Commerce application.
  - Web services and WebSphere Commerce
    A web service is an interface that describes a collection of operations that are accessible through the network by using standardized XML messaging.
  - WebSphere Commerce Search
    WebSphere Commerce comes with a powerful and fully integrated search function. The search functions in WebSphere Commerce provide an enriched customer experience, with features such as automatic search term suggestions and spelling correction. Since it is built on open standards, WebSphere Commerce Search is highly flexible and extensible. Starter stores can use the search engine's most sophisticated features without requiring extra customization. A key feature of Search is that sales personnel can create and manage search term associations, and search-based merchandising rules, from within the Management Center and Store view.
- Compliance
  The following section describes how you can leverage WebSphere Commerce features and functionality to help your site be compliant with different privacy and security standards.
- Securing
  These topics describe the security features of WebSphere Commerce and how to configure these features.
- Performance
- Troubleshooting

Custom conditions

Custom conditions can be created and used to build a promotion. You can create your own custom promotion conditions to ensure that your available promotion types meet your business needs.

When you are creating a custom condition for a promotion type, you must follow the expected XML format. This format is required so that the promotion engine can use your condition when the engine evaluates promotions on the storefront. The following code is a sample custom condition that you can use to model your own custom conditions:

<CustomConditions> 
  <Condition impl= "com.myCompany.condition.custom.MyOtherMoreComplexCondition">
  <!-- where myCompany is a custom package name -->
    <ConfigParameter1>XXXX</ConfigParameter1>
    <ConfigParameter2>
      <CP2.1>YYYY</CP2.1>
      <CP2.2>ZZZZ</CP2.2>
    </ConfigParameter2>
  </Condition>
</CustomConditions>

A custom condition must implement the com.ibm.commerce.marketing.promotion.condition.Condition interface, which is a subclass of XMLizable. The following code is an example definition of this interface:

package com.ibm.commerce.marketing.promotion.condition;

import com.ibm.commerce.marketing.promotion.runtime.PromotionContext;
import com.ibm.commerce.marketing.promotion.xml.*;

public interface Condition extends XMLizable {

    /**
     * IBM copyright notice field.
     */
    public static final String COPYRIGHT =
          com.ibm.commerce.copyright.IBMCopyright.SHORT_COPYRIGHT;

    boolean evaluate(PromotionContext context)
       throws PromotionConditionEvaluationException;
}

The evaluate method is expected to return either true or false. If true, the condition is considered satisfied. If false, the condition is considered not satisfied and the promotion to which this custom condition belongs will not be applied.

Note: All custom conditions must be thread safe and re-entrant.