Monthly Archives: July 2016

Content Search Web Part – Data Crawling Issue in SharePoint 2013

A very interesting feature that has been introduced in SharePoint 2013 is – “Content Search web-part (CSWP)” which purely depends on search index and search crawling mechanism. In other words, once you add data in list or library , it will not be reflected instantly, instead it might take 15-60 minutes to reflect the data, based on search crawling.

Content Search web part is available as out-of-the-box (OOTB) web-part in “Content Roll-up” category which you can use to show data from various sites or sub-sites, on your application landing page. It gives us the option to search data from Current Site or Site Collection. Also, we can specify a URL to get the data from.

In my case, I was working on a SharePoint Online project (Office 365), where I want to roll-up & roll-down data from 300 sub-sites. I decided to use CSWP, because using jQuery or Client side object model, it would be tedious to get the data from such sub-sites. (Remember in server side object model, we used to have SPSiteDataQuery API)

While working and playing around with CSWP, we created Search Managed properties based on crawled properties for specific list/library columns and our CSWP queries were all based on Content Types. Initially, my understanding was that the moment I created managed properties, I can use them in CSWP queries. But that was not happening. 😦 and data was not appearing as CSWP Search results. I also contacted Microsoft for this issue, and they said that it may take time to crawl the data depending on the last search crawl.

Then I found two important aspects of CSWP and Managed properties. –

  • In site settings, there is a option – “Search and Offline availability” where you can “Reindex site”. This option helps in re-indexing of the site and will take your site little up the next time SharePoint will start crawling the data.
  • Since the managed property was not showing in CSWP queries, and was not showing the results – I added some data in list and you know what – Managed property shown up !!! Hurray :). This suggests that if you add data in list/library and search for managed property, it will show up.

Getting Lookup Type field in REST API SharePoint 2013

In my previous post, I wrote about – “Getting Person or group type field in REST API” –  . In this post, I will be explaining about using Lookup field in REST API.

Analyze the below code:-

var ddEventType;
ddEventType = $(‘select[title=”Events Type Required Field”]’).children(“option”).filter(“:selected”).text();
$(‘select[title=”Events Type Required Field”]’).on(‘change’, function(e) {
ddEventType = $(‘select[title=”Events Type Required Field”]’).children(“option”).filter(“:selected”).text();
});//End of Doc ready
function GetddlValues(ddlValue){
SP.SOD.executeFunc(“sp.js”, “SP.ClientContext”, function() {
SP.SOD.executeFunc(“sp.runtime.js”, “SP.ClientContext”, function() {
var queryUrl = “<server_url>” + “/_api/web/lists/getbytitle(‘Event Category’)/items?$expand=Events_x0020_Type&$select=Id,Events_x0020_Type/Title,Events_x0020_Type/Id,Title
&$orderby=Title asc&$filter=Events_x0020_Type/Title eq ‘” + ddlValue + “‘”;
url: queryUrl,
method: “GET”,
headers: {
“Accept”: “application/json; odata=verbose”
success: onQuerySuccess,
error: onQueryError
function onQuerySuccess(data) {
$(‘select[title=”Events Category Required Field”]’).empty();
var userEntry = [];
var results = data.d.results;
$.each(results, function(index,dataRec) {
});//End of push
//alert(“In each userEntry”+ JSON.stringify(userEntry));
});//End of each
for(var j=0;j<userEntry.length;j++){
$(‘select[title=”Events Category Required Field”]’).append($(”, { value: userEntry[j].id,text : userEntry[j].name}));
}//End of for
}//End of onQuerySuccess
function onQueryError(error) {
}//End of onQueryError

In the above code, Event Type is a Lookup column. The most important point to consider here is how to save/append options in the drop-down.

Hope this helps. 🙂

Getting Person or Group Type field in REST API SharePoint 2013

Today, while working on a project, came across an interesting fact about REST API. I had a list having columns as Employee Name, Job Title, Department and Description. Their types were Person or Group, Single line of text, Single line of text and multiple lines of text respectively.

The general URL in REST API to query data from list is:-

WRONG WAY – /_api/web/lists/getbytitle(listname)/items?$select=Employee Name,JobTitle,Department,Description.

This is wrong, because Employee Name is a Person or Group type column and you cannot use it in select parameter. For that you must use – “expand” like below in your URL:-

RIGHT WAY – /_api/web/lists/getbytitle(listname)/items?$select=JobTitle,Department,Description,EmployeeName/FirstName,EmployeeName/LastName

Noticed Above ?? In above REST URL, I have used “EmployeeName/ID” in expand parameter and then you can access all user properties with select parameter like FirstName, LastName, EMail, UserName,Department,Name,JobTitle etc.

Please remember, if you want to use other User Properties, appropriate names should be given. (For E.g. – for getting email of the user, do not use WorkEmail or Email. instead use EMail – capital M 🙂 )