Elastic Path Commerce Deployment Guidelines
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 Deployment package structure.
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 is designed to be deployed with one active instance at any given time. These instances cannot be scaled horizontally, but your deployment environment should be configured to stand up a new instance if the active instance goes offline.
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.
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 with one active instance at any given time. These instances cannot be scaled horizontally, but your deployment environment should be configured to stand up a new instance if the active instance goes offline.
Search Server
The Search Server depends on the Solr Primary/Replica architecture. For configuration and management details, see Search Server Clustering.
The primary Search Server is designed to be deployed with one active instance at any given time. These instances cannot be scaled horizontally, but your deployment environment should be configured to stand up a new instance if the active instance goes offline.
The primary Search Server can be deployed to the same VM as the Batch Server for small installations or to a separate VM to handle larger catalogs.
Failure of the primary Search Server does not impact application availability.
For small installations, deploy a replica instance to each node that requires search functionality.
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 replicas needs to be weighed against deployment complexity.
Alternatively, deploy a pool of replicas 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.
Apache ActiveMQ
- Apache ActiveMQ is required for all services except the Search Server.
- In production, implement one primary broker and one replica broker (in case the primary broker becomes unavailable).
- Monitor ActiveMQ as a core component.
- Other Java Message Service (JMS) implementations are not supported at this time.
Configuration
This section describes the major configuration points for deployment. See Environment Specific Configuration for additional details.
The database connection and JMS (Java Messaging Service) broker are defined using JNDI.
For examples, see the
context.xmlfiles in thetomcatdirectory of extensions web app modules.- The Commerce Database JDBC data source is defined by the
jdbc/epjndiJNDI resource. - The JMS broker connection is defined by the
jms/JMSConnectionFactoryJNDI resource. - The Data Sync target database JDBC data source is defined by the
jdbc/targetepjndiJNDI resource.
- The Commerce Database JDBC data source is defined by the
Cortex is configured using property files. See Cortex Configuration Files.
Additional application configuration is contained in the database. See Configuring System Settings.
Values in Spring configuration files can be overidden at runtime. See Overwriting Spring Configuration.
System Properties
Elastic Path Commerce can be configured at run time using -D command line parameters to set Java system properties. The table below documents these system properties, with the exception of properties defined in Tomcat context.xml files that are the same for all environments.
| System Property | Used By | Description |
|---|---|---|
enableTrustedSubjectHeaderMode | Cortex | Supports switching between OAuth2 authentication and Trusted Subject Header Mode authentication when starting Cortex. For more information, see Cortex Authentication. |
ep.asset.location | Integration | Overrides COMMERCE/SYSTEM/ASSETS/assetLocation system setting. |
ep.changesets.enabled | Commerce Manager, Import | Overrides COMMERCE/SYSTEM/CHANGESETS/enable system setting. |
ep.external.channel.inventory | Integration | The asynchronous channel used to receive inventory updates from external systems. |
ep.external.channel.inventory .dlq | Integration | The dead letter channel associated with ep.external.channel.inventory. |
ep.external.channel.purchases | Integration | The external channel used to send purchases to external fulfillment systems. |
ep.external.channel.purchases .dlq | Integration | The dead letter channel associated with ep.external.channel.purchases. |
ep.external.channel.shipments | Integration | The external channel used to receive shipping notifications from external systems. |
ep.external.channel.shipments .dlq | Integration | The dead letter channel associated with ep.external.channel.shipments. |
ep.search.default.url | All | Overrides the default value of the COMMERCE/SYSTEM/SEARCH/searchHost system setting. |
ep.search.master.url | Search Master | Overrides the master context value of the COMMERCE/SYSTEM/SEARCH/searchHost system setting. |
ep.search.document.creator .queue.capacity | Search Master | Overrides the default document creator queue capacity (10000). Can be set in CloudOps using the EP_SEARCH_DOCUMENT_CREATOR_QUEUE_CAPACITY .env variable. For more information, see CloudDeploy Configurations. |
ep.search.entity.loader .queue.capacity | Search Master | Overrides the default entity loader queue capacity (10000). Can be set in CloudOps using the EP_SEARCH_ENTITY_LOADER_QUEUE_CAPACITY .env variable. For more information, see CloudDeploy Configurations. |
ep.smtp.host | Integration | Overrides COMMERCE/SYSTEM/EMAIL/mailHost system setting. |
ep.smtp.port | Integration | Overrides COMMERCE/SYSTEM/EMAIL/mailPort system setting. |
ep.smtp.scheme | Integration | Overrides COMMERCE/SYSTEM/EMAIL/smtpScheme system setting. |
ep.smtp.username | Integration | Overrides COMMERCE/SYSTEM/EMAIL/emailAuthenticationUser system setting. |
ep.smtp.password | Integration | Overrides COMMERCE/SYSTEM/EMAIL/emailAuthenticationPassword system setting. |
epdb.username | All | The Elastic Path database user name. |
epdb.password | All | The Elastic Path database password. |
epdb.url | All | The Elastic Path database URL. |
epdb.ro.url | All | The URL of the read-only database cluster when horizontal database scaling is implemented. |
ep.jms.url | All | The Elastic Path JMS URL. |
epdb.synctarget.username | Data Sync | The Data Sync target database user name. |
epdb.synctarget.password | Data Sync | The Data Sync target database password. |
epdb.synctarget.url | Data Sync | The Data Sync target database URL. |
epdb.synctarget.jms.url | Data Sync | The Data Sync target JMS URL. |
org.eclipse.rap.rwt .enableUITests=true | Commerce Manager | Enables support for Commerce Manager Selenium testing. Disable for production, or there will be a performance impact. CloudOps enables this only for single instance environments. |
Context Paths
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