We’re working with a large Pharmaceutical company to install Documentum xPlore as a replacement for FAST. We’ve just finished the QA environment deployment, and we’re planning for the Production deployment in mid-April. For this post, we are going to discuss the cutover strategy as well as some lessons learned from the project.
Cutover and Reindexing Strategy
The client’s current environment contains one Content Server serving five repositories, and one full text server running FAST indexers for each repository. The upgrade plan is to stop FAST, install xPlore to the existing full text server and re-index all of the repositories. We’re planning on starting the installation on a Friday evening after business close. Accounting for time to upgrade the content server to the latest patch and actually do the xPlore installation, we need to make sure that the re-indexing operation is complete before Monday morning. To increase the likelihood that re-indexing will be complete, we decided to install an extra Content Processing Server (CPS) instance on the full text server. The full text server has enough memory and CPU to handle the extra instance, so that is the best way to increase our indexing throughput. We recently executed the upgrade in the client’s QA environment, and our average re-indexing throughput was 70 documents per second. Assuming we see a similar average in production, this should be more than enough to complete the re-indexing operation over a weekend.
- Full text searches do not support wildcards or fragment matching. This means that a search for ‘car’ does not return a document containing ‘careful’. However, a document containing ‘blue car’ is returned. xPlore treats wildcards as literal values. Searching for ‘car*’ still does not return ‘careful’.
- Metadata searches in Webtop’s advanced search work in a similar way, even when using the begins with, ends with, or contains modifiers. For example, searching for titles that contain ‘car’ will return titles that contain ‘blue car’, but will not return titles containing ‘careful’. However – xPlore does support wildcard characters in metadata searches. Therefore, if the user executes the search as ‘*car*’, then documents with titles of both ‘careful’ and ‘blue car’ will be returned. When executing a contains search on metadata, think of it as a ‘contains word’ search rather than a true contains search.
- Wildcards are supported from simple search and full-text searches. Searching for ‘car*’ does return ‘careful’. Note that fragments are still not returned. Searching for ‘car’ will not return ‘careful’.
- Wildcards are implicitly placed in metadata searches. For example, if you search for documents containing ‘123’ in the object_name, the actual search would be for ‘*123*’, and in our previous example, would return document ‘1234’ as expected by the user.
xPlore Admin Interface – IE Settings for Reporting
- Navigate to the xPlore admin website
- In IE, choose Tools -> Internet Options -> Security tab
- Click on Trusted sites and click the ‘sites’ button to add the xPlore admin website to the list
- Below, set the security level to Medium-low.
Agreed, the behavior of ‘contains’ on metadata is not optimal and might confuse users especially when searching for a reference, a part number or an identifier. As you noticed the behavior of ‘starts with’ and ‘ends with’ in the compatible mode improved in the latest DFC. We plan to make things simpler to understand in the next version of xPlore.
Note that soon we will release on the EDN a custom indexing annotator that would help normalize and simplify searches for ID/references like PX-SOP-1234. Stay tuned.
Final comment. The admin interface does work and is certified with Firefox – I’m using it.
–pitch
Pitch – thanks for your comments and clarification on the Admin browser support. I’ve updated the relevant text in the post.
We installed xPlore a few months ago. We were having an issue with FAST just shutting off once a week. xPlore has had no issues with staying up and is faster than FAST but is also on a new faster server. We have a lot of hyphens and underscores in batch numbers and etc. From the documentation I thought the default would be these are treated as white space but they where in the indexserverconfig.xml out of the box, no complaint just seemed like a discrepancy between the documentation and the install. One problem we did have was some of our documents though English were getting indexed as “it” Italian, “pt” ? EMC informed us to en to index-default-locale in the indexserverconfig.xml. Most of out properties are alphanumeric, when I put an English word in xPlore would index the document as English. Overall it was an easy install and is working well.
Can you enable ‘FAST compatibility mode’ anytime? Or do you have to do it during installtion?
FAST compatibility is enabled via the fast_wildcard_compatible attribute on xPlore’s dm_ftengine_config object in the repository, so it can be modified anytime after installation.
Hey George,
After editing the object in the repository? What else do I have to do? I restarted the index server services, but it didn’t seem to take affect? Do I need to restart the Docbase?
Thanks!
Did you restart the main xPlore server and any secondary instances? The index agents don’t really do anything with search, so restarting those won’t make a difference. If restarting xPlore doesn’t do the trick, try restarting Webtop – it may cache the setting somehow, but I’m not sure.
The solution that I reached in this scenario when documents do not get searched in when value of some of its attribute is like ‘PX-SOP-1234’ is Enforcing Default Language to English. This can be done by editing indexserverconfig.xml. In case CPS won’t recognize language, only in that case document get indexed in English language.