I was working on several Service Manager engagements where I had very large computer, software, and user lists that I wanted to query content from through Request Offerings. The Service Manager content returned by the query is out-of-box set to return 2,000 items in a Request Offering. This is fine for many environments, but in this situation we needed to determine how we'd deal with the result set. There are two approaches to this. We could increase the size of the query results in the portal so all results are returned, or we could apply pre-search filters.
Ultimately you'll see that for these large data sets, pre-search filters provides the best results in user experience and speed of data return.
Increasing Query Result Max Sizes in Request Offerings
In order to increase the query results in a Request Offering to a larger number, you'll change the maximum query results configuration on the SCSM Portal Web Server. You'll open the XML at "inetpubwwwrootSystem Center Service Manager PortalContentHostClientbinSettings.xml" and modify the key to the value you want "
"
If you'd like more information on this, check out Travis Wright's blog here:
http://blogs.technet.com/b/servicemanager/archive/2011/11/08/advanced-query-results-customization-for-request-offerings.aspx
You'll need to be careful about using this option. If you increase the maximum of query results size too large you'll be causing unnecessary IO against your Service Manager infrastructure and could cause performance problems. The general idea is that the maximum results returned should be no larger than you require to serve the customer. I've rarely had a reason to go over 2,000 results, especially since a query result larger than that quantity is not as useful as it would seem. The idea is that we want to make the return of data as effective at finding the right data to select as possible, vs. causing the end user to tab through the query results.
Using Query Result Filters
I've found that when you are querying content from large data sets, such as 20,000 computers or users, you can't simply increase the size of the query results, since it will cause a significant load on the server. Also, users will spend too much time looking through results that don't match their needs. In order to deliver users more specific content to select from you can use pre-filters using previously entered data.
Let's pretend that we want to return a list of workstation(s) for a primary user from inside our domain You'd use this for requests such as self-service application deployment, workstation refresh, and settings pushes. We don't want to change our maximum query results, since returning 30,000 workstations for every request would be a bad idea. Instead, we're going to ask the user questions to filter the list of workstations that they are presented with. In order to provide faster results and cause an immediate blank first pass, we'll also use a pre-filter which aids our request process. In our case, the desired result is a list of workstations which match our specific requirements.
I started working on this type of request and immediately created a user search box and the CMDB query. These two combined to form a functional search, but also resulted in a poor user experience, since the initial return was searching for blank data and took an extended time to return a useable user prompt. The result was an initial screen load that looked like this:
I found that if I used "Token Portal Username" it worked perfectly and the response was almost instant. However, in this case the workstation isn't tied to that user, so I can't leverage existing data.
I found that by configuring simple lists with filtering criteria in combination with my search I was able to provide a very responsive interface and also better results for my request offering. In this case I added a drop-down list to ask for the domain of the workstation, which then functioned as a filtering criteria through an AND statement to create my results. I found that even when combining this with a filter criteria which included all workstations, this was drastically faster. The trick was to setup the simple list to include no initial results, which provided very fast form load and quick search result return speeds.
The query filter critera looks like:
Resulting in this:
I've used this same technique in searching for many other types of values, such as computer's based on primary user, groups, or software items. The key is to choose something that helps the user narrow down the result set. Ideally I want the device, application, or group to be returned without the user needing to do any additional filtering to select it.
I hope this helps everyone out.
Nathan Lasnoski