Forum Stats

  • 3,872,506 Users
  • 2,266,435 Discussions


Search Integration Issue - Portal 10.2

653189 Member Posts: 101
edited Nov 10, 2008 11:20AM in WebLogic Portal
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.


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.


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,


  • 430429
    430429 Member Posts: 55
    Hello Srinivas,

    Have you tried

    1. Content Management API (Search Engine) [cm:search based on query]
    2. Autonomy Search Engine bundles along with ORACLE WebLogic Portal
    3. You can also go for third party search engines like "Verity, Lucene, Google"

  • 653189
    653189 Member Posts: 101
    Hi Paz,

    Thanks a lot for your reply.

    I am currently using Autonomy Search and CMS AP as you suggested.

    If I am searching with a keyword , I am able to get results which satisfies the search criteria.

    And the results are , contents created in the admin Console.

    And application is built upon these contents using content selectors,

    i.e Content in the application page is rendering dynamicaly as per content selector query.

    pls suggest me, how to display search results which points to application pages , which satisfies search criteria , as we wll get in Google.

    Thnanks & Regards,
  • Depending on the level of personalization in your portal, this can be very cumbersome or not possible at all. If your personalization is limited in scope to depending on certain user classifications, you can use the Autonomy HTTPFetch to spider the portal. You would set up a spider once for each user classification and have the spider execute it's crawl by logging into the portal as a user in each classification. Each spider could store it's index in a distinct namespace in the Autonomy IDOL Server. Then, when a user executes a search, you would target that search to the specific namespace represented by the user classification of the logged in user.

    Now, if you go beyond simple personalization like the above, you will probably not find a solution where you can direct the user to the portal page where the resulting content was displayed. For example, if you allow end user customization of the portal whereby they can move or remove portlets, change pages, etc. There is no way for the search infrastructure to know how to redirect after search. This is why sites like always take you directly to the "full page" view of the resulting search result, even if the result was also displayed in your customized page. In this situation, the best you can do is to take the user to a view of the individual content item that was in the result set. The situation can get even more complex if content is displayed in your site based on request/session attributes, time of day, etc.
  • 665334
    665334 Member Posts: 40
    edited Nov 5, 2008 3:34PM
    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,

    Edited by: Petri Pellinen on Nov 5, 2008 10:32 PM
  • 653189
    653189 Member Posts: 101
    Hi Brad And Petri,

    Thanks for your suggetions.


    As per your , suggetion to use each spider for each classification,
    1) Will it effect the perfomance of the application , if no of spiders are more?
    2) If the application page is indexed in the IDOLserver , How to query IDOL server to retrieve the results?

    3) I got one suggetion to check OOTB autonomy portlets , But I didnt find much according to my reqment

    Pls suggest for 1 , 2 questions

    Thnaks & Regards,
  • 653189
    653189 Member Posts: 101
    Hi All ,

    As per your suggetion , I have created SPIDER Process, and the application pages are indexed into IDOL Server,
    Eventhough my application ,is developed using Content Selectors, If i run spider process , application pages are indexed into IDOL Server.

    And in the following URL ,I can see the list of pages indexed.

    And I can query IDOL Server using following URL ,

    Could you please suggest me , how to retrieve the data(results) , programmatically,

    Means How can I Query IDOL Server Programmatically.

    Thanks & Regards,
  • See

    The Autonomy ACI (Action Command Interface) API javadoc is included in your WLP installation. Extract it check it out. The jar file is already included in your WLP EAR project so you shouldn't have to do much else to get going. There's also an ACI_API.pdf file that will give you some basic information on using the API.

    If you want to check out some sample code, look at the Autonomy Portlets that are included with WLP. These are JSP based portlets, so the code is all right there for you to review.
This discussion has been closed.