HttpCode

I read with interest Arpan’s article on Finding and Growing Great SharePoint Talent which covers the topic’s of developing and keeping great SharePoint talent in a broader context. I’m mostly concerned with the developer role, so I’ll focus on that.  

The Interview

The thing to extract here is their level of exposure to ASP.NET, depending on what role you want them to take in your SharePoint development you would at least want them to have a good grasp of ASP.NET. You really don’t want to spend time training them up on concepts that are generally related to ASP.NET development.

The next thing you should look for is their attitude towards SharePoint administration, the key to becoming an awesome SharePoint developer is knowing the product, if you want a developer to just develop some web parts then having a deep understanding of the product might not be needed, but if your looking for someone to tackle a wide range of SharePoint development tasks they need a broad understanding. I mean how can you develop a personalised web part if they can’t setup a development environment properly? or how can they build a feature or solution if they have no idea how they are used. Some developers will cringe at the thought of admin / setup work, but the fact is, it’s the best way to become familiar with the product.

On the Job - Day One

So you’ve picked someone who is going to become your superstar SharePoint developer, where do you start now? Do you leave them alone with a stack of books and training material? or do you throw some code at them and say start typing? There is no correct answer, each developer learns in a different way, you just have to work out what that way is. It’s probably not a huge stretch to start with the familiar topics like web parts but only after the developer has in fact used the SharePoint UI.

As time passes

Once the developer has done some admin and bits of development, they will start to speak and understand the SharePoint vocabulary, don’t expect them to instantly know the answer to all your development questions, even the seasoned developers need time to investigate the solutions, SharePoint is such a large product it’s not an easy task to know everything, but once you digest the core concepts a lot of stuff can be inferred and it gets easier to grasp new SharePoint related ideas. You’ll probably find that your administrators look to your developers at the first sign of trouble, which is another reason why your developers should experience the SharePoint world from an administrative perspective.

So in summary, I think ASP.NET skills provide the best leg up to SharePoint development combine that with someone prepared to sit and learn some administrative / setup tasks and you have the makings of a great SharePoint developer.

One of the cool things that MOSS offers is the ability to display the people search results ordered by social distance. You can see what result format was returned by looking at the search action links web part:

The default people search results view can be changed in the Core results web part:

The MSDN SharePoint blog has a detailed post which outlines how the colleague connections are formed:

• Immediate colleagues which are formed using the manager profile field.
• Colleagues added by you
• Suggested colleagues

It’s also an interesting read to find out some small details like:

• The first 3 pages of search results are grouped by colleague-ness: first your colleagues appear, then colleagues of your colleagues, then everyone else.
• Within each group, the ordering is still by relevance.
• When paging through results, another 3 pages of results will be grouped once you reach page 4, then page 7, etc.

Overall I think the feature works extremely well, although I’ve seen some users struggle with the feature, these users were typically expecting the results to be in alphabetical order like their previous pre-MOSS system. While I don’t agree with the concept since the results are returned by relevance (but in a social context) it is possible to sort the results alphabetically, Paul Galvin has posted some XSLT that does this. Remember that this is done outside of the search engine itself, so the XSLT is only going to sort the results per page. So its possible to have page 1 contain 10 results ordered alphabetically, then page 2 will contain 10 results that are again sorted alphabetically, which might cause problems to some users.

I think ultimately these users just need a little bit of training to understand the social distance format. Just like any search engine if you don’t get the results you are looking for on the first page, I really think you need to refine your search. If your just looking for a colleagues details the social distance is fantastic and saves lots of time, my experience is that I use the people search 90% of the time to find colleagues, of course your situation may be different.

By default SQL Server will auto grow your databases by 1 MB for your data file and 10% for your log files. There have been numerous discussions about the usefulness of this default value, but at the end of the day you should really understand how this will effect your database.

In the world of SharePoint it’s common for users to upload multiple mega-byte files, which will be stored in the content database and would cause the database file to grow and could potentially cause performance issues.

Another SharePoint scenario that needs consideration is the SSP databases, the indexing of content performs a large number of write operations of the metadata associated with the crawled content. It might be wise to monitor the performance of these databases to determine if changing the auto growth rate would help.

If you came to the conclusion that you did want to change the default options for all new databases, then you can simply change the default values of the model database, you can do this by right clicking on the model database and selecting the button next to the file you wish to change:

