Ask Questions and Find Answers

Hey Mohammed, Just a small correction. You don't need to implement the OpenSearch interface to make your entity searchable with the Liferay search -- all you have to do is make sure that your search configuration includes the model for your custom entity.  If you have implemented the indexer, then they will be found, and if you have implemented the Asset Renderer, then they will be rendered as part of the out of the box functionality. Open Search is for something else altogether. Implementing this interface allows you to use a global search bar (read: browser) and set the scope of the search to the current site -- so you search the "Liferay site" but using your browser in place of the search portlet. Normally you have to actually make configuration changes to your browser to enable this behaviour. Outside of this correction, I would agree with everything else you've said here -- custom indexer, custom renderer and I would also add several methods to my service definition (MyCustomEntityLocalServiceImpl) that you can use to invoke searches.

Check  whether your asset renderer is getting called by adding log in your gettitle() or getjsppath ()  or any exception your getting  while rendering your custom asset

Also check have u added Field.CLASS_NAME_ID,and Field.CLASS_NAME_ID to your  document.add();

You can refer Journal Indexer and see are you missing soemthing​​​​​​​
​​​​​​​https://github.com/liferay/liferay-portal/blob/7.1.x/modules/apps/journal/journal-service/src/main/java/com/liferay/journal/internal/search/JournalArticleIndexer.java

Let's shed a little light for you on CLASS_NAME and CLASS_NAME_ID and CLASS_PK. This is an important pattern in Liferay to understand as you work with the product because it is used extensively, and once you get a handle on it, it allows you to start wiring in a lot of the out of the box features into your custom features. 

First things first, since you have a service builder project and you have generated some custom entities, go to your database and do a SELECT * on the ClassName_ table.

You'll find many familiar references in here, along with the custom stuff that you have added. So basically, when you use Service Builder to generate your entity and deploy your module, one of the many things that happens is you get an entry in this table. So what is it used for?

Truthfully, I have always struggled to explain this -- I understand it, just finding the right words seems to be a challenge. The best way I have come up with to date is that the ClassName, ClassNameId and ClassPK are ways to "genericize" references. The AssetEntry is a great example, but there are many more -- Ratings, Subscriptions, etc. The challenge is, how do you data model something like a Rating (which is generic) but then associate it to something specific, like a Message Board Post vs. a Blog Post. Well, in Liferay, we do this with the ClassName, ClassNameId, ClassPK stuff.I'm just going to make numbers up here to illustrate the point. Let's say in your ClassName_ table you have the following.

Class Name                                              Class Name Id

com.liferay...JournalArticle                                 21005

com.liferay...BlogEntry                                      22004

com.abc...Player                                             24500

Where the first two rows are of course out of the box entries, and the last one is a reference to your custom entity. Let's assume that you have a Player table with the following --

Player ID      Name                  Position      Age       Retired

21345          John Snow                CF          22        False

98432          Chris Jade               RD          20        False

Now, if you use the Liferay pattern then that means you can identify John Snow, as

className=com.abc...Player
classNameId=24500classPK=21345

... so in your code you can identify the model and the specific data record by combining the class name and the PK from the player table. So, if you wrote a portlet that rendered player details for example, and then you added the option to be able to "rate a player" you don't have to write all that plumbing to manage ratings yourself. You can use Liferay's Ratings API and services to record ratings for Player, John Snow, in the Ratings tables and then you can use the Ratings taglibs to render them in your portlet. AND! like I mentioned above, this pattern can repeat itself for other features like comments, subscriptions, asset entries etc.  So it's a way to genericize meta data about your entity but store it in a central table so that you don't end up with a Ratings_Blogs table and a Ratings_Journal_Article table and a Ratings_Player table etc. 
Make sense?

Hi Dorian,

I speak French, so you could try to explain it in French if you think that will help. I will warn you though that I don't get to use my French very much these days so my replies might be a little bit like your English. Maybe you can write to me in French and I can write to you in English haha

Ok -- it certainly sounds like everything you have is correct. I mean, the AssetFactory, the Renderer and the fact that you have a facet in your search rights showing up with a count for your type means that if much be found. You're referencing the 7.0 Documentation .. so I just want to clarify something. You are dusing a Liferay 7.0 installation, but can you clarify specifically which version?

The next thing I would try would be to remove the search portlet from the equation and try with a custom query. If you create a new MVC Portlet, then in the render method you can try to use something like this --

long companyId = _portal.getCompanyId(portletRequest);
long groupId = _portal.getScopeGroupId(portletRequest);

// build the basic object

HttpServletRequest request = _portal.getHttpServletRequest(portletRequest);
HttpServletRequest originalRequest = _portal.getOriginalServletRequest(request);

SearchContext searchContext = SearchContextFactory.getInstance(request);
searchContext.setEntryClassNames(new String[]{Ads.class.getName()});
searchContext.setStart(0);
searchContext.setEnd(10);

Indexer indexer = IndexerRegistryUtil.nullSafeIndexer(Ads.class.getName());
Hits hits = indexer.search(searchContext);

Or something close to that -- I'm going a bit from memory here. If you then set a breakpoint after the last line above, then you you can inspect the Hits and the SearchContext objects to understand what is being passed to elastic. Just make sure, in your portlet class, to inject a service for the Portal .. or change the references above (_portal) to use PortalUtil instead.

@Reference
private Portal _portal;

.. also, are you able to share the code for your indexer class with us?

EW. .. just kidding . I get it, sometimes you have to do what you have to do to get it done and keep the wolves at bay. With that said, if you have a have a technical debt backlog item for this and want to continue to troubleshoot to figure out what the missing piece was, so that one day you can swap out the temporary fix for the better solution, I'm happy to continue to troubleshoot it with you.