+

Search Tips   |   Advanced Search

Prepare for Portal Search

Portal Search is preconfigured with a search service, a portal site search collection, and scopes. We can add, modify, and remove search services, collections, and scopes. We can install additional portlets related to Portal Search and apply special configurations. To prevent errors during crawls and enable viewing of documents, enable Document Conversion Services.


Language and region support in Portal Search

Depending on the portal environment and the users, we might want to make multilingual content available and searchable in the portal.

Internet search engines usually take care of language support in terms of language determination and language specific processing. The language information need not be carried in the URLs itself, nor in language specific metadata in the HTML source of the respective page. In most cases it is good practice to encode the content of pages using UTF-8 encoding.

If the site is a multilingual site, then enable the web crawlers to get to the content in the various languages through links. Enable language switching or selection based on either the cookie of a returning customer or using JavaScript to switch from one language to the other, will lock out web crawlers. Therefore in such a case the crawler picks up the content in the default language only. We can also check the webmaster recommendations published by the internet search providers for further details and suggestions.


Region support and multi-regional sites

Global companies might choose to publish content, and offer products or services specifically for certain regions. In this you need to distinguish between the various regions; in this context the term 'region' is sometimes used synonymous with 'country'. While today a language can be detected, there is no technical solution available to detect a region.

As was described for language identification, Internet search engines also find that location or region specific metadata is not reliable enough to use it for region detection. Consequently crawler expects the URL to carry region specific information. The most obvious is that the top level domain name carries the country code and thereby the region information.

For example, a domain name such as XYZ-Co.fr or XYZ-Co.co.jp strongly indicates that the company resides or operates either in France or Japan.

Top-level domain names are used, no further action is required to allow region identification on that web site. However, for more generic domain names such as .com or .eu , additional steps are required for enablement. In such cases you need to encode the region information in the URL, and pair it with tools provided by Internet search engines, such as Google's Webmaster Tools for Geographic Targeting.


Enable region identification in WebSphere Portal

Geographic targeting tools allow us to associate a URL pattern with a specific region. However not all URL patterns are typically supported. URL patterns that are not supported have the region or country information encoded as a string value in a parameter list, such as www.XYZ-Co.com/products/information/?article=ABC123?country=UK . The following options are supported:

Configure top-level domain names with country codes and subdomains with generic domain using standard portal configuration steps. However, when we write the region information into the relative path of a Portal URL, you need to adapt the portal site structure to differentiate between pages and page groups for a specific country. If we use Web Content Manager to deliver the content into the portal, this has implications as to how the content is managed and organized in the library or libraries. In both cases the portal capabilities of rendering user friendly URLs is important. You have two options to handle this situation. They are described in the following.

  1. The first option is based on the assumption that the site is split up at a certain point to reflect the different regions or countries. A typical scenario can be either an online shop or a product overview specific to the countries in which a company operates. Example URLs could then look as follows:

    • For the US: http://www.xyz-co.com/home/products/us/
    • For France: http://www.xyz-co.com/home/products/fr/
    • For Italy: http://www.xyz-co.com/home/products/it/

    To achieve this, set the friendly name of the top-level page that serves as the entry page for a specific country, with the appropriate country code as the identifier that will then be published via the URL. Note that you need to assign friendly names in the whole hierarchy of all pages that can be identified as a page for a certain region. The previous example would result in two main unique portal pages:

    1. home
    2. products This has three region specifics pages: us , fr , and it .

  2. The second option has the same first two levels in its page hierarchy as the first: home and products .

    The products page renders the content based on user selection or preference. Web Content Manager then delivers the content for the chosen country. The association of a web page with has a set of content items in the Web Content Manager library is done using site areas. The names of the site areas represent the country codes. Three portal "content" pages are added to the products page associated with the site areas. In the example this adds three region specific portal pages associated with the site areas us , fr , and it .


Security considerations


Use remote search service

A remote search service offloads and balances system load.

The remote search service can either be an EJB or a Web service via SOAP. Security can be enabled with EJB but not with SOAP. SOAP support for remote search services has been deprecated with WebSphere Portal v8.0.

Separate WebSphere Portal environments cannot use the same remote search service. Only multiple nodes in the same cluster can use the same remote search service.

Search results are filtered based on user security credentials. This filtering occurs independently of whether security is enabled on the remote search server or not. However, if security is not enabled, an unauthorized user can connect to the remote server and obtain unfiltered search results. To prevent this, use EJB and enable security on the remote server.


Configure remote search service


Search across Lotus Quickr servers

In a collaborative environment where users are working across Lotus Quickr servers, the portal server can be configured to access these remote servers and make the content on the servers available for searching.

To enable users to search content from Lotus Quickr servers, create a new search service on the portal server that retrieves search information from the remote Lotus Quickr servers. This search service discovers search scopes on the Lotus Quickr servers, and represents them as new scope locations on the portal server. Using these new locations, it is possible to define new scopes, which will allow users to search seamlessly across local portal and remote Lotus Quickr content.


Create a new search service

  1. Install Interim fix LO25578 on Lotus Quickr v8.0 servers.

  2. Enable single-signon (SSO) and exchange LTPA keys between all servers

  3. Verify both servers are using the correct SSL certificate.

    1. On the Lotus Quickr server, start the IBM Key Management tool,

        was_profile_root/bin/ikeyman

      and open...

        was_profile_root/etc/DummyServerKeyFile.jks

      The password is WebAS.

    2. Extract the certificate file to...

        was_profile_root/bin/cert.arm

    3. Transfer cert.arm to the machine where the portal is installed.

      If we are working in a clustered environment, copy the file to each node in the cluster.

    4. On the portal server machine, start ikeyman

    5. Open cacerts as JKS key database file...

        WAS_HOME/java/jre/lib/security/cacerts

      The password is changeit.

    6. Add the cert.arm file that you transferred from the Lotus Quickr server to the key database file cacerts.

    7. Click OK, and give the signer certificate a name.

    8. Restart the Lotus Quickr server and the portal server.

  4. Add a new content search service to the local portal server where the search will be initiated.

  5. Modify the new Search Service configuration by setting the following parameters, if required.

    Setting the RestServiceHost parameter is required. You must also define a secure port for the parameter RestServiceSecurePort (for example, 10035) during creation of the RCSS Service, and use https for the RestServiceSecureProtocol parameter. By default, the service work with scopes, and the remote Lotus Quickr server is excluded from the All Sources scope.

    Parameter Value Description
    RestServiceHost example: myserver.myco.com The host name of the remote Lotus Quickr server. Required
    RestServiceSecureProtocol https Protocol required for use with secure port.
    RestServiceSecurePort example: 10035 A secure port. Required.
    RequestLocationType /scopes for discovering scopes on the remote Lotus Quickr server (default) Represents part of the URL path from the REST Search request for retrieving all available locations on the Lotus Quickr server.
    LocationParam scope if using a scope identifier (default) Represents the location parameter name for the REST Search request against the Lotus Quickr server.
    DefaultCollectionName example: DefaultRemoteContentServerCollection The name of the collection which represents the remote Lotus Quickr search service.
    IgnoreAllSourcesSearch True if the Lotus Quickr results will not be included in the All Sources scope (default). False if the Lotus Quickr results need to be included in the All Sources scope Defines whether the Lotus Quickr search service will participate in the All Sources scope search.

  6. Click OK.

  7. Check that a new collection was generated for the new service with the name as specified in the parameter DefaultCollectionName.

    This is a virtual collection that represents the remote Lotus Quickr content.

To define a new search scope that includes the location from the remote Lotus Quickr server:

The Remote Content Server Search Service contains the Lotus Quickr scope, as defined by the RequestLocationType parameter defined in the search service.

Select the scope, or select multiple locations of the scope.

Selecting multiple locations from the same server will result in multiple calls to the remote server, which can cause performance degradation.


Parent: Portal Search
Related: Configure Portal Search in a cluster on AIX
Tips for using Portal Search
Portlets for working with Search
Administer Portal Search
Use the WAS admin console to administer Portal Search
Enable Document Conversion Services
Portal farm considerations