Elastic Path Commerce Application Servers Guideline
note
This topic describes the manual installation and configuration of Elastic Path Commerce applications on application servers in addition to how to horizontally-scale those applications. Elastic Path Commerce is most often run in Docker-style containers and not installed manually. Application server installation and configuration is handled for you when using the containerization tooling provided by Elastic Path. For more information about containerization and other deployment options, see Elastic Path Commerce Deployment Solutions.
Application Server Tier
The following information provides guidance on the deployment and configuration of the Elastic Path Commerce applciations.
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.
- To avoid CORS (Cross Origin Resource Sharing) issues, deploy the Cortex Studio Web App to the same application server as the Cortex Server.
- The application servers should use the same timezone as the database server. In most circumstances, we recommend using
UTC
.
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 System Configuration for additional details.
The database connection and JMS (Java Messaging Service) broker are defined using JNDI.
For examples, see the
context.xml
files in thetomcat
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.
- The Commerce Database JDBC data source is defined by the
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.
System Properties
The following sections provides Java system properties can be provided on the command line at run time:
-Dcortex.response.header.vary
Used By: Cortex
Allows the list of headers specified in the Vary
header of Cortex responses to be overridden. By default this is set to authorization, accept, accept-language, x-ep-account-shared-id, x-ep-user-traits, x-ep-user-id, x-ep-user-roles, x-ep-user-scopes, x-ep-data-policy-segments
.
-Dep.asset.location
Used By: Integration
Overrides COMMERCE/SYSTEM/ASSETS/assetLocation
system setting.
-Dep.audit.enabled
Used By: All
Specifies whether Object Auditing should be enabled.
-Dep.changesets.enabled
Used By: Commerce Manager, Import/Export
Overrides COMMERCE/SYSTEM/CHANGESETS/enable
system setting.
-Dep.smtp.host
Used By: Integration
Overrides COMMERCE/SYSTEM/EMAIL/mailHost
system setting.
-Dep.smtp.port
Used By: Integration
Overrides COMMERCE/SYSTEM/EMAIL/mailPort
system setting.
-Dep.smtp.scheme
Used By: Integration
Overrides COMMERCE/SYSTEM/EMAIL/smtpScheme
system setting.
-Dep.smtp.username
Used By: Integration
Overrides COMMERCE/SYSTEM/EMAIL/emailAuthenticationUser
system setting.
-Dep.smtp.password
Used By: Integration
Overrides COMMERCE/SYSTEM/EMAIL/emailAuthenticationPassword
system setting.
-Dep.search.mode
Used By: Search
Identifies whether the search server uses the PRIMARY
or REPLICA
URL for communicating with SOLR
. It also causes the search server to build a local SOLR
index based on data in the database if the mode is set to PRIMARY
.
-Dep.search.replica.url
Used By: All
Overrides the replica
context value of the COMMERCE/SYSTEM/SEARCH/searchHost
system setting.
-Dep.search.primary.url
Used By: Search primary
Overrides the primary
context value of the COMMERCE/SYSTEM/SEARCH/searchHost
system setting.
-Dep.search.entity.loader.queue.capacity
Used By: Search primary
Overrides the default entity loader queue capacity (10000).
-Dep.search.document.creator.queue.capacity
Used By: Search primary
Overrides the default document creator queue capacity (10000).
note
The -Dep.search.entity.loader.queue.capacity
and -Dep.search.document.creator.queue.capacity
parameters are set during deployment. Assign the values to the EP_SEARCH_ENTITY_LOADER_QUEUE_CAPACITY
and EP_SEARCH_DOCUMENT_CREATOR_QUEUE_CAPACITY
specified in the .env
files in the cloud-deploy-aws/Config/cloudops-env-files
folder. For more information, see: CloudDeploy Configurations.
-Dorg.eclipse.rap.rwt.enableUITests=true
Used By: Commerce Manager
Enables support for Commerce Manager Selenium testing. Disable for production, or there will be a performance impact.
-DenableTrustedSubjectHeaderMode
Used By: Cortex
Supports switching between OAuth2 authentication and Trusted Subject Header Mode authentication when starting Cortex.
For more information, see Cortex Authentication.
-Dspring.profiles.active=disable-domain-events
Used by: Commerce Manager, Integration Server, Import/Export, Data Sync
Disables the event listener that writes records to the TOUTBOXMESSAGE
table when catalog domain objects are inserted, updated, or deleted in the database.
-Depdb.synctarget.username
Used By: Data Sync Server
User name is required by the Data Sync web application.
-Depdb.synctarget.password
Used By: Data Sync Server
Password name is required by the Data Sync web application.
-Depdb.synctarget.url
Used By: Data Sync Server
The Sync Target URL is required by the Data Sync web application.
-Depdb.synctarget.removeAbandonedTimeout
Used By: Data Sync Server
The Sync Target removeAbandonedTimeout is required by the Data Sync web application.
-Depdb.username
Used By: All
Elastic Path database user name.
-Depdb.password
Used By: All
Elastic Path database password.
-Depdb.url
Used By: All
Elastic Path database URL.
-Dep.jms.url
Used By: All
Elastic Path JMS URL.
-Dep.datasync.context
Used By: All
Properties that can be passed.
-Dep.datasync.port.http
Used By: All
Properties that can be passed.
-Dep.datasync.port.https
Used By: All
Properties that can be passed.
-Dep.datasync.tomcat.port.http
Used By: All
Properties that can be passed.
-Dep.datasync.tomcat.port.https
Used By: All
Properties that can be passed.
-Dep.tomcat.maxcachesize
Used By: All
Property that can be passed to all Elastic Path web applications.
-Dosgi.taskexecutor.maxpoolsize
Used By: Cortex
The Blueprint Extender task executor controls how many threads are used to create Spring application contexts for bundles. This property controls the maximum number of threads that can ever be created, however a new thread will only be created if the number of items in the queue exceeds queue capacity. The default is Integer.MAX_VALUE
.
-Dosgi.taskexecutor.poolsize
Used By: Cortex
The Blueprint Extender task executor controls how many threads are used to create Spring application contexts for bundles. This property controls the minimum number of threads to keep alive. The default is set to the number of processors available on the machine.
-Dosgi.taskexecutor.queuecapacity
Used By: Cortex
The Blueprint Extender task executor controls how many threads are used to create Spring application contexts for bundles. This property controls how large the queue should be allowed to become before a new thread is created. The default is Integer.MAX_VALUE
.
-Dquartz.timezone
Used By: Batch Server
This property allows a timezone to be set for use by the quartz jobs. For example, if a job is scheduled to run at midnight, it should run at midnight in the timezone specified by this JVM parameter. If not specified, the local application timezone will be used.
relos.prototype.operation.timeout
Used By: Cortex
This property allows the Cortex timeout on Helix resource operations to be modified. If a particular resource operation takes longer than this value, an exception will be thrown instead of leaving a stuck thread behind. The value is set in seconds, and defaults to 30.
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