Elastic Path Commerce Development

Deployment Guidelines

Deployment Guidelines

Introduction

Pusher deployment scripts are used in all deployment scenarios. For more information on the Pusher and how it is used in the deployment process see:

Elastic Path Commerce is available for cloud deployments on Amazon Web Services or Microsoft Azure. For more information, see:

Deployment Suggestions

The following suggestions apply to all deployments:

  • To simplify management, tuning and monitoring of Web Apps (except for Cortex Studio), deploy each to a separate application server instance.
  • Deploy the Cortex Studio Web App to the same application server as the Cortex Server to avoid CORS (cross-origin resource sharing) issues.
    Note: Cortex Studio is typically deployed to test environments, as it is not required in production environments.
For more information on the Elastic Path Commerce the deployment package and artifacts that are supplied, see:

Clustering and Scaling

The following Elastic Path Commerce components are listed along with optimization advice on how best to implement clustering and scaling to suit your installation.

Cortex Server

  • The Cortex Server is sessionless and can be scaled horizontally behind a load balancer for availability and throughput.
  • Auto-scaling may be used to handle peak volumes, based on your Elastic Path license terms.
Commerce Manager Server
  • The Commerce Manager Server can be scaled horizontally behind a load balancer with sticky sessions.
  • Server performance beyond 50 concurrent users per server may cause a reduction in performance.
  • The default session timeout is 4 hours. This time is set to minimize impact on users that do not save changes due to unplanned interruptions.
  • Longer session timeout is not expected to cause performance issues because there are a predictable and finite number of admin users.
Integration Server
  • The Integration Server is sessionless, and can be scaled horizontally for availability.
  • For most installations, 2 instances are enough. More than 2 are required with very high order volumes or extensive back-end integration processing.
  • Use a load balancer when exposing web services through the Integration Server.
  • When using a single instance, set it to automatically restart after a failure.
Batch Server
  • The Batch Server is designed to be deployed as a single instance. It is not intended to be scaled horizontally.
Search Server
  • The Search Server depends on the Solr Master/Slave architecture.
  • See Search Server Clustering for configuration and management details.
  • The Search Master can be deployed to the same VM as the Batch Server for small installations, or to a separate VM to handle larger catalogs.
  • Only one Search Master instance can be running at a time.
  • Search Master failure does not impact application availability.
  • For small installations, deploy a Slave instance to each node that requires search functionality.
    Note: This works well for smaller installations, but may not scale for a large number of nodes or for very large catalogs. The overhead of replicating search indexes to multiple slaves needs to be weighed against deployment complexity.
  • Alternatively, deploy a pool of search slaves behind a sessionless load balancer.
Data Sync Server
  • The Data Sync Server is sessionless and can be scaled horizontally.
  • For single instance installations, set this server to restart after a failure.

Configuration

This section describes the major configuration points for deployment. See System Configuration for additional details.

  • The database connection and JMS broker are defined using JNDI. For examples, see the context.xml files in the tomcat directory of extensions web app modules.
    • The Commerce Database JDBC data source is defined by the jdbc/epjndi JNDI resource
    • The JMS broker connection is defined by the jms/JMSConnectionFactory JNDI resource
  • Application ports are defined using property files. See Configuring Environment Specific Settings
  • Cortex is also configured using property files. See Cortex Configuration Files
  • Additional application configuration is contained in the database. See Configuring System Settings
  • The sync will introduce a new Commerce Target Database JDBC data source defined by the jdbc/targetepjndi JNDI resource
The following table lists Java system properties can be provided on the command line at run time:
System Property Used By Description
-Dep.asset.location Integration Overrides COMMERCE/SYSTEM/ASSETS/assetLocation system setting
-Dep.changesets.enabled CM, Import/Export Overrides COMMERCE/SYSTEM/CHANGESETS/enable system setting
-Dep.smtp.host Integration Overrides COMMERCE/SYSTEM/EMAIL/mailHost system setting
-Dep.smtp.port Integration Overrides COMMERCE/SYSTEM/EMAIL/mailPort system setting
-Dep.smtp.scheme Integration Overrides COMMERCE/SYSTEM/EMAIL/smtpScheme system setting
-Dep.smtp.username Integration Overrides COMMERCE/SYSTEM/EMAIL/emailAuthenticationUser system setting
-Dep.smtp.password Integration Overrides COMMERCE/SYSTEM/EMAIL/emailAuthenticationPassword system setting
-Dep.search.default.url All Overrides the default value of the COMMERCE/SYSTEM/SEARCH/searchHost system setting
-Dep.search.master.url Search master Overrides the master context value of the COMMERCE/SYSTEM/SEARCH/searchHost system setting
-Dorg.eclipse.rap.rwt.enableUITests=true CM Enables support for Commerce Manager Selenium testing. Disable for production, or there will be a performance impact.
-DenableTrustedSubjectHeaderMode Cortex Supports switching between OAuth2 authentication and Trusted Subject Header Mode authentication when starting Cortex. For more information, seeCortex Authentication.
epdb.synctarget.username Data Sync Server User name is required by the Data Sync web application.
epdb.synctarget.password Data Sync Server Password name is required by the Data Sync web application.
epdb.synctarget.url Data Sync Server The Sync Target URL is required by the Data Sync web application.
epdb.synctarget.removeAbandonedTimeout Data Sync Server The Sync Target removeAbandonedTimeout is required by the Data Sync web application.
epdb.username All Elastic Path database user name.
epdb.password All Elastic Path database password.
epdb.url All Elastic Path database URL.
ep.jms.url All Elastic Path JMS URL.
ep.datasync.context All Properties that can be passed.
ep.datasync.port.http All Properties that can be passed.
ep.datasync.port.https All Properties that can be passed.
ep.datasync.tomcat.port.http All Properties that can be passed.
ep.datasync.tomcat.port.https All Properties that can be passed.
ep.tomcat.maxcachesize All Property that can be passed to all Elastic Path web applications.

The default application context paths are:

Web Application Context Path
Batch Server batch
Cortex cortex
Cortex Studio studio
Commerce Manager cm
Search Server searchserver
Integration Server integration
Data Sync Server datasync

Additional JARs

Deployment of additional JARs to the application server depends on the database and JMS broker being used.

The deployment packages includes JARs in the following default directory locations:

  • JDBC driver - database/jdbc
  • Active MQ JARs - tools/activemq/lib