Wednesday, August 10, 2011

Working with Content Collections via the API–Continued (and yet another bug)

Yesterday I wrote about how you could use the admin API to create a new content collection for FAST Search for SharePoint. I explored this further, and discovered a more serious bug. From within a SharePoint context it will never work (see the end of this post for the solution)

For the code sample yesterday I instantiated the ContentContext with the line
ContentContext contentContext = new ContentContext();

Using the default constructor like this implies that the code is run on a server which has FAST Search for SharePoint installed as it will read the configuration file from %FASTSEARCH%\etc\Admin.config.

When using the ContentContext object from within SharePoint you have to go via the FASTAdminProxy property on the SearchServiceApplicationProxy object from the FAST Query SSA. If this sounds greek to you, the code below might shed some light.

var ssaProxy = (SearchServiceApplicationProxy)SearchServiceApplicationProxy.GetProxy(SPServiceContext.Current);
if (ssaProxy.FASTAdminProxy != null)
   var fastProxy = ssaProxy.FASTAdminProxy;
   // Get a reference to the ContentContext via a WCF proxy
   ContentContext coll = fastProxy.ContentCollectionContext;
   coll.Collections.AddCollection("notes", "Lotus notes connection");

The FASTAdminProxy reads it’s WCF configuration from C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebClients\FASTSearchAdmin\ContentCollectionService\client.config.

But, now we encounter yet another bug. The factory class which creates the proxy has a readonly member “ServicePostfix” which returns the name of the WCF service endpoint. For the ContentContext it returns “ContentCollection.svc”.


But on the FAST server the endpoint is named “ContentCollectionService.svc”, so we get an error that it cannot connect to the WCF service. The fix is simple and involves copying the file


over to