WebSphere Commerce Search server: Advanced configuration

The advanced configuration federates and clusters WebSphere Commerce Search. First, in the standard configuration, it creates and deploys a separate search profile and web module on the same machine as the WebSphere Commerce profile. Then, federates them across nodes using the deployment manager (DMGR).
The following diagram shows a sample topology for a WebSphere Commerce and WebSphere Commerce search cluster in the production environment, with load balancing and failover configured:
Advanced deployment cluster
Where a WebSphere Application Server cluster with multiple WebSphere Commerce server and WebSphere Commerce Search nodes (machine) is deployed for scalability and failover support.
The following list summarizes the recommended WebSphere Commerce Search deployment in the advanced configuration:

Recommended WebSphere Commerce Search deployment
Component or task Details
Prerequisites
  • A dual WebSphere Application Server profile, with WebSphere Commerce and WebSphere Commerce search, on the same (non-managed) node.
  • A common database. DB2, Oracle, or IBM i.
Single cell WebSphere Application Server cluster federation
  • Deployment manager.
  • Web and WebSphere Commerce cluster, web and WebSphere Commerce Search cluster, and Repeater.
  • Federate to managed nodes and Repeater.
Edge component
  • Dispatcher for load balancing, with content-based forwarding session affinity.
  • Routing rules for REST services.
Index replication
  • Repeater, WebSphere Commerce Search in each search cluster node.
  • Verify all WebSphere Application Server name space binding.
WebSphere Application Server security
  • A self-signed certificated is imported by default. You must import your own CA-signed certificate in production environments.
  • Administrative security is enabled on the WebSphere Commerce server.
Maintenance
  • The same maintenance mechanism applies to both the WebSphere Commerce and WebSphere Commerce search applications.
  • All maintenance is applied to the local node, and then the DMGR syncs other nodes.
Service request dynamic routing
  • A new request routing mechanism called dynamic service routing is introduced into the WebSphere Commerce topology. The setup, as illustrated in the preceding diagram, consists of a typical Load Balancer that can route HTTP requests based on certain business criteria. The recommendation is to use the IBM WebSphere Application Server Edge Component. For more information, see Introducing WebSphere Application Server Edge components.
    The WebSphere Application Server Edge component comes with a Load Balancer that has a Content Based Routing ability to dispatch live traffic based on a set of programming logic. For more information, see Dispatcher component. For example, in the preceding diagram, the person resource URL is routed to the WebSphere Commerce cluster. The ProductView resource URL for searching and browsing is dispatched to the WebSphere Commerce Search cluster.
    Note: IBM WebSphere Application Server Edge Component is the recommended setup. However, there are many variations of software and hardware substitutes available in the market. Select the solution that best applies to your requirements and business needs.
  • To maintain compatibility with an earlier version with the REST services provided in Feature Pack 4, 5, and 6: it is mandatory to maintain the REST interface for existing search and browse resources. The 2 REST resources are ProductView and CategoryView. The compatibility rule covers the context path and its corresponding input parameters, and the format of the returning response. Therefore, easing the migration efforts for the previous versions of the services.

Another advanced configuration option is the managed repeater:

Managed repeater


Managed repeater
Where the following cluster deployment configuration exists in the production environment:
  • Code is installed on the primary node. Future interim fixes and maintenance are applied to the primary node. Changes to either WebSphere Commerce and search applications are propagated to other cluster members through the node agent.
  • Routing live traffic to the primary node is optional. After both the WebSphere Commerce and Search applications on the primary node are federated to the WebSphere Commerce cluster and Search cluster, you can remove the Search application from showing under the Primary node in the Deployment Manager.
  • The following approach is used to deploy the repeater:
    Managed repeater
    The repeater resides in the search cluster and is managed by the same deployment manager.
    Fixes and maintenance can be applied using the deployment manager.
  • The replication configuration on each subordinate server points to the repeater.
  • Search cluster web servers can optionally be exposed externally, if direct access to the search REST services is required.
  • WebSphere Commerce should be configured to point to the search cluster for search requests. For example, /term, /select, or REST requests.
  • Search administration requests should be configured to point to the repeater, for example, /dataimport requests.
  • The repeater web server should not be exposed externally.