Apr 25, 2024
One of the biggest advantages of integrating Adobe Experience Manager (AEM) with Adobe Target is the ability to reuse existing content as Experience Fragments (XF). Although this may seem straightforward, the steps that are scattered across various sections of the Adobe documentation. In this blog, we’ve compiled the steps to help developers take full advantage of this feature.
Note: This isn’t a deeply technical blog but instead highlights the steps to get XF exporting working properly. At the end of the article we’ve provided additional resources if you wish to dive deeper.
-
Create an Adobe Target Legacy Configuration. ALegacy Cloud Configuration for Adobe Target is required regardless of whether you connect through the Adobe Developer Console (Adobe I/O) to export Experience Fragments.
-
Configure which folder(s) from your DAM will support XF exporting to Target. After configuring the Legacy Cloud Config, you will be presented with the option to bind this configuration to an asset folder through its properties. The configuration will propagate downwards through the folder’s tree and can be overwritten at any point in the tree if another config overlaps.
-
Configure the Externalizer Service. This is already set for you if you are using AEM as a Cloud Service.. Otherwise, make sure you have correctly configured the author and publish domains. Plenty of information is available on how to set this up, so I won't delve deeply into this point again.
-
Implement the Link Rewriter Provider Interface. If you plan to export your Experience Fragments (XFs) as HTML offers to Adobe Target, you should know that all links (including images) will be relative URLs.
-
Choose the Correct Workspace. Lastly, make sure to set the correct Adobe Target Workspace with your AEM instance. By default, all the XF will be published into the “default” Adobe Target workspace. This configuration is part of the Adobe Target Configurations from the Cloud Services menu.
This is a problem because relative links are resolved based on the current URL’s path. When you navigate to a different domain, the path structure might be different, leading to broken links or incorrect resource paths.
For example, if you have a relative link like <img src="/content/dam/picture.jpg"> and you're currently on www.example.com, it would correctly load the image from www.example.com/content/dam/picture.jpg. However, if you use the same relative link on a page from a different domain, say www.anotherdomain.com, the browser will try to load the image from www.anotherdomain.com/content/dam/picture.jpg, which might not exist or might not be the intended location.
As you can imagine, this scenario is possible when using offers in Adobe Target. To solve this issue, we should implement Absolute URLs when linking resources on different domains. Adobe has provided the ExperienceFragmentLinkRewriterProvider to "transform" the links before rendering them on the page.
Adobe Target will invoke the HTML offer appending the selector nocloudconfigs. This would be our flag to trigger the transformer and adjust whatever our links need to render properly. In the case of the above example, we would have to transform the links to include the full path to the image like so: <img src="https://www.example.com/content/dam/picture.jpg">
Wrapping Up
There are several common issues that arise while exporting Experience Fragments to Target. However, by following our tips you can avoid any issues.
Useful Links
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.