Adobe Tech Blog
Published in

Adobe Tech Blog

Use AEM as a Cloud Service with Multiple Adobe Commerce Systems

Co-Author: Dirk Rudolph

With AEM Commerce as a Cloud Service, brands with multiple Adobe Commerce deployments now enjoy the simplicity of a single experience management layer.

AEM is a powerful content management system (CMS) that seamlessly connects and streamlines the creation of digital content and media and its delivery to provide omnichannel, personalized customer experiences. Having a single experience management layer to combine and simplify these processes not only accelerates time to value (TTV) but also decreases the total cost of ownership (TCO).

In this post, Part 5 of our Commerce Integration Framework (CIF) series, we’re going to walk you through the steps of deploying a complex setup, connecting a single Adobe Experience Manager (AEM) as a Cloud Services environment with multiple Adobe Commerce deployments.

This is a new feature that was introduced in the latest release for AEM Commerce as a Cloud Service. So in this post, we want to give you an overview of the setup options, explain the architecture, and show you what a multiple commerce endpoint deployment looks like. We’ll guide you through the configuration steps, too. But first, let’s first look at a simple deployment to help you more fully understand the power of this new feature.

Simple deployment of AEM as a Cloud Services with a single instance of Adobe Commerce

Figure 1 illustrates a simple and pretty typical deployment of AEM as a Cloud Services together with a single instance of Adobe Commerce. This setup pattern is currently used by the majority of our AEM Content and Commerce customers. It works perfectly fine for one or multiple commerce websites. Using AEM Multi Site Manager, customers can roll out global stores and websites, each of them connected to a dedicated store configuration on Adobe Commerce.

Simple deployment of AEM as a Cloud Services with a single instance of Adobe Commerce.
Figure 1. Simple deployment of AEM as a Cloud Services with a single instance of Adobe Commerce.

With this setup, you can have localized regional catalogs, create translation workflows, use different currencies, and run different campaigns for each website. All of this is possible out of the box with the Commerce Integration Framework (CIF). However, there is one limitation — all the commerce configurations must be done on a single Adobe Commerce instance.

Multiple Adobe Commerce Systems

While a direct connection between one AEM environment and a single Adobe Commerce system works very well for the majority of our customers, we’ve learned that many businesses have more complex deployments. To meet the needs of these businesses, we have introduced additional support for one-to-many deployments so that now, one AEM environment can be used to connect to multiple commerce backend systems. The complexity of a one-to-many setup can vary, but the three most common situations requiring the ability for AEM with CIF to communicate with multiple Adobe Commerce deployments are:

  • Multi-region commerce deployments with different, isolated Adobe Commerce instances for America, Europe, Asia, and other regions. This setup might be needed for either or both compliance with legal requirements and scalability.
  • Multi-branch manufacturers, where brands may autonomously operate their own commerce backend. This is often needed for commerce in the consumer-packaged goods and retail sectors.
  • Incremental migration from a legacy commerce deployment to Adobe Commerce, where some sites connect to the new Adobe Commerce deployment while others remain connected to the legacy system.

Let’s walk through the reference setup covered in the diagram, based on the first of these examples where one AEM as a Cloud Service deployment hosts the store websites in two geographic regions (Figure 2).

AEM and Commerce deployment for two geographic regions.
Figure 2. AEM and Commerce deployment for two geographic regions.

This deployment handles all the traffic for the various stores in the different regions and in each country. In our example here, we’re deploying two Adobe Commerce instances. One in data centers in the U.S. and the other one in Europe, to legally separate the customer databases, which allows us to more easily comply with General Data Protection Regulations (GDPR) required only in the European Union. With this setup, the Adobe Commerce deployment in Europe is configured to meet the GDPR requirements and handles all the commerce transactions of European shoppers. The other deployment is configured for U.S. customers and handles all of their transactions from the U.S. data center.

