Introduction to SharePoint 2013 App Model - A Primer

SharePoint 2013 introduces the new App Model that adds another dimension to the kinds of solutions you can build on the SharePoint technology platform in addition to Full Trust Solutions and Sandboxed solutions.

Lets take a deep dive on the App Model and understand the fundamental building blocks. 

I. SharePoint 2013 App Model Highlights:

1. SharePoint applications no longer live in SharePoint
2. Custom code executes in the client, cloud or on-prem
3. Apps are granted permissions to SharePoint via OAuth
4. Apps communicate with SharePoint via REST / CSOM
5. Acquire apps via centralized Marketplace, Corporate Marketplace, Public Marketplace (via submission process)
6. APIs for manual deployment
7. Everything in a SharePoint site is an app: Contact form, Travel request, Shared Documents library, Contacts list
8. Apps for SharePoint mimics Facebook Apps to an extent.

II. SharePoint 2013 App Model Benefits:

1. No custom code on the SharePoint server
2. Easier to upgrade to future versions of SharePoint
3. Works in hosted environments w/o limitations
4. Reduces the ramp-up time for those building apps
5. Don’t need to know/be as familiar with SharePoint “-isms”
6. Leverage hosting platform features in new apps
7. Enables taking SharePoint apps to different levels – further than what can be done with farm / sandbox solutions
8. Isolation – private vs. public clouds

III. SharePoint 2013 Application Architecture: The diagram below talks about the SP 2013 Application Architecture and its components.

REST / CSOM - are the programmatic approaches available to access SP 2013 data from Apps.
Remote Event Receivers - To handle events in an app for SharePoint remotely, you create remote event receivers and app event receivers.
BCS - Apps can perform CRUD operations on external data store using ODATA by leveraging External Content Types and External Lists.

IV. SharePoint 2013 App URL:

V. SharePoint 2013 Application Comparison Chart: Lets see what programming options we have while creating Apps for SharePoint.

VI. Different kinds of Apps for SharePoint 2013:  Here are 3 different kinds architecture approaches available for creating SharePoint 2013 Apps.

 

 1. SharePoint-Hosted App:

•     SharePoint hosted apps wholly reside in SharePoint
•     Uses SharePoint artifacts (lists/libraries)
•     Business logic executes or on the client
•     HTML5
•     JavaScript using CSOM or REST API's

 2. Cloud based Apps:

•     Cloud hosted apps primarily execute outside of SharePoint
•     May use SharePoint artifacts (lists/libraries)
•     Communicate via CSOM / REST
•     Granted permission to SharePoint via OAuth
•     Business logic lives & executes outside of SharePoint
•     On-Premise hosted web application
•     Windows Azure
•     3rd party host
•     Managed CSOM (Client Side Object Model) can be adopted as a programming model for both     these kinds of Apps.   
•     Within cloud based apps, we have a further bifurcation between:  
•     Provider-Hosted Apps- Apps developed/maintained on Premises or a Private Cloud.  
•     Auto-Hosted Apps - Apps provisioned using Windows Azure Auto-Hosting. SharePoint deploys ASP.NET application & SQL Azure DB to Azure automatically when SharePoint app is installed.

VII. SharePoint 2013 Application UX (User Experience):

VIII. SharePoint 2013 Application Scopes:

i. Web scope - By default all SharePoint 2013 SharePoint apps are scoped to Web.

ii. Tenant scope - Cloud based apps can have their Apps as tenant scoped. For e.g.: Apps hosted on Office 365 can have a Tenant scope for privacy and security. Not Applicable to SharePoint Hosted Apps.

IX. SharePoint 2013 App Hosting Options: Cloud v/s SharePoint

 

 X. SharePoint 2013 Application Isolation:

• When apps are provisioned, new SPWeb (AppWeb) created within hosting SPWeb
• Each app resides within it’s own SPWeb for isolation
• Special DNS address configured by administrators
• App SPWeb’s live in separate domain (DNS)
• Each App hosted on it’s own unique URL because:
• Blocks XSS: isolation to special SPWeb under special domain blocks cross site scripting
• Enforces App Permissions: apps communicate with sites via CSOM /API & must be granted to do so

XI. Obtaining SharePoint 2013 Applications:

 Applications can be acquired multiple ways:

• Public Marketplace
• Similar Windows Phone Marketplace

Subject to submission process & approval

• App Catalog
• Apps developed internally

Apps acquired and approved for internal use

• Custom Deployment Process
• Developers can use remote / local SharePoint & Windows Azure APIs to deploy apps with custom code. These APIs are restricted to the developer site for tooling scenarios

References: http://msdn.microsoft.com/en-US/office/apps

Powershell script to Export and Import Managed Metadata Termstore across SharePoint farms while still retaining its GUIDs

While migrating your site collections from one farm to the other, Managed Metadata termsets being used and stored in lists and libraries for various site collections would reference to the GUID’s of the original managed metadata term store. The site columns themselves, would reference the GUID of the term sets of the source managed metadata service. Hence, it becomes difficult to migrate the various site collections to the new farm. In this situation, we run the risk of making the existing managed metadata columns being orphaned for the source site collection to be migrated.

Below mentioned PowerShell script Exports and Imports Managed Metadata termstore still retaining its GUID's (sspId's- used internally by the Termstore) and referred by Managed metadata columns in list/library.

#Export Managed Metadata Taxonomy Name

$managedMetadataAppSource = “4a867ce5-d9ee-4051-8e73-c5eca4158bcd”; #this sets the exporting MMS ID
$mmSourceProxy = Get-SPServiceApplicationProxy | ?{$_.TypeName -eq "Managed Metadata Service Connection"};
Export-SPMetadataWebServicePartitionData -Identity $managedMetadataAppSource -ServiceProxy $mmSourceProxy -Path "C:\ExportManagedMetadata\locationexportfile.bak";

#Import Managed Metadata Taxonomy Name

$managedMetadataAppTarget = "d045d3ce-e947-4465-b039-0dfbbe24fb22"   #this sets the importing MMS ID
$mmTargetProxy = Get-SPServiceApplicationProxy | ?{$_.TypeName -eq "Managed Metadata Service Connection"};
Import-SPMetadataWebServicePartitionData -Identity $managedMetadataAppTarget -ServiceProxy $mmTargetProxy -Path "C:\ImportManagedMetadata\locationexportfile.bak" -OverwriteExisting;

Powershell Script to query and export Workflow History List Items across a Site Collection using CrossListQueryInfo in a .csv file

This Power Shell script queries across a given Site Collection using CrossListQueryInfo and CrossListQueryCache objects available in SharePoint 2010 OM. The script also generates a CSV file report of all Workflow History List items across the given site collection.

Add-PsSnapin Microsoft.SharePoint.PowerShell

## SharePoint DLL
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Publishing")
   
    $SiteCollUrl = "https://sharepointfix.com/sites/crosslistquerycache"
 
    $site = new-object Microsoft.SharePoint.SPSite($SiteCollUrl)
    $web = $site.OpenWeb()
   
    try
       {
        #Specify your CAML query here
        $caml = "" #You can specify your <Where/> clause here
        $lists= "<Lists ServerTemplate='140' Hidden='True'/>"
        $viewFields = "" #You can specify your <ViewFields/> here
        $webs = "<Webs Scope='SiteCollection' />"
        $queryInfo = new-object Microsoft.SharePoint.Publishing.CrossListQueryInfo
        $queryInfo.Webs = $webs
        $queryInfo.Lists = $lists
        $queryInfo.ViewFields = $viewFields
        $queryInfo.Query =$caml
        $crossListCache =  new-object Microsoft.SharePoint.Publishing.CrossListQueryCache –ArgumentList $queryInfo
        $allow= "TRUE"
        $results = $crossListCache.GetSiteDataResults($web, $allow)
        Write-Host "There are $($results.Data.Rows.Count) items."
        $results.Data | Export-Csv -Path "F:\WorkflowHistoryListItemReport.csv" -NoTypeInformation -Force       
       }
    catch
    {
        "Error encountered:" | Out-Default
        $_.Exception | Write-Error
    }
    finally
    {
        $web.Dispose()
        $site.Dispose()
    }
   
Remove-PsSnapin Microsoft.SharePoint.PowerShell
Write-Host "Finished"

Powershell script to get Site Collection Pages and List Items count using SPSiteDataQuery object

This PowerShell script queries a given Site Collection and returns all its Pages and List Item count recursively using SPSiteDataQuery object model.

Add-PsSnapin Microsoft.SharePoint.PowerShell

## SharePoint DLL
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Publishing")

# CHANGE THE FOLLOWING LINE TO POINT TO THE DESIRED PORTAL SITE COLLECTION
$web = Get-SPWeb "http://sharepointfix/sites/spsitedataquery"

if($web -ne $null)
{ 
    # Adding fields to the view
    $viewFields = New-Object System.Collections.Specialized.StringCollection
    $viewFields.Add(“Title”)
    $viewFields.Add(“Name”)

    # Construct the query object for publishing pages
    $queryPages = New-Object Microsoft.SharePoint.SPSiteDataQuery
    $queryPages.Lists = "<Lists ServerTemplate=""850""/>"

    #Specify your clause here
    $queryPages.Query = ""
    $queryPages.RowLimit = 1000000
    $queryPages.ViewFields = $viewFields
    $queryPages.Webs = "<Webs Scope=""Recursive""/>"
   
    # Construct the query object for list items
    $queryItems = New-Object Microsoft.SharePoint.SPSiteDataQuery
    $queryItems.Lists = "<Lists ServerTemplate=""100""/>"

    #Specify your clause here
    $queryItems.Query = ""
    $queryItems.RowLimit = 1000000
    $queryItems.ViewFields = $viewFields
    $queryItems.Webs = "<Webs Scope=""Recursive""/>"
   
    # Execute both queries and display the count of the number of pages and items
    $pagesData = $web.GetSiteData($queryPages)
    $itemsData = $web.GetSiteData($queryItems)
    Write-Host "There are $($pagesData.Rows.Count) pages and $($itemsData.Rows.Count) items."
   
    $web.Dispose()
}

Remove-PsSnapin Microsoft.SharePoint.PowerShell

Write-Host "Finished"

Benefits of SPSiteDataQuery over SPQuery is that SPSiteDataQuery queries the whole site collection including all its subsites recursively and brings back the desired data.

Powershell script to get SharePoint Page Layouts inventory and its usage across site collection

I was writing a PowerShell script that needed to do 2 things primarily:

1. Get an inventory of all Page Layouts deployed across a SharePoint 2010 Farm.
2. To find out whether or not any of these Page Layouts were in use or not within its various sites/sub-sites. To simply put it the other way, did any of the sites/sub-sites had Pages created out of any of the available Page Layouts in the farm.

The first requirement was not too hard to accomplish, we have the PublishingSite.GetPageLayouts in the SharePoint OM, but I had to scratch my head a little bit for the second one though.

Iterating through Pages library within numerous site/sub-sites for approximately 20,000 site collections in the Farm, in order to find out the Page Layout usage would be too expensive and time consuming. There had to be a better/faster approach to handle this scenario.

The clue was SharePoint 2010's OOTB related resources inventory. Go to “Site Actions” -> “Site Content and Structure” and select “Master Page Gallery”. See snapshot below:

The OOTB Show Related Resources functionality allows a user to select any of the Page Layouts/resources within the Master Page and Page Layouts Gallery and mentions files that uses it across the site collection.

Now there has to be a way to achieve the same programmatically as well.
I started exploring SPFile object model and voila, I found the SPFile.BackwardLinks property, see the MSDN article: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.backwardlinks.aspx

So my sample PowerShell code snippet does 2 things:

1. Gets an Inventory of all Page Layouts for a Publishing Site, see sample PowerShell script code :

$objSite = Get-SPSite "http://sharepointfix.com/sites/PageLayoutUsageReport"

[Microsoft.Sharepoint.Publishing.PublishingSite]$publishingSite = New-Object Microsoft.SharePoint.Publishing.PublishingSite($objSite)

#Gets all Page Layouts for the current Site Collection, no need to iterate all subwebs
$pageLayouts = $publishingSite.GetPageLayouts($false)

#I can make use of Export-CSV to generate a .csv file for reporting purposes. That works like a charm.
#But Powershell also provides you with a lovely Grid View interface, try doing something like this:

$pageLayouts | Out-GridView

## Of course, I will wrap the above script in a foreach block to iterate through all web applications and site collections in the SP 2010 Farm.

2. Get Page Layout Usage - The sample code now makes the use of SPFile.BackwardLinks property in order to find whether the Layout is in use or not

## Iterate through all the Publishing Page Layouts
foreach($layout in $pageLayouts)
{
      ## Get Page Layout File object
      [Microsoft.SharePoint.SPFile]$file = $publishingSite.RootWeb.GetFile($layout.ServerRelativeUrl);

#Backward links contain the URLs of all files that link to the current file from the current site collection and its # sites/subsites.
# Pages that link to the current file from another Web site or site collection are not included in the backward
# link information.

# returns $true, if SPFile.BackwardLinks.Count is greater than 0
 $IsPageLayoutInUse = ($file -ne $null -and $file.BackwardLinks -ne $null -and       $file.BackwardLinks.Count -gt 0)
}

The above script is just a primer to the wide array of possibilities that PowerShell offers as a tool.
I hope this post has helped you in someway or the other. Happy Programming :)