Like all performance related tips, it’s best if you conduct some of your own analysis.

Scott Hanselman recently posted about the IIS 7 Rewrite module and how easy it is to setup and use, he covers the topic extensively, I just wanted to point out that this tool will also work with SharePoint.

I was recently in a position where the marketing guys had decided that the URL should be the promotion name of the marketing campaign, but it was both impractical and impossible (the URL had to point to a survey) to create a page in SharePoint that would suit their needs. Since the site was running IIS 7 we used the IIS 7 Rewrite module.

For example:

Say the requested URL was:  http://server/marketing/promo/

But we needed to post to:  http://server/Lists/Marketing Survey 1/overview.aspx

The first step after installing the rewrite module is to create a ‘Rule with rewrite map’:

Then choose the rule action type, in this case it is a rewrite action, give it a meaningful name:

Then add the mapping (right click in the panel that gets opened after the last step), the Original value is the URL you want your users to navigate to:

That’s it your done, now you can browse to your URL and your users will end up in the correct location:

Some of the major web 2.0 sites like facebook and twitter are providing REST based API’s to interact with their services, if your not familiar with Representational State Transfer (REST), then now might be the perfect time for you to come up to speed because it seems that Microsoft is planning on incorporating more REST features in .NET 4, we already have some REST support in the current generation of tools.

The basic idea of REST is to use the existing infrastructure that the web already provides, we have HTTP verbs such as GET, POST, DELETE and PUT, which map pretty well to the CRUD model we deal with often. The web provides us with a simple error handling model, we all understand 404, 501 and 403 error codes (file not found, server error, unauthorised access). The final building block is the URL itself, we can create descriptive URL’s such that any user can infer it’s intent just by looking at it, while some may disagree with my summation, I think all of these elements together define what REST is.

If we contrast all of this with the world of SOAP and webservices, we soon realise that the webservices/SOAP model has been over-engineered. Do we really need to re-invent error codes and the calling conventions that already sit on top of the web, do we need all this SOAP overhead, one end-point for a raft of operations? Of course there will still be a place for traditional webservices, I’m not saying they don’t work or are going away, they clearly work and will be around for a while.

The webforms model of ASP.NET hasn’t really made it easy to create REST services, it was never really designed for it, however the ASP.NET framework has made developing REST’ful services a lot easier.

The first feature that the MVC framework offers is the flexibility of offering a URL routing engine, so that it is possible to easily create nice URL’s, but more than that, the way MVC uses the convention of {controller}/{action}/{parameter} you end up with code that without much effort becomes very REST like.

The second feature that MVC offers is the way each action on a controller returns an ActionResult, the framework provides inherited result classes such as the JsonResult and ContentResult, in effect the one action can return multiple payloads of data (in this case either a JSON view or an XML view). While not strictly fitting to the REST definition, most modern REST API’s return data in a format that is most easiest to work with which is increasing becoming JSON for AJAX/Mashable operations.

With this background we can now focus our attention on SharePoint, currently there are two ways to work with the data stored:

• Web services
• Object Model

I’ve already touched on what the limitations of the web services are, the SharePoint object model really only concerns us if our code is working inside SharePoint (i.e. on the same machine/s as SharePoint).

The Benefits to SharePoint of a REST API

• Enterprise mash-ability – the web is becoming more and more useful, one reason is that its now easier to mash together applications, look at any application that makes use of virtual earth or Google earth, flickr, twitter, live services etc. Imagine having this flexibility in your organisation, if your organisation has really embraced SharePoint then most likely it contains data that could be mashed into other systems, this REST framework is about exposing that data more easily.
• It still fits with an organisations Service Oriented Architecture (SOA) in most cases. A lot of people feel strongly that SharePoint isn’t the single source of truth for data, that may be the case, but SharePoint is a tool that does aggregate data and adds value to it (a user might create a list with BDC data with additional columns describing some business function), this framework is designed to make this data more accessible to an organisation trying to construct some form of SOA.

The URL Format

A REST API that sits over the object model would provide the best of both options, we could craft a simple URL that returned the items that we are after such as:

http://mashserver/Site/            -- returns all sites
http://mashserver/Site/all/            -- same as above
http://mashserver/Site/get/{guid-id}    -- returns the selected site

http://mashserver/List/                  --returns all lists that the user has permissions for
http://mashserver/List/forsite/{site-guid-id}   -- returns all the lists for the given site id

