Adobe Experience Manager (AEM) Magento Adobe Commerce Integration overview

Yegor Shytikov
11 min readSep 7, 2021

--

AEM and Adobe Commerce (Magento) integration Using Commerce Integration Framework

The Experience Manager and Adobe Commerce (Magento) are integrated using the Commerce Integration Framework (CIF). Now you need to have extra layer of obfuscation and complexity. CIF enables AEM to directly access and communicate with the commerce instance using slow Magento 2 GraphQL APIs backend.

Instead of make stuff simpler like VueStorefront Adobe will sell magneto together with Java based WordPress like CMS.

There are 6 different CIF elements that merchants can utilize to improve specific aspects of their website. These elements include:

  • AEM CIF cloud connector. This connector connects AEM with Magento Cloud GraphQL endpoint or Adobe I/O Runtime GraphQL to allow AEM to access commerce data.
  • AEM CIF core components. These server-side and client-side components are used to create static and SEO-friendly eCommerce storefronts.
  • AEM CIF archetype w/ AEM Venia storefront. This option is for those who need a starting point for their AEM projects. It provides a basic B2C storefront and uses both AEM CIF core components and AEM sites core components.
  • CIF extension layer. This refers to a middle layer that retrieves complex business logistical information. For instance, using a location and channel to determine the best inventory strategy would be an example of business logic.
  • CIF integration layer. This is the option used to connect AEM with other eCommerce solutions, including Magento and other third-party options.
  • Campaign integration. This process uses microservices and gathers live data on I/O Runtime to reduce cart abandonment rates on Magento sites.

Within CIF, there is support for server-side and client-side communication patterns.
Server-side APIs calls are implemented using the build-in, generic GraphQL client in combination with a set of generated data models for the commerce GraphQL schema. Additionally, any GraphQL query or mutation in GQL format can be used.

Magento GraphQL data models and query builders that have been automatically generated based on the default/generic (= out-of-the-box) Magento GraphQL schema. These classes can be used to build GraphQL requests and to parse/deserialise GraphQL JSON responses into java objects. These files are suitable for all projects that want to manipulate the default set of objects and attributes available in Magento, without any need to access for example customized product attributes.

If you want to access customized attributes like extra product attributes added to your product attributes set in Magento, you can use the GraphQL Java Generator to generate a similar set of Java classes that would include the custom attributes of your Magento project.

Using the query builders and parsing responses

To use this library in your project, just add the following maven dependency to your project and install the bundle in your AEM instance:

<dependency>
<groupId>com.adobe.commerce.cif</groupId>
<artifactId>magento-graphql</artifactId>
<version>...</version>
<scope>provided</scope>
</dependency>

In addition, you can use generic GraphQL client bundle for AEM to send the queries.

For the client-side components, which are build using React, the Apollo Client is used.

AEM CIF Core Component Obfuscation Architecture

AEM CIF Core Components follow very similar obfuscation patterns and best practices as the AEM WCM Core Components.

The business logic and backend communication with Adobe Commerce for the AEM CIF Core Components is implemented in Sling Models. In case it is necessary to customize this logic to fulfill project-specific requirements, the delegation Pattern for Sling Models can be used.

Within projects, AEM CIF Core Components and custom project components can easily retrieve the configured client for an Adobe Commerce store associated with an AEM page via Sling Context-Aware configuration.

Set up a Local AEM Development Environment

Guide to setting up a local development for Adobe Experience Manager, AEM. Covers important topics of local installation, Apache Maven, integrated development environments and debugging/troubleshooting. Development with Eclipse IDE, CRXDE Lite, Visual Studio Code and IntelliJ are discussed.

Overview

Setting up a local development environment is the first step when developing for Adobe Experience Manager or AEM. Take the time to set up a quality development environment to increase your productivity and write better code, faster. We can break an AEM local development environment into 4 areas:

  • Local AEM instances
  • Apache Maven project
  • Integrated Development Environments (IDE)
  • Troubleshooting

Install local AEM Instances

When we refer to a local AEM instance, we are talking about a copy of Adobe Experience Manager that is running on a developer’s personal machine. All AEM development should start by writing and running code against a local AEM instance.

If you are new to AEM, there are two basic run modes can be installed: Author and Publish. The Author runmode is the environment that digital marketers will use to create and manage content. When developing most of the time you will be deploying code to an Author instance. This allows you to create new pages as well as add and configure components. AEM Sites is a WYSIWYG authoring CMS and therefore most of the CSS and JavaScript can be tested against an authoring instance.

It is also critical test code against a local Publish instance. The Publish instance is the AEM environment that visitors to your website will interact with. While the Publish instance is the same technology stack as the Author instance, there are some major distinctions with configurations and permissions. Code should always be tested against a local Publish instance before being promoted to higher level environments.

