Portlet store -- how is this done in AEM? (so it works like Liferay, WebCenter, etc.) | Community
Skip to main content
J
Jeff_Stieglitz
Level 2
January 9, 2018
Solved

Portlet store -- how is this done in AEM? (so it works like Liferay, WebCenter, etc.)

  • January 9, 2018
  • 12 replies
  • 4407 views

Folks, I am evaluating Adobe Experience Manager and I'm impressed by the power and and user interface of the overall solution.

A primary requirement of my project is allowing B2B end-users to customize what they see on their landing page.  With traditional portal products like Liferay, Oracle WebCenter, and IBM Websphere portal, a user can access a slide-out "store" of portlets, and then add them to their landing page, and then to a certain extent can re-arrange tiles or regions on their landing page.

I see that AEM can run portlets, but I wonder if I would have to code the end-user portlet selection capability on my own.    Please share your advice and links to examples; I've looked through the documentation but did not see anything which addresses this.

The portlets would be free and the list would be filtered by the end-user's role.

Jeff

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

The frontend part (the drag&drop if widgets) is something a good UX team can implement pretty fast, that's the least of my concerns :-)

But for me it looks like you are not that familiar with AEM, so I will go more into details.

* The general AEM architecture splits between the authoring and publish (public, internet-facing) part. I assume that these 100k users are working on the publish system (they are rather consuming than creating content).

* The standard, default and recommended architecture for AEM publish is the farming approach. That means, that you have a number of independent publish instances in a shared nothing approach. Every AEM publish instance is self-containing and hosts a full copy of all content.

* This also means that any change which happens solely on one publish instance (someone changes its profile) must be synchronized to all other publish instances.

With Sling Distribution there is a mechanism available which is designed for that usecase, it is hardly used (it's part of AEM Communities). I still would not call it "mainstream". But you could have a look at AEM Communities if it caters your needs.

Serverside personalization is a hard topic, as every AEM architect will tell you to personalize as much as possible on client side, because it scales much better. And use the dispatcher to cache as much HTML as possible (at best: 100%).

Jörg

12 replies

Show previous replies
J
Jeff_StieglitzAuthor
Level 2
January 16, 2018

That's what I'm starting to think, especially as the team is not accustomed to this type of user interface development; they are business systems developers.  But I really, really appreciate the ongoing conversation and your willingness to share your thoughts.

Adding some details based on your questions:

* Where do you store the preferences for the users (or the layout of these widgets)? On the server? In a cookie?

My initial thought is server-side, as that is the model used by similar portal products which implement this type of solution, i.e. Liferay.  But Liferay does not have the rich ecosystem of AEM, which is why I am exploring this topic.

* How would you do authentication?

Oh, I didn't give that a second thought, thinking that authentication and role management is offered by the AEM out-of-the-box as it is with other portals.  In this project everyone needs to log in, there are no anonymous users, so it would seem to make sense to store the personalization settings by userid.  I glanced at https://helpx.adobe.com/experience-manager/using/secure_sites.html and it seems like the secure sites feature would be adequate.

* What kind of content would AEM deliver? Personalized on server-side? Client-side? Requesting data from 3rd parties? Or just static content snippets?

Personalized on server side.  Some of the content would be dynamic from back-end systems -- such as an inventory level.  Some of the content would be static coming out of the AEM content manager, where business users would update marketing test.  Hoping that piece seems feasible.

* I don't think that this is a mainstream usecase for AEM.

Just trying to make sure.

joerghoh
Adobe Employee
joerghohAdobe EmployeeAccepted solution
Adobe Employee
January 17, 2018

The frontend part (the drag&drop if widgets) is something a good UX team can implement pretty fast, that's the least of my concerns :-)

But for me it looks like you are not that familiar with AEM, so I will go more into details.

* The general AEM architecture splits between the authoring and publish (public, internet-facing) part. I assume that these 100k users are working on the publish system (they are rather consuming than creating content).

* The standard, default and recommended architecture for AEM publish is the farming approach. That means, that you have a number of independent publish instances in a shared nothing approach. Every AEM publish instance is self-containing and hosts a full copy of all content.

* This also means that any change which happens solely on one publish instance (someone changes its profile) must be synchronized to all other publish instances.

With Sling Distribution there is a mechanism available which is designed for that usecase, it is hardly used (it's part of AEM Communities). I still would not call it "mainstream". But you could have a look at AEM Communities if it caters your needs.

Serverside personalization is a hard topic, as every AEM architect will tell you to personalize as much as possible on client side, because it scales much better. And use the dispatcher to cache as much HTML as possible (at best: 100%).

Jörg

Terms & ConditionsAccessibility statement

Loading footer...