Retrieving values of Managed Properties in SharePoint 2013 Search REST API

Having just spent the best part of a day trying to figure out how to query values of Managed Properties within a SharePoint 2013 App using the new Search REST API, I thought I would share with you how it’s done.

There is a real lack of decent MSDN documentation at the moment (especially around the search REST API – the word ‘search’ is mentioned three times in three pages of documentation!) and there aren’t many blog posts as people are only just getting started with SP2013. Over the coming few months I expect we’ll see much more content published by SharePoint MVPs and bloggers.

I did find one decent blog post by Nadeem Ishqair which lists the Query Parameters available for the query endpoint in the Search REST API.

One thing tripped me up though, in the above blog post it says that when using the selectproperties parameter to retrieve managed properties the ‘Retrievable’ flag must be set to true in the Search Schema.

“Specifies the list of managed properties to return for each search result item. For a managed property to be returned; the Retrievable flag must be set to “true” in the Search Schema.”

Whilst this is true you also need to set the ‘Searchable’ flag to true otherwise the result will come back as null in the query. In the below example I am using the following query to get the value of the WorkPhone Managed Property from a Contacts list –

http://app-b425a64b04c315.apps.mydomain/sites/devsite/myapp/_api/search/query?querytext=’intelligent’&selectproperties=’WorkPhone’

Observe how the value of the WorkPhone property comes back as null.

SP2013 Search Rest API Results

Now go to the Search Schema, find the Managed Property and tick the Searchable box –

SP2013 Search Schema

Run and incremental crawl and then re-execute the query, observe that now we get a value back.

SP2013 Search Rest API Results

Hope that helps someone, I’m glad to have this problem fixed – now on to the next thing, trying to set that searchable flag using the Javascript Client OM!!

0  

SharePoint 2013–retrieving the lookup value of User fields using the REST API

I’ve been stuck on an issue for a while trying to retrieve the value of a User field using the SharePoint 2013 REST API.

The MSDN documentation is less than helpful and offers this advice for retrieving the value of lookup fields using REST –

In addition, you can specify that the request returns projected fields from other lists and the values of lookups. To do this, specify the field name in both the $select and $expand query options. For example:

http://server/site/_api/web/lists(‘guid’)/Products?$select=Title,Products/Name&$expand=Products/Name

It seems less than clear to me what you need to specify in the $select and $expand parameters!

Doing a bit of googling turned up nothing, surely someone has worked with the REST API in SharePoint 2013?!

If you simply select all fields from the list in your REST query you will find that your field does come back but instead the name will have ‘Id’ appended to it e.g ‘fieldnameId’ and it’s value will be the users’ id in the User Information List.

So what’s the fix I hear you cry?? Well it turns out this is the syntax you need to use in your REST query:

http://server/site/_api/lists/getbytitle(‘My List’)/items/$?select=Title,MyUserField/Name&$expand=MyUserField/Name

  • MyUserField is the name of my User field and Name is the target field in the User Information List. This syntax basically tells the OData property to expand the results for MyUserField to include the value of the Name field.
  • The User Field will come back as a new object which you can interrogate and there you will see the Name property.

Untitled

Hope this helps!

0  

SharePoint 2013 ‘SharePoint Hosted’ App Permissions

It turns out this SharePoint 2013 dev malarkey is actually pretty good! I’m working on a SharePoint hosted app at the moment which queries the User Profile Service using SP.UserProfiles.js. It’s nice to see that we have a decent javascript API to use now when querying user profiles.

Anyhow my code was failing when trying to retrieve a User Profile Property with the following exception –

Access denied. You do not have permission to perform this action or access this resource.

It turns out the AppManifest.xml is the key, in here you can set Permission requests that your App will be able to perform e.g. read from the current web, write to the Taxonomy service etc. In my case I hadn’t set the read permission for the User Profile service.

Permission requests

Once I had set this up. hey presto it worked!!

1  

Failed to install App for SharePoint error when provisioning Lookup columns

I came across this error today while trying to provision some lookup columns as part of a SharePoint 2013 App I was creating. It seems in 2013 you can provision lookup columns declaratively in the Elements XML – this is great news! In 2010 you had to do a sort of halfway house with a combination of XML and some C# code to wire the column up.

The XML I was using for the lookup column was -

<Field
 ID="{87217691-FA03-4178-8823-DA9626F89FFF}"
 Type="Lookup"
 Name="TestLookup"
 DisplayName="Test Lookup"
 Required="TRUE"></Field>

It seems you will only see this error when a – you haven’t wired up the lookup column declaratively and b – the column is being provisioned as part of a list – either through the use of a Content Type or otherwise.

Failed to install app For SharePoint

Of course the first thing I did was to check the logs in the 15 hive, the message that appears in here is rather spurious –

Possible mismatch between the reported error with code = 0×81070504 and message: “There is no Web named “/mytestapp”.” and the returned error with code 0×80070002.    36714239-fd6e-47c8-b7d5-b5577627c58e

This seems to be referring to the appweburl which of course doesn’t exist until the app has been deployed by Visual Studio. Anyhow once I correctly wired up the lookup columns to their relevant lists the error disappeared and my app deployed. The correct XML to declaratively wire-up a lookup column is as follows -

