AEM Search Solution

Hi, Philip.

Are you aware of the thread Implementing site search?

Regards,

Daniel.

Hi Daniel,

Been through all that Solr <-> AEM integration. But like I explained, search has to go through Publisher, which causes bottleneck and is not scalable solution.

An ideal search solution would be that there is a standalone search server that hooks into AEM Publisher, indexes all it needs to, at the meta data level (nodes) (just like how Lucene does with AEM), and then be able to hit it externally via API.

This way, we can simply use AJAX to grab search results by hitting this external standalone search server. AEM/Solr integration OOTB does not provide this.

Thanks!
Philip

Search and Promote is an option worth spending your time on. Do check.

Hi, Philip.

Sorry, but I couldn't follow you...

As far as I've understood, the recommend solution is to use a 3rd party service/platform to index AEM content. This way your website (I mean its client side) would hit that service/platform to search for a specific content instead of hitting the publish instance .

Or do you have a hard requirement that demands accessing the search service through the publish instance?

Regards,

Daniel.

PhilipBae wrote...

Hi Daniel,

Been through all that Solr <-> AEM integration. But like I explained, search has to go through Publisher, which causes bottleneck and is not scalable solution.

An ideal search solution would be that there is a standalone search server that hooks into AEM Publisher, indexes all it needs to, at the meta data level (nodes) (just like how Lucene does with AEM), and then be able to hit it externally via API.

This way, we can simply use AJAX to grab search results by hitting this external standalone search server. AEM/Solr integration OOTB does not provide this.

Thanks!
Philip

 

Hi, didn't that product become Adobe Target? From what I know, Target does not serve up search results but targeting content doing A/B testing.

Lmk!
Philip

Hi Daniel,

I think we are on the same page. That is exactly what I meant. My requirement is to stay off of Publish instance because it becomes a performance bottleneck and was hoping if anyone knew a good enterprise-level search engine that already has good integration built that we can purchase.

There are a few search solutions out there like: Apache Solr (free), Oracle Endeca, Microsoft FAST, Google Search Appliances, to name a few, but they do not have any prebuilt integration with AEM.

Lmk! Thanks so much!
Philip

Yes. I believe we are on the same page :-)

Here, for example, we've developed a custom solution using Amazon CloudSearch:

• some preprocessors index the page content (I think this could be done in a Replication Agent instead);
• the page templates and components include a custom client library;
• this client library makes AJAX calls to the CloudSearch endpoint;
• some portions of the page/component are re-rendered based on that results (we use an Angular-like framework to do it).

Regards,

Daniel.

@PhilipBae, I'll second @karthickky2k4's recommendation to look at Adobe Search and Promote (SnP). We're using it on two sites. I'm not sure what you mean by "search has to go through Publisher", but in our case load on the Publish servers is low and controllable, because it's only hit when indexing content, not when conducting the search or presenting results.

We're using SnP to search our product catalog, not (yet) for full-text search of AEM pages. Catalog inventory can change throughout the day. An SnP crawler comes along every half hour and queries the JCR for nodes that have changed since the last crawl, and updates the SnP index. We also do a full re-index every night.

To search, we present a form to get the search terms, then issue an AJAX call from the page to SnP, which in our case returns JSON data that the front-end consumes and formats for presentation. So, our solution is heavy on the JavaScript side, but not on the Publish server.

SnP is not without problems (but what is?): documentation is very sparse, it's a cloud-hosted solution with limitations on testing environments, no ability to export settings from one environment and import into another, and some limitation on how you can search -- e.g. from what I understand, it's not possible to have multiple conditions on the same "column" like "SquareFootage > 1000 AND SquareFootage < 5000". We get around this by creating extra fields and mapping the same value to them: SquareFootage -> SFMin and SFMax , and the query becomes "SFMin > 10000 AND SFMax < 5000". In other instances we do only very simple filtering in the SnP query, and further filter the results on the page in JavaScript.

The benefits are that it doesn't impose a lot of load on the Publisher (again, depending on what you mean by "a lot of load"), and is supported by Adobe, which may outweigh the limitations.

I agree! Thanks for the feedback!!

Philip