SharePoint Saturday Canberra 2012

I had the pleasure of presenting REST services and AJAX at Canberra again.  It was a fun and sunny day that started at 4am in the morning, and packing a sleeping mr4 into the car and drive down.  Mr4 and my wife went to see the Cockington Miniature Gardens for the day, leaving me to geek out with fellow crazy SharePoint Saturday-ers.

As promised, there are a number of links:

• The demo solution https://static1.squarespace.com/static/5527bff2e4b0b430660b0d10/5527c30de4b030eeeef09715/5527c30fe4b030eeeef09e8a/1316868647487/SPGSvcWp.zip
• The powerpoint https://static1.squarespace.com/static/5527bff2e4b0b430660b0d10/5527c30de4b030eeeef09715/5527c30fe4b030eeeef09e8b/1344213437847/SharePoint+REST+and+jQuery6.pptx

Some of the comparisons I've made in the talk:

• In SharePoint 2013, Microsoft wants you to use the services to talk to SharePoint, either via the Client Object Model, or via JavaScript and REST.  They also provide a whole lot of service endpoints for you to use:
• /_vti_bin/listdata.svc
• /_vti_bin/*.asmx
• /_api/
• In SharePoint 2010, you don't have nearly as many service end points, nor all the capabilities, but you can build custom services (which BTW, will still work in 2013).  So if you want to future-proof your solutions it is good to start thinking about implementing services and keeping the Javascript UI tier separate from the underlying services.
• In the SharePoint 2013 Azure Workflow model, you can't deploy workflow actions.  But you are given an out of the box action that will let you call web services.  So building custom services is still a good way going forward to implement functionality that you can then reuse.
• Re-use everywhere:
• InfoPath
• Workflow Web Request action
• JavaScript AJAX

SharePoint - showing Contacts in People Search results

Scenario:

• You have a working and functioning People Search page, and it's used to show information (and lovely photos) of your employees and acting as a very capable office phone book.
• HR now wants to add more people to the list, people that, for some reason (may be they are kiosk workers, or external contractors), don't have an Active Directory account.  The phantom people.

Solution:

• Create a standard SharePoint Contacts list
• Include this list as part of the People search scope
• Configure Search Metadata Properties to bring across the correct Site Columns, ultimately, showing both Real users and Contacts from Contact List in the same People Search results.

Create a contact list

The Contact list doesn't come with a Contact Photo by default, we should add one

• Go into List Settings, enable Manage Content Types
• Go into the Contact content type
• Add Site Column "Contact Photo" - this is an out of the box column, don't create your own Site Column
  
  
• Check you've added the right Site Column, the internal name should be:
  http://server/_layouts/ManageContentTypeField.aspx?ctype=0x010600D07645B29A88F34C98B3FE05BEB3478E&Field=Contact%5Fx0020%5FPhoto
• It should be "Contact_x0020_Photo", this is important later in search properties.
• Add an item in the contact list
  
  

Configuring Search

• Create a new Search Scope "Humans"
  
  
  
• Add rules, in addition to the rule to include People, which is "contentclass = urn:content-class:SPSPeople"
  Add rule to also include Folder = http://server/Lists/Contacts
  
  
  
• You'll need to do a full crawl, which will pick up the Contact list, this will also pick up a crawled property for Contact_x0020_Photo
• Then update the Scopes

Configure Search Page

• Configure the Search Page
  • Change People Search Core Results webpart:
  • Scope: humans
  • Use Location Visualization: untick
  • Append Text To Query: scope:humans 
    (this allows your search results to show the first 20 people always, even when no query is specified)

Your search results should begin to show something, but it's not right:

• Some fields are mapped automatically, here, the Job Title, Company, WorkPhone and Email fields have come across.  We're missing two significant ones

Configure Search Metadata Properties

• Fix PreferredName
  
  
  
  Add both "ows_FullName(Text) and ows_Full_x0020_Name(Text)
  Tick "Include values from all crawled properties mapped
  
• PictureUrl
  
  
  
  Add ows_Contact_x0020_Photo(Text)
  Tick Include values from all crawled properties mapped
  
• Full crawl again.

The End result

Real users and Contact list entries displayed together in the search results!

SharePoint - The object has been updated by another user since it was last fetched - while updating Site Columns

This is the second time I've been bitten by this error.

Exception:

The object has been updated by another user since it was last fetched

And both times I had forgotten why, and then panicked, then searched online, found articles talking about this, and figured it all out, only to recall in the last minute...

Hey, wait a minute, this happened before.

The story begins as soon as you are trying to update your site columns.  Either via the web UI, or via code, or via PowerShell.  And then you hit this error.

The cause:

This is most likely because you've created the site column using an invalid Schema XML, in particular, you've embedded the version field in the <Field> definition.

<Field Type="Text" DisplayName="OrganisationName" Required="FALSE" EnforceUniqueValues="FALSE" Indexed="FALSE" MaxLength="255" ID="{guid-xxx}" StaticName="OrganisationName" Name="OrganisationName" Version="1" ></Field>

The Version attribute could have got in via a number of means, but most likely you exported the existing Schema from somewhere and it got embedded.

My explanation:

When you update a site column, SharePoint expects that the version number of this site column object increments after the update.  But because you are updating the site column via Schema and forcing the version to be fixed all the time, that number doesn't increment.  SharePoint now thinks there's something really wrong.

The Fix:

Remove the Version attribute from the Field definition, and then redeploy that definition to the server.

<Field Type="Text" DisplayName="OrganisationName" Required="FALSE" EnforceUniqueValues="FALSE" Indexed="FALSE" MaxLength="255" ID="{guid-xxx}" StaticName="OrganisationName" Name="OrganisationName" ></Field>

SharePoint Saturday Melbourne 2012

I had a great time in Melbourne and presented my session on Building Custom REST services and consuming them with jQuery AJAX.  Thank you for attending my session and listen to me ranting for an hour.

As promised, there are a number of links:

• The demo solution https://static1.squarespace.com/static/5527bff2e4b0b430660b0d10/5527c30de4b030eeeef09715/5527c30fe4b030eeeef0a174/1316868647487/SPGSvcWp.zip 
• The powerpoint https://static1.squarespace.com/static/5527bff2e4b0b430660b0d10/5527c30de4b030eeeef09715/5527c30fe4b030eeeef0a175/1344213437847/SharePoint+REST+and+jQuery6.pptx

There are a few things I missed:

On 2007, you can't easily deploy WCF or REST services to a 2007 installation.  But you can still use Javascript to talk to SharePoint 2007's built in WCF services.  Check:

• http://spservices.codeplex.com

For 2013, the WCF/REST solutions work fine.  I had a quick test and took some screenshots.

• /blog/2012/7/30/sp2013-custom-services-deploys-and-runs-on-v15.html

For DataService (ADO.NET / exposing Entity Framework via REST service), see the last feature in the demo project.

Drop me a comment if you want to ask me about anything specific and I'd love to geek out!

T: @johnnliu

E: john.liu at sharepointgurus.net

SP2013 Custom services deploys and runs on v15

I fired up my SP2013 VM to do some simple tests tonight, I wanted to know if the REST services that I've built and demo'ed for SharePoint 2010 would run in SP2013.  Technically, they should.

So I deployed:

• stsadm -o addsolution -filename .\SPGSvcWp.wsp
• stsadm -o deploysolution -name SPGSvcWp.wsp -local -allowgacdeployment -allcontenturls

The files are copied to the services OK.

Deployed to ISAPI folder (_vti_bin)

DataService

REST service

SOAP service

Activate the features for the webpart:

Add the Web Part to the page:

The javascript needs a small modification - since the page in 2013 is loaded asynchronously.  But once I've re-attached the click event, the REST service itself works fine and returns the properties of the selected item.