ÃÛ¶¹ÊÓƵ

Transcript

AEM as a cloud service eventing allows customers to build integrated and efficient content ecosystems that are loosely coupled, independently scalable and flexible. So let’s first understand what AEM eventing is. Simply put, AEM eventing operates on a published subscribe model. AEM produces events, and other systems consumes these events based on their subscription criteria. An event signifies a content state change in AEM, such as create, publish or unpublishing of a page. Normally, a Biddleware or Event Bus separates publishers and subscribers. In this case, ÃÛ¶¹ÊÓƵ IO Events serves to separate AEM and external systems for communication security and interoperability purposes. Please note that ÃÛ¶¹ÊÓƵ IO Events is a developer platform for integrating your applications with ÃÛ¶¹ÊÓƵ services and solutions. Next, let’s understand how AEM eventing is different. Apache Sling, OSGI and JCR all offer a PubSub model, and most of you are familiar with it. The key difference is, event consumer code is executed outside of AEM, and to communicate back to AEM, this code uses AEM as a cloud service API. Out of the box AEM code is responsible for defining and sending these events to ÃÛ¶¹ÊÓƵ IO Events. And many more. So, an obvious question is when to use it. As you guessed, loosely coupled systems that scales independently and provide flexibility are on everyone’s mind, thus resulting in event-driven architecture comprised of microservices and serverless code. Here are key advantages. Reduce custom code in AEM. Simplify and standardize communication between AEM and external systems, such as your application or third-party software. Durability and parallel processing of events. Now let’s understand the how part. AEM eventing is enabled per AEM as a cloud service environment. In the ÃÛ¶¹ÊÓƵ Admin console, ensure that you are assigned to the correct product profile for your desired AEM as a cloud service environment. To subscribe to AEM events, you need access to the ÃÛ¶¹ÊÓƵ Developer Console to create a project. Then, add event service. In the Add Events dialog, filter by experience cloud and select AEM Sites. On the next event registration step, select your AEM instance. Then from the list of available events, select the event you are interested in. Please note, over time, the list of available event types will grow. Or, reach out to the AEM eventing team to request an event type. Next, select the authentication type and give a meaningful name to this event registration, like a combination of AEM program, environment, and event name. Now, for how to receive events, push and pull are the primary methods. While all these options involve push methods, journaling operates as a pull method. Let’s use a hosted webhook for testing purposes. This webhook is publicly available for testing purposes. Feel free to use it. The webhook endpoint URL is shown here and also documented in the tutorial example. This completes the how to enable, subscribe, and consume part. Finally, when I change content in my AEM as a cloud service environment, the public webhook is notified with the AEM event details. The event details contain the source, event time, type, and data. Using this information, the external system can perform additional tasks to build an efficient content ecosystem. So, using AEM eventing alongside various content-related activities allows us to create powerful ecosystems. The AEM event’s consumer can be a downstream or upstream system that needs to know about the content state change. For example, a product information management or PIM, CRM, external search, knowledge base, customer service, or even a custom application. In summary, AEM eventing is crucial for building loosely coupled, scalable, and flexible applications, ensuring success in achieving your business goal and expanding your content reach. Thank you and let’s build.