Introduction to the Minimal Download Strategy (MDS) – SharePoint 2013

 

As we all aware that Inter web is based on a request-response approach where you request a page and get a response back. The approach is the same whether we update the whole page or portions of it. The last decade we've seen smart approaches working around this "problem" using DHTML, JavaScript, AJAX, and UpdatePanels. Up until now SharePoint (out-of-the-box) has not been that efficient on this, even though SharePoint 2010 did some improvements. Most often the whole page has been reloaded for each and every action; this of course affects all end-users and the perceived performance of SharePoint. But now, with SharePoint 2013, we have a whole new paradigm thanks to the Minimal Download Strategy – MDS 

Minimal Download Strategy in SharePoint 2013 improves rendering performance when browsing content where large parts of the page do not change providing a more fluid navigation experience. For example when navigating between a site’s home page and Shared Documents page only the content that has changed between the source and destination page (controls and placeholders in the content area) is downloaded and the URL subsequently updated where the chrome is persisted. 

The Minimal Download Strategy is by default enabled on Team sites, Community sites and a few others in SharePoint 2013. All pages for that site are rendered "through" the /_layouts/15/start.aspx page. This page is responsible for loading pages from the site using the MDS. The start.aspx page has a specific JavaScript object asyncDeltaManager (defined in start.js). Basically it parses the URL, looks for the # sign and takes the path following that and dynamically loads that page. 

Subsequent requests to pages are dynamically loaded through the asyncDeltaManager object. Once a link is clicked it will invoke a method in the JavaScript object which creates the MDS URL and appends the query string parameter AjaxDelta=1. A request is created and downloaded asynchronously and only the "delta" is returned to the client and assembled and rendered using JavaScript.

Enabling or disabling MDS on a site

First of all what sites do have the MDS enabled by default? MDS is actually a SharePoint feature (Name; MDSFeature, Id: 87294C72-F260-42f3-A41B-981A2FFCE37A) which is Web scoped. Some of SharePoint 2013 Site Templates has this feature stapled (for instance Team, Community, Wiki, Projects, App and Blog sites). The feature is very straightforward - it toggles the EnableMinimalDownload property of the SPWeb object. So you can quite easily yourself turn it off using code (server side or CSOM!!) or PowerShell. Of course you also use the Site Settings > Site Features to turn it on or off as well. The MDS is not enabled on publishing sites and is not compatible with publishing sites.  

Requirements for MDS 

Except enabling MDS it is required for the MDS to work there is one control that must be placed in the master page - the AjaxDelta control. It should be added to the head section of the master page. This control is responsible for a couple of things. If the page is a start/home page it will clear all controls and make sure that the page is loaded fully and registers the correct scripts. 

Ajax Delta 

What this AjaxDelta control does is to only download to the client (browser) what has been changed since the previous download. If nothing has changed, nothing is downloaded Ajax Style.

Following are the AjaxDelta controls that are available in the Master page.

1.       DeltaPlaceHolderAdditionalPageHead

2.       DeltaSPWebPartManager

3.       DeltaSuiteLinks

4.       DeltaSuiteBarRight

5.       DeltaSPNavigation

6.       DeltaWebPartAdderUpdatePanelContainer

7.       DeltaWebPartAdderUpdatePanelContainer

8.       DeltaTopNavigation

9.       DeltaSearch

10.   DeltaPlaceHolderPageTitleInTitleArea

11.   DeltaPlaceHolderPageDescription

12.   DeltaPlaceHolderLeftNavBar

13.   DeltaPlaceHolderMain

14.   DeltaFormDigest

15.   DeltaPlaceHolderUtilityContent

How is the delta pages generated?

One of the key things in the MDS implementation is that SharePoint 2013 contains a new Page class - the DeltaPage. This page class is the key to generating the full pages or just the deltas. Fortunately the common pages such as WebPartPage, WikiEditPage, UnsecuredLayoutsPageBase, LayoutsPageBase etc. are inheriting from this page. So most of the out-of-the box pages works and custom application pages as well. This page class is quite smart it can handle when MDS is not enabled (i.e. default rendering) and when MDS is enabled. When MDS is enabled for the site this page is responsible for creating the delta response. The DeltaPage is also responsible for handling exceptions such as when the master page is different (another one or a new version). Every delta request sent using the asyncDeltaManager has a specific request header - the X-SharePoint header. This header contains information about the master page, the language and if the page is in read-write or read-only mode.

This header is important since it contains the master page, the version of the master page etc. and SharePoint uses this to determine whether to do a full reload (if the master page has changed) or not. So if you’re working on a master page, be prepared for full reloads of the page, at least the first time you request a page using the modified master page. 

The PageRenderMode control 

There is one control called PageRenderMode that can be used on a master page, web part page or page layout. This control has one property called RenderModeType which can have one of two possible values; Standard or MinimalDownload. If the control is placed on a page and have the property set to Standard – it will prohibit the page from being rendered using MDS. If the control is not present or if it’s property is set to MinimalDownload it can participate in MDS rendering. So this control can be used on specific (master) pages to prohibit MDS. 

Note: if you’re using the Design Manager to generate master pages, this control will automatically be inserted into the generated artifacts .Another gotcha here is that even if you have the PageRenderMode control set to MinimalDownload whenever the publishing features are enabled and you have the ribbon on the page, specifically when using the Publishing Ribbon in your master page, SharePoint will automatically inject, during runtime, the PageRenderMode control with the property set to Standard.

 

MDS compliant controls 

