The information contained in this section applies to IBM WebSphere Commerce Version 7.0.0.9 and Feautre Pack 8. The documentation also applies to all subsequent releases and modifications until otherwise indicated in new editions.
The topics in the Developing section describe tasks performed by an application developer.
WebSphere Commerce search provides enhanced search functionality in starter stores by enabling enriched search engine capabilities such as automatic search term suggestions and spelling correction, while influencing store search results by using search term associations, and search-based merchandising rules.
This guide outlines the WebSphere Commerce search programming model, extension points, and how it can be customized. There are mandatory and optional areas to work with, depending on the customization that is being performed to your WebSphere Commerce search implementation.
The following guide outlines the WebSphere Commerce search programming model, extension points, and how it can be customized. There are mandatory and optional areas to work with, depending on the customization that is being performed to your WebSphere Commerce search implementation.
You can customize several areas of the search run time.
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.
Review this section for information about installing the WebSphere Commerce product, associated maintenance, and WebSphere Commerce enhancements.
Before you migrate WebSphere Commerce, review this information for an overview of the migration process.
WebSphere Commerce provides many tutorials.
Functional architecture provides both the set of patterns used to implement the business functionality and the frameworks in which these business functions execute.
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.
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.
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 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).
WebSphere Commerce Developer is the development toolkit for customizing a WebSphere Commerce application.
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.
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.
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.
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.
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.
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 uses a number of specialized terms. A concise list of the most commonly used terms is provided to get you started.
WebSphere Commerce search includes several key services and interaction areas, including the search interface, programming model, and its interactions with other WebSphere Commerce components.
The WebSphere Commerce search index is built from temporary tables that read from a search index schema, and build structured and unstructured site content.
WebSphere Commerce search indexes are created separately based on a specific master catalog. After deploying the WebSphere Commerce search index, you can separately manage and rebuild each index to refresh its data.
Search relevancy and merchandising is the process of controlling the search results that are returned to shoppers in the storefront, and the order in which they appear. There are several techniques that can be used to influence search relevancy, which lets you return products in the order that best suits your business needs.
WebSphere Commerce search is configured using several files. These files contains properties that control certain search features, and can be extended to meet your business requirements.
Adding new fields into the index schema requires modifying the schema.xml file to add the new index field. Typically, an existing index is updated to add new fields (local index). In other instances, it is recommended to extend the product index by creating an index as an extension of an existing index (extension index).
The base index schema can be extended to suit your business needs. For example, to separate data into different indexes that are based on their refresh intervals.
The indexing process requires mapping data from an external source (database or file) to index fields to create index records or index documents. Depending on the complexity of the source data and index schema design, preprocessing the data might be required. Otherwise, indexing can be directly performed by using either the Data Import Handler (DIH) to index data from the database, or SolrJ APIs to index data from a file.
You can add native Solr query parameters to each search profile's query parameter section to enhance and customize the final Solr query.
You can add custom index fields to be returned in REST responses by updating the wc-component.xml file.
WebSphere Commerce search uses search profiles to control the storefront search experience at a page-level. Search profiles group search runtime parameters (search index name, search index fields, expression providers and result filters, paging and sorting), and search feature configurations (text highlight, facets, and spelling correction). Search profiles are defined in the WebSphere Commerce search configuration file, wc-search.xml.
You must customize WebSphere Commerce search when you are adding new indexed catalog entry properties to search rule actions or targets.
You can customize WebSphere Commerce search in the storefront to suit your business needs. You can customize WebSphere Commerce search according to your role within the WebSphere Commerce site.
The following limitations exist in WebSphere Commerce search-enabled starter stores.
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.
These topics describe the security features of WebSphere Commerce and how to configure these features.