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.
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).
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).
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:
- A reverse proxy for GraphQL requests that originate from website frontend components and from the AEM Commerce authoring tools
- A GraphQL Client, which is a thin, preconfigured layer around the Apache HttpComponents HttpClient, that is used by server-side components to issue GraphQL requests
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:
- You want to hide Adobe Commerce endpoint and URLs from the public.
- 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.
- 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.
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).
For any of the other environment variables, use the configuration interface instead (Figure 7).
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).
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:
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.
- Taking a Deep Dive into Adobe Experience Manager’s Commerce Integration Framework (CIF Series, Part 1)
- Architecting a Better Ecommerce Experience with Adobe Experience Manager’s Commerce Integration Framework (CIF Series, Part 2)
- How CIF integrates with Adobe Commerce and Third Party Commerce Solutions (CIF Series, Part 3)
- Building Rich Content and Commerce Experiences with CIF (CIF Series, Part 4)
- Adobe Experience Manager (AEM)
- Adobe Commerce
- Adobe Experience Manager Cloud Service
- AEM Multi Site Manager
- AEM CIF Core Components
- Adobe Cloud Manager
- Getting Started with AEM Commerce as a Cloud Service
- Authoring Commerce Experiences
- Apache HttpComponents HttpClient
- Configuring Advanced Networking for AEM as a Cloud Service
- Introduction to Author and Publish Tier
- Apache HTTP Server Module mod_proxy
- AEM Content and Commerce