If you upgrade a SharePoint 2010 site with custom Web Parts or controls, you will soon realize that the upgraded Webs are not rendered using MDS - even if you update the EnableMinimalDownload property on the SPWeb object. This is due to the reason that the DeltaPage checks all controls present on the page for a specific attribute - the MdsCompliantAttribute. This is an attribute that you can set on a class or on an assembly. If any of the controls present on a page does not have this attribute nor has the IsCompliant property set to false it will not render any delta for that page.

To make your own controls MDS Compliant the classes should look like this:

[ToolboxItemAttribute(false)]

[MdsCompliant(true)]

public class MDSTest : WebPart

{

     protected override void CreateChildControls()

     {

             this.Controls.Add(new LiteralControl("MDS is enabled on the site:" +

             SPContext.Current.Web.EnableMinimalDownload));

     }

}

Or, you could add the MdsCompliant to the assembly instead of to each class.

The MdsCompliant attribute is set on the whole Microsoft.SharePoint.dll assembly, but not on the Microsoft.SharePoint.Publishing.dll assembly. This means that all the Field Controls, used in page layouts, are not MDS compliant – which means no MDS on publishing sites.

Note: MdsCompliant attribute does not work in the Sandbox!!! So adding a Sandboxed Web Part to a page disables MDS for that page, period

SharePoint Workflow - A Business Process

A workflow is a natural way to organize and run a set of work units, or activities, to form an executable representation of a work process. A workflow is a set of co-ordinate event-driven activities. Assigning workflow to a document or a piece of content is the act of binding a business process to this entity. Suppose you need to create a simple workflow that routes a document to a series of users for approval or comments. This workflow would include actions that the system needs to perform, as well as provide interfaces for the users to interact with the workflow in prescribed ways. For example, Windows SharePoint Services would send an e-mail message to the selected users when the document was ready for review. Those users would then need to be able to notify Windows SharePoint Services when they had completed their reviews and, optionally, enter any comments.

Types of Workflow
SharePoint workflows are based on Windows Workflow Foundation (WF) which is a base set of technologies that programmers can access using Visual Studio or SharePoint Designer.
There are two types of workflow supported:
1. Sequential - This is similar to a flow chart style where there are decision points along the way that indicate what the next step is in the workflow based on some condition being met (or not met). These steps generally execute in a specific order.

2. State Machine - This style workflow is more complex and consists of a number of states, transitions between states and actions.

Workflow Architecture
The basic components of a workflow include:
1. An XML-based markup file that contain the basic information about the workflow and the activities contained within it
2. An XML-based rules file that contains the business logic of the workflow in declarative rules form
3. One or more aspx or Info Path forms
Unless you are using SharePoint Designer, workflows are compiled into assemblies and installed as features at the site collection level.
Workflow associations are stored in the database for SharePoint. For each type of content (document, list, or a content type), an association is made is made in the table. You can have more than one workflow associated with a content type, but they can't be the same type of workflow (i.e. you can have an approval and a translation workflow, but not two approval workflows). In addition, workflows can be manually initiated or system initiated based on an event (i.e. changing the content).

SharePoint Administration: Workflow Settings
There is an administration option for workflows that allows you to set some global settings at the Web Application level. These setting include whether user-defined workflows are enabled and how users who don't have site access are notified of their participation requirements in a workflow (i.e. they are assigned a task).

Out the box Workflow
SharePoint provides a base set of workflows out of the box including:
1. Approval workflow
2. Collect Feedback
3. Collect Signatures
4. Disposition Approval
5. Three-state
6. Translation Management
Not all of these workflows are turned on by default. To see what's activated, view the Features at the Site Collection level.
By default, when you create a publishing site with workflows, an approval workflow is automatically attached to each content type created for the site. You can add new workflows through Site Actions…Site Settings…Modify Pages Library Settings.

Creating Workflows in SharePoint Designer 2007
You can use SharePoint Designer 2007 to create custom workflows for your site. The designer enables you to create workflows using a wizard type approach. This does have limitations.
The wizard is declarative rules-based and code-free. You can’t create activities using this wizard, you can only select from a pre-defined list. The other drawback is that you create the workflow for a particular site and for a particular list or document within that site. You cannot create a workflow for a content type using the designer.
To create a workflow, open the site you want to add it to and select the list type to attach the workflow to (see figure below).

You can create one or more steps for your workflow. For each step you assign conditions and actions when the condition is met. If you have multiple actions to take you can apply them in one of two ways:
1. Serial: the actions happen in a specific order (denoted by “then”)
2. Parallel: actions can occur at the same time (denoted by “and”)

You can also create forms to make the workflow more dynamic and flexible. In SharePoint Designer you can include 2 types of forms in your workflow:
1. Initiation forms – these are the forms that gather information when the workflow is first activated (such as date approval required)
2. Custom task forms – these allow users to interact with the tasks in the Task List
The designer generates the forms as aspx pages and stores them with the source files for the workflow. You can open these aspx files in Designer or another editor and modify them.
When you have completed creating your workflow, two source files are generated and stored in a document library within the site. The workflow is not compiled into an assembly, rather when the workflow is initiated; the source files are compiled and stored in memory. There are two XML-based source files:
1. Markup File: outlines the activities included and the basic workflow information
2. Rules File: contains the business logic of the workflow in declarative rules form

Creating Workflows in Visual Studio 2005
Creating workflows in Visual Studio 2005 is much more involved than using SharePoint Designer, but it’s also much more robust. Workflows created using Visual Studio are compiled assemblies with each activity in the workflow represented by a .net class.
Visual Studio has a workflow designer that you use to create your workflows. There is a graphical representation of your workflow that you create by clicking and dragging components in the interface.

Only a subset of the WF activities is available when designing a workflow for a SharePoint site. However, in addition to these activities, SharePoint itself provides a number of activities via its own workflow namespace (API).