Building a website in AEM when the content is going to be authored in some other CMS?

HI Nandhini

    Technically it can be , but it is really not the best approach. You are just letting go of the main purpose of AEM. When you have AEM, why do you need another CMS and why you need to pull the content and display it. You will be making your life difficult by this approach. I would recommend you some expert advice here

smacdonald2008​ Jörg Hoh​ Giancarlo (Sapient)​ Sham HC​ kautuksahni​ Feike Visser​ Ratna Kumar​

Yes. Thanks @Veena_07, i understood that, but if we have to provide justification why this not a best approach and what most important feature we would miss out by this approach.

( like we will not able to use taxonomy features that AEM provides, asset/dam / metadata capabilities. dispatcher capabilities)

1) especially pros and cons? If at all there is , is there any pros of doing it?

2) By this approach will we be able to use any of the feature provided by AEM itself?

That is a very bad practice - best practice is to use AEM to author the content and develop the components, templates, etc within AEM to drive your web site development.

Hi Nandhini

As Veena mentioned, building the site in AEM and authoring content in another CMS makes your life very difficult. In fact, since AEM is managing content itself via page creation and populating content, I would even go so far to say it's an "unfortunate approach".

Your question implies you might be thinking of more like "consuming" content created with another CMS?

If this is the case, then yes, it's possible. However, you may want to consider that using AEM just for the presentation layer and using another CMS to manage the content is not only very cumbersome to build/manage, but also quite a waste of the AEM capabilities (and hence costly too).

If you can share your plan or what you have in mind, I can give you better answers. I can sketch a few solutions showing the out-of-the-box Sling servlets together with a REST architecture.

Maybe a side note: Your question seems to be tangent to the commonly seen "Headless CMS" concepts. You may want to know that with AEM not the CMS per se is "headless", but the content. By managing content with an API you can use out-of-the-box JCR services to distribute the same content to multiple channels and sources.

Totally Agree !!

Thanks smacdonald2008​ and Giancarlo (Sapient)​.

Just summarizing,

1) Even though its a bad practice , it is technically feasible using AEM?

2)But by going down this path(that is using AEM just as a presentation layer ),

we wont be able to use any of the AEM capabilities.

Please correct me if i am wrong.

This is very bad practice and i would encourage you to rethink this approach as you will not be able to take advantage of AEM capabilities.

Much better to build AEM content under /apps and build your components, templates and so on and port the content and make it AEM content.

Let me clarify as a more "neutral" person:

1) Don't go there! If you don't have AEM, don't acquire just to do some presentation layer stuff. If you have AEM, do a migration from the other CMS to AEM. The reason is more about the content authors. AEM is "content centric" meaning that authors deal only with the browser to manage content. No database, no integration, no micro-servces, etc.

2) Note that CRX is a content API. This has tons of advantages. Authors can add content directly on a Web page and it stores it to the hierarchically organized content model. The API comes with all sorts of services, like observation service, full-text search, versioning and a lot more. By providing content to AEM via REST API you cannot use all these content services.

3) There are other advantages of using AEM: Digital Asset Management, Analytics, scripting languages, and a lot more. AEM is great for developers, but even more valuable for authors!

Thanks smacdonald2008 , Giancarlo (Sapient)., @Veena_07