Monthly Archives: November 2013

Before moving on to some real action let’s get familiar with some of the facts on Activity:

An activity is a portion of work that is completed with the help of other resources.

Activities are the basic building blocks of workflows.

A workflow can be created by using a single activity or a group of activities. SharePoint 2010 enables both out-of-the-box and custom activities.

Out-of-the-box activities can be used directly in Microsoft SharePoint Designer 2010; custom activities require some coding.

Now let’s see some facts on Custom Code Activity With a wide selection of out-of-the-box activities, why are custom activities needed at all? This question is especially relevant when you consider that it is also fairly easy to execute code in an existing workflow by adding a CodeActivity and then writing the code in the ExecuteCode event handler. However, custom activities are especially helpful because they wrap custom code in a reusable component. Further, as the following examples show, some essential actions require more functionality than out-of-the-box activities can provide.

Looping: Out-of-the-box activities cannot provide direct looping support through collections, such as the lists in a site or the items in a list.

Accessing outside content: With out-of-the-box activities, it is not possible to access SharePoint content in other sites or site collections or to access anything at the farm or web application level.

Calling across the network: Standard actions do not support calling a remote web service from a SharePoint Designer 2010 workflow.

Running with elevated permissions: Out-of-the-box activities run under the current user’s identity and permissions. Although Impersonation steps can help mitigate this, workflow actions are still restricted from running under a more privileged user’s identity and elevated permissions.

Obtaining control at the workflow level: By its nature, SharePoint Designer 2010 insulates the workflow builder from the details of the underlying SharePoint workflow architecture.

Enough of the theory for now. Now it’s time to see some action. Steps to Implement Custom Activity:

Add a new project using class library project template

Add new workflow activity as shown below

Add code to the activity as shown below

Now we will do some investigation on each property and functions used in this code.

Dependency properties indicate that the workflow depends on this value. All values that are used as inputs or outputs for the custom workflow activity should be marked as dependency properties. Following are the available dependency properties in our code:

Browsable Properties are the simple properties decorated with a number of Attributes. Browsable Properties must be mapped with corresponding Dependency Properties. Following are the available Browsable Properties in our code:

SiteUrl

ListName

ListTemplate

Execute Method: The Execute method must complete by returning a value from the ActivityExecutionStatus enumeration. Enumeration of activity status values corresponds to the life cycle of an activity in a running workflow instance. Once execution of the code is complete, you must call the enumeration Closed for the activity. The following table shows different enumerations for custom activities:

CreateList Method: This is just a simple helper function which creates the SharePoint List using server side object model.

And that’s the end of our analysis. Now lets continue with the remaining steps

Add Strong Name Key to the Project by going to the Project Properties > Signing Tab as shown below:

Build the solution

Steps to Implement Custom Activity Deployment Project:

Add Empty SharePoint Project as shown below:

Add the reference of CustomWorkflowActivties.dll in this solution

Add SharePoint Mapped Folder TEMPLATE\1033\Workflow

Add xml file with the name CreateListWorkflowActivity.Actions, make sure this file must have the .Actions extension otherwise SharePoint Runtime would not get it recognized as an workflow action.

Add the configuration entries to the CreateListWorkflowActivity.Actions file as shown below:

Note: To make a full-trust workflow activity available to declarative workflows, add an authorizedType entry to the Web.config file for the content web application. This gives your custom activity the same status as the built-in workflow activities that are included with SharePoint 2010. The following code example shows the format of an authorizedType entry.

Build the solution

Deploy the solution

And with this we are done with our development work, now it is the time to test our efforts. Steps to test Custom Activity:

Launch SharePoint Designer

Connect to SharePoint Site

Click on left navigation link “Workflows”

Click on Site Workflows in the ribbon. Enter Name and Description for the workflow.

SharePoint Foundation development projects often involve a mixture of imperative coding and XML markup. Frequently, you add your new assembly’s Public Key Token to a project file, such as an XML configuration file.

If your Visual Studio project is based on any of the SharePoint 2010 project templates in Visual Studio, you can simply insert the placeholder $SharePoint.Project.AssemblyPublicKeyToken$ where the Public Key Token should be in most kinds of project files (but not .cs or .vb files or other compilable files).

When you build and deploy the project, Visual Studio will replace the placeholder with the Public Key Token in the copies of the files that are actually deployed.

If you need to insert the Public Key Token in a file that does not support the placeholders, you will need a way to obtain the Public Key Token. This topic explains how to add an item to the Visual Studio Tools menu that can be used to obtain the Public Key Token of an assembly under development.

If we inspect the response object, we will find the incoming JSON structure as follows, this information is very important to understand how to use the response the response object in code. Properties exposed by the response object are highlighted as follows:

That’s the end of this simple implementation employing SharePoint Rest API and JSON.

We can following noteworthy points on Delegate Controls in SharePoint:

SharePoint provides a mechanism that allows developers to customize out-of-the-box functionality in pages, without the need for modifying the pages that come with SharePoint. This mechanism is provided with delegate controls.

A delegate control defines a region in an aspx page that allows the content to be replaced with our custom content. This custom content is created via a SharePoint feature, and when deployed and activated, replaces the standard content at runtime.

By declaring a control as an element in a Feature and giving it a priority through the Sequence attribute of the Control element, SharePoint selects the declared control candidate and instantiates it as a child of the delegate control. At run time, this delegate control accepts the union of control elements declared at the server farm, Web application, site collection, and Web site levels.

The control that has the lowest sequence number is added to the control tree through the DelegateControl.

Delegate controls for which the AllowMultipleControls property equals true can host more than one child control.

If there are multiple delegate control candidates, they are all added as children at runtime in the order specified by the Sequence attribute. For example, by default the AllowMultipleControls property is used in the AdditionalPageHead delegate control to allow multiple child controls to be added to any page that contains the delegate control.

Now let see the delegate control in action.

In this article we will see the steps involved in replacing the SharePoint global navigation with Control ID “GlobalNavigation”. We will discuss the significance of this Control ID attribute in detail later in this article.

Project Structure:

Based on the above project structure following are required artifacts to be developed in order to get the delegate control working:

Custom Control : GlobalNavigation.ascx

Module : GlobalNavigation

Web Scoped Feature : CustomDelegateControl

Custom Control: First of all we need to create a custom control that will be used to replace the existing SharePoint Delegate Control.

Definition of GlobalNavigation.ascx

GlobalNvaigation.ascx file contains the UI logic for the delegate control, in this case this is simply declaring a label control that will contains the urls of all lists in current site.

Definition of GlobalNavigation.ascx.cs

GlobalNavigation.ascx.cs file contains the logic to display all the lists from current site.

Element.xml

The information in Element.xml file is very important to understand, as this information tells SharePoint which Delegate Control needs to be replaced.

Sequence Attribute contains the value of the sequence in the control tree, make sure this value is less than the sequence value for OOB SharePoint Delegate Control else OOB SharePoint Delegate Control won’t get replaced by the custom control.

ControlSrc Attribute contains the path of the custom control relative to the ControlTemplates Directory under SharePoint Root Folder (14 Hive).

Web Scoped Feature:

Now we are done with all the deployable, and it’s time to create a feature which will deploy the artifacts in SharePoint Farm.

We need to create a Web Scoped feature, which allows us to activate this Global Navigation Control on the specific sites instead of the complete site collection, though this can be designed based on the business requirements.