Steps:

  1. Ensure Java is installed.
  1. Get a copy of the AEM QuickStart Jar and a license.properties.
  2. Create a folder structure on your computer like the following:
  • ~/aem-sdk /author /publish
  1. Rename the QuickStart JAR to aem-author-p4502.jar and place it beneath the /author directory. Add the license.properties file beneath the /author directory.
  2. Make a copy of the QuickStart JAR, rename it to aem-publish-p4503.jar and place it beneath the /publish directory. Add a copy of the license.properties file beneath the /publish directory.
  • ~/aem-sdk /author + aem-author-p4502.jar + license.properties /publish + aem-publish-p4503.jar + license.properties
  1. Double-click the aem-author-p4502.jar file to install the Author instance. This will start the author instance, running on port 4502 on the local computer.
  2. Double-click the aem-publish-p4503.jar file to install the Publish instance. This will start the Publish instance, running on port 4503 on the local computer.

Install Apache Maven

Apache Maven is a tool to manage the build and deploy procedure for Java-based projects. AEM is a Java-based platform and Maven is the standard way to manage code for an AEM project. When we say AEM Maven Project or just your AEM Project, we are referring to a Maven project that includes all of the custom code for your site.

All AEM projects should be built off the latest version of the AEM Project Archetype: https://github.com/Adobe-Marketing-Cloud/aem-project-archetype. The AEM Project Archetype will create a bootstrap of an AEM project with some sample code and content. The AEM Project Archetype also includes AEM WCM Core Components configured to be used on your project.