<Field
 ID="{87217691-FA03-4178-8823-DA9626F89FFF}"
 Type="Lookup"
 Name="TestLookup"
 DisplayName="Test Lookup"
 List="Lists/Test"
 ShowField="Title"
 Required="TRUE"></Field>

Looks like I’m in for a world of pain with SharePoint 2013 development – these sandbox errors are even worse than the ones in 2010!

0  

Enabling SharePoint 2013 ‘Apps’

After installing and configuring SharePoint 2013, if you try to visit the SharePoint App Store you will notice a warning message ‘Sorry, apps are turned off. If you know who runs the server, tell them to enable apps.”. Well lucky for us, we run this server so it’s time to configure it to run Apps or Crapps (@jimmywim).

SharePoint App Store

I thought it would be as simple as creating an App Management Service Application and starting the service but alas sadly not.

Basically SharePoint apps can be deployed in three ways -

- Provider-hosted (Developer or IT department provides the hosting infrastructure)
- Autohosted (Uses Windows Azure or SQL Azure for hosting)
- SharePoint-hosted (Hosted inside existing SharePoint infrastructure)

In order to install an App from the App Store you must setup an isolated App Domain, this is because Apps from the store deploy to their own app domain and run under a separate process from your SharePoint sites. If your SharePoint site uses the DNS alias http://sharepoint.contoso.com you could have *.apps.contoso.com as your app domain. I’m going to walkthrough the process required to set-up your environment for Apps but at a high level, if you need more details for each step then head on over to the MSDN documentation.

Follow the steps below to setup your environment for Apps:

1. Start the App Management Service from Services on Server
2. Provision an App Management Service Application (You can use the UI for this)
3. Create a subdomain domain in DNS – e.g. *.apps.contoso.com. You can either create a subdomain or a new domain to host your apps. I’ll leave that choice up to you. Make sure that when setting up the subdomain in a multi-server environment you set the FQDN of the target host to be your SharePoint 2013 box.
4. Set your isloated App Domain by running this command:

Set-SPAppDomain -AppDomain "apps.contoso.com"

5. Start the SPSubscriptionSettings Service by running the following PowerShell command:

Get-SPServiceInstance | where{$_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"} | Start-SPServiceInstance

6. Ensure the App Management Service and SPSubscriptionSettings Services are online by running this command:

Get-SPServiceInstance | where{$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"}

7. Provision a Subscription Settings Service Application (You will need to use PowerShell for this as it can’t be created through the UI). In my example below I am using the same Application Pool I created for the App Management Service Application.

$appPool = Get-SPServiceApplicationPool "SharePoint Service AppPool"$appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool
$appPool –Name "Subscription Settings Service Application" –DatabaseName Settings_Service
$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc 

8. Visit the Manage Service Applications page in Central Admin and verify that both the App Management Service App and Subscriptions Settings Service App are provisioned and started.
SharePoint 2013 Service Apps List
9. The next thing to do is create an App Catalog. This is essentially a Document Library which is hosted within a separate Site Collection. Choose Apps > Manage App Catalog from Central Admin.
10. Select your Web Application and ensure ‘Create a new app catalog site’ is checked and click OK.
11. Fill in the details for your App Catalog Site and click OK to create it.
12. Nearly there! now we need to configure the App URLs. Select configure App URLs in the Apps section of Central Admin. Enter your App domain you setup earlier (apps.contoso.com) and for the App prefix enter ‘app’.
13. *Important – please note that if you are using Host Headers for your Web Application then you will need to create a new Web Application on port 80 that doesn’t use Host Headers. This Web App must have a root site collection which can be of any template. If you don’t do this then when you try to click on an App you will be met with a 404 error. This is because SharePoint uses the site running on Port 80 to resolve the app url, this must be a SharePoint site so the Default Web Site won’t work.  Once you have created the Web Application and blank Site Collection do an IISRESET just to be sure. For more details on this check out Mirjam’s post here.
14. Done! your environment is now configured for Apps. Now when you navigate to your Site Collection and browse to the SharePoint Store you will notice that the warning/error message has disappeared. Try downloading the Facebook Integration App and see how you get on.
15. Grab a brew and congratulate yourself on a job well done!

Here are a few screenshots of the process when adding an App -
Facebook Integration App

Adding App to SharePoint

New App

0  

Converting a List Workflow to a Re-usable Workflow

Recently I had the task of converting a bunch of SharePoint 2010 list workflows to re-usable workflows. I needed a way to copy the workflows and assign them to a new list I had created. First I thought I could just export the workflow to Visio, re-import it and it would prompt me to attach it to a list. Sadly this is not the case, when you re-import it simply replaces the old workflow and remains attached to the same list.

Thankfully @ScoutmanPt came to the rescue on Twitter.

The key here is that you need to delete the wfconfig.xml file to get SharePoint Designer to prompt you for a list.

Follow the steps below to successfully convert a list workflow to a re-usable one -

1. Export the workflow to Visio by clicking ‘Export to Visio’ on the ribbon.

SPD Workflow Export to Visio

2. Open the exported .vwi file with 7-Zip or similar and delete the workflow.xoml.wfconfig.xml file.

3. Import the .vwi file into SPD using the ‘Import from Visio’ option on the ribbon.

4. You will now be prompted to enter a workflow name and choose to attach the workflow to a list to create a re-usable workflow.

SPD Import Workflow from Visio Drawing

5. Enjoy your new re-usable workflow!

0  

SharePoint 2013 Configuration Wizard Error ‘maxdegree of parellelism’

When trying to configure SharePoint 2013 on SQL Server 2012 I got the following error – ‘This SQL Server Instance does not have the required maxdegree of parellism setting of 1’

It turns out this is a simple fix, just run the following SQL script to set the ‘maxdegree of parellism’ setting to the required value of 1 -

sp_configure 'show advanced options', 1; 
GO 
RECONFIGURE WITH OVERRIDE; 
GO 
sp_configure 'max degree of parallelism', 1; 
GO 
RECONFIGURE WITH OVERRIDE; 
GO

You will need to login with an account that has the appropriate SQL permissions to do this, the SharePoint installation account won’t suffice. After you have changed the setting, delete the config database and re-run the wizard.

Hope this helps!

0  

Microsoft has just announced SharePoint 2013!

In case you have been living under a rock, Microsoft has just announced the next version of SharePoint (SharePoint 2013). They have also unveiled the new ‘Metro’ style version of Office (Office 2013) which runs using the software-as-a-service model.

You can download SharePoint 2013 Server and Foundation flavours and Office 2013 from here, be patient though as TechNet is taking an absolute beating at the moment!

Microsoft Download Center

If you can’t find a link to SP2013 above then use this direct link –

SharePoint 2013 Download

0  

Content Type SPI bug in SharePoint Sandbox Solutions

I seem to have come across what I believe to be a bug when with Content Types in SharePoint 2010 Sandbox Solutions. I believe this bug to be caused by Visual Studio but I haven’t been able to confirm this yet. The issue arises when you provision a Content Type on a list definition declaratively, when I say declaratively I mean include the ContentTypeRef  Element in the List Definition Schema.xml. You cannot enable Content Types on a list declaratively so I am using some code in the FeatureActivated event to do this.

When the solution is deployed the Content Type will be correctly provisioned on the list but it will have the same name as the list and it will inherit from System rather than Item or whichever parent Content Type it should inherit from.

Originally I thought it was an issue with my environment so I recreated a fresh SharePoint farm on a Virtual Machine and the issue still exists. My environment is setup as follows:

  • Windows Server 2008 R2 64-bit SP1
  • SQL 2008 R2 64-bit
  • SharePoint 2010 SP1 (14.0.6029.1000)
  • Visual Studio 2010 SP1

To reproduce this issue follow the steps below:

  1. Create a new Empty SharePoint Project (Sandboxed Solution)
  2. Add a Content Type SPI to the project inheriting from Item
  3. Add a new List Definition to the project (Custom List) and choose to add a List Instance
  4. Add the DisallowContentTypes=”FALSE”tag to the Elements.xml for the list
  5. Add the EnableContentTypes=”TRUE” tag to the List Definition Schema.xml
  6. Remove all ContentTypeRefElements from the Schema.xml
  7. Add a ContentTypeRef Element for the Content Type created above to the <ContentTypes>Element
  8. Create a Feature Receiver and add code into the FeatureActivatedevent to enable Content Types on the list
  9. Deploy the solution

Observe that on visiting the List Settings page for the list that the Content Type has been added but has the wrong name (same name as the list) and inherits from System and not Item.

List Settings page

List Content Type Information

I would be grateful if someone can confirm whether or not this is a bug, by design or something that is not supported in Sandbox solutions.

You can obtain the Visual Studio project containing the code that I have created to replicate this issue here.

Thanks! Open-mouthed smile

2  

Debugging SharePoint 2007 Customer Timer Jobs–The easy way

When debugging your custom SharePoint 2007 Timer Jobs you don’t necessarily need to attach to the OWSTimer process. All the blogs and information I have found out there on the interwebs suggest two options

  1. Attach your Timer Job code to the OWSTimer process and then wait for the job to execute
  2. Create a Console Application with the below code and run it whilst your Timer Job project is attached  -
using (SPSite site = new SPSite("yoursharepointsiteurl"))
            {
                using (SPWeb web = site.OpenWeb())
                {
                    foreach (SPJobDefinition job in site.WebApplication.JobDefinitions)
                    {
                        if (job.Title == "Your Job Name")
                        {
                            job.Execute(Guid.Empty);
                        }
                    }

                }
            }

However I have had trouble getting the second option to work. For me when I let my Console Application run, the job doesn’t seem to execute and the breakpoints in my attached code don’t get hit.

Actually the EASIEST way is to place a breakpoint on the job.Execute line and then step in to the Execute method, this will actually step in to your Timer Job code and hit your breakpoints. However in order for it to step in to the code correctly you will need to have your Timer Job project open in a separate Visual Studio window/instance.

Hope this helps!

0