Search Integration Issue - Portal 10.2

Question

Hi All,
I am trying to integrate Search in weblogic portal 10.2.
After some trials , i was able to search the published content in the admin console.
And if any content is created , that content is getting indexed ,,I have seen from following URL.
http://localhost:9014/action=list
But the problem is
I want to integrate this search facility in my portal application.
And this search has to search the list of pages in the portal apllication.
How this can be acieved , because content is dynamically populating in my portal application using content selectors.
Simply:
If I am searching with the word "xyz" in my application , It has to display the list of pages in the application containing the text "xyz".
Because content is getting displayed using content selectors.
Thanks & Regards,
Srinivas

Answer 1

pls suggest me, how to display search results which points to application pages , which satisfies search criteria , as we wll get in Google.Hi Srinivas,
as Brad already pointed out, this is a complicated problem in the case of portal and cms, mostly due to the fact that there is no out of the box glue layer between cms hierarchy and portal hierarchy. Because of personallization, content selectors, etc. it is not a one-to-one mapping. However, this is merely a technological issue and a business requirement similar to yours keeps popping up in real world projects including a few of the ones I've been involved with. There are some workarounds, but so far I've not come up with a "perfect" solution. I would <strong>love</strong> to hear from someone who has an elegant solution.
One approach is to define a "home" location in the portal hierarchy for a piece of content in CMS using metadata. A simplistic approach to this would be to e.g. set a metadata attribute that specifies the instance label of a page that is guaranteed to have a portlet that displays the content item. A variation is to use a CMS site hierarchy (or folder hierarchy) that mimics the portal book/page hierarchy. The "home" location in this case can be deduced from the CMS hierarchy. As you will notice, both of these approaches require that CMS is kept in sync with the portal hierarchy. Also, if you have multiple desktops and reuse a piece of content across them you need to modify this scheme with additional metadata and/or site hierarchy setup. Yet another approach is to have a separate mapping layer that maps the content node id's and/or hierarchies to portal hierarchy. This mapping layer can be anything from a properties file to an elaborate DB based application...
With these approaches when you get a search result node you need to retrieve either the metadata item or the folder hierarchy or the mapping layer translation and then set up a page change event to take the user to the proper page.
One of the many issues with these approaches is that when you move content display portlets around you need to update stuff elsewhere (CMS or mapping layer). Depending on your content display portlet mechanism you can also consider setting a portlet preference that points to a cms folder or node. You can then traverse the desktop hierarchy using presentation contexts while extracting the cms contexts from the portlet properties. This way you can semi-automatically create a cms-to-portal mapping which serves as a lookup table for the search results. Obviously, this time around the challenge is keeping the portlet preferences in synch when stuff is moved around on the cms side :) To overcome this, you would probably need to hook into the content events inside the repository and modify the portlet preferences on the fly when stuff is moved around. This would be quite hard core in my opinion and I've never gone that far in a real world project....
Summa summarum: there are no low-hanging fruits here, but what you describe can (and has been) achieved to a certain degree with some serious admin/management headaches. Sometimes the business requirement is set in concrete and it overrides the admin concerns :)
Hope this helps, I'll be happy to elaborate on the thoughts above since this is one of my pet peeves when doing architectural design for a new portal project :D
Best regards,
Petri
Edited by: Petri Pellinen on Nov 5, 2008 10:32 PM