AEM as a Cloud Service handles all the calls from shoppers navigating through the store website, routing them to the correct data center. If the customer navigates to a page that contains commerce components to render products like a product list or a product detail page, AEM will direct the GraphQL call automatically to the correct store on the Adobe Commerce instance. This is possible because each website is associated with a CIF Cloud Service configuration, which holds the relevant store information for the connected GraphQL client.

Direct GraphQL calls from the shopper's browser can be routed directly to the Adobe Commerce instance or via the reverse proxy provided by AEM as a Cloud Services (Figure 3).

AEM multi-site with Adobe Commerce multi-store setup.
Figure 3. AEM multi-site with Adobe Commerce multi-store setup.

Multiple Endpoint Architecture

To support one-to-many commerce endpoints, we followed the same general approach as we did for a single endpoint.

As a customer, you can define environment variables, which will be used to automatically configure everything required for the CIF Core Components and the Commerce Add-on to connect to your Adobe Commerce deployments. The Commerce Add-On is available for all Adobe Experience Manager deployment models, including Adobe Experience Manager Cloud Service. Once enabled, it will be automatically deployed to all environments with the Cloud Manager program.

The implementation uses two methods to connect to the Commerce endpoints:

While using the reverse proxy is not a hard requirement for CIF projects, we highly recommend it. There are three important reasons to use the built-in reverse proxy:

  1. You want to hide Adobe Commerce endpoint and URLs from the public.
  2. Your Adobe Commerce deployment exists behind some VPN or an IP allowlisting control and cannot be accessed from the public internet. This requires additional configuration steps for Advanced Networking.
  3. You want to circumvent cross-origin resource sharing (CORS) limitations of your commerce backend, which is less of a challenge if all requests are served from a single domain

The reverse proxy implementation is slightly different for the AEM Author and Publish tier. In an AEM Author environment, the reverse proxy is implemented by a servlet contained in the Commerce Add-On, which provides the authoring tools. In the AEM Publish environment, it is realized via an immutable mod_proxy configuration in the Apache HTTP server.

Each GraphQL Client has an identifier, which is also used to construct the path required for the reverse proxy. That means, if a GraphQL Client is registered with the identifier endpoint-2 and it is used in a CIF Cloud Service configuration, the reverse proxy path of this configuration will automatically be set to /api/graphql/endpoint-2 assuming the default scheme is used. However, it is still possible to configure an absolute URL as the proxy path in the CIF Cloud Service configuration. In this case, the proxy path will be left untouched by the implementation.

Multi-endpoint deployment for AEM Author.
Figure 4. Multi-endpoint deployment for AEM Author.
Multi-endpoint deployment for AEM Publish.
Figure 5. Multi-endpoint deployment for AEM Publish.

AEM as a Cloud Service comes preconfigured with the default endpoint (the one that has always been supported) and four additional endpoints:

You will notice that the default GraphQL client and reverse proxy configuration uses a slightly different scheme for backward compatibility reasons. However, overall, AEM rules, especially for the environment variable naming have changed.

Also, keep in mind that the GraphQL Clients and reverse proxies are only enabled when the respective environment variables are set, which makes them automatically available on both the AEM Author and Publish tier.

Note that the multiple commerce endpoint support is for one AEM environment connecting to multiple Commerce installations of the same deployment type (e.g. AEM production, commerce production, etc.). You should not need or use this setup to connect from an AEM production environment to commerce staging. Connecting environments of different types is already supported by CIF and AEM Commerce as a Cloud Service.

How to set up multiple Adobe Commerce systems with your AEM Cloud Services environment

To configure the environment variables, you can use either the Cloud Manager UI or the Adobe I/O CLI. The default endpoint can be configured using the specific Commerce Endpoint interface available in all programs that have the Commerce Add-On enabled (Figure 6).

Setting the default commerce endpoint with the Cloud Manager UI.
Figure 6. Setting the default commerce endpoint with the Cloud Manager UI.

For any of the other environment variables, use the configuration interface instead (Figure 7).

