Christopher Even on SharePoint Search

This question from your clients will always come up. You have just integrated their LOB system into SharePoint Search and now you are having results show up. Those results are nothing more than a set of property values that were crawled earlier and now your clients want to be able to actually interact with them. The first question to ask is what level of interaction are they looking for. Here are the different levels:

1. Launch a client application to open and work with the item.
2. Go to a details page on your portal with more data about the item and that has more links to work with the item.
3. Provide a contextual menu on each item that lets you act directly on that item. Open/Edit/Check-In/ Check-Out. These menu clicks will need to go to somewhere and provide the desired functionality. 

As I stated above your search results are just crawled property values with no magic solution built in for working with the results (unless they are crawls of standard portal content sources, but we are talking about all the other LOB systems out there). By default one of the properties that gets crawled is the link or HREF, and this is what will be the link that you get served. If you are using a vendor provided integration then the integration may be taken care of for you. Some vendors create a central site under _layouts which serves as the target for all their items they index.

But let's focus on a custom integration for now. You have just written a neat protocol handler (http://sharepointsearch.com/cs/blogs/notorioustech/archive/2007/06/19/contentenumerator-cs-for-stored-procedure-sample.aspx) or created a BDC definition (http://blah.winsmarts.com/2007-4-SharePoint_2007__BDC_-_Enabling_Search_on_business_data.aspx) to index content from some system.  In either case you have to decide what you are going to put in for a hyperlink property for this item.

Note: you CAN"T put javascript as SP Search will URL Encode it for you and that will break it. 

Here are some helper ideas on what to actually do to make your results super actionable.

1. Create a destination page like customer.aspx  and use the BDC web parts to display a detail view of the search item. Have the id of the item be passed in as a parameter to that customer.aspx and the web parts filter on it. NOTE: The profile page will be the default for BDC items that were indexed by SharePoint search, but I am talking about a custom destination page. 

2. If you or a vendor has already developed a web based integration whether SharePoint enabled or not, you can alter the search results xslt to pop open a window to that application passing in the id of the item.

3. If you are good with xslt you can edit the results web part to check for your content type and provide the users with more options than a simple single link. I have created menus on the fly based on both the content source and also individual crawled properties of that item. For instance: You can have a property that says whether an item is readonly or not and provide a link to edit/check out.  Ontolica provides you with many tools to customize your results without resorting to xslt editing, including the adding of menu actions based on crawl property values.

4. Client Side Integration - This is for experts only.  Microsoft uses activex controls to launch office applications from sharepoint http://blogs.technet.com/josebda/archive/2007/03/26/searching-the-visible-moss-2007-code-for-activex-references.aspx  and so can you for your own applications.  I will try and whip up a sample, but here is a freeware link http://www.whirlywiryweb.com/q/launchinie.asp for now. So what you do is write some custom xslt to replace the standard href of your content with javascript calls to an embedded activex control on the search results page to launch your client application for your item. I said it was for experts :).

5. Citrix Side integration - Now this is really really tricky. If you are running a citrix server and can host applications there, you can use the newly released WISP SharePoint product from Citrix to actually launch applications from your portal as in #4 above but they don't need to reside on your client. This is not standard public functionality and it took a lot of poking around with reflection to figure out how to trick it to open items that aren't actually stored in the portal, but it works for Hummingbird, Worksite, etc. pretty much every LOB application out there.  I would post specifics about this but unfortunately I have to keep some trade secrets for my company. If you have gotten all the way through all of the above and this is a model you are interested in, contact me directly.

To find which vendors already provide integrations for your ERP, CRM, DM and other LOB systems use this cross reference:  http://sharepointsearch.com/pages/vendormatrix.aspx

To find all the MOSS Search enhancement products from all the vendors see the product list: http://sharepointsearch.com/pages/products.aspx

Also a good starting point to learn about SharePoint Search and how to do your own integrations: http://sharepointsearch.com/pages/spsearchresources.aspx

