Test Environments

This topic describes an approach to set up a Self-Managed Commerce test environment.

tip

CloudOps for Kubernetes includes tooling to provision an Amazon Elastic Kubernetes Service (EKS) cluster and prepare and manage Self-Managed Commerce environments that run in the EKS cluster. To learn more about CloudOps for Kubernetes, see Infrastructure Options.

The information in this topic is for users who are not using CloudOps for Kubernetes.

Environment Components

A typical Self-Managed Commerce environment, or stack, is composed of the following:

• A relational database.
• An ActiveMQ Java Message Service (JMS) broker.
• A set of Self-Managed Commerce web applications.

note

For information on supported and tested vendors and technologies, see Supported Technologies.

Setup Overview

A high-level description of the process to create a Self-Managed Commerce environment is:

1. Provision the relational database service and database.
2. Provision the ActiveMQ JMS service.
3. Populate the Self-Managed Commerce database by running the Elastic Path data-pop-tool. The data-pop-tool is built from the ep-commerce source code and contains the files necessary to populate the database schema with the correct tables, indices, data.
4. Start the Self-Managed Commerce services. These services are Java web applications that are built from the ep-commerce source code. They require configuration information to connect to and access the database and JMS broker.

Containerized Deployments

Elastic Path provides tooling for building Self-Managed Commerce Docker-style containers. The container images are built after the Self-Managed Commerce deployment package is built. For more information about available containerization tools, see DevOps Tooling.

Docker Compose Examples

There are many possible approaches to provision and run the components of a Self-Managed Commerce environment. Elastic Path provides Docker Compose files as examples of configuring and running a fully-containerized Self-Managed Commerce environment stack. For more information, see DevOps Tooling.

Compute Requirements

Below are the suggested minimum resources required to run the Self-Managed Commerce services for testing. This is a guideline only and your needs may vary depending on requirements and deployment approaches. As you begin testing, you will learn if these are appropriate for your needs.

• CPU: 4 cores
• Memory: 10 GB
• Disk: 40 GB

Accessing the Web Applications

The URLs to the user-facing web applications are below:

tip

The hostname and ports may vary depending on your deployment mechanism and configuration. The ports listed are those used in the Docker Compose examples.

• Cortex API Service: http://<hostname>:8080/cortex/
• Cortex Studio: http://<hostname>:8080/studio/
• Commerce Manager business user tooling: http://<hostname>:8081/cm/

Health Check Endpoints

The below endpoints can be used as health checks for the various services.

tip

The hostname and ports may vary depending on your deployment mechanism and configuration. The ports listed are those used in the Docker Compose examples.

• Cortex: http://<hostname>:8080/cortex/status

  Cortex health monitor

• Commerce Manager: http://<hostname>:8081/cm/?servicehandler=status

  Commerce Manager health monitor.

• Search Primary: http://<hostname>:8082/search/status/

  Primary search service health monitor. The primary search server was previously known as the search master.

• Search Secondary: http://<hostname>:8085/search/status/

  Secondary search service health monitor. The secondary search server was previously known as the search slave.

• Batch Server: http://<hostname>:8084/batch/status/

  Batch service health monitor.

• Integration Server: http://<hostname>:8083/integration/status/

  Integration service health monitor.

• Active MQ: http://<hostname>:8161/admin

  Active MQ control panel