Jump to main content
HCL Logo Product Documentation
Customer Support Software Academy Community Forums
IBM WebSphere Commerce V7
  • Product overview
  • WebSphere Commerce search
  • Precision marketing
  • What's new
  • User Guide
  • Reference
  • Other versions
  1. Home
  2. User Guide

    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.

  3. Developing

    The topics in the Developing section describe tasks performed by an application developer.

  4. 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.

  5. Customizing IBM Sales Center

    In the IBM Sales Center for WebSphere Commerce there is a set of user interface panels, views and dialogs that contain the most commonly used features. You can add to or configure the user interface to suit your needs, as well as changing the content and format of the data that is passed between the client and the server.

  6. Service request handlers

    The IBM Sales Center service request extension point is the mechanism by which requests are made of the server and the request results are handled and the model is updated. The class that constructs the request and interprets the response is the request handler.

  7. Replacing an existing service request handler

    To replace a service request handler implementation:

  • User Guide

    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.

    • 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 this section for information about installing the WebSphere Commerce product, associated maintenance, and WebSphere Commerce enhancements.

    • Migrating

      Before you migrate WebSphere Commerce, review this information for an overview of the migration process.

    • Operating
    • Administering
    • Tutorials

      WebSphere Commerce provides many tutorials.

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

      • Business logic
      • 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.

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

      • WebSphere Commerce development environment

        WebSphere Commerce Developer is the development toolkit for customizing a WebSphere Commerce application.

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

        • WebSphere Commerce Struts framework

          Struts is a well documented, mature and popular framework for building front ends to Java applications. To address concerns in software applications, it uses a Model-View-Controller (MVC) architecture: The Model represents the business or database code, the View represents the page design code, and the Controller represents the navigational code.

        • Management Center framework

          The Management Center framework is the foundation for business user tooling. The business objects are defined by the individual components that make up the Management Center. The framework uses those definitions to provide all of the features that you can use to find, create, modify, and delete the defined business objects. If you plan to customize the Management Center, it is important to understand the framework and the components that make up the Management Center.

        • ***
        • Management Center test automation framework

          You can use the test automation framework to write test cases that validate the Management Center model, services, and object definitions; this test framework is not intended to validate Management Center user interface widgets, such as properties views and list views.

        • Customizing content versioning

          The content versioning feature is enabled for some objects in the Catalogs tool in Management Center. You can add or remove content versioning support for existing objects and custom objects by customizing both Management Center and WebSphere Commerce server.

        • Customizing promotions

          Customizing promotions can involve the customization of the promotion business user tools and the underlying promotion engine, which features a clean architecture supporting rich functionality, as well as a wide array of customization possibilities.

        • Customizing marketing
        • Customizing price rules

          You can customize price rules to suit the business needs of your site. For example, you can create a new condition or action for business users to add to price rules. Customization is supported for both the Price Rule Builder tool user interface in the Catalog Filter and Pricing tool, and for the pricing services.

        • Customizing store preview

          You can customize store preview to add enhancements that help business users work more efficiently. These enhancements include the click-to-edit function and in-context preview function.

        • Customizing the infrastructure component

          Customizing the infrastructure component provides you the ability to change configurable properties for Management Center and Search Engine Optimization (SEO) functionality.

        • Customizing WebSphere Commerce Accelerator, Organization Administration Console, or Administration Console

          The WebSphere Commerce browser-based tools (WebSphere Commerce Accelerator, Organization Administration Console, Administration Console) can be extended or changed. In addition to customizing the tools you can also create a new browser-based tool that uses the same underlying framework. A new tool based on the tools framework is referred to as a WebSphere Commerce tools user interface center.

        • Working with JSP pages

          To create JSP pages for WebSphere Commerce, you should have Rational Application Developer skills and JSP skills. You should also be familiar with JSTL.

        • Storefront customization tools

          WebSphere Commerce Accelerator provides tools to change various elements of the storefront, such as the store or site's logo, flow, text, and style. WebSphere Commerce starter stores, showcase many such configurable elements. Depending on the needs of the store or site, the store developer can make additional choices for flow, text, and style available to the WebSphere Commerce Accelerator tools by modifying the store or site's storefront assets.

        • WebSphere Commerce JSP programming best practices

          This section offers the following selection of JSP programming best practices, which promote development of reusable and easily maintainable JSP pages within the WebSphere Commerce store development framework:

        • WebSphere Commerce useBean tag

          The useBean tag instantiates a WebSphere Commerce data bean and automatically populates it for you. A new programming direction has also been undertaken with our starter stores that now use the JavaServer Pages Standard Tag Library (JSTL) to perform view logic, instead of Java code. At the same time, business logic has been moving into data beans. The combination of these steps allows for less Java code in a JSP page.

        • Working with Facebook integration

          Facebook integration relies on several Facebook plugins to add the Connect to Facebook, Like and Send buttons to the Aurora and Madisons starter stores.

        • Search engine optimization (SEO)

          Depending on the feature pack level of your store, you can use one of the following solutions to optimize your store for search engine results.

        • Customizing IBM Sales Center

          In the IBM Sales Center for WebSphere Commerce there is a set of user interface panels, views and dialogs that contain the most commonly used features. You can add to or configure the user interface to suit your needs, as well as changing the content and format of the data that is passed between the client and the server.

          • IBM Sales Center architecture

            The IBM Sales Center architecture, when viewed in its entirety, contains the IBM Sales Center client, WebSphere Commerce Server, and a messaging architecture to allow for customization and extensibility.

          • Planning a customization to the IBM Sales Center

            The following steps are a general overview of the actions required to customize the IBM Sales Center.

          • Eclipse and plug-ins in the IBM Sales Center client

            The IBM Sales Center client relies heavily on the use of the Eclipse platform. Eclipse is a platform that has been designed for building integrated web and application development tooling. The platform has become extremely popular based on what it supports and encourages: the rapid development of integrated features based on a plug-in model.

          • System configurator

            The system configurator extension point is defined in the com.ibm.commerce.telesales plug-in. The IBM Sales Center platform provides the ability to specify a system configurator for each plug-in to identify which extensions will be used over the default IBM Sales Center extensions. The purpose of this extension point is to allow plug-ins to specify the location of their system configurator file. The file name must be config.ini. This file is a text file that allows you to provide a substitute extension ID that will be used to replace a standard IBM Sales Center extension ID. For information about the general syntax of a properties file, refer to the j ava.util.Properties API information. The following is a sample system configurator extension definition. The configurator file config.ini must be located in a directory called config that is located in the root directory of the plug-in that is defining the extension.

          • Globalization in the IBM Sales Center

            The IBM Sales Center has a large set of displayable text on the various parts of its user interface, such as window titles, dialog messages, labels, button text, and table column headers. These text strings are externalized from the code and placed into Properties files called resource bundles. Properties files exist for the default language as well as various supported locales.

          • IBM Sales Center development environment

            The IBM Sales Center development environment is the recommended tool for creating IBM Sales Center customizations. The IBM Sales Center development environment is built on Rational Application Developer 7.5. In addition to Rational Application Developer, the IBM Sales Center development environment also requires that the IBM Sales Center client is installed.

          • Creating the .option file to debug Sales Center client
          • Enabling tracing and debugging in the IBM Sales Center client

            When working within the IBM Sales Center development environment, you can enable tracing and debugging. However, there may be situations in which you want to enable tracing and debugging in the IBM Sales Center client that is not running in the development environment.

          • Deploying customizations to the IBM Sales Center

            Depending on the number of clients and frequency of updates required, you have several choices for installing and updating the IBM Sales Center.

          • User Interface Layouts in the IBM Sales Center

            The IBM Sales Center client follows the standard SWT Layout architecture as defined by the Eclipse platform. These layouts determine the size and spacing of the contents of dialogs, editors, perspectives, and views in the IBM Sales Center. Each layout sets the size and position of the individual widgets in a composite by reference to the composite definition.

          • IBM Sales Center customization

            This section related to troubleshooting while using IBM Sales Center customization.

          • Controls

            The layout of the IBM Sales Center dialogs and editors are constructed using configured controls. A configured control is a user interface element that is declared using the controls extension point. The definition of a configured control includes a unique identifier, the type of control, and additional attributes and properties that are specific to the type of control being defined. The control type is used to locate a control factory class that will construct the new configured control. Examples of control types include text, label, requiredLabel, combo, pushButton, checkBox, radioButton, table and composite. The complete list of controls is found in the extension point documentation.

          • Editors

            There are several types of editors in the IBM Sales Center. These editors are used to create and manage orders, quotes, ticklers, returns, and customers. Editors are where the Customer Service Representatives do the majority of their work.

          • Dialogs

            Dialogs are a common user interface element in the IBM Sales Center. Dialogs are used when the user chooses to perform an action and needs to provide additional information. For example, the interface that a customer uses to log on, or search for an order, are dialogs.

          • Views

            Several default views are available for customization within the IBM Sales Center client. These views are defined in the com.ibm.commerce.telesales.ui.impl plug-in using the base Eclipse product org.eclipse.ui.views extension point. For more information about views, refer to the Eclipse platform documentation.

          • Perspectives

            A perspective is a particular rendering of the IBM Sales Center that contains a predefined combination of views and editors. There are two perspectives in the IBM Sales Center, the Orders and Web Browser perspectives, that enable different sets of tasks. Both perspectives can be open and visible, but only one can be active at a time.

          • Dynamic IDs

            In some cases, it may not be possible to statically declare the identifier for an extension definition. There are cases where the choice of which extension definition to use needs to be made at run time. For example, if the layout of a composite depends on the current locale, then you cannot use the same extension declaration for every locale. The locale must be checked and the composite definition declaration must be chosen. To handle this, the system configurator allows dynamic identifier resolution.

          • Infopops

            An infopop is a small window associated with a particular widget. It displays context-sensitive help and links to related help topics for the widget. An infopop displays when the user puts focus on the widget and presses the F1 key. They are registered using the base Eclipse extension point org.eclipse.help.contexts. For the IBM Sales Center user interface elements the mappings are done programmatically by registering the infopop ID using the setHelp method on the class org.eclipse.ui.help.WorkbenchHelp (refer to the Workbench class API documentation for more information about using setHelp). The default IDs are defined in the Java interface com.ibm.commerce.telesales.ui.ITelesalesHelpContextIds and can be overridden using the System configurator extension point.

          • Preference pages

            You can set preferences in the IBM Sales Center user interface to make working with orders, customers, and stores easier. For example, you can set a preference to autoselect a particular store, or create customers by default with certain country, currency, and language attributes. There are preference pages for communication preferences, logon preferences, customer preferences, order preferences, store preferences, search preferences, and image preferences. Preference page definitions for default preference pages are in the com.ibm.commerce.telesales.config plug-in manifest file (plugin.xml).

          • Online help

            The online help is defined using the base Eclipse extension point org.eclipse.help.toc. Put your new help documentation in a new plug-in.

          • Status line
          • Menu actions

            The default IBM Sales Center actions are defined by the com.ibm.commerce.telesales.ui.actionSetGroups extension-point. This extension point allows you to specify a list of actionSet IDs and an ID for the whole group. When a IBM Sales Center perspective is loaded, it will use a predefined ID to determine which action set group to use. You can use the system configurator plug-in to override an entire action set group, or a specific action set that already defined as part of the action set. All of the out of the box IBM Sales Center menu items delegate their actual work to an action that is registered with the com.ibm.commerce.telesales.ui.actions extension point. This allows you to use the system configurator to replace the implementation of a single action.

          • Accelerator keys

            The default IBM Sales Center accelerator keys are defined by the org.eclipse.ui.commands extension point in the com.ibm.commerce.telesales.ui.impl plug-in. This extension point allows you to define a command and a keyBinding for that command. The commands are associated with Actions by calling the setActionDefinitionId method on the Action class. Commands can also be associated with actions by specifying the command ID on the definitionId attribute of the action element of the org.eclipse.ui.actionSets extension point. The key bindings are associated with a key configuration. The default IBM Sales Center key configuration ID is com.ibm.commerce.telesales.ui.telesalesAcceleratorConfiguration. You can change the default key configuration using the system configurator.

          • Resources

            A common customization scenario involves replacing the terminology used by the application with terminology that is more appropriate to the organization where the application is deployed. You might also want to replace application images with your own images. To ensure that this is possible, the IBM Sales Center application is designed to allow you to replace text and images that appear on the user interface.

          • Sales Center Auto-logon

            The IBM Sales Center client provides default autologon support for the WebSphere Commerce Accelerator and the Organization Administration Console. The autologon feature can be extended to any external Web based application.

          • Browser integration techniques

            If you integrate the IBM Sales Center with an existing WebSphere Commerce application, you can leave part of the application's browser interface intact and allow the user to switch to the browser to interact with that portion of the application.

          • Data model

            The data model is used to cache business objects on the client. The TelesalesModelManager class provides access to the model and contains convenience methods for accessing and updating child objects. The default IBM Sales Center data model contains model objects that represent the operator, customers, orders, products and other commonly used objects. All of the objects found in the client cache are instances of ModelObject. You can store additional properties in a model object using the setData and getData methods. You can also add listeners to model objects that will be notified of any change to the model object. If a property is a list of model objects, use the ModelObjectList instead of a generic container object to ensure that property notification is handled properly. Listeners will be notified if any changes to model objects that are properties of the model object that you are listening to. If you define a listener to the root model object, your listener will be notified of all changes to the model.

          • Communication services

            Communicating with the server is handled by a communication service. The request is prepared by the service request handlers and the specified communication service is invoked to send the request to the server. The response that is returned by the communication service is given back to the request handler so that it can be unmarshalled.

          • Service request handlers

            The IBM Sales Center service request extension point is the mechanism by which requests are made of the server and the request results are handled and the model is updated. The class that constructs the request and interprets the response is the request handler.

            • Adding a new service request handler

              The IBM Sales Center service request extension point is the mechanism by which requests are made of the server and the request results are handled and the model is updated. The class that constructs the request and interprets the response is the request handler. This section explains how to add a new service request handler.

            • Replacing an existing service request handler

              To replace a service request handler implementation:

            • Extending an existing service request handler

              The IBM Sales Center service request extension point is the mechanism by which requests are made of the server and the request results are handled and the model is updated. The class that constructs the request and interprets the response is the request handler. This section explains how to extend an existing service handler request.

          • WebSphere Commerce integration

            Business Object Document messages sent from the IBM Sales Center client to the WebSphere Commerce Server are mapped to WebSphere Commerce controller commands through the WebSphere Commerce message mapper. The WebSphere Commerce configuration file contains this message mapper entry. The contents of the file are:

          • Customizing Sales Center support for large shopping carts
          • Applying custom merchandising associations

            You can create custom merchandising association types based on your requirements. For example, you may want to offer a down-sell merchandising association to suggest lower-priced catalog entries based on the selected catalog entry.

          • Error handlers

            The IBM Sales Center error handler extension point is the mechanism for defining a new error handler. Errors handlers are used to handle exception thrown by the service layer while performing a Service request.

        • Double-click handling in WebSphere Commerce

          The purpose of double-click handling in WebSphere Commerce is to prevent processing the same request twice to ensure data integrity within the system. When processing certain URL requests, such as OrderItemAdd, the double-click feature of WebSphere Commerce will identify whether the request from the online shopper is currently being processed and blocks the current request if that is the case.

        • WebSphere Commerce integration with WebSphere Portal

          You can integrate WebSphere Commerce, a Business Application Service with WebSphere Portal, an Interaction Service. The Interaction Service provides core portal services (WebSphere Portal) that aggregate applications and content and deliver them as role-based applications. The Enterprise Service Bus (ESB) pattern is used for communication, mediation, transformation and integration with external systems. Using an ESB to integrate the Web services exposed from WebSphere Commerce to the WebSphere Portal promotes a loosely coupled design where the ESB manages the interactions styles between the WebSphere Commerce services and the presentation layer. You do not need to alter your presentation layer to support the protocol and format used by the WebSphere Commerce services. Instead, you rely on the ESB to perform tasks such as message transformation and protocol mediation. Neither WebSphere Commerce nor WebSphere Portal needs to change in order to communicate with one another. The ESB is used to act as an interpreter between the two systems and will translate the messages into a format the receiving system understands.

        • Content management system integration

          To integrate WebSphere Commerce and an external content management system, such as IBM Web Content Manager, ensure that you understand the JSTL tags for the integration. The JSTL tags are used on store pages to retrieve content and resolve links from the external system.

        • Analytics for IBM WebSphere Commerce

          WebSphere Commerce provides a framework that you can configure to integrate your store with an external Web analytics solution. This framework includes a tag library that you can use in store page JSP files to provide appropriate analytics information to the external analytics system.

        • IBM Product Recommendations and WebSphere Commerce

          IBM Product Recommendations is an IBM Digital Analytics solution that you can subscribe to that automatically generates personalized product recommendations on the storefront. The recommendations are based on the browsing, shopping, and purchasing behavior of individual customers. If your site is integrated with IBM Digital Analytics, you can display recommendations from IBM Product Recommendations on your store pages.

        • IBM Marketing Center integration

          You can integrate Management Center with IBM Marketing Center, a cloud-based, all-in-one solution that combines customer analytics with real-time marketing. To integrate with IBM Marketing Center, you must configure the WebSphere Commerce biConfig.xml file to enable the integration. You can also configure single-sign on between Management Center and IBM Marketing Center.

        • IBM Digital Data Exchange integration

          To simplify the process of collecting and sending customer shopping behavior data to analytics providers, integrate WebSphere Commerce with IBM Digital Data Exchange (DDX)

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

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

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

    • 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
WebSphere Commerce EnterpriseWebSphere Commerce Professional

Replacing an existing service request handler

To replace a service request handler implementation:

Procedure

  1. Define an extension definition of the Service requests extension point.
  2. Use the System configurator extension point to indicate that the new definition will be used instead of the default IBM Sales Center implementation.
  • Share: Email
  • Twitter
  • Disclaimer
  • Privacy
  • Terms of use
  • Cookie Preferences