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.
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).
Inventory assets
An Inventory package. In WebSphere Commerce, inventory is the products at a fulfillment center. Inventory is specific to a particular Store, and thus the Inventory package is shown as dependent on the Store package.
ATP inventory information model
ATP inventory consists of inventory operations, which include check, allocation, and reverse based on on-hand inventory minus reserved inventory and inventory that is allocated for a backorder.

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.
  - 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).
    - Store data assets
      A package of stores. In WebSphere Commerce an online store is the place where all transactions for your online business occur. WebSphere Commerce supports several different types of entities that are defined as stores. These store types include customer-facing store, asset store, and proxy store.
    - Pricing assets
      A package of prices. Prices are not specific to any particular store. Each store can use Prices, and thus the store object is shown as dependent on the Prices package.
    - Catalog assets
      A package of catalogs. Catalogs are not specific to any particular store. Each store can use Catalogs, and thus the store object is shown as dependent on the Catalogs package.
    - Site assets
      A package of Site Level Information. A site can contain information such as organizations, member attributes, language, roles, and other information that pertains to the site. Site information is not particular to any store. Each store can use Site Level Information, and thus the store object is shown as dependent on the Site Level Information package.
    - Trading agreement data
      A package of Trading Agreements. WebSphere Commerce provides a number of trading mechanisms that govern the interactions between buyers and sellers. A trading agreement represents an instance of a trading mechanism and records the properties of that instance of a trading mechanism. Each contract, business account, and RFQ in WebSphere Commerce is represented by a trading agreement. WebSphere Commerce supports several trading agreement types, including account, contract, RFQs, and exchange. Trading Agreements are specific to a particular Store, and thus the Trading Agreements package is shown as dependent on the Store.
    - Contract and account assets
      A package of Contracts and Accounts. In WebSphere Commerce, a contract is an agreement that represents the terms and conditions that apply to a transaction. An account is a relationship between the merchant and the financial institution that processes transactions for that merchant. Contracts and Accounts are not particular to any store. Each store can use Contracts and Accounts, and thus the store object is shown as dependent on the Contracts and Accounts package.
    - Member assets
      A package of Members. A member is a person, group, or organization that is known to the system. A member can be a user, an organization, an organization unit, or a member group. A member can act as a customer or an administrator, or can own entities.
    - Fulfillment assets
      A Fulfillment package. In WebSphere Commerce, fulfillment is the process of filling an order for a client. A fulfillment center serves as a storage warehouse where products are packaged and shipped to customers. Fulfillment centers, stores, and shipping carriers are treated as separate entities. Fulfillment is not particular to any store. Each store can use Fulfillment and the store object is shown as dependent on the Fulfillments package.
    - Vendor assets
      A Vendors package. A vendor represents a source for merchandise that is received at a fulfillment center, or expected to be received at a fulfillment center. Vendors are not particular to any store, but rather each store can work with vendors. Since each store can work with Vendors, the store object is shown as dependent on the Vendor package.
    - Inventory assets
      An Inventory package. In WebSphere Commerce, inventory is the products at a fulfillment center. Inventory is specific to a particular Store, and thus the Inventory package is shown as dependent on the Store package.
      - ATP inventory information model
        ATP inventory consists of inventory operations, which include check, allocation, and reverse based on on-hand inventory minus reserved inventory and inventory that is allocated for a backorder.
      - Non-ATP inventory information model
        Non-ATP inventory consists of inventory operations, which include check, allocation, and reverse operations that are only based on existing on-hand inventory.
    - Jurisdiction assets
      A Jurisdictions package. A jurisdiction is a geographical region for tax or shipping purposes that represent a country or region, province or territory, postal code range, or an application-specific geo-code. In WebSphere Commerce, a geo-code is an application-specific code that represents a geographical region. Jurisdictions are specific to a particular Store, and thus the Jurisdictions package is shown as dependent on the Store.
    - Tax assets
      A Taxes package. Taxes are specific to a particular Store and its location, and thus the Taxes package is shown as dependent on the Store.
    - Customer segment assets
      A Customer Segments package. Customer Segments are specific to a particular Store, and thus the Customer Segments package is shown as dependent on the Store.
    - Email activity assets
      An email Activities package. Email activities provide Marketing Managers with a method by which they can perform direct marketing to customers by using email. Email activities are specific to a particular Store, and thus the email Activities package is shown as dependent on the Store.
    - Experiments assets
      An Experiments package. Experimentation enables Marketing Managers to run alternative web activities concurrently with existing activities. Experiments are similar to web activities, in that they deliver an alternative marketing message. Experiments are specific to a particular Store, and thus the Experiments package is shown as dependent on the Store.
    - Campaign assets
      A Campaigns package. A campaign is a planned series of operations that include advertisements and suggestive selling techniques, that are pursued to achieve a defined set of business objectives. Campaigns are specific to a particular Store, and thus the Campaigns package is shown as dependent on the Store.
    - Promotion assets
      A Promotions package. Promotions are specific to a particular Store, and thus the Promotions package is shown as dependent on the Store.
    - Shipping assets
      A Shipping package. Shipping is specific to a particular Store, and thus the Shipping package is shown as dependent on the Store.
    - Relationships between stores
      A Store Relationships package. A store relationship (captured in the STOREREL table) is the relationship between two stores. All store relationships are directional. In each store relationship, one store provides the services and the second store in the relationship uses those services. For example, store A uses the catalogs that are provided by store B. Store relationships are specific to a particular Store, and thus the Store Relationships package is shown as dependent on the Store.
    - Currency assets
      A Supported Currencies package. A supported currency is a currency that an online store can display and handle. Supported currencies are specific to a particular Store, and thus the Supported Currencies package is shown as dependent on the Store.
    - Language assets
      A Supported Languages package. Supported languages are specific to a particular Store, and thus the Supported Languages package is shown as dependent on the Store.
    - Units of measure assets
      A Supported Units of Measure package. Supported units of measure are specific to a particular Store, and thus the Supported Units of Measure package is shown as dependent on the Store.
    - Command, view, and URL registries
      A Supported Units of Measure package. Supported units of measure are specific to a particular Store, and thus the Supported Units of Measure package is shown as dependent on the Store.
    - Store data information model viewed by subsystem
      Each of the data assets in the store data information model can be grouped into the following functional areas:
    - Store data information model viewed by data type
      Data in WebSphere Commerce stores conforms to the types depicted in the following diagram. Each of the store data assets in the list of the Store data information model can be classified as belonging to one or more of the types of store data that is illustrated in the following diagram.
    - UML legend
      Unified Modeling Language is a standard graphical language for presenting different elements of Software design. The following examples are some of the most common elements of UML.
  - 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

