Paging search results via Content Server SearchService web services.

Are there any examples or documentation on how to use the SearchService web service to handle larger search results by using the paging side of Content Server search results?

We currently use the SearchService to carry out various category/attribute metadata searches via .Net/C#/WCF etc i.e objects like

SearchServiceClient search = new SearchServiceClient();

SingleSearchRequest request = new SingleSearchRequest();

But we are finding when the search result set gets up to 100-200 results, the response time is often far too slow. When this is the case we want to look into paging search results, like the Content Server web interface does to maintain good initial search response performance.

We realise it's possible to say how many results to return in the SingleSearchRequest object, and which result to start on by changing the properties of the request i.e

request.FirstResultToRetrieve = 1;

But how to handle using search result paging? i.e when you want to say bring back the first 10 result, then build your own paging grid, then make the request for the second set of 10 results from the original search request. Clearly the web interface of Content Server already uses such functionality, but is it possible to replicate this via web services?

If so, are you then limited to returning search results in whatever order they are found in the index? Or can you still request some sort of ordering (or does that then reduce performance as it needs to find all results first to be able to return pages of results in the right order still)?

Any pointers or advice?

Many thanks in advance.

Find more posts tagged with

Comments

Steve Brezina

Hi John,

You should be able to replicate the UI pagination to by resubmitting the request with
updated FirstResultToRetrieve and NumResultsToRetrieve parameters. They are analogous to
startAt and goFor (page size) in the Search API.

i.e.
FirstResultToRetrieve=1, NumResultsToRetrieve=100
FirstResultToRetrieve=101, NumResultsToRetrieve=100
FirstResultToRetrieve=201, NumResultsToRetrieve=100
etc..

Continue until a partial page is encountered.

By default, searches sort on relevance. A sort region and direction may be specified according to the Search API in the ResultOrderSpec parameter.
i.e. ResultOrderSpec='sortByRegion=OTObjectDate&sortDirection=asc'

I suggest reading the Search API documentation.

Regards,

Steve

John_Henderson

Thanks Steve.

How does this work with remembering the state/session of the underlying search result? i.e if the app is via http and the user makes a request for page 1, then reviews and doesn't make the request for page 2 until a while later, do you have to store/remember and then pass in some sort of search cache id or reference to get details of the original search result (so you can move onto the exact page 2 of the first response) or does it just rely on the system returning documents in exactly the same order on the second search request that is then made but asking for the next 10 results say? In this instance the underlying data may change, and we wouldn't want for documents to be missed in the search / paging results because of that?

cheers

John

Steve Brezina

Hi John,

The Search API (and Search Services) are stateless, so each page request must fully specify the search query. The Content Server search UI does use a cacheID when paginating and performing bulk operations on search results. The pagination implementation relies on consistent ordering of search results from the search engine. i.e. The first 10 are discarded when showing page two of size 10.

Regards,

Steve

John_Henderson

Thanks Steve,

We have managed to use the web service search request properties 'FirstResultToRetrieve' and 'NumResultsToRetrieve' to get back chunks of search results in smaller amounts, and ordered, however to do effective paging, you still really need to know how many results could be found overall (so you can calculate how many pages of results there are, or how many page numbers to show in a paging grid etc). Is there a property that exposes this in the search result even when using the properties above? Or are we constrained to having a user option (button etc) that in effect says 'More Documents' which then looks to see if any more docs (and repeating this).

The Content Server interface itself seems to be able to know roughly how many pages of results are expected, even when limiting the returned docs to 25 a page etc, so is this a property that is exposed in the CWS search request / response? Or specific something coded for the application itself?

many thanks

John

Steve Brezina

Hi John,

The UI has access to the raw unpermissioned result count and an estimate based on the user's past search result permission success rate. A user must have System Administration rights or be a member of the "See Unpermissioned Result Counts" privilege group to be shown the raw count.

The SearchService returns the estimate or the raw count (based on the above criteria) in the ListDescription.fActualCount field.

Regards,

Steve

John_Henderson

Thanks Steve, that’s superb, ListDescription.fActualCount is what I needed.

From: eLink Entry: Content Web Services Forum [mailto:otdncontentwebservices971forum@elinkkc.opentext.com]
Sent: 21 January 2015 19:08
To: eLink Recipient
Subject: re Paging search results via Content Server SearchService web services.

re Paging search results via Content Server SearchService web services.

Posted by sbrezina@opentext.com (Brezina, Steve) On 01/21/2015 02:01 PM

Hi John,

The SearchService returns the estimate or the raw count (based on the above criteria) in the ListDescription.fActualCount field.

Regards,

Steve

[To post a comment, use the normal reply function]
Topic:	Paging search results via Content Server SearchService web services.
Forum:	Content Web Services Forum
Content Server:	Knowledge Center

Important Information - Disclosure, Confidentiality and Monitoring of this email

This email communication may be monitored by the Isle of Wight Council for regulatory, quality control, or crime detection purposes.

If you are not the Intended Recipient please contact the sender as soon as possible. It is intended only for the personal attention of the named person, firm or company to whom it is addressed. It may contain information that is privileged and confidential in law. Accordingly any unauthorised dissemination, distribution, copying or other use of this message or any of its content by any other person may constitute a breach of civil or criminal law and is strictly prohibited. No mistake in transmission is intended to waive or compromise any such privilege. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of the Isle of Wight Council.

The information contained in this e-mail may be subject to disclosure to third parties under either the Data Protection Act 1998 or the Freedom of Information Act 2000 to the extent the law allows and in accordance with the Isle of Wight Council's policies on information management. (If you wish the disclosure of the information in any reply to be restricted please make this clear in your response).