http://mashserver/ListItems/get/{list-guid-id}  -- returns all the items in the list,

http://mashserver/BDC/   --Return all the BDC applications

http://mashserver/Permission/site/{site-guid}   --Return objects representing the security ACL’s on the given object

The REST API should expand across all areas of the SharePoint system. Each action should be decorated with an accepted verb type attribute which MVC provides.

The Return Values

We could build a HybridResult that looks at the HTTP headers to determine the accepted input and then either return JSON or XML:

In fact Omar has already provided a nice starting platform.

This HybridResult can also be smart enough to return a 404 if the object we are trying to serialize is null. If we get any security exceptions we can set the return status code to 403, again the MVC provides a nice mechanism to support this via it’s Error Handling attribute.

Problems

• Do we build our own object model, reinvent the wheel?

I think the answer is yes, we can’t serialize the SharePoint object model to our needs as a REST API, in some cases we want to return properties in a form that would be easy to use from JavaScript. We often don’t want to return the whole object graph, if you ask for all the lists, you really don’t want to have a list object returned will a collection of list items. By using the new language features in .NET 3.5 we can build extension methods that provide a neat way to convert the existing Object Model entities to those created by the MVC framework.

• Security – The double hop issue

Since the API is going to make heavy use of the object model, it’s going to have the same limitations as the object model, i.e. the API web sites will need to live on the same server as SharePoint unless the double hop authentication issue is taken care of via the use of Kerberos, which is a likely event in most larger organisation.

 Features - Thoughts?

So what do you think? Is a REST API for SharePoint something that would be useful? I’ve already started developing some proof of concept prototypes which I’ve included on the project’s Codeplex site:  http://www.codeplex.com/REST4SharePoint so please leave any feedback there.

What features do you think it should include?

What are your thoughts?

What obvious thing have I missed?

I wrote about setting Microsoft Search Server 2008 Express up and configuring it to index a web site, the search interface that I demonstrated was a standard SharePoint site based on the Search Centre Template. I thought it would be nice to show how easy it is to build your own search interface.

I think the big appeal about Microsoft Search Server 2008 Express is that it can be used without the full overhead of SharePoint. So with that in mind and the fact that I’m unhealthily in love with the MVC framework, I’ve put together a simple ASP.NET MVC sample that works with the search server:

The screen cast shows the sample application as well as an overview of the code:

The thing that is really appealing is that by using the ASP.NET MVC framework, you have complete control over the generated HTML, there is no nasty webpart hidden fields or the hideous viewstate.

I hope you come away with the idea that Search Server would be perfect for indexing your website or file shares etc, but that you ultimately have the power to present those results how you see fit.

You can download the source code to my sample application here. It makes use of the MVCContrib library for the pagination support and preview 5 of the MVC framework.

A list of all the default columns that are returned by the search web service can be found here:

• WorkId
• Rank
• Title
• Author
• Size
• Path
• Description
• Write
• SiteName
• CollapsingStatus
• HitHighlightedSummary
• HitHighlightedProperties
• ContentClass
• IsDocument
• PictureThumbnailURL

If these don’t provide what you need then you can use the other enterprise search schema’s.

By default SharePoint will create a content source called ‘Local Office SharePoint Server sites’ such as:

This will contain the starting addresses of all the sites on your SharePoint server such as:

Notice how it also includes the sps3://, this is the indexing of your user profiles.

My tip is to remove the sps3:// link from the default content source and add it as a new content source on it’s own.

The reasons why I think this is helpful:

• By default you need to crawl all your other content just to update your user profile information.
• You can schedule your profile crawls at a time that suits your active directory imports

In any case it’s worth considering breaking the profile crawl into it’s own content source.

I’ve put together a screencast that carries on from my previous post on installing and configuring Microsoft Search Server 2008 Express.

This screencast covers:

• Setting up a new external content source (my example is this indexing this site)
• Viewing the crawl log to determine the success or failure of a crawl
• Adding a search scope to give the end users the option to focus there search query to a particular area
• Enabling the search scope in the site collection
• Setting up the search centre page web parts to show the search scope dropdown

In the screen cast I mention that the navigation links in central admin or the search administration don’t link to the search scopes settings page. I manually added the url:  http://<server-name>/ssp/admin/_layouts/viewscopes.aspx?mode=ssp

The higher quality screencast can be found here or the youtube version: