Microsoft acquistion of LinkedIn News!

In my opinion great move by Microsoft:

http://www.wsj.com/articles/microsoft-to-acquire-linkedin-in-deal-valued-at-26-2-billion-1465821523

Question is how or if this will impact SharePoint 2016 and Office 365?  There are obviously potential integration opportunities between both platforms.

LinkedIn established as the social networking platform of choice for professionals world-wide and it’s large member base.  For enterprises an opportunity to move to the MSFT cloud for recruiting, task management, organization contacts, etc. with an established professional social network LinkedIn and the associated features and benefits.

For Microsoft conceivable this move will cause organizations on the fence to consider  a move to Office 365 verses other platforms.  Compelling to combine the social networking features of LinkedIn with the collaboration features of Office 365, SharePoint Online, PowerView Business Intelligence, and Outlook Online verses the competition out there.  Have to wait and watch for the availability of APIs for integration into applications and services on premises, Azure hosted, SharePoint or Office 365.

SharePoint Lists-Smarter with JavaScript

SharePoint lists are great for tracking data-easy to create, export to Excel, develop against using JSOM.  Problem is when you have a list sometimes you have documents that are associated with the list item.  There are attachments to the list but better to use a document library right?  Maybe create a folder in the document library for each new list item created and tag the folder for the specific folder associating the item to the folder.

Here is where some simple JavaScript and the SharePoint JSOM come in to save the day…

Step 1: Create your SharePoint list, add your fields, etc.

Step 2: Create a new item, when the newform.aspx opens simply select Edit Page from settings.  Settings-Edit page.  Now you can place a content editor web part referencing your script file.

Screenshot (Standard NewForm.aspx un-customized)

SPLISTFORM

Also, add a document library web part to display the folders we are going to create from the script and filter for your specific list item using the web part connection from the list item web part to the document library web part.

Add any other web parts to the page, calendar, tasks lists etc.  This provides a simple all up view for related content tagged to the list item.

Add a content editor web-part or script editor web part referencing your script file (I typically organize conveniently in the site collections style library)

Example script:
//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js

//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js

var matterName;
var matterNum;
var folderName;
var collListItem;
var folderUrl ;
var folderpath;

//Execute when the user saves the item create a folder in our document library and tag the folder with relevant data from our list item in order to associate the two
function PreSaveItem()
{

//grab some fields off the newform.aspx to use for tagging the folder we create
matterNum = $(‘input[title=”MatterNum”]’).val();
matterName = $(‘input[title=”Name”]’).val();

//Create the folder

folderName = matterName;
folderUrl = “[SiteUrl]” + “/” + folderName;

createFolder(folderUrl, folderName, matterNum);

return true;
}
function createFolder(folderUrl, fname, matterNumber) {

var clientContext;
var oWebsite;
var oList;
var itemCreateInfo;

clientContext = new SP.ClientContext.get_current();
oWebsite = clientContext.get_web();
oList = oWebsite.get_lists().getByTitle(“Documents”);

itemCreateInfo = new SP.ListItemCreationInformation();
itemCreateInfo.set_underlyingObjectType(SP.FileSystemObjectType.folder);
itemCreateInfo.set_leafName(folderName);
//I am using a specific content type inherited from the folder type
this.oListItem = oList.addItem(itemCreateInfo);
this.oListItem.set_item(“ContentTypeId”, “0x0120003C4F41AA23709B458E3DA2EEFAA5DCAA”);
this.oListItem.set_item(“Title”, fname);
this.oListItem.set_item(“MatterNum”, matterNumber);
this.oListItem.update();
clientContext.load(this.oListItem);
clientContext.executeQueryAsync(
Function.createDelegate(this, successHandler),
Function.createDelegate(this, errorHandler)
);
}
function successHandler() {

//Yeah have a new folder

}

function errorHandler(sender, args) {
alert(‘Record Create failed. ‘ + args.get_message() + ‘\n’ + args.get_stackTrace());
}

//TO DO-This part for next time-build out a complete folder structure based on a pre-built document libary structure
function retrieveFolderStructure() {
var _clientContext1;
_clientContext1 = SP.ClientContext.get_current();
var oList = _clientContext1.get_web().get_lists().getByTitle(‘Matter Documents’);

var camlQuery = new SP.CamlQuery();
camlQuery.set_viewXml(“500”);

this.collListItem = oList.getItems(camlQuery);

_clientContext1.load(collListItem);

_clientContext1.executeQueryAsync(Function.createDelegate(this, this.onQuerySucceeded2), Function.createDelegate(this, this.onQueryFailed2));

}

 

Summary:

Make your SharePoint lists a little smarter.  Why not?  Of course all this works on SharePoint 2013 and Office 365.  Also can use on editform.aspx, the script to access the form fields slightly different but doable np.

Bonus material:

Add a calculated column to your SharePoint list that links users to the specific folder:

=”<a class=’docs’ title=’Documents’ href=”&”‘”&”/[Site]/Shared Documents/Forms/AllItems.aspx?RootFolder=/[Site]/Shared Documents/”&Name&”‘”&”>Documents</a>”

*Set your column format to “number” so displays HTML

 

SharePoint 2013-Create User Profiles from BCS External List using PowerShell

Overview:
We have an internal identity management system that stores and manages identities and custom properties for all employees.  As part of a recent project designed a solution to populate our SharePoint user profile store using information stored about each user in our custom indentity management system.

Alternatives:
We evaluated the Active Directory Import and User Profile Synchronization as well.  The Active Directory Import supports LDAP sources for profiles and although can be configured to import from BCS external list does not actually create user profiles based on that data, rather can populate additional properties for AD user profiles that already exist.  In our case those user profiles do not exist since we are not able to use AD import or profile sync in this environment.

Solution steps::

Step 1:
Configure SharePoint 2013 Secure Store Service and Business Connectivity Services

Step 2:
Configure an external content type and external list in SharePoint Designer 2013 with full CRUD operations enabled bound to a custom database table in SQL where identities are stored.

Note: The external list provides full CRUD operations on the external list to the SQL database table.  This is a key additional feature over a standard SharePoint list which was useful in our case having the option of querying and perform updates to the external list directly from our custom admin form via JavaScript and the SharePoint REST API.

This could be interesting for other use cases as well where updating a custom SQL database table from a SharePoint list is usefull i.e. AngularJS or REACT UI user-interface integrated with SharePoint list data via REST.  Exploring more on this front soon.

Step 3:
Develop PowerShell script to query the SharePoint external list, for each item check for existing profiles in SharePoint, and if none exist create a new profle populated with the data in the external list item for each user.

Example PowerShell script:

#Rod Stagg

#Create SharePoint User Profiles based on data in External List (BCS)

[CmdletBinding()]
Param(
[Parameter(Mandatory=$True)]
[System.String]$siteUrl,
[Parameter(Mandatory=$True)]
[System.String]$listSiteUrl,
[Parameter(Mandatory=$True)]
[System.String]$domain,
[Parameter(Mandatory=$True)]
[System.String]$user
)

Remove-PSSnapin Microsoft.SharePoint.Powershell -ErrorAction SilentlyContinue
Add-PSSnapin Microsoft.SharePoint.Powershell

$claimsformat = “i:0#.w|”;
$accountName = “”;
$fullname = “”;
$lastfirst = “”;
$firstname = “”;
$lastname = “”;

$Web = Get-SPWeb $listSiteUrl
$SourceList = $Web.Lists[“External List”]
$SourceItems = $SourceList.Items | where {$_[‘networkid’] -ne “”}
$site = Get-SPSite $siteUrl
$context = Get-SPServiceContext($site)
$profilemanager = new-object Microsoft.Office.Server.UserProfiles.UserProfileManager($context)
$SourceItems | ForEach-Object {
# Assumes account in domain\account format and networkid field is the unique identifier on external list
$accountName = $claimsformat + $domain + “\” + $_[‘networkid’]
# Assumes username stored as lastname, firstname on external list so split
$lastfirst = $_[‘lastfirst’];
$firstname = $lastfirst -split “,”
Write-Host $firstname[1];
Write-Host $firstname[0];
Write-Host $accountName;
# If user profile doesn’t exist create new one
if ($profilemanager.UserExists($accountName)) {
$userProfile = $profilemanager.GetUserProfile($accountName)
}
else {
$userProfile = $profilemanager.CreateUserProfile($accountName)
}

# Update any necessary user profile properties
$userProfile[“FirstName”].Value = $firstname[1]
$userProfile[“LastName”].Value = $firstname[0]
# Commit changes
$userProfile.Commit()

}

Additional elements of entire solution:

  • SSIS population of SQL database table that is bound to the SharePoint 2013 external list.
  • Windows schedule task to execute PowerShell script on
  • JavaScript to update the external list from our custom form.

 

SharePoint 2013 and AngularJS perform CRUD operations in multiple site collections with REST

SharePoint 2013 and AngularJS-performing CRUD operations in multiple site collections with REST

Overview:

This post covers a specific scenario with SharePoint 2013 and AngularJS (or other javascript framework) to host HTML and JavaScript in one site collection that create/update SharePoint list items that reside in a completely different site collection, and doing so without using SharePoint Hosted Apps.

If you are using AngularJS/SharePoint 2013 in a project that requires both querying AND updating data stored in lists that reside in a separate site collection than where the AngularJS app files are hosted than you may want to read on.

Issue:

The app files are stored at the root of the web application while the data is distributed to separate site collections and team sites for each organization and individual teams. This structure provides a mechanism to distribute the data surfaced in the AngularJS UI using SharePoint to provide the necessary security trimming of the data at each level of the organization.  Using SharePoint for the backend data and security and structuring the information architecture in this manner was designed to eliminate the need to manage user permissions as part of the custom application.

In SharePoint 2013 hosted apps the ability to query and update list items dispersed among multiple site collections is provided by scoping the SharePoint app to tenant and using the SP.RequestExecutor to make the REST calls (I covered in a recent post)

In this particular application however the decision was made not to go with a SharePoint hosted app until a solution could be developed to safely remove the app id from the URL.

Recently,  in fact just last week we ran into a blocking issue performing updates to lists that reside in a different site collection than were the AngularJS app files reside.  Once we rolled out the new site collection/team site structure the development team reported that the REST calls to perform updates to the list items were now all of a sudden returning an error. Curiously these identical REST calls functioned as expected when the data resided in the same site collection as the REST code and although errors now returned when performing updates the code was able to query the data in the separate site collection as expected.

Error:

The REST call to the _api/ContextInfo was failing with the message “the Method was not allowed and that it was using a GET but required a POST”  This was odd since the code was in fact using a POST, not a GET.

Solution:

When I first dug into the issue myself it occurred to me that maybe the form digest issue was the culprit. I reviewed the code being used to make the REST calls to update the data and it all appeared fine-very similar to documented examples from Jeremy Thake, Andrew Connell, and others.   Wictor Wilen has a well documented fix for the form digest issue on his blog but after reviewing against our existing code did not see any substantial difference that would explain why our code was failing.  The code in our specific application is slightly different since it uses promises but had similar characteristics to examples from other sources.

However I did notice our code was hard-coded to the root URL so I tried changing the call to use the URL to the site where the data resided rather than the root site collection.

Example:

FROM:

$.ajax({
    url: "/_api/contextinfo",
    method: "POST",
    headers: { "Accept": "application/json; odata=verbose"},
    success: function (data) {
        $('#__REQUESTDIGEST').val(data.d.GetContextWebInformation.FormDigestValue)
    },
    error: function (data, errorCode, errorMessage) {
        alert(errorMessage)
    }
});
TO:
$.ajax({
    url: /org/team/subteam/_api/contextinfo",
    method: "POST",
    headers: { "Accept": "application/json; odata=verbose"},
    success: function (data) {
        $('#__REQUESTDIGEST').val(data.d.GetContextWebInformation.FormDigestValue)
    },
    error: function (data, errorCode, errorMessage) {
        alert(errorMessage)
    }
});
Unfortunately this did not resolve the issue entirely-I did additional research along with trial and error to determine the root cause of the error.  Finally thought to read the comments on Wictor Wilens post on the form digest issue and there the solution presented itself in one of the comments-one line from a comment stood out that if you use Type: Post  rather than Method: Post the call will give you the $(‘#__REQUESTDIGEST’).val() rather than the object.  Sure enough, turned my chair around and asked the developer to give it a try.  IT WORKED!  So simple but seemed like a needle in the haystack on a day where this one issue was holding up deploying the app for our customer to test.  Seems obvious looking back, but like my grandma said hindsight is 20/20.
Root cause:
SharePoint requires the form digest for creating and updating items in separate site collections but not for querying items and our code was not accounting for providing the correct URL for the source data and was using method: POST rather than TYPE: POST when attempting to access the #_REQUESTDIGEST.val required for the post to execute successfully.

Resolution:
When creating or updating list items from javascript executed in a separate site collection than the SharePoint list resides AND you are not using a SharePoint Hosted App and SP.RequestExecutor ensure you set your REST call to use type: “POST” rather than method: POST AND  pass in the URL to the site where the data actually resides for the _api/contextinfo.

Updated example:

$.ajax({
    url: /org/team/subteam/_api/contextinfo",
    type: "POST",
    headers: { "Accept": "application/json; odata=verbose"},
    success: function (data) {
        $('#__REQUESTDIGEST').val(data.d.GetContextWebInformation.FormDigestValue)
    },
    error: function (data, errorCode, errorMessage) {
        alert(errorMessage)
    }
});
Guess its a good idea to read blog comments:)

Also, big props to Wictor Wilen for sharing great info and also to whoever posted this insightful comment on his blog that saved the day:

“it’s a great post, but one issue is coming with “method: ‘POST’ – which is it is throwing “The HTTP method ‘GET’ cannot be used to access the resource ‘GetContextWebInformation’. The operation type of the resource is specified as ‘Default’. Please use correct HTTP method to invoke the resource”.
 If we’ll use “type – ‘Post” rather than “method – ‘Post’, it will give you the $(‘#__REQUESTDIGEST’).val(). :)”

http://www.wictorwilen.se/sharepoint-2013-how-to-refresh-the-request-digest-value-in-javascript

Rod Stagg

 

TIP using SP.RequestExecutor to access data in SharePoint 2013 hosted apps with AngularJS cross domain

Background: In my current project developing a SharePoint 2013 hosted app where all the UI is developed in AngularJS presentation framework while using SharePoint host site collection and subsites for storing data in lists, security, version control, etc.  Convinced this is the best way to develop great UI in SharePoint after seeing the results of using AngularJS presentation framework for UI and SharePoint hosted app for the data.  There are a couple custom WCF services and also Node.js in the mix as well-very cool and the client very happy with the speed and responsiveness of the single page app.

In the process though, ran into a couple interesting aspects of accessing data from lists stored in both the SharePoint host site collection and subsites.  The few examples I found are from Jeremy Thake here and Andrew Connell here and recommend both since they are excellent.  But overall the web is a little sparse working with data in the host site collection/subsites using the SharePoint cross domain access via SP.RequestExecutor. The one I started from is a decent post on http://msdn.microsoft.com/en-us/library/office/fp179927%28v=office.15%29.aspx#SP15Accessdatafromremoteapp_Hostweb but there are few details when working with AngularJS routes had to work out in addition so sharing for those working on similar projects.

Tips for avoiding issues accessing SharePoint lists in the host site collection/subsites web in a SharePoint 2013 hosted app and angularJS routing.

TIP 1: Avoiding SP not defined issue: ensure the appurl passed to SP.RequestExector cross domain does not contain unacceptable characters in the url obtained from the querystring parameters.

One example being the angularJS “#/” that can get appended to the SPAppWebURL in the querystring

One slightly frustrating issue easy to miss was with the appweburl used by SP.RequestExecutor. Watch out for the SPAppWebURL obtained from the querystring when using SharePoint cross-domain access and AngularJS routes. If SP.Requestor sees the “#/” you may get an error displayed in FireFox as “SP not defined“.

Example URL:
http://app-33fd23755c4644.apps.smartek21:20982/AmazonRodUpdates/Pages/app.html?SPHostUrl=http%3A%2F%2Fwin-6viq5heh7nd%3A20982&SPLanguage=en-US&SPClientTag=0&SPProductNumber=15.0.4569.1000&amp;SPAppWebUrl=http%3A%2F%2Fapp-33fd23755c4644.apps.smartek21%3A20982%2FAmazonRodUpdates#/goals

Removing the “#/” from the appweburl is one way to resolve this issue.

appweburl = decodeURIComponent(getQueryStringParameter(“SPAppWebUrl”)).split(“#/”)[0];

//Get the URI decoded URLs.
hostweburl = decodeURIComponent(getQueryStringParameter(“SPHostUrl”));
//appweburl = decodeURIComponent(getQueryStringParameter(“SPAppWebUrl”));
appweburl = decodeURIComponent(getQueryStringParameter(“SPAppWebUrl”)).split(“#/”)[0];
var scriptbase = hostweburl + “/_layouts/15/”;

// Load the js files and continue to the successHandler

$.getScript(scriptbase + “SP.RequestExecutor.js”, loadUser);

function getQueryStringParameter(paramToRetrieve) {
var params =
document.URL.split(“?”)[1].split(“&”);
var strParams = “”;
for (var i = 0; i < params.length; i = i + 1) {
var singleParam = params[i].split(“=”);
if (singleParam[0] == paramToRetrieve)
return singleParam[1];
}
}

TIP 2: Avoiding scoping issues: ensure you set the proper scope for accessing SharePoint list data in subsites and/or cross site collections

When accessing lists stored in subsites in the host web set the scope to tenant in AppManifest/xml

<AppPermissionRequests>
<AppPermissionRequest Scope=”http://sharepoint/content/tenant&#8221; Right=”Write” />
<AppPermissionRequest Scope=”http://sharepoint/content/sitecollection/web/list&#8221; Right=”Write” />
<AppPermissionRequest Scope=”http://sharepoint/content/sitecollection/web&#8221; Right=”Write” />
</AppPermissionRequests>
Example AngularJS routing used:

var goalsApp = angular.module(‘goalsApp’, [‘ui.bootstrap’, ‘ui.bootstrap.tpls’, ‘ui.router’, ‘ngGrid’]);

goalsApp.config(function ($stateProvider, $urlRouterProvider, $httpProvider) {

$urlRouterProvider.otherwise(‘/goals’);

$stateProvider

// HOME STATES AND NESTED VIEWS

.state(‘dashboard’, {
url: ‘/dashboard’,
templateUrl: ‘../apps/partials/dashboard/dashboard.html’,
controller: ‘dashboard’,
controllerAs: ‘vm’
})
//nest projects on dashboard page
.state(‘dashboard.projects’, {
url: ‘/projects’,
templateUrl: ‘../apps/partials/projects/projects.html’,
controller: ‘projects’,
controllerAs: ‘vm’
})

// customers
.state(‘customers’, {
url: ‘/customers’,
templateUrl: ‘../apps/partials/customers/customers.html’,
controller: ‘customers’,
controllerAs: ‘vm’
})

// goals
.state(‘goals’, {
url: ‘/goals’,
templateUrl: ‘../apps/partials/goals/goals.html’,
controller: ‘businessreview’,
controllerAs: ‘vm’
})

});

AngularJS and SharePoint 2013 together-loving it!

Rod Stagg

http://rstagg.com

Are SharePoint database-attach upgrades still the gold standard of upgrades?

I have completed many successful SharePoint migrations using the database attach method but increasingly seeing the benefits of starting fresh with a new install/configuration and performing manual content migration targeting specific content and bulk tagging on the destination site map. Interested in what others are experiencing in the way of database upgrades verses manual content migrations and third party migration tools.