ATP inventory information model

ATP inventory consists of inventory operations, which include check, allocation, and reverse based on on-hand inventory minus reserved inventory and inventory that is allocated for a backorder.

ATP inventory

Base item: The base item is the center of the inventory diagram and represents a general family of goods with a common name and description. Base items are used exclusively for fulfillment and are not particular to any store. Each catalog entry that represents a product in the catalog, has a corresponding base item for fulfillment purposes. Base items are defined in the BASEITEM table.
Item specification: An item specification is a base item with values defined for all its attributes. Each catalog entry that represents an item in the catalog has a corresponding item specification for fulfillment purposes.
Catalog entries: Products and items are catalog entries. Catalog entries are associated with store entities, meaning catalog entries, such as products and items, are found in stores.
Distribution arrangement: A distribution arrangement is associated with a base item, enabling a store to sell its own inventory. Distribution arrangements are stored in the DISTARRANG table.
Store item: A store item represents attributes that affect the way a particular store or store group allocates inventory for the specified items of a particular base item, including whether to allow a backorder and track inventory. The STORITMFFC table defines an estimate of the number of seconds it takes from the time an order item is released for fulfillment until it is shipped to the customer. This table is only populated if a store wants to define an override to the FFMCENTER default shipping offset for a store item.
The store item asset can be used by other stores.