Steps

  1. Download Apache Maven
  2. Install Apache Maven and ensure that the installation has been added to your command-line PATH.
  • macOS users can install Maven using Homebrew
  1. Verify that Maven is installed by opening a new command line terminal and executing the following:
  • $ mvn --version Apache Maven 3.3.9 Maven home: /Library/apache-maven-3.3.9 Java version: 1.8.0_111, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8
  1. Add the adobe-public profile to your Maven settings.xml file in order to automatically add repo.adobe.com to the maven build process.
  2. Create a file named settings.xml at ~/.m2/settings.xml if it doesn’t exist already.
  3. Add the adobe-public profile to the settings.xml file based on the instructions here.
  4. A sample settings.xml is listed below. Note, the naming convention of settings.xml and the placement beneath the user’s .m2 directory is important.
  1. Verify that the adobe-public profile is active by running the following command:
  • $ mvn help:effective-settings ... <activeProfiles> <activeProfile>adobe-public</activeProfile> </activeProfiles> <pluginGroups> <pluginGroup>org.apache.maven.plugins</pluginGroup> <pluginGroup>org.codehaus.mojo</pluginGroup> </pluginGroups> </settings> [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.856 s

If you do not see the adobe-public it is an indication that the Adobe repo is not properly referenced in your ~/.m2/settings.xml file. Please revisit the earlier steps and verify that the settings.xml file references the Adobe repo.

Set Up an Integrated Development Environment

An integrated development environment or IDE is an application that combines a text editor, syntax support and build-tools. Depending on the type of development you are doing, one IDE might be preferable over another. Regardless of the IDE, it will be important to be able to periodically push code to a local AEM instance in order to test it. It will also be important to occasionally pull configurations from a local AEM instance into your AEM project in order to persist to a source-control management system like Git.

Below are a few of the more popular IDEs that are used with AEM development with corresponding videos that show the integration with a local AEM instance.

Troubleshooting

Help! My code isn’t working! As with all development, there will be times (probably many), where your code is just not working as expected. AEM is a powerful platform, but with great power… comes great complexity. Below are a few high level starting points when it comes to troubleshooting and tracking down issues (but far from an exhaustive list of things that can go wrong):

Verify Code Deployment

A good first step, when encountering an issue is to verify that the code has been deployed and installed successfully to AEM.

  1. Check Package Manager to ensure that the code package has been uploaded and installed: http://localhost:4502/crx/packmgr/index.jsp. Check the time stamp to verify the package has been installed recently.
  2. If doing incremental file updates using a tool like Repo or AEM Developer Tools, check CRXDE Lite that the file has been pushed to the local AEM instance and that the file contents are updated: http://localhost:4502/crx/de/index.jsp
  3. Check that the bundle is uploaded if seeing issues related to Java code in an OSGi bundle. Open the Adobe Experience Manager Web Console: http://localhost:4502/system/console/bundles and search for your bundle. Ensure that the bundle has an Active status. See below for more information related to troubleshooting a bundle in an Installed state.

Check the Logs

AEM is a chatty platform and logs a lot of useful information in the error.log. The error.log can be found where AEM has been installed: < aem-installation-folder>/crx-quickstart/logs/error.log.

A useful technique for tracking down issues is to add log statements in your Java Code:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
public class MyClass {
private final Logger log = LoggerFactory.getLogger(getClass());
... String myVariable = "My Variable"; log.debug("Debug statement of myVariable {}", myVariable); log.info("Info statement of myVariable {}", myVariable);
}

By default the error.log is configured to log INFO statements. If you want to change the log level you can do so by going to Log Support: http://localhost:4502/system/console/slinglog. You may also find that the error.log is too chatty. You can use the Log Support to configure log statements for just a specified Java package. This is a best practice for projects, in order to easily separate custom code issues from OOTB AEM platform issues.

Bundle is in an Installed state

All bundles (excluding Fragments) should be in an Active state. If you see your code bundle in an Installed state then there is an issue that needs to be resolved. Most times this is a dependency issue:

In the above screenshot the WKND Core bundle is an Installed state. This is because the bundle is expecting a different version of com.adobe.cq.wcm.core.components.models than is available on the AEM instance.

A useful tool that can be used is the Dependency Finder: http://localhost:4502/system/console/depfinder. Add the Java package name to inspect what version is available on the AEM instance:

Continuing with the above example, we can see that the version installed on the AEM instance is 12.2 vs 12.6 that the bundle was expecting. From there you can work backwards and see if the Maven dependencies on AEM match the Maven dependencies in the AEM project. In the above example Core Components v2.2.0 is installed on the AEM instance but the code bundle was built with a dependency on v2.2.2, hence the reason for the dependency issue.

Verify Sling Models Registration

AEM components should always be backed by a Sling Model to encapsulate any business logic and ensure that the HTL rendering script remains clean. If experiencing issues where the Sling Model cannot be found it may be helpful to check the Sling Models from the console: http://localhost:4502/system/console/status-slingmodels. This will tell you if your Sling Model has been registered and which resource type (the component path) it is tied to.

Shows the registration of a Sling Model, BylineImpl that is tied to a component resource type of wknd/components/content/byline.

CSS or JavaScript Issues

For most CSS and JavaScript issues, using the browser’s development tools is the most effective way to troubleshoot. To narrow down the issue when developing against an AEM author instance it is helpful to view the page “as Published”.

Open the Page Properties menu and click View as Published. This will open the page without the AEM editor and with a query parameter set to wcmmode=disabled. This will effectively disable the AEM authoring UI and make troubleshooting/debugging front-end issues much easier.

Another commonly encountered issue when developing front-end code is old or outdated CSS/JS is being loaded. As a first step, ensure that the browser history has been cleared and if necessary start an incognito browsers or fresh session.

Debugging Client Libraries

With different methods of categories and embeds to include multiple client libraries it can be cumbersome to troubleshoot. AEM exposes several tools to help with this. One of the most important tools is Rebuild Client Libraries which will force AEM to re-compile any LESS files and generate the CSS.

  • Dump Libs — Lists all of the client libraries registered in the AEM instance. <host>/libs/granite/ui/content/dumplibs.html
  • Test Output — allows a user to see the expected HTML output of clientlib includes based on category. <host>/libs/granite/ui/content/dumplibs.test.html
  • Libraries Dependencies validation — highlights any dependencies or embedded categories that cannot be found. <host>/libs/granite/ui/content/dumplibs.validate.html
  • Rebuild Client Libraries — allows a user to force AEM to rebuild all of the client libraries or invalidate the cache of client libraries. This tool is particularly effective when developing with LESS as this can force AEM to re-compile the generated CSS. In general it is more effective to Invalidate Caches and then perform a page refresh versus rebuilding all of the libraries. <host>/libs/granite/ui/content/dumplibs.rebuild.html

Example of getting AEM Remote Block With the Magento CMS Block:

class RemoteHeader extends \RemoteBlocks\Block\Html\AbstractBlock{protected $_remoteBlockHttp;/*** construct method to allow usage of the HTTP api model* @param \Magento\Framework\View\Element\Template\Context $context* @param \RemoteBlocks\Model\Api\Http $http* @return void*/public function __construct(\Magento\Framework\View\Element\Template\Context $context,\RemoteBlocks\Model\Api\Http $http) {$this->_remoteBlockHttp = $http;parent::__construct($context);}/*** Retrieve the remote block content for a given block and decode type* @return string*/public function getRemoteBlockContent() {$_remoteBlockContent = $this->_remoteBlockHttp->getRemoteBlockContent("remote_header","raw");return $_remoteBlockContent;}}

AEM Video Explanation :

--

--

Yegor Shytikov
Yegor Shytikov

Written by Yegor Shytikov

True Stories about Magento 2. Melting down metal server infrastructure into cloud solutions.

No responses yet