This has been out for awhile, it's incredible. I was reminded of it while talking with Martin of BA-Insight and noticed that very few people have clicked the link on the SharePointsearch.com site and thought everyone should at least view it once for a truly humbling experience.

Here it is: Diagram  ( this link redirects through the SPSearch site only to update the number of clicks to track popularity) or go direct http://www.impacsystems.com/contentdocs/ISE%20Enterprise%20Search%20Placemat.pdf

BTW. Good luck trying to print it out unless you have a large plotter.

I am writing this blog post with the latest beta from microsoft http://get.live.com/betas/writer_betas

I am very impressed with it's capabilities. It easily recognized my CommunityServer type blog and even downloaded the theme so I can see exactly how it will look as I am typing it.

I am just now starting to play with all the features.

Everything is possible. It is just a matter of cost and time. I have been having an ongoing discussion with Lar's of Mondosoft about faceted searching and here is summary of what we came up with:

First off you could just license an external search engine that already has faceted searching and plug it into SharePoint replacing the standard SharePoint search. But what we are discussing is the possibility of doing true faceted searching with the SharePoint Search Engine.

See http://sharepointsearch.com/pages/bigresourcelist.aspx or ask.com for for an example of what I mean.

Here are the requirements:

• a facet can be both static ( metadata property) or dynamic (conceptually determined) 
• all facets are displayed and searchable (meaning clickable to further narrow the search).
• counts are displayed for each facet entry which represents the total search result entries that contain the entry.
• The facet entries and their counts are accurate which means they honor the current search, current security of that search and are not just a subset of the returned results. If a search returns a million results, all results are used to determine the facet entries not just the first 20k.
• The interface for facet display must be clean and configurable by users so as to allow them to hide unnecessary facets.

Here are the barriers:

• Currently only possible to do static facets as SharePoint doesn't have the ability to do conceptual searching ( see Engenium for possible future availability) 
• Impossible to reliably get large( 100k+)  result sets back from SharePoint as the new security trimmer model will block that. Although you could target specific content sources that don't have a real time security trimmer and just do faceted searching within that set.
• Since behind the scenes SP Search is combining a SQL search and a file based full text search there is alot of work going on and it is optimized to return the first few thousand results back fast. Beyond that it will start to slow down and getting all million results out will certainly exceed user time requirements.
• Current SP Web parts and search UI is locked down hard and not extendable enough to work with for this purpose, so you have to write your own search interface from scratch or work with another vendor who has one like Mondosoft or BA-Insight.

Ideas for approach ( they can be used in any combination):

• read ALL the results back from a Search without limits and read the whole dataset into memory, then programatically ( or through xslt) generate accurate facets. This is possible if you own the search interface like Ontolica, but will still face issues with performance and be at the mercy of the security trimmers.
• Create a duplicate SSP that crawls the same data but has Security Trimming turned off ( can be done through object model easily enough)  and use that to generate facets. Numbers may be off but think it is acceptable.
• Use your result set to return only the workIDs (document ids) back and use them to run a query directly against the SP Search SQL database to get the metadata property counts.
• Create an OLAP cube from the SP Search SQL database with all the facets predefined and generated. Include the workid as primary key and run OLAP queries with the working universe from the SP Search to get totals. - This sounds like a fun approach but not sure of its merit without some testing.

Will continue to think about this.

Here is a good discussion thread about it: http://sharepointsearch.com/cs/forums/t/464.aspx

extract: 

According to Foxit Tech support, their iFilter is currently not capable of emitting custom metadata. I suspect that Adobe's iFilter does not support this feature either; however I have not contacted them to find out.

There is an iFilter, PDF+ iFilter, from ifltershop.com that DOES support emitting custom XMP data. They have directions in their help/readme file to make it work.

"In order to set up PDF+ IFilter to index custom XMP schema you will need to add information about this schema to the IFilter registry settings as described in "Support for custom XMP schemas" section of README file. "

Those directions in that section were not as clear as I would like, But no fear, they were willing to take a sample PDF from me and create the REG file required. Still waiting on getting that back to test, but it looks promising,