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.
Administering
Staging server
The WebSphere Commerce staging server is a part of the production environment where business and technical users can update and manage store data and preview changes. The changes can then be propagated to the production server.
Creating a staging server
You can create a staging server for testing changes to your WebSphere Commerce site before the changes are moved to a production environment.
Creating the staging server before the production server
The staging server can be created either immediately before the production server, for example, a few minutes or hours. The staging server can also be used as a development environment for a longer period of time, for example days or months, before the production server is created. This is the most common and easiest scenario to set up.

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
  - Overview of administering a WebSphere Commerce site
    In WebSphere Commerce the person who performs administrative tasks is called a Site Administrator. The Site Administrator installs, configures, and maintains WebSphere Commerce and the associated software and hardware. The administrator responds to system warnings, alerts, and errors, and diagnoses and resolves system problems. Typically, this person controls access and authorization (creating and assigning members to the appropriate role), manages the Web site, monitors performance, and manages load balancing tasks. The Site Administrator might be responsible for establishing and maintaining several server configurations for different stages of development such as testing, staging, and production. The Site Administrator also handles critical system backups and resolves performance problems.
  - WebSphere Commerce instance
    Every WebSphere Commerce installation requires at least one instance to function, and each WebSphere Commerce instance can contain one or more stores.
  - Managing features
    You can administer the features for your store and site, such as attribute, catalog, promotion, marketing, order management features, and more. The administration tasks that you can complete differ depending on the type of feature and the tool that you use to administer your store and site.
  - Logging services
    WebSphere Commerce provides facilities for logging. For existing customers, ECTrace and ECMessage are still supported. For new implementations, use the WebSphere Application Server recommendation for logging and tracing.
  - Business auditing
    Business auditing is the capturing of the business logic and objects during a WebSphere Commerce operation. You may want to audit your business for various reasons: generic, such as to review various tasks performed weekly; or specific, such as to track the steps involved in a particular Customer Service Representative's order. A report on business auditing is available in the Administration Console.
  - Business events
    Each time that a command triggers a business event, a record is added to the BUSEVENT database table to persist data from the event. Event listeners and external systems (such as the Marketing component, a back end order management system, or an external analytics system) can use this data to perform further processing.
  - Staging server
    The WebSphere Commerce staging server is a part of the production environment where business and technical users can update and manage store data and preview changes. The changes can then be propagated to the production server.
    - Creating a staging server
      You can create a staging server for testing changes to your WebSphere Commerce site before the changes are moved to a production environment.
      - Creating the staging server before the production server
        The staging server can be created either immediately before the production server, for example, a few minutes or hours. The staging server can also be used as a development environment for a longer period of time, for example days or months, before the production server is created. This is the most common and easiest scenario to set up.
      - Creating the staging server after the production server
      - Creating a staging server on a migrated environment
        You can create a staging server after migrating your WebSphere Commerce environment.
      - Configuring databases for use with the staging utilities
        Configure the staging utilities for use with your staging environment database.
      - Enabling custom tables for staging
        If you have customized your database schema by creating new tables and you want to stage these custom tables, perform the following steps for each custom table you want to stage.
    - Testing the site on a staging server
      Follow this procedure to test your site on a staging server.
    - Staging server utilities
      The staging server uses three utilities: stagingcopy, stagingprop, and fileprop.
    - Staging server limitations
      Review and consider the limitations that can affect the staging server before you begin using this server.
    - WebSphere Commerce staging-enabled tables
      WebSphere Commerce staging-enabled tables are grouped according to whether they contain site-related data, merchant-related data, or both site and merchant-related data. Staging-enabled tables are also called staged tables.
  - WebSphere Commerce database
    As a site administrator, maintain the WebSphere Commerce database and ensure that any WebSphere Commerce utilities and processes that load and retrieve data from the database is configured to connect to the database properly.
  - Dynamic caching
    In general, caching improves response time and reduces system load. Caching techniques are used to improve the performance of World Wide Web Internet applications. Most techniques cache static content (content that rarely changes) such as graphic and text files. However, many websites serve dynamic content, containing personalized information or data that changes more frequently. Caching dynamic content requires more sophisticated caching techniques, such as those provided by the WebSphere Application Server dynamic cache, a built-in service for caching and serving dynamic content.
  - Extracting, transforming, and loading data
    WebSphere Commerce provides multiple utilities for preparing and loading data into a WebSphere Commerce database. The loading utilities are flexible and you can continue to use these utilities when you customize the WebSphere Commerce schema.
  - Payment plug-ins
    To configure a payment plug-in define payment and refund methods; payment and refund rules; and the payment protocols that you intend to use.
  - WebSphere Commerce Search
    For a fully functioning WebSphere Commerce Search implementation, you must understand and complete the search administration tasks, which include search index management and ongoing maintenance.
  - Deploying a WebSphere Commerce dual cell environment
    Consider deploying a dual cell environment to achieve continuous availability and ensure that shoppers are minimally affected by planned or unplanned outages.
  - IBM Customer Service for WebSphere Commerce
    IBM Customer Service for WebSphere Commerce is a separately purchased product that provides a light-weight customer service solution that is embedded in the Aurora B2C and Aurora B2B storefronts. Even though this solution is a separately purchased product, it is not a separate application. Stores that are enabled with IBM Customer Service for WebSphere Commerce allow a customer service representative (CSR) to act on behalf of guest customers and registered customers. A CSR can manage customer accounts, cancel and reorder orders, and shop as customer. A CSR can also act on behalf of Buyer Administrators to help complete Aurora B2B tasks from the storefront, without having to access the Organization Administration Console.
- 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.
- 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

Creating the staging server before the production server

The staging server can be created either immediately before the production server, for example, a few minutes or hours. The staging server can also be used as a development environment for a longer period of time, for example days or months, before the production server is created. This is the most common and easiest scenario to set up.

The following high-level steps describe how to setup the staging server before the production server:

Install WebSphere Commerce and create an instance on the staging and production servers. During staging instance creation, ensure that you select the Use Staging Server check box on the Database panel to configure the instance as your staging server. To avoid complexity and performance issues, it is best to have two physically different servers for your staging and production servers.
On the staging server, create your store and its assets. For example, create a catalog and upload product information such as images and create users such as Marketing and Catalog managers.
Test your store to ensure it functions as you expect.
When the store is ready to run on the production server, propagate the data from the staging server to the production server.
- Publish database data using the stagingprop utility.
- Publish managed files using a fileprop utility.
- Publish all other files using the WebSphere Application Server update utility. For more information, see the Updating enterprise applications with the console topic.

The stagingcopy command, which copies the production data to the staging server is not required in this scenario, but can be used to synchronize the staging server and the production server if their databases are no long synchronized.