Expand my Community achievements bar.

SOLVED

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

Avatar

Level 2

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

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

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

View solution in original post

12 Replies

Avatar

Level 10

Getting internal ppl's thoughts on this question.  Did you look here (i assume you have) -- AEM Portals and Portlets

Avatar

Level 10

Hi Jeff,

Each of the platforms will have its own architecture and Adobe AEM is not built on portlets model as primary like Liferay or WebSphere portals.

All these portals come with the capabilities of portlets as primary and have the CMS capabilities to it while AEM has CMS as the primary capabilities but can support the architecture of portlets. The link provided by @Scott talks about the same. Not sure if there are many implementations of that as a case study. https://helpx.adobe.com/experience-manager/6-3/sites/administering/using/aem-as-portal.html

Avatar

Level 2

Thank you for the link.   I see that AEM *can* run portlets but that is not a primary function of the overall ecosystem.

It seems like AEM has a rich and graphical web environment which will allow my team to deliver CMS-related web sites very quickly.  The team is developing a horizontal portal for franchises, and it will be used by back-office staff.  One of the key requirements is that the users be able to customize their landing pages.  With something like Liferay, we can have a region of the screen where users can specify "portlets"  to run there from a portlet pallet.   But Adobe does other things we would like to do like PDFs, digital signatures, and so on.  

So I'm curious about the amount of custom coding would be required to implement this concept and/or live tiles.   None of these portlets have actually been written yet, so the approach is flexible.   FWIW we have a lot of .NET code around here and hopefully the resulting solution would allow us to harvest that code somehow rather than ground-up rewrites.

Avatar

Level 10

If your code is .NET and you want to get that logic into AEM, this will require a re-write to get that logic into the AEM OSGi service container. AEM cannot run .NET libs as its a Java platform.

Also - its true that Adobe stack can do tasks like PDF generation, etc. This is a module that works with AEM named Document Services - here is a webinar about Document Services so you better understand them --

ATACE 6_21_16 AEM Forms dive into Document Services

Avatar

Level 2

Please allow me to clarify the question; the responses so far have been valuable and I appreciate the collaboration.

I have a requirement for end-user customization -- the end user must be able to select content feeds from a content store and determine where they will display on the screen.  With something like Liferay, I can put together each content item as a portlet and then users would be able to drag the portlets from a pallet into pre-defined locations on the screen and re-arrange them at will.

How would you approach something like this with AEM/CQ?   Standard Java portlets aren't an absolute requirement, but the concept of user-selected content from a widget store is a requirement.  Some of the widgets are little inquiry applications, it's not all about static content.

I guess one way to do this would be to develop my own display layer, and then it would read through a list of user selections and format the content accordingly; I think implementing drag and drop would need tricky custom code.  However, it seems to me that this is foundational code that should be built into the platform.   If AEM can implement this cleanly then it has a decent chance of being used for this project.   It's not a small project -- maybe 100,000 users.

Please share your ideas.

Jeff

Avatar

Employee Advisor

You are building a portal with a strong focus on personalization of the login page. I think you can do that. But in my opinion that is not a usecase where AEM is especially strong at. Your usecase rather looks like a standard case for a (traditional) portal software.

I would hesitate to implement this in AEM only.

Jörg

Avatar

Level 2

Thank you, Jörg.  I agree that personalization can be achieved with AEM using rules and code.  I am wondering about something slightly different, the idea of an internal portlet pallet or "widget store" that the users can access to customize their own experience.  This is exactly what Liferay does, but Adobe has lots of other interesting features so I was wondering what an expert in AEM would think about the complexities of implementing that type of drag and drop portlet approach. Even if they are not actual portlets, but the UX makes it seem to the user like an app store.  There would a max of 40 widgets, and we would start with just 10.

Avatar

Level 10

Though it's not AEM's strength, I think we can use some of the UI frameworks which enables the drag and drop features to create a template in AEM. Now list all the widgets(AEM Components) which users can organize within the layout.

Avatar

Level 2

Oh, that is getting close to what we are after - with the end user doing customization, the drag and drop all by themselves, and each user may do it differently, up to a few hundred thousand users.   Most users, won't change a thing.

So do these components have that level of dynamic placement?  This is very interesting and I hope someone can point me to an example or some documentation showing where this was actually done.  I wan't to stay solidly in supported, mainstream, capabilities of AEM/CQ.

Avatar

Employee Advisor

The UI part is the part I would worry about the least.

In your usecase my questions are:

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

* How would you do authentication?

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

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

Jörg

Avatar

Level 2

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.

Avatar

Correct answer by
Employee Advisor

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