June 2009 - Posts

It seems everybody is moving to the cloud with their Enterprise applications. Some of the most popular systems are available as remote hosted solutions: SAP(mysap.com), Salesforce.com, MS Exchange Online, MS CRM etc. But as companies start to migrate to these remote hosted best of breed systems they start to face challenges with data visibility aka Knowledge Management. Searching and Reporting are critical tools for the the enterprise but if your data is no longer centralized how can you get a complete picture of all your data.

Enterprise Reporting has always been a critical part of business, being able to run reports and analyize data across multiple systems whether ad hoc or OLAP is critical for making reliable business decisions. But now building that data wharehouse is not so simple, you can't just import directly from your local databases of each of your systems. Hope is not lost though, I have researched many of those systems and there usually is a partner or two with an offering to provide that data extraction automatically for your reporting purposes. I would be curious to find out if anyone has build a centralized cloud based reporting solution that includes connectors for those system like SAP and Salesforce.com, if not i think i have my next startup company plan.

Anyways, this is a blog about search so let's focus on that. If you are hosting SharePoint internally (or FAST) for your Enterprise Search solution then how do you continue to maintain a centralized search interface when your data isn't so centralized anymore. The first option that comes to mind is Federated Search.

There has been alot of confusion about what Federated search means so let's clear that one up first. Federated Search is simply the combining of search results in a single interface from multiple search engines, for SharePoint that means when you run a query you get your regular search results in one webpart and completely seperate set from your Federated sources in another. In order for Federated search to work, either the vendor has to offer a standard Federatable (is that word?) interface or your have to write your own. There is possibly a second psuedo federated option to be considered depending on the remote systems search interface. Adding an iframe to host the remote search interface and some javascript to pass the search parameters has worked for me for some systems (sharepointsearch.com uses that model actually for it's search) and may provide what you need.

While i am at it, i might as well list the pros/cons of Federating search interfaces
Federated Search Pros:
  • Security can be handled by the remote system so no translation is required into your native search system (if you can resolve your single sign on issues)
  • No delays on index updates so search results are usually fresh
  • Minimizes network and internet bandwidth as the data doesn't have to be extracted out
Cons
  • Reliance on a Single Sign On model usually which adds an additional step before end users can search.
  • Loss of integrated features like Facetted navigation, customizable search results, and advanced searching
  • Complete loss of the relevancy capabilies of your search engine, your data is not actually in the index

You will have to be the judge on whether the loss of some search features is enough to justify the third option, index your cloud data with your Enterprise search engine. How you ask? Here are your options:

  • If you are already extracting out the data for reporting purposes into a datawarehouse most search engines provide a way to crawl sql data ( or there are vendors to help. See sharepointsearch.com for the list).
  • Write your own connector (see prior blog posts about how) to the remote systems APIs
  • Look to a third party vendor (again see sharepointsearch.com for a complete list).

NOTE: For Exchange, MS CRM, Salesforce.com/force.com and SAP Cloud systems see BA-Insight for SharePoint and now FAST. (shameless plug)

Powered by Zoundry Raven

Technorati :
Del.icio.us :
Zooomr :
Flickr :

Del.icio.us | Digg It | Technorati | Blinklist | Furl | reddit | DotNetKicks

I don't know how i missed this post from a couple weeks ago, but asking around nobody seemed to have caught it so here it is.

http://blogs.msdn.com/sharepoint/archive/2009/05/21/attention-important-information-on-service-pack-2.aspx

Here is an excerpt

During the installation of SP2, a product expiration date is improperly activated. This means SharePoint will expire as though it was a trial installation 180 days after SP2 is deployed. The activation of the expiration date will not affect the normal function of SharePoint up until the expiration date passes. Furthermore, product expiration 180 days after SP2 installation will not affect customer’s data, configuration or application code but will render SharePoint inaccessible for end-users.

Here is the KB article on it: http://support.microsoft.com/kb/971620

Del.icio.us | Digg It | Technorati | Blinklist | Furl | reddit | DotNetKicks