Develop > Presentation layer > Customize promotions

Promotion engine customization

You can customize the promotion engine if the customization scenario is not already supported by the existing promotion engine function.

This type of customization can be complex and requires an in-depth understanding of the promotion engine and how it relates to the customization scenario.

• 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, we 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 WCS 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.

• Raise 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.

• 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_INSTALL/instances/instance/xml/PromotionEngineConfiguration/ directory.

• Example: runtime promotion XML
  The runtime promotion XML is the name 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
  

+

Search Tips   |   Advanced Search