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

[nandhini]

Hi,

Is it possible to build a website in AEM, when the content is going to be authored in some other CMS?(lets assume methode or teamsite) considering the other CMS is going to create XML/JSON data of the content while publishing which should be accessible to AEM,

I would assume yes it should be possible as long as we have access to the JSON/XML, using a java application we should still be able to build a site in AEM for presentation. Please let me know otherwise.

But my main question is , is it it worth following this path? If yes, what are the pros and cons of doing it? (especially from an architecture or design perspective)

Thanks,

Nandhini

[VeenaVikraman]

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​

[nandhini]

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?

[smacdonald2008]

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.

[Giancarlo__Sapi]

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.

[VeenaVikraman · Accepted solution]

HI Nandhini

      If you are talking about one time migration, then doing the content migration as JSON or XML is okay. (But only if it is a one time activity).

    To say in simple words, AEM provides customers a platform to manage their content (in your case you say that will be residing in another CMS ) with additional features for like DAM, workflow, campaigns , MSM and a lot more. And more over such an approach will be a performance overload for AEM.

    For simple website management , AEM gives the flexibility of templates and components and full control on Authors to decide what to display where?

    I don't know how to put my thoughts into words but may be some read on may help you to find your answers your self

https://blog.3sharecorp.com/why-adobe-experience-manager-aem-for-your-web-content-management-system

https://www.cmswire.com/cms/web-cms/the-inside-scoop-on-adobe-experience-manager-adobesummit-028397....

[VeenaVikraman]

Totally Agree !!

[nandhini]

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.

[smacdonald2008]

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.

[Giancarlo__Sapi]

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!

[nandhini]

Thanks smacdonald2008 , Giancarlo (Sapient)., @Veena_07