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
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.
Search index lifecycle
The search index lifecycle includes tasks that you perform after WebSphere Commerce search is deployed. For example, building, replicating and propagating the search index, backing up and restoring the search index, and monitoring indexing activities across different search servers.
Populating and building the search index data
Populating and building the search index data includes the following tasks: preprocessing and building the search index, indexing site content, propagating the search index with the repeater, and setting up cache invalidation in the storefront.
Indexing site content with WebSphere Commerce Search
WebSphere Commerce contains unmanaged content such as site content, that must be crawled using the site content crawler. Unmanaged content intended for production must be published separately, as it is not part of staging propagation. Once the static content is copied to the correct location, a manual site content re-indexing from the production system is required against the repeater.
Site content crawler configuration
The site content crawler uses configuration files and manifest files to determine the site content crawler behavior.
Site content crawling in a staging environment
In a staging environment, the site content crawler is used to crawl site content, and can be configured to invoke indexing the internal site (auto-index=true) and have the content that is tested in staging. After all content is approved, the site content index update can also be replicated to the repeater as part of indexprop. Again, unmanaged content asset files must be manually copied to production. When manually publishing site content from staging to production, ensure that the manifest.txt file is also replicated. This file is later used for emergency updates.

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.
  - 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.
    - Search index lifecycle
      The search index lifecycle includes tasks that you perform after WebSphere Commerce search is deployed. For example, building, replicating and propagating the search index, backing up and restoring the search index, and monitoring indexing activities across different search servers.
      - Setting up the search index
        Your search index structure can be set up for a specific master catalog. You can deploy your search index structure on your WebSphere Commerce server (embedded configuration or standard configuration). Then, you can configure WebSphere Commerce to use the Solr index by running the search index setup utility. This utility ensures that your index is built successfully by using your WebSphere Commerce master catalog data.
      - Populating and building the search index data
        Populating and building the search index data includes the following tasks: preprocessing and building the search index, indexing site content, propagating the search index with the repeater, and setting up cache invalidation in the storefront.
        Index-building topologies and scenarios
        WebSphere Commerce Search indexes are created separately based on a specific master catalog. Deploy the WebSphere Commerce Search index, then separately manage and rebuild each index to refresh its data.
        Preprocessing and building the search index
        Building search indexes in WebSphere Commerce includes two steps: preprocessing the data using the di-preprocess utility, and building the search index using the di-buildindex utility.
        Indexing contract prices
        You can index prices in WebSphere Commerce Search. For example, you can build the WebSphere Commerce Search price index by using the calculate price utility, and then index contract prices.
        Setting up and building the inventory index
        The inventory index, a separate index that contains index data, is an extension of the product index. For accurate inventory status, you can refresh the inventory index more frequently than the product index.
        Parallel preprocessing and distributed indexing
        You can index large catalog data into the search server with parallel preprocessing and distributed indexing by sharding and merging.
        Indexing site content with WebSphere Commerce Search
        WebSphere Commerce contains unmanaged content such as site content, that must be crawled using the site content crawler. Unmanaged content intended for production must be published separately, as it is not part of staging propagation. Once the static content is copied to the correct location, a manual site content re-indexing from the production system is required against the repeater.
        Crawling WebSphere Commerce site content
        You can use the site content crawler utility to crawl WebSphere Commerce site content in starter stores.
        Crawling WebSphere Commerce site content from the repeater
        You can use the site content crawler utility from the repeater to crawl WebSphere Commerce site content in starter stores.
        Site content crawler configuration
        The site content crawler uses configuration files and manifest files to determine the site content crawler behavior.
        Crawling site content remotely
        You must consider extra factors when you build the search index for unstructured content with the site content crawler remotely.
        Site content crawling in a staging environment
        In a staging environment, the site content crawler is used to crawl site content, and can be configured to invoke indexing the internal site (auto-index=true) and have the content that is tested in staging. After all content is approved, the site content index update can also be replicated to the repeater as part of indexprop. Again, unmanaged content asset files must be manually copied to production. When manually publishing site content from staging to production, ensure that the manifest.txt file is also replicated. This file is later used for emergency updates.
        Site content crawling in Extended Sites
        You must consider extra factors at indexing time, at run time when you use Extended Sites.
        Index synchronization and delta updates
        The WebSphere Commerce Search index can typically fall out of synchronization with the latest production data over time. To maintain accuracy of the search result data, reindexing must be performed at a certain time during normal business operation. There are three forms of search reindexing, and depending on your business requirements, there are costs and benefits associated with each of the following options: Full reindexing, delta reindexing, and emergency updates.
        Caching and invalidation in WebSphere Commerce Search
        The JSP fragment cache and the data object cache can be used with the search server for caching and invalidation. The JSP fragment cache is used on the WebSphere Commerce server to cache portions of the storefront user interface for future reuse. The data object cache is used on the search server to store internal runtime properties that are used by certain search features to improve overall performance.
        Performing search index optimization
        There are several search optimization hints and tips to consider when administering WebSphere Commerce Search.
      - Replicating and propagating the search index
        You can replicate and propagate the WebSphere Commerce Search index to ensure that your catalog changes are populated into the WebSphere Commerce Search index in production.
      - Backing up, restoring, recovering, and verifying search indexes
        Several tasks help you backup and restore the WebSphere Commerce Search index, depending on your business needs.
      - Using the search administration logger
        You can use the WebSphere Commerce Search administration logger to check logging information throughout the WebSphere Commerce Search lifecycle.
    - Search best practices
      Follow the best practices to ensure that your WebSphere Commerce Search implementation works efficiently. Best practices include specific roles, such as site developers, administrators, and business users.
    - Tracing and logging
      You can enable tracing and logging to help troubleshoot WebSphere Commerce Search after deployment.
  - 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

Site content crawling in a staging environment

In a staging environment, the site content crawler is used to crawl site content, and can be configured to invoke indexing the internal site (auto-index=true) and have the content that is tested in staging. After all content is approved, the site content index update can also be replicated to the repeater as part of indexprop. Again, unmanaged content asset files must be manually copied to production. When manually publishing site content from staging to production, ensure that the manifest.txt file is also replicated. This file is later used for emergency updates.

For regular updates, the indexing processing is done in the staging server and then replicated to production. In this case, the manifest file does not need to be copied because it is only needed when indexing.

For emergency updates, the indexing processing is done in the production server against the repeater. In this case, the manifest.txt file must be copied.

For applying emergency fixes to site content, the following outline shows the high-level procedures involved:

After the site content is tested in staging, the updated asset files are manually copied to production.
In the production system, an IT Administrator updates the correct manifest.txt file to include only the set of files that must be reindexed.
Start the site content index rebuild script from the production system so that the repeater can be updated with the latest site content changes.
After reindexing the repeater is completed, the subordinate search servers in production detect these updates and immediately initiate the replication.
Optional: If the updated site content is cached, a manual invalidation is required.

In both cases (regular updates and emergency updates), you must manually copy the updated unmanaged content asset files to production. For deleted files, the index of those deleted files must be manually deleted on the server where the indexing processing occurs by using the di-buildindex utility with webcontentDelete set to true.