Skip to main content
Version: 8.2.x

Self-Managed Commerce Application Servers Guideline

Self-Managed Commerce is available for cloud deployments on Amazon Web Services. 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.
  • To avoid CORS (Cross Origin Resource Sharing) issues, deploy the Cortex Studio Web App to the same application server as the Cortex Server.
note

Cortex Studio is typically deployed to test environments, as it is not required in production environments.

For more information on the Self-Managed Commerce the deployment package and artifacts that are supplied, see Deployment package structure.

Clustering and Scaling​

The following Self-Managed 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 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.

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.

Context Paths​

The default application context paths are:

Web ApplicationContext Path
Batch Serverbatch
Cortexcortex
Cortex Studiostudio
Commerce Managercm
Search Serversearchserver
Integration Serverintegration
Data Sync Serverdatasync

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