Setting additional environment variables with the Cloud Manager UI.
Figure 7. Setting additional environment variables with the Cloud Manager UI.

You can also use the Adobe I/O CLI with the Cloud Manager plugin to set the default Commerce Endpoint using the following code:

aio cloudmanager:set-environment-variablesoaio cloudmanager:set-environment-variables ENVIRONMENT_ID — variable COMMERCE_ENDPOINT “<Adobe Commerce GraphQL endpoint URL>”

Or you can use the following for the other environment variables, respectively:

aio cloudmanager:set-environment-variables ENVIRONMENT_ID — variable AEM_COMMERCE_ENDPOINT_2 “<Adobe Commerce GraphQL endpoint URL>”

Once the environment variables are configured, the endpoints will be listed in the CIF Cloud Configuration and can be selected by an administrator, or they can be deployed. Selecting any of the endpoints will automatically update the proxy path in the configuration (Figure 8).

Selecting preconfigured additional endpoint in CIF Cloud Service configuration.
Figure 8. Selecting preconfigured additional endpoint in CIF Cloud Service configuration.

It is possible to adjust the settings of the GraphQL Clients, for example, to optimize timeouts, configure caching, or add additional HTTP headers. To do so we recommend configuring your own GraphQL Clients as part of the project setup.


To replace the out-of-the-box configuration use the same identifier with a higher service ranking. The code below provides an example of the default configuration.

If the five pre-configured endpoints are not enough for your deployment, it is possible to configure custom endpoints as well. For this, you’ll need to create an OSGI configuration for the GraphQL Client with the factory PID, for example:

You can also add a new reverse proxy configuration for the proxy path to your project's dispatcher vhost with the following code. Make sure the LocationMatch directive matches the identifier used in your GraphQL Client OSGI configuration:

Next Steps

When it comes to offering personalized customer experiences, growing brands need a platform that can help them meet new and more complex needs. AEM as a Cloud Service with CIF makes building your commerce business with multiple, highly customized backend deployments fast and easy while accelerating your time to market.

If you already have a custom setup that connects your AEM as a Cloud Service to multiple Commerce backends, migrate now to the latest release for AEM Commerce as a Cloud Service to save on maintenance costs in the long run.


  1. Taking a Deep Dive into Adobe Experience Manager’s Commerce Integration Framework (CIF Series, Part 1)
  2. Architecting a Better Ecommerce Experience with Adobe Experience Manager’s Commerce Integration Framework (CIF Series, Part 2)
  3. How CIF integrates with Adobe Commerce and Third Party Commerce Solutions (CIF Series, Part 3)
  4. Building Rich Content and Commerce Experiences with CIF (CIF Series, Part 4)
  5. Adobe Experience Manager (AEM)
  6. Adobe Commerce
  7. Adobe Experience Manager Cloud Service
  8. AEM Multi Site Manager
  9. AEM CIF Core Components
  10. Adobe Cloud Manager
  11. Getting Started with AEM Commerce as a Cloud Service
  12. Authoring Commerce Experiences
  13. Apache HttpComponents HttpClient
  14. Configuring Advanced Networking for AEM as a Cloud Service
  15. Introduction to Author and Publish Tier
  16. Apache HTTP Server Module mod_proxy
  17. AEM Content and Commerce




News, updates, and thoughts related to Adobe, developers, and technology.

Recommended from Medium

Azure Container Registry(ACR) Cleanup

Issabel Installation

Apple schedules WWDC22 returns June 6–10

Minimize the waste in software development

Updating Local Default Branch

Creating aVR game in Unity

Upload media in rails app to Cloudinary for FREE (no credit card)


Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Markus Haack

Markus Haack

I'm a software engineer, passionate about Home Assistant and automating our house. In my professional life I’m working on commerce and content topics at Adobe.

More from Medium

What is a Product Owner (PO)?

Product Requirement Documentation

Scrum Master vs Project Manager : What are the Differences?

Scrum Master Vs Project Manager

The Release (Planning) Checklist 🚀