Welcome to Tech Mastery, your expert source for insights into technology and digital strategy. Explore topics like Adobe Experience Manager, AWS, Azure, generative AI, and advanced marketing strategies. Delve into MACH architecture, Jamstack, modern software practices, DevOps, and SEO. Our blog is ideal for tech professionals and enthusiasts eager to stay ahead in digital innovations, from Content Management to Digital Asset Management and beyond.
Most of you might have already heard about AEM Edge Delivery Services.Edge Delivery Services (EDS) is a set of composable services designed to enhance the capabilities of Adobe Experience Manager, along with expanded content authoring functionalities.
EDS significantly improves website performance, shortens development processes, democratizes authoring at scale, and enables real-time experimentation to drive better engagement. When you hear EDS, the first assumption might be authoring content through known tools like SharePoint and Google Docs. However, EDS also supports authoring content in AEM through the Universal Editor. By using EDS blocks, similar to how you would author content in Google Docs or SharePoint, EDS renders AEM authored content directly to the website.
In this post, let’s explore some details on authoring EDS-supported content in AEM.
As you all know, Edge Delivery Services (EDS) supports authoring content through SharePoint documents and Google Docs, and EDS renders this content on the website in a way that achieves high Core Web Vitals (CWV) scores.
Additionally, content for EDS can be authored through AEM. While the traditional Page Editor and Core Component-based content can be used, this requires an external converter to transform the traditional HTML into EDS-supported markup so that the EDS front end can render the content.
Another option is using the Universal Editor along with EDS blocks to author the content. This approach uses EDS blocks directly in AEM through the Universal Editor, eliminating the need for an additional converter setup. While the traditional Page Editor/Core Component-based approach is not recommended, it can be used as a starting point for completely migrating to an EDS-based approach. Start by rebuilding the front end with EDS, and later adapt the Universal Editor along with EDS blocks to author the content within AEM.
Some existing projects may have complex components, so a step-by-step approach works well — the migration is not mandatory for existing websites. They can continue to work with the traditional approach, but you should decide based on your primary focus and benefits. However, new projects can start by adopting EDS with the Universal Editor.
Document based and AEM Content through Universal
AEM Edge Delivery Services with Existing AEM Projects
Creating and editing EDS-based content directly in AEM through the Universal Editor brings additional benefits. EDS leverages AEM’s JCR repository to store content, ensuring secure storage. The Universal Editor can utilize most of the existing AEM authoring capabilities, such as MSM (with some current restrictions, like only page-level inheritance being supported, not block-level), translation, launch, workflow, and publishing/scheduled publishing. No code changes to AEM are required, as the code changes are directly synced to Edge Delivery Services from GitHub, avoiding the need to install and maintain a local AEM instance for development.
Let’s quickly explore the details of authoring content in AEM through the Universal Editor and EDS blocks, and how to render that content on a website using the EDS front-end approach.
The authors create and edit pages using EDS blocks defined in the GitHub repository through the Universal Editor. The content is persisted in the JCR repository. Scripts, styles, and other resources are applied from the Edge Delivery Service deployment. The code from the GitHub repository is synced to Edge Delivery Services. Additionally, the Universal Editor pulls scripts, styles, and other resources from GitHub to render the authoring view. A Publish Event Handler subscribes to publication events and calls the AEM Admin API to retrieve the content, which is then persisted to Edge Delivery Services. Requests for content from users are served from Edge Delivery Services through a CDN
Currently, EDS content authoring through the Universal Editor is supported only for AEM as a Cloud. In the future, it may be supported by AMS. The Universal Editor can be set up in a local AEM SDK, but it will have some restrictions, such as limited access to AEM assets from the local AEM system. To start with EDS content authoring through AEM, ensure that you have access to an AEM as a Cloud Sandbox or a real AEM as a Cloud environment. Also, ensure that the Universal Editor is enabled for your AEM as a Cloud program. If it is not enabled, reach out to Adobe support. The Universal Editor allows you to directly author content using EDS blocks inside AEM. The content is persisted in the AEM JCR repository and shared with EDS for rendering.
EDS Boilerplate for AEM Content:
The https://github.com/adobe-rnd/aem-boilerplate-xwalk GitHub repository provides a boilerplate template for EDG projects with AEM content. Create a project using this template to obtain the basic configurations, blocks, scripts, and styles, which can then be customized as needed. Additionally, configure https://github.com/apps/aem-code-sync to the new repository. AEM Code Sync listens to changes in your code repository and publishes the code to EDS.
Configure the AEM Author server details in the fstab.yaml file. Replace the default URL with the URL of your AEM as a Cloud Service authoring instance: https://<aem-author>/bin/franklin.delivery/<owner>/<repository>/main.
Additionally, change the mapping of the content paths in the paths.json file. For example, map /content/test to /content/aem-boilerplate/:/.
The files component-models.json, component-definition.json, and component-filters.json are used to manage and configure components:
component-models.json: This file defines the data models for components. It specifies the structure and properties that each component can have, detailing how data is represented and handled within the component.
component-definition.json: This file contains the definitions of the components. It includes metadata such as the component’s name, type, and other configurations that determine how the component behaves and interacts with other components within AEM. Additionally, it enables the mapping between EDS components and AEM component resource types.
component-filters.json: This file is used to define filters for components. Filters are used to manage the visibility and availability of components based on certain criteria. This can include conditions under which a component should be displayed or hidden, or how components should be filtered when queried.
The AEM Command Line Interface (CLI) can be used to develop and test the websites on a local system.
AEM Site Template for EDS Sites:
The AEM Site for EDS Sites template helps create new AEM sites through the EDS site template. The new site content can be created and edited through the Universal Editor and Blocks. Access the latest AEM Authoring with Edge Delivery Services site template from GitHub at https://github.com/adobe-rnd/aem-boilerplate-xwalk/releases
Authors can now create, edit, publish/unpublish and test pages in AEM through the Universal Editor for EDS websites. Styles, scripts, and other resources are managed in a GitHub repository, while the content is directly managed and persisted in AEM. The Universal Editor pulls scripts, styles, and other resources from GitHub for authoring. EDS syncs the code from the GitHub repository for the live website and fetches the content from the AEM JCR repository.
EDS blocks and Content mapped to franklin core components
The Franklin core components help map the EDS blocks and content to AEM. They also assist in instrumenting the pages and components for Universal Editor authoring.
Apart from content pages (e.g., index) and fragments (e.g., header and footer), different page types can be created, such as placeholders, spreadsheets, metadata, configurations, headers, and redirects.
The EDS website can be accessed through https://main--<repository-name>--<owner>.hlx.page or https://<branch>--<repo>--<owner>.hlx.live/. Custom website domains can also be mapped. Like the EDS documentation, there are no separate preview and live URLs; both display the same published content from AEM. The preview and approval to live should be part of the AEM Content Authoring workflow. The repository is mounted to a single AEM Author instance. The published EDS content on this instance is displayed on the live site, but you can adjust this by creating environment-specific branches and pointing those branches to the appropriate AEM Author instances.
Conclusion:
In summary, leveraging AEM Edge Delivery Services (EDS) for AEM authored content brings numerous benefits to your content management and delivery workflow. By utilizing the Universal Editor, authors can efficiently create and edit content directly within AEM, making use of advanced features like MSM, translation, workflow, and scheduled publishing. The integration with GitHub allows for seamless synchronization of scripts, styles, and other resources, ensuring a smooth authoring experience and consistent content delivery.
The EDS boilerplate and the configuration of key files such as fstab.yaml, paths.json, component-models.json, component-definition.json, and component-filters.json streamline the process of setting up and managing components. This setup not only enhances the flexibility and scalability of your AEM projects but also reduces the need for local AEM instances, simplifying development and deployment processes.
By adopting AEM Edge Delivery Services, organizations can ensure secure, efficient, and scalable content delivery, making it a powerful solution for modern content management needs.
No comments:
Post a Comment