We receive a lot of questions related to the Remote Search features available with WebSphere Portal. We have summarized a few frequent ones and the answer below:
- If using a cluster or farm with more than one node and want to use Portal Search do I need a remote Search server?
Yes. The local Search feature can only search a single node in a cluster and since indexes are stored locally other nodes would not be able to leverage those.
- What is the difference between Authoring Search and Rendering Search?
Authoring Search is used by the WCM Authoring Portlet - it is implemented using JCR (Java Content Repository) Text Search that relies upon the Portal Search Service. Rendering Search does not leverage the JCR text search feature but leverages the Portal Search indexing feature.
-If I want to use Authoring Search in a cluster or farm with more than one node what are the high level steps required?
It is required to setup and configure a remote search server (including remote document conversions services). In addition one needs to configure the icm.properties file to point to the remote search service.
The nodes need to be able to communicate with each other so you will need to exchange SSL certificates and LTPA tokens. After these steps have been taken the JCRCollection1 resource collection should be recreated.
- What do I need to configure for rendering search?
Just a remote search service needs to be configured and leveraged when creating the collections. We recommend to not configure authoring search for the production rendering systems due to the performance impact and it not being required since authoring should happen on an authoring system.
- Should I remove local search collections after configuring remote search collections?
- Is a shared file system required for authoring search in a clustered or farmed system topology with more than one node?
No. The documentation has been updated to reflect this.
- Should remote search be configured via EJB (Enterprise Java Beans) or SOAP?
We recommend to use EJB as communication mechanism between Portal and Remote Search.
- How to achieve failover with a remote search server?
Right now it is not supported to cluster a remote search server. One possible solution is to configure a primary and secondary remote search server. One can then use access control to manually switch between the different servers when needed (e.g. when maintenance is applied to one of them) without requiring a restart. There are other approaches possible as well as discussed in the document "High availability options for IBM WebSphere Portal 6.1 search".
- What are the most common issues related to remote search?
1. Communication Issues between the remote search server and Portal due to firewalls, incorrect seedlist URLs, timeouts, SSL certificates, ...
2. Security challenges with the remote search server not being able to authenticate to Portal and vice versa. Check the LTPA tokens, used userid's and passwords.
If possible use the same user registry for both Portal and remote search.
3. Document Conversion not being correctly configured on the remote search server.
4. Resource contention issues on the remote search server - ensure a 64 bit JVM is used and that enough heap has been assigned and that the file system has sufficient space.
Also do not forget about the remote search server(s) - it should be a managed server that is monitored for log errors, service availability.
- Are there alternatives to remote search?
IBM Omnifind is an enterprise search solution that can be leveraged with WebSphere Portal and that has Out of the Box integration options with Portal.
It is also possible to use third party search solutions but one would need to handle the integration effort.
Java Content Repository TextSearch in IBM WebSphere Portal Web Content Manager V8: http://www.ibm.com/developerworks/websphere/zones/portal/proddoc/jcrtextsearchportal8/