How to Use AEM as a Headless CMS to Support Content-as-a-Service

A headless CMS, i.e., a backend-only content management system allows you to manage and re-use digital content from a single repository and publish it on different applications. The absence of a headless architecture can lead to several challenges, including siloed development, slower time-to-market, heavy IT dependency, difficulty in optimization, and more.

An integrated model like a headless CMS with a central Web Services layer can overcome such challenges. Using this approach with Adobe Experience Manager - AEM CaaS and Web Services layer acting as a back-end for business applications, it’s easier to create, manage, test, and deliver experiences across the customer journey. This approach majorly leverages AEM Content Fragments that allow users to create channel-neutral content with variations. They are designed and managed as page-independent assets.

Read why multi-brand companies choose AEM as their content management system here.

In today’s competitive world, organizations need to adopt an integrated model for their businesses to leverage best-in-class software systems. The need to act swiftly to market changes and to provide a unified, engaging experience to its customers across various channels like web, mobile, business Apps, email, etc. have propelled the companies to look towards a distributed architecture to meet their needs.

For any sizable organization, a software infrastructure supporting their businesses on digital platforms can be categorized as follows:

Data Tier: This is the central hub where data or content resides. Usually, companies require a centralized data tier to manage content efficiently and avoid duplication. A central data tier also makes it easier to enforce organization-wide content governance besides helping to ensure that the content is uniform and reflects a true sense of oneness for the company’s overall brand image when used in different applications.

Web Services Tier: The web services are essential for an organization to encapsulate the business logic, which is integral to the core business model of the company. There is a need to maintain a central Web Services layer that is agnostic of the underlying data/CMS layer.

Application Tier: This tier has the company’s business applications that are used by its customers and drives the company’s revenue. Typically, this tier depends on the Web Services tier, which exposes the data/content from the Data tier.

This blog explains how we can implement an integrated solution featuring the best software products in each tier, leading to a more optimized IT infrastructure and translating into more revenues for companies. In this use case, we will use Adobe Experience Manager (AEM 6.3 or above) for the Data tier. However, we are going to use AEM as a headless CMS, leveraging its CaaS feature. For the Web Services tier, we will use a custom Spring application built outside AEM. Finally, for the Application tier, let’s assume that the company has several business applications built on different technologies like React, AngularJS, Spring, .NET, etc.

Business Challenges in Using Multiple Systems with Disparate Content Repository and Structure

When an organization uses multiple disparate systems, they encounter some challenges as mentioned below:

Long Release Cycles

The business applications are slow to react to current happenings in the world as they pass through a long IT release cycle. It is almost impossible for the applications to incorporate the content changes corresponding to the real-time happenings in the world, and as a result, it takes longer to publish information about new products, offers, time-sensitive messages, etc. which leads to an increased time to market.

Migrating these applications over to the AEM platform is painstaking, mainly because these applications are transactional and require a swift/agile publishing of changes only for the content part. While the business logic seldom changes, the content in the form of messages, labels, disclaimers/disclosures, etc. needs to be changed and published swiftly, necessitating the use of AEM as a headless CMS.

Duplication of Content

It is usual to find some overlap of content consumption across business applications. Content curated once could be used in several business applications. To avoid duplication of content and to allow for efficient content governance, a company needs to have a central place from where content can be created and published to multiple business applications across various channels.

Brand Inconsistencies

Business applications are often developed in silos and do not have a standard content structure and theme, which reflects poorly on the company's branding. This calls for a centralized platform to publish information about the company’s products, offers, messages, etc., and to create consistent branding across its business applications and customer touchpoints.    

Poorly Connected Software Systems

Lack of a single, consolidated Web Services layer makes it difficult to regulate connectivity between the application and data tiers. The absence of systematic integration between these software systems hinders the ability to provide a dynamic, cognitive, and seamless experience to the customers.

The Solution – AEM as Headless CMS (Content Tier) + Spring Application (Web Tier) + Open Technologies (Application Tier)

The integrated solution comprises the best-of-breed CMS, AEM, acting as the central hub for all content creation and management. Content created is exposed as JSON response through the CaaS feature in AEM to the Web Services layer. The Web Services layer is built on Spring Boot outside the AEM platform to ensure content/data messaging can be processed, business logic can be implemented, and the response can be cached. The separation of this layer from AEM also ensure a long-term stable Web Services layer, agnostic of changes in the underlying CMS.

This pluggable architecture makes it possible for the Web Services layer to continue relaying services seamlessly to several business applications, even if the underlying CMS is replaced with a different one. The Web Services layer uses Amazon S3 to serialize the cached response. In the event of a crash, the cache stored in the JVM/memory gets wiped out. In such cases, the cache can be reinstated by deserializing from Amazon S3.

Alternatively, we can use packaged caching software like Redis. Redis provides Java APIs called Jedis to manipulate its cache, which is similar to Amazon S3 APIs. The Web Services layer is fronted with Apigee and uses OAuth2 protocol for the security of the Web Services APIs. The business applications pull the content via Apigee. The architecture diagram below shows the process flow.

Request Flow

1. A business application loads on a customer’s device and, in the process, makes a call to Apigee URL with a token (the token is provided to the application when it makes the first call to Apigee with credentials).
2. Apigee checks the token (for invalid tokens, it returns 403 Forbidden). For valid tokens, it passes the request to the Web Services layer.
3. The Web Services layer looks up for the response in its cache (Amazon/Redis) based on the request parameters concatenated as the cache key.
4. If found, the response is returned from this layer (typically, 95% of the requests get returned from the cache).
5. If not found in the cache, the Web Services layer dispatches the request to AEM, receives the response from AEM, messages the data, applies business logic, caches the response (using the parameters concatenated as key) and returns the response.

Also, when new content is created or when existing content is modified in AEM and published, it makes a call to an endpoint in the Web Services layer, signaling it to clear the cache corresponding to the item published. This ensures that stale content is not shown on business applications.

Steps to Configure the Systems Involved for this Model

Below is a detailed explanation of how to configure different systems in the suggested solution.

Adobe Experience Manager

1. Create the Content Fragment Models, using which the business content team can create content fragments representing the textual data as well as digital assets like images, videos, documents, and more.
2. Enable CaaS in AEM, and use the Models and Entities to aggregate content as service. Alternatively, develop custom servlets by leveraging the CaaS feature in AEM to allow exposing the content as JSON response.
3. If using custom servlets, develop the supporting structure using the components and templates in AEM.
4. Leverage the language copy feature for multi-lingual content (if applicable) and variations for channel-based content (separate variations could be created for the fragments for Mobile, Web, Kiosk, Email, etc.)
5. Develop a workflow to automate and streamline the business approval process along with email notification for Authors, Approvers and Publishers.
6. Integrate the AEM replication with the Web Services layer to ensure real-time content changes are reflected despite the caching at the Web Services layer.
7. Set up AEM Author, AEM Publish, Dispatcher, and Web Server stack for AEM.

Web Services Layer

1. Develop the Spring Boot application and configure deployments into a hosting platform such as Pivotal Cloud Foundry (PCF) or server containers.
2. Build custom business logic and data messaging (e.g., date format conversion, designating the fetched content as active/inactive based on time of day, etc.) into the services.
3. Set up multi-node architecture on PCF/container for the Spring Boot application. This is elastic and adds additional server nodes based on traffic in real time, handling the load efficiently.
4. Implement caching for the generated response and integrate the Web Services layer with Amazon S3 (or Redis) for serializing the cache.
5. Integrate the Web Services layer with Apigee for OAuth2.0 based security for the APIs.

Business Applications

1. Develop the business application in React or AngularJS to show offers, messages, labels, disclosures, and other content to customers by making API calls to the Web Service layer to fetch the content from AEM.
2. Integrate business applications and Apigee (with Authorization and Refresh tokens). Apigee acts as a proxy directing request to the Web Services layer if the token is valid.

Read how a US-based brokerage firm enhanced user experience by switching to AEM here.

Business Benefits of Using AEM as a Headless CMS with the CaaS Model

Utilizing the above-prescribed robust, integrated software solution, a company can improve its business operations dramatically. Here are some benefits of implementing this model:

Shorter Release Cycles Leads to a Faster Time-to-Market

The use of AEM platform allows for a very swift content creation-to-publishing pipeline, reducing the time-to-market to mere hours from days or weeks. The efficient content governance model, streamlined deployments, automated workflows, and publishing allows for quick launches of new products and helps the company to stay ahead in the competition.

Central Repository of Content for Consistent Branding

With features like CaaS, content fragment variation for channels and language copy for multiple languages is possible, with which a company can quickly expand business across geographies and channels. The dedicated caching mechanism results in impressive page load speed for the company’s business applications.

Standardize Content Structure for Making Quick Changes

Using CaaS features like content fragments, the existing business applications can continue to use their respective technologies like React, AngularJS, etc. and yet become smart and agile when it comes to pushing content changes rapidly. The dedicated Web Services layer ensure a long-standing, central layer to provision content as service seamlessly even if the company decides to switch to a different CMS later.

Final Words…

Implementing an integrated solution with AEM CaaS and Web Services can do wonders in revenue generation of business. The ease of using the AEM content management system to author information together with a swift publishing mechanism leads to a decreased time to market of new products.

Further, provisioning the content via web services eliminates the time and effort otherwise spent on migrating business applications on to the AEM platform. It means that the company gets full benefits of using AEM for content management without the high cost involved in migrating business applications.

Plus, by configuring several applications to consume data from the central AEM repository via a single entry-point in the form of the Web Services layer, the company can project a more unified brand image across all its business applications.