Fail Forward Fast: SharePoint Development

SharePoint Development

03/23/2011

External data, Parent-Child workflows, but in SharePoint Designer? Heck yes!

In the world of SharePoint Workflows, there are really only two options for creating custom workflows (excluding 3rd parties), SharePoint Designer and Visual Studio (Office Visio is just a toy at this point). Figure 1 below shows the trade offs, where with SharePoint Designer you get more maintainability because you don't need low level, highly technical developers implementing your business processes. With SharePoint Designer, even your grandma can do it!

Figure 1, SharePoint Designer offers more maintainability, but Visual Studio offers more flexibility.

The trouble with SharePoint Designer is flexibility to meet complex business requirements, and this is where Visual Studio workflows typically come into view. I always like to point out three main "platform busters" with SharePoint Designer workflows that necessitate Visual Studio workflows, and they are:

Buster #1) Sequential Workflows vs State Machine Workflows: SharePoint Designer only supports Sequential workflows, in that the workflow executes in a specific sequence (eg, A -> B -> C -> D). Whereas Visual Studio workflows can execute in any sequence, eg A -> C -> B -> A -> D. The image below shows the two different types and how they would look on a diagram:

Figure 2, SharePoint Designer workflows can only do sequential workflows. You need Visual Studio to do state machines.

Buster #2) External Data and/or Integrate with Line of Business Applications: SharePoint Designer workflows can't really integrate well (out-of-the-box) with other systems external to SharePoint. Now, you can use BCS with Workflows but really all you can do is CRUD (create, review, update, and delete) data, YOU CAN'T RESPOND TO EXTERNAL EVENTS! This is a significant limitation to SharePoint Designer workflows. For instance, look at Figure 3 below. This figure shows several workflow instances in SharePoint that interact with some Line of Business application. They call into the system, and then sit and wait for a response from that system. The red arrows reflect the response, where the line of business app wants to notify the waiting instance that it has either finished processing or that a human has performed some action. You can't cross this boundary in SharePoint Designer workflows.

Figure 3: Wouldn't it be great to have a SPD workflow leverage external systems? It's possible!

Buster #3) Parent Child workflows: In SharePoint Designer there is no way (out-of-the-box) to have a parent workflow spawn child workflows and wait for those workflows to finish executing. I see so many companies build a huge workflow that tries to do everything and fails. Plus, you then get no reusability in your workflows. Rather, I suggest building smaller, reusable workflows and having parent workflows invoke those child workflows, as seen in Figure 4:

Figure 4, REUSABILLITY!!!! Plus, there are many cases where parent/child workflows are the ONLY way that works.

So back to figure 1. There's an obvious chasm between SharePoint Designer workflows and Visual Studio workflows. Is there a sweet spot? I believe there most certainly is!!!!

The question is this... do you have capital to spend on buying 3rd party software? Typically 3rd parties try to fill the gap. In my opinionNintex Workflows is the best 3rd party in this space. However, if you can't/won't buy a third party, you can still build it, and I think in this post you'll see it is entirely reasonable for a good .NET/SharePoint Developer to extend their workflows into this sweet spot. The goal for this post is to show how to extend SharePoint Designer workflows with custom .NET code to solve platform busters #2 and #3. Specifically, my walkthrough shows how to build #3 in SharePoint Designer! (once you see how to build #3 you can easily translate that into how to build #2)

As far as buster #1 goes, we're still up a creek there. Really the only way in SharePoint Designer to "mimic" a sate-machine is to have a complicated set of nested loops... ick! This unfortunately is essentially what even Nintex does... mimic state machines :( But hey, let's celebrate that we can accommodate #2 and #3 at least :)

The "how" is quite simple. SharePoint Designer allow you to deploy your own custom Actions and Conditions. You can then therefore build your custom actions in Visual Studio, and then deploy them to your SharePoint Designer users. This is in essence how you can "bridge the chasm" between Designer and Visual Studio, because now your developers can build actions that do very advanced things like connect to external systems, and your power users can use those actions when they model their business processes in SharePoint Designer.

This is done by placing a custom XML file into the "SharePoint Root", "Workflow" directory (Figure 3). This XML file will need a .ACTIONS extension. When SharePoint Designer loads, it goes to this folder and downloads all the .ACTIONS files it sees there, and uses those actions (and conditions) to populate the Actions drop down in the workflow designer interface.

Figure 3

So let's walk through Buster #2 for a bit. How exactly does this work? What we're going to leverage is a workflow technique called Pluggable Workflow Services, or otherwise called External Data Exchanges. In Visual Studio, this translates into essentially three things:

Custom External Data Exchange Service: This service is really just a class/interface. Don't get scared! It's easy. Simply implement the interface and add your code that connects to your external system! EDE more or less does the rest!
CallExternalMethodActivity Activity: This activity is used to call into your custom EDE service. AKA, your workflow uses this activity to send some data to your external application, and then can optionally sit and wait for a response.
HandleExternalEventActivity Activity: This activity is used to handle a event that was fired externally to SharePoint. In our example, our SharePoint Designer workflow will use this activity to sit and wait for the response from the external system. Our custom service code will raise the event, and this activity will respond to that event being raised.

So with those three key pieces, let's expand on figure 3 by adding those 3 pieces, as seen in figure 4 below:

Figure 4

As you can see, we added two red arrows and two green boxes into the existing figure. The first "Local Service" green box is our custom service (component #1). The two red arrows are the two activities (components #2 and #3). The "Call" arrow calls the service, which then the service does some junk like call into the external system. Then, our "Handle" arrow handles the event raised from the external system.

The only other piece is the "Custom WCF Service" box. This is only needed if a external line of business application needs to call into SharePoint. Essentially, to raise the event to the handle method, the event needs to be raised on the SharePoint Farm. Well, how does the external system get on the SharePoint farm? The best way to do this is to have the external system invoke a WCF service that resides on the SharePoint Farm. From that WCF service, the event to which the workflow is waiting, can be raised. Again, this WCF service is ONLY needed when receiving messages/events externally to the SharePoint farm.

So how do we build this custom EDE service?

The first step is to create an interface marked with the [ExternalDataExchange] attribute. What's in the interface is up to you. Essentially, keep two things in mind:

What data do you want the workflow to send to the external system?
What data do you want the external system to send back to the workflow when it's done?

The answer to those questions help you create the interface. Notice my example in Figure 5. I have one method, and one event. The workflow can call the method which takes some parameters (answer to #1). Secondly, the workflow can sit and wait for the external system to respond which when it does sends some arguments through the raising of the event (answer to #2).

Figure 5

With the interface in place, the next step is to implement that interface on a class. Notice our implementation in figure 6. We simply extend the SPWorkflowExternalDataExchangeService class, and then we implement our custom interface. The only curve ball is the CallEventHandler method that satisfies the SPWorkflowExternalDataExchangeService implementation. When our custom WCF service raises the event, this method is called. The method checks to see what event the WCF service want's to raise, and then this method actually raises the event which then notifies the appropriate workflow instance that is waiting on the event to be raised.

Figure 6

The last bit of code is the code in the WCF service. How do we raise the event? It's very simple, in fact it's pretty much one line of code using the SPWorkflowExternalDataExchangeService.RaiseEvent method, as can be seen in Figure 7:

Figure 7

Step by Step Walkthrough - Creating Parent Child Workflows in SharePoint Designer

Up to this point we've just be theoretical. How do you actually do this? The following is a smattering of steps that can walk you through the somewhat complicated process. Figure 8 is a diagram that shows exactly what we're building. We're going to create a parent workflow that runs in Farm #1 that starts a workflow in Farm #2. The parent workflow then sits and waits for its child workflow in farm #2 to finish. When the child finishes, it will then call a WCF service in Farm #1 which then notifies the parent workflow that the child has finished. And the best part - BOTH THE PARENT AND CHILD WORKFLOWS ARE SHAREPOINT DESIGNER WORKFLOWS!!!

Figure 8

Create a new Visual Studio project using the Sequential workflow template:

You'll step through the new project wizard... just enter your Dev site URL and next through and click Finish. The project will create a workflow called Workflow1. Delete this workflow as we will not use it.
Right click the project and choose Add, Class. Call the class something like ParentChildService.cs

Add the following using statements to the top:

using System.Workflow.Activities;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WorkflowActions;
using System.Workflow.ComponentModel;
using System.ComponentModel;
using Microsoft.SharePoint.Workflow;
using Microsoft.SharePoint.Client;
Create your interface and event args in this same cs file, something like the following:

[ExternalDataExchange]

public interface IParentChildService

{

    // CallExternalMethod

    void StartSomeWorkflow(string Message, Guid CallbackWorkflowId);

    // CallExternalMethod

    void UpdateParentWorkflow(string Message, Guid CallbackWorkflowId);

    // HandleExternalEvent

    event EventHandler<UpdateParentWorkflowEventArgs> UpdateParentWorkflowEvent;

}

[Serializable]

public class UpdateParentWorkflowEventArgs : ExternalDataEventArgs

{

    public UpdateParentWorkflowEventArgs(Guid workflowIdtoUpdate) : base(workflowIdtoUpdate) { }

    public string Response;

}
Make the ParentChildService class public, and extend SPWorkflowExternalDataExchangeService and your interface, eg IParentChildService. Afterwards, implement each interface which will stub out the necessary methods.
In the StartSomeWorkflow method, paste the following code:

using (ClientContext context = new ClientContext("http://intranet.pdd.com"))

{

    List list = context.Web.Lists.GetByTitle("Some List");

    context.Load(list);

    ListItem newitem = list.AddItem(new ListItemCreationInformation());

    newitem["Title"] = Message;

    newitem["Instance"] = CallbackWorkflowId.ToString();

    newitem.Update();

    context.ExecuteQuery();

}

This code create a list item in a list titled "Some List" in Farm 2. In a bit, we'll create a SharePoint Designer workflow that sits on this list and waits for this item to be created. Note - you'll need to add a reference to the Microsoft.SharePoint.Client and Microsoft.SharePoint.Client.Runtime DLLs since this code is using the Client object Model to connect to the external Farm to create the list item. This wouldn't be necessary if the child workflow is on the same farm as the parent.

Also note the "Instance" column. The child workflow needs to know the ID of it's parent. If it doesn't know the ID, it won't know which running workflow is waiting for it to complete, so the parent workflow has to pass it's ID to the child so the child can respond when its done.
Add the following code into the CallEventHandler method:

switch (eventName)

{

    case "UpdateParentWorkflowEvent":

        var args = new UpdateParentWorkflowEventArgs(workflow.InstanceId);

        args.Response = eventData[0].ToString();

        this.UpdateParentWorkflowEvent(null, args);

        break;

}
Now we need to create the WCF service that the child workflow can invoke when it's done executing. In the same solution, create a new WCF Service project named something like "ChildWorkflowCallback":
In the IService1 interface in the new project, paste the following service method that our child workflow can invoke:

[OperationContract]

void UpdateParentWorkflow(string Message, Guid CallbackWorkflowId);
Rename the IService1.cs class and class file to IChildWorkflowCallback and IChildWorkflowCallback.cs respectively.

Rename the Service1.cs class and class file to ChildWorkflowCallback and ChildWorkflowCallback.cs respectively.
Re-Implement the interface on ChildWorkflowCallback which will generate our UpdateParentWorkflow method, then paste the following code into that method:

using (SPSite site = new SPSite("http://dev.farm.com/"))

{

    using (SPWeb web = site.RootWeb)

    {

        // handled by the CallEventHandler callback, which

        // in turn invokes the [in] event that then communicates

        // with the workflow instance

        SPWorkflowExternalDataExchangeService.RaiseEvent(web,

            CallbackWorkflowId,

            typeof(IParentChildService),

            "UpdateParentWorkflowEvent",

            new object[] { Message });

    }

}

Note - you'll need to add a reference to the SharePoint DLL and to the other (SharePoint) project to get this code to work. Since this code will run on the Parent workflow's SharePoint farm, we can simply use the standard object model. We get our site and web, and then raise the event to the EDE service, and pass in the Parent's ID to notify.
Next we need to deploy this WCF Service. Create a new IIS site in the Parent's farm. Ensure that the new site's Application Pool is set to an App Poo where the service account HAS DBO TO THE SHAREPOINT DATABASE AS WELL AS FULL CONTROL TO THE PARENT's SHAREPOINT SITE.
Next we need to right click the WCF project and choose Publish. Enter the name of the IIS site and the URL and click publish.
With this WCF service in place, the next step is to invoke the service from the UpdateParentWorkflow method that is called when the child workflow finishes executing. To do this, add a Web Reference to the project and enter the url to the WCF service you just deployed. Name the service reference ChildWorkflowCallback and then paste in the following code into the UpdateParentWorkflow method:

ChildWorkflowCallback.ChildWorkflowCallbackClient client = newChildWorkflowCallback.ChildWorkflowCallbackClient();

client.UpdateParentWorkflow(Message, CallbackWorkflowId);
Next we need to create the action that the parent workflow calls when they want to start the child workflow. Back on the SharePoint Project, create a new class titled StartWorkflow. Make this class a public class and extend "SequenceActivity". Add the following using statements:

using System.Workflow.Activities;

using System.Workflow.ComponentModel;

using Microsoft.SharePoint.WorkflowActions;

using System.ComponentModel;

Next add the following properties inside the class:

public StartWorkflow()

{

    InitializeComponent();

}

public static DependencyProperty SomeDataToSendProperty =

            System.Workflow.ComponentModel.DependencyProperty.Register(

            "SomeDataToSend", typeof(string), typeof(StartWorkflow));

public static DependencyProperty __ContextProperty =

    System.Workflow.ComponentModel.DependencyProperty.Register(

    "__Context", typeof(WorkflowContext), typeof(StartWorkflow));

[Description("SomeDataToSend")]

[Browsable(true)]

[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]

public string SomeDataToSend

{

    get { return ((string)(base.GetValue(StartWorkflow.SomeDataToSendProperty))); }

    set

    {

        base.SetValue(StartWorkflow.SomeDataToSendProperty, value);

    }

}

[Browsable(true)]

[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]

public WorkflowContext __Context

{

    get

    {

        return ((WorkflowContext)(base.GetValue(StartWorkflow.__ContextProperty)));

    }

    set

    {

        base.SetValue(StartWorkflow.__ContextProperty, value);

    }

}

These are two properties, one called __Context, and the other called SomeDataToSend. The parent workflow will pass a string into the SomeDataToSend which the child will reference. The __Context property is simply there so we can grab the parent workflow ID.
Next double click SomeWorkflow.cs in the project explorer to open the activity in design mode. Drag and drop the CallExternalMethod activity onto the surface from the toolbox under WWF v3.0. Next edit the properties of this method:

1) Edit the InterfaceType property and change it to the IParentChildService interface.
2) Edit the MethodName property and change it to StartSomeWorkflow.
3) Edit the ClientCallbackWorkflowID and change it to the __Context.WorkflowInstanceId property.
4) Edit the Message property and change it to the SomeDataToSend property.
Next we need to create another activity. When the child workflow is done executing, it needs to call the custom WCF service. Create a new class just like in step 14 but this time called UpdateWorkflow.cs, paste in the following properties like before:

public UpdateWorkflow()

{

    InitializeComponent();

}

public static DependencyProperty InstanceProperty =

            System.Workflow.ComponentModel.DependencyProperty.Register(

            "Instance", typeof(Guid), typeof(UpdateWorkflow));

[Description("Instance")]

[Browsable(true)]

[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]

public Guid Instance

{

    get { return ((Guid)(base.GetValue(UpdateWorkflow.InstanceProperty))); }

    set

    {

        base.SetValue(UpdateWorkflow.InstanceProperty, value);

    }

}

public static DependencyProperty ResponseDataToSendProperty =

            System.Workflow.ComponentModel.DependencyProperty.Register(

            "ResponseDataToSend", typeof(string), typeof(UpdateWorkflow));

[Description("ResponseDataToSend")]

[Browsable(true)]

[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]

public string ResponseDataToSend

{

    get { return ((string)(base.GetValue(UpdateWorkflow.ResponseDataToSendProperty))); }

    set

    {

        base.SetValue(UpdateWorkflow.ResponseDataToSendProperty, value);

    }

}

public static DependencyProperty __ContextProperty =

            System.Workflow.ComponentModel.DependencyProperty.Register(

            "__Context", typeof(WorkflowContext), typeof(UpdateWorkflow));

[Browsable(true)]

[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]

public WorkflowContext __Context

{

    get

    {

        return ((WorkflowContext)(base.GetValue(UpdateWorkflow.__ContextProperty)));

    }

    set

    {

        base.SetValue(UpdateWorkflow.__ContextProperty, value);

    }

}

The only difference with these properties is now instead of SomeDataToSend, we have a property called ResponseDataToSend, aka the data the child is going to send to the parent.
Just like before, in the solution explorer double click UpdateWorkflow.cs to load the activity in the designer. Drop the CallExternalMethod activity onto the surface, and set the properties:

1) InterfaceType should again be IParentChildService.
2) MethodName should be UpdateParentWorkflow
3) CallbackWorkflowId should be set to the Instance Property.
4) Message should be set to the ResponseDataToSend property.

Lastly, right click on the activity and choose Generate Handlers. Add the following code into the GH method to set the Instance property to that of the parent's workflow ID:

SPListItem item = __Context.Web.Lists["Some List"].GetItemById(__Context.ItemId);

Instance = new Guid(item["Instance"].ToString());
With that activity done, we need one final activity. The parent workflow needs an action to make it wait for the child to finish, and then to do something with the data that the child sends. Add another activity but this time with the name of HandleWorkflowUpdate.cs and paste in the following properties:

public HandleWorkflowUpdate()

{

    InitializeComponent();

}

public static DependencyProperty ResponseReceivedProperty =

            System.Workflow.ComponentModel.DependencyProperty.Register(

            "ResponseReceived", typeof(string), typeof(HandleWorkflowUpdate));

[Description("ResponseReceived")]

[Browsable(true)]

[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]

public string ResponseReceived

{

    get { return ((string)(base.GetValue(HandleWorkflowUpdate.ResponseReceivedProperty))); }

    set

    {

        base.SetValue(HandleWorkflowUpdate.ResponseReceivedProperty, value);

    }

}
Instead of the CallExternalMethod activity, drag and drop the HandleExternalEvent activity onto the new activity's design surface. Set the following properties:

1) InterfaceType again to IParentChildService.
2) EventName to UpdateParentWorkflowEvent

Like the last activity, right lick the activity and choose Generate Handlers and paste the following code to set the Response property to that of the argument's value:

UpdateWorkflowEventArgs args = (UpdateWorkflowEventArgs)e;

ResponseReceived = args.Response;
The last step in Visual Studio is to create the .ACTIONS file that makes these .NET activities available as Actions in SharePoint Designer. To do this, right click the project and choose Add->Mapped folder and select the Template->1033->Workflow folder:

Next, within the newly mapped folder, create a new XML file and paste in the following code (note, name of the file doesn't matter, just make sure it has a .ACTIONS extension):

<?xml version="1.0" encoding="utf-8"?>

<WorkflowInfo Language="en-us">

  <Actions Sequential="then" Parallel="and">

    <Action Name="StartWorkflow"

        ClassName="[AssemblyName].StartWorkflow"

        Assembly="[AssemblyName], Version=1.0.0.0, Culture=neutral, PublicKeyToken=[TOKEN]"

        AppliesTo="all"

        Category="Custom Actions">

      <RuleDesigner Sentence="Send %1 data to a new workflow instance on intranet.pdd.com.">

        <FieldBind Field="SomeDataToSend" Text="this" Id="1" />

      </RuleDesigner>

      <Parameters>

        <Parameter Name="__Context" Type="Microsoft.SharePoint.WorkflowActions.WorkflowContext, Microsoft.SharePoint.WorkflowActions" Direction="In"/>

        <Parameter Name="SomeDataToSend" Type="System.String, mscorlib" Direction="In" />

      </Parameters>

    </Action>

    <Action Name="UpdateWorkflow"

        ClassName="[AssemblyName].UpdateWorkflow"

        Assembly="[AssemblyName], Version=1.0.0.0, Culture=neutral, PublicKeyToken=[TOKEN]"

        AppliesTo="all"

        Category="Custom Actions">

      <RuleDesigner Sentence="Update parent workflow and send %1 this data.">

        <FieldBind Field="ResponseDataToSend" Text="this" Id="1" />

      </RuleDesigner>

      <Parameters>

        <Parameter Name="__Context" Type="Microsoft.SharePoint.WorkflowActions.WorkflowContext, Microsoft.SharePoint.WorkflowActions" Direction="In"/>

        <Parameter Name="ResponseDataToSend" Type="System.String, mscorlib" Direction="In" />

      </Parameters>

    </Action>

    <Action Name="HandleWorkflowUpdate"

        ClassName="[AssemblyName].HandleWorkflowUpdate"

        Assembly="[AssemblyName], Version=1.0.0.0, Culture=neutral, PublicKeyToken=[TOKEN]"

        AppliesTo="all"

        Category="Custom Actions">

      <RuleDesigner Sentence="Wait for child workflow to complete and save response in this %1.">

        <FieldBind Field="ResponseReceived" Text="variable" Id="1" DesignerType="ParameterNames" />

      </RuleDesigner>

      <Parameters>

        <Parameter Name="ResponseReceived" Type="System.String, mscorlib" Direction="Out" />

      </Parameters>

    </Action>

  </Actions>

</WorkflowInfo>

Notice in the code that you'll have to replace [AssemblyName] and [TOKEN] with your actual values.
Lastly, build the project and if you'll deploy to your local dev workstation, right click and choose "Deploy". Otherwise take the WSP solution package and upload it on your SharePoint farm to deploy (through powershell - Add-spsolution). Since my parent workflow runs on the local farm, "Deploy" will suffice. However, since my child is on a different farm, I'll need to manually move the WSP and run Add-SpSOlution.

However, before we can create your SharePoint Designer workflows we need to do a bunch of stuff to the web.config files on both the parent and child farms.
WCF Service web.config (note [AssemblyName], [NAMESPACE], and [TOKEN] tags):

in the <configSections> tag:

<sectionGroup name="System.Workflow.ComponentModel.WorkflowCompiler"type="System.Workflow.ComponentModel.Compiler.WorkflowCompilerConfigurationSectionGroup, System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">

      <section name="authorizedTypes"type="System.Workflow.ComponentModel.Compiler.AuthorizedTypesSectionHandler, System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

      <section name="authorizedRuleTypes"type="System.Workflow.ComponentModel.Compiler.AuthorizedTypesSectionHandler, System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

    </sectionGroup>

in the <configuration> tag:

<System.Workflow.ComponentModel.WorkflowCompiler>

    <authorizedTypes>

      <authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="*" Authorized="True" />

      <authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="WhileActivity" Authorized="False"/>

      <authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="ConditionedActivityGroup"Authorized="False" />

      <authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="ReplicatorActivity"Authorized="False" />

      <authorizedType Assembly="System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="*" Authorized="True" />

      <authorizedType Assembly="System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.Runtime" TypeName="CorrelationToken"Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System" TypeName="Guid" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System" TypeName="DateTime" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System" TypeName="Boolean" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System" TypeName="Double" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System" TypeName="String" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System" TypeName="Enum" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System.Collections" TypeName="Hashtable" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System.Collections" TypeName="ArrayList" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System.Diagnostics" TypeName="DebuggableAttribute" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System.Runtime.CompilerServices" TypeName="CompilationRelaxationsAttribute" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System.Runtime.CompilerServices" TypeName="RuntimeCompatibilityAttribute" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System" TypeName="Int32" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System" TypeName="TimeSpan" Authorized="True" />

      <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"Namespace="System.Collections.ObjectModel" TypeName="Collection`1" Authorized="True" />

      <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow"TypeName="SPWorkflowActivationProperties" Authorized="True" />

      <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow"TypeName="SPWorkflowTaskProperties" Authorized="True" />

      <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow"TypeName="SPWorkflowHistoryEventType" Authorized="True" />

      <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPItemKey"Authorized="True" />

      <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowUserContext"Authorized="True" />

      <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.WorkflowActions" TypeName="*"Authorized="True" />

      <authorizedType Assembly="Microsoft.Office.Access.Server.Application, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.Office.Access.Server.Macro.Runtime"TypeName="*" Authorized="True" />

      <authorizedType Assembly="Microsoft.Office.Access.Server.Application, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"Namespace="Microsoft.Office.Access.Server.Quickflow.Runtime" TypeName="*" Authorized="True" />

      <authorizedType Assembly="Microsoft.Office.Workflow.Actions, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.Office.Workflow.Actions" TypeName="*"Authorized="True" />

      <authorizedType Assembly="[AssemblyName], Version=1.0.0.0, Culture=neutral, PublicKeyToken=[TOKEN]"Namespace="[NAMESPACE]" TypeName="*" Authorized="True" />

    </authorizedTypes>

    <authorizedRuleTypes>

      <authorizedType Assembly="Microsoft.Office.Access.Server.Application, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"Namespace="Microsoft.Office.Access.Server.Quickflow.Runtime" TypeName="*" Authorized="True" />

      <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.WorkflowActions"TypeName="WorkflowCodeTypeReferenceExpression" Authorized="True" />

      <authorizedType Assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.Runtime.CompilerServices" TypeName="ExtensionAttribute"Authorized="True" />

    </authorizedRuleTypes>

  </System.Workflow.ComponentModel.WorkflowCompiler>
In the SharePoint site's web.config:

In the <AuthorizedTypes> tag:

<authorizedType Assembly="[AssemblyName], Version=1.0.0.0, Culture=neutral, PublicKeyToken=76b48d68efbe7cc6"Namespace="[NAMESPACE]" TypeName="*" Authorized="True" />

In the <WorkflowServices> tag:

<WorkflowService Assembly="[AssmeblyName], Version=1.0.0.0, Culture=neutral, PublicKeyToken=46f02ef46891fd72" Class="[NAMESPACE].ParentChildService">

</WorkflowService>
In the External farm's web.config (in addition to what's found in step 24). Note, this can be found in the App.config file in the project AFTER you add the service reference:

In, <system.serviceModel>

<bindings>

            <wsHttpBinding>

                <binding name="WSHttpBinding_IChildWorkflowCallback" closeTimeout="00:01:00"

                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"

                    bypassProxyOnLocal="false" transactionFlow="false"hostNameComparisonMode="StrongWildcard"

                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"

                    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"

                    allowCookies="false">

                    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"

                        maxBytesPerRead="4096" maxNameTableCharCount="16384" />

                    <reliableSession ordered="true" inactivityTimeout="00:10:00"

                        enabled="false" />

                    <security mode="Message">

                        <transport clientCredentialType="Windows" proxyCredentialType="None"

                            realm="" />

                        <message clientCredentialType="Windows" negotiateServiceCredential="true"

                            algorithmSuite="Default" />

                    </security>

                </binding>

            </wsHttpBinding>

        </bindings>

        <client>

            <endpoint address="http://dev01.pdd.com:12345/ChildWorkflowCallback.svc"

                binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IChildWorkflowCallback"

                contract="ChildWorkflowCallback.IChildWorkflowCallback"name="WSHttpBinding_IChildWorkflowCallback">

                <identity>

                    <dns value="localhost" />

                </identity>

            </endpoint>

        </client>
Now create the SharePoint Designer Workflow!!!!! Create a new site workflow in the parent farm. The first thing you'll notice is our custom actions in the Actions drop down!

For the parent workflow, I simply did the following:

This will start the workflow, and the StarWorkflow action will create a list item in Farm #2. When the list item is created, we want a child workflow to automatically start (next step). Until that workflow finishes the parent is waiting with it's status set to "Waiting for response". The response is then logged to the history list when it's received.

Lastly, create the child workflow which will look something like this:

With the two workflows deployed, its now time to test! Below is a screen shot of the 8 steps:

Parent workflow is started in Farm #1.
Parent workflow creates list item in Farm #2 and sets its own status to "Waiting for Response".
The list item the parent created shows up in Farm #2 with the parent workflow's ID.
The child workflow either starts automatically, or in this case manually.
ditto.
The child workflow calls the WCF service notifying the parent.
The custom service raises the event that the parent is waiting for. The parent awakes from its slumber and writes the child's message to the log.
The parent then finishes executing now that all it's child workflows are done.

Posted at 07:50 PM in SharePoint Designer, SharePoint Development, Workflow Development | Permalink | Comments (0)

Technorati Tags: External Data, External Data Exchanges, Line of Business Data, Pluggable Workflow Services, SharePoint Designer Workflow

01/21/2011

Developer's Guide to Silverlight in SharePoint

What's in this article:

Building a Silverlight Web Part for SharePoint 2010
Accessing SharePoint Data from Silverlight Via the Client Object Model
Using Silverlight to access external systems like WCF and REST while inside a sandboxed solution
Deploying a Silverlight Web part for a Sandboxed Solution via a Feature
Debugging Silverlight Web Parts in SharePoint
A Faster Option: Piggyback on the HTML Bridge

DOWNLOAD Source code for the following...

My goal with this blog post is to take a 360 degree tour of where SharePoint and Silverlight technologies come together. Silverlight is undoubtedly a technology that is growing in popularity, and from a SharePoint perspective introduces some unique benefits that can't be achieved any other way. One such benefit is the ability to access external systems from Silverlight while in SharePoint Sandboxed Solutions. This is not possible with a .NET web part.

From a SharePoint data access perspective, there are several compelling techniques that I outline herein, such as using REST and the Client Object Model. Another important technique to understand is HTML bridging, whereby you can reduce server round trips and increase performance of your applications.

But before I get too dirty, I want to start off with a quick Silverlight/SharePoint 101... building a Hello World Silverlight web part...

1) Building a Silverlight Web Part for SharePoint 2010

To get started with our Silverlight journey, let's begin by building a simple "Hello World" Silverlight web part. To spice it up a bit, we'll add some animations, and color effects that show off the "brilliance" of Silverlight.

Building a Silverlight web part involves essentially 3 steps, 1) build the Silverlight application, 2) deploy that application into a SharePoint document library, 3) use the Silverlight web part to render the application. Steps 2 and 3 are pretty elementary, but for newbies, let's walkthrough how to build an application. Note - steps 2 and 3 don't necessarily represent the best practice approach to deploying your Silverlight application. Later in the article we'll touch on a better way, but for now let's keep things simple.

Create a new Visual Studio 2010 project using the Silverlight Application template (.NET 4.0 framework is OK):
Next choose to create a new hosting site. This site will be used to unit test our Silverlight application before we bother getting it into SharePoint. Choose Silverlight 4 from the drop down (if not present, download the Silverlight 4 toolkit for Visual Studio):
If you double click on MainPage.xaml, you'll notice the Silverlight xaml surface where we can start building our application. Enter the following TextBlock to simply render our text onto the Silverlight application:

<TextBlock x:Name="Text" Text="Hello World!" FontSize="50" VerticalAlignment="Center"TextAlignment="Center" FontFamily="Georgia" FontStyle="Italic"
FontWeight="Bold" FontStretch="Expanded">

</TextBlock>
If you're impatient or nervous, you can test the application by first building the Silverlight project, then building the test project, and simply right click the HTML page and choose View in Browser:

Pretty easy huh?
Well technically we've built our application, but it sure isn't "cool". Let's extend it a bit to change the font color, make it rotate when a user hovers their mouse over it, and make it fade in and out (opacity). First let's make the color a rainbow gradient by adding the following into the xaml just before the </TextBlock> tag:

<TextBlock.Foreground>

    <LinearGradientBrush>

        <GradientStop Color="Red" Offset="0.0" />

        <GradientStop Color="Yellow" Offset="1.0" />

    </LinearGradientBrush>

</TextBlock.Foreground>
To make the text move around we need to add a Silverlight transform. Again, just before the </TextBlock> tag add the following xaml:

<TextBlock.RenderTransform>

<RotateTransform x:Name="spin" Angle="0" CenterX="200" CenterY="50" />

</TextBlock.RenderTransform>

This code define the transform the text block will use. Note it's name is "spin", which is another piece of xaml we'll need to add later. This xaml is more or less a pointer to "spin" which will define what actually will happen.
Now let's add a storyboard and an animation named "spin" that will dictate the movement of the text block. Add the following xaml just above the <TextBlock> tag:

<UserControl.Resources>

    <Storyboard x:Name="homeboard">

        <DoubleAnimation

        Storyboard.TargetName="spin"

        Storyboard.TargetProperty="Angle"

        From="0" To="360" Duration="0:0:5"

        RepeatBehavior="Forever" />

    </Storyboard>

</UserControl.Resources>

This xaml defines a storyboard named homeboard, with one animation named spin (a story may have many animations, etc). Spin instructs the object to rotation on its axis over a half second.
The next step is to start the story board. We want our story board to start when the user clicks on the text block. Add the following xaml as a property of the text block (similar to FontFamily, FontSize, etc):

MouseLeftButtonDown="StartAnimation"
StartAnimation points to our custom event handled defined in the MainPage's code behind. Right click on MainPage in the solution explorer and click View Code. Next add the following code into the class:

private void StartAnimation(object sender, MouseEventArgs e)

{

homeboard.Begin();

}

This code simply executes the homeboard storyboard.
The last thing we wanted to do was make the text fade in and out by changing its opacity. To do this, add another animation directly below the DoubleAnimation within the storyboard:

<DoubleAnimationUsingKeyFrames Storyboard.TargetName="Text" RepeatBehavior="Forever"Storyboard.TargetProperty="(Opacity)" BeginTime="00:00:00">

<SplineDoubleKeyFrame KeyTime="00:00:01.0000000" Value="0"/>

<SplineDoubleKeyFrame KeyTime="00:00:02.0000000" Value="1"/>

</DoubleAnimationUsingKeyFrames>

Notice how we're targeting the "Opacity" property of the TextBlock, and it takes 2 seconds. The first second it fades out, and the second it fades back in.

Before we deploy into SharePoint, build the project(s) again and ensure all the animations are working. The next step is to upload the XAP file (project directory/bin/debug) into a document library in your SharePoint site (note, a more advanced approach would be to package the XAP in a feature and module to have it automatically deployed). Following this, find a page and drop in the Silverlight web part and set the URL property and point it to your XAP file. That should be it!

2) Accessing SharePoint Data from Silverlight via the Client Object Model

I doubt you'll ever build a web part for SharePoint that doesn't need to interact with data that is actually stored in SharePoint. This next section will extend the "Hello World" web part we built in the previous section to include a walkthrough on how to read the web parts text (Hello World) out of a SharePoint list. With a .NET web part this would be trivial. You'd simply do SPContext.Current.Web.Lists["ListName"].GetItemByID(1)["Title"].ToString(), for example. Well the bummer with Silverlight is we're not going to have the same typical Object Model experience. In fact, Silverlight is treated as if it were a client application, such as Word, Excel, etc, and we're going to need to leverage SharePoint's WCF web services to get at our SharePoint data.

If this sounds scary - don't worry! A new feature with SharePoint 2010 is the new client object model. With the client object model, you can access SharePoint data via their WCF services in nearly the identical way you would if you were using the standard OM. The client object model wraps the WCF services with classes that have that work in nearly the same way as standard OM classes work.

For example, the standard OM has a class called "SPWeb", which you are likely familiar with. The client OM has a similar class named "Web". This paradigm is true with other classes such as SPContext->Context, SPSite->Site, SPList->List, etc. The following is a quick example of how these classes are used (for more info, reference this MSDN article):

using Microsoft.SharePoint.Client;

...

using (ClientContext context = new ClientContext("http://intranet"))

{

Web web = context.Web;

context.Load(web);

context.ExecuteQuery();

string title = web.Title;

}

The first thing the code does is wrap the Context in a using statement pointing to the SharePoint site we want to get data from. Next the Web object is loaded, followed by calling Execute. When Execute is called, the Client OM will invoke the WCF services and take the round trip to get the data from SharePoint. Note, only the data that is loaded will come back not the entire site collection. If you ever had to use the web services in SharePoint 2007, you'll know how incredibly easy this is in comparison.

With this quick tutorial under our belt, let's extend our Hello World example to read a list item in SharePoint, and retrieve the Hello World text:

Add a reference to the Microsoft.SharePoint.Client.Silverlight DLL and the Microsoft.SharePoint.Client.Silverlight.Runtime DLL (TEMPLATE\Layouts\ClientBin).
Right click on App.xaml, and click View Code. Then, add the following using statement:

using Microsoft.SharePoint.Client;

using System.Threading;
Within the Application_Startup method, add the following line of code:

ApplicationContext.Init(e.InitParams, SynchronizationContext.Current);
Just within the class, add the following global fields:

ListItem item;

Web web;

ClientContext context;
Back at the MainPage code behind, add another using statement for Microsoft.SharePoint.Client, and paste the following code inside the constructor, bellow the InitializeComponent() call:

context = new ClientContext(ApplicationContext.Current.Url);

web = context.Web;

context.Load(web);

context.Load(web.Lists);

List list = web.Lists.GetByTitle("Hello World Test");

context.Load(list);

item = list.GetItemById(1);

context.Load(item);

context.ExecuteQueryAsync(new ClientRequestSucceededEventHandler(success), null);

Notice how the first thing you do is instantiate the context off the current Silverlight's application URL. Next we load the web, lists, and the list we want, in this case the list titled Hello World Test. Then we get the item we want and load that as well. The last thing is to call Execute which is what initiates the round trip to the server. The main difference with this example, versus the previous one, is this code works in Silverlight and the other doesn't. Essentially all calls in Silverlight must be asynchronous, hence ExecuteQueryAsync. The next step is to add the "success" method delegate defined in the Async Execute.
Below the constructor paste in the following success method:

private void success(Object sender, ClientRequestSucceededEventArgs args)

{

    Dispatcher.BeginInvoke(() =>

        {

            Text.Text = item["Title"].ToString();

        });

}

All we want to do in the success method is update the Text of our TextBlock. The trouble is the UI thread and the background thread (thread we're currently in), are just that... two separate threads. It's impossible for the background thread to update the UI, so the Dispatcher is what allows us to get our code block in the UI thread's queue. With this in place, we're DONE! time to test...
Build the project, upload the new XAP file into the doc library (override old one), and test your web part. This time it will read the Title field from the 1st list item in the list specified in code.

NOTE: CLEAR YOUR BROWSER CACHE! If you are thinking you're not seeing your XAP changes taking hold, clear your browser's cache (delete cookies, etc), then close and reopen your browser. Thereafter you will see your changes.

NOTE: if you get the following error, make sure that you have loaded **ALL** the objects before calling Execute, as well as use the Dispatcher to update the UI. If anyone tells you the XAP file has to be in the Layout\ClientBin directory, they're lying.

Error:

Unhandled error in silverlight application invalid cross-thread access

3) Using Silverlight to access external systems like WCF and REST, while inside a sandboxed solution

There are two MAIN reasons why I feel Silverlight is becoming an important asset in a SharePoint Developer's toolbox. The first is obvious... Silverlight gives a developer the ability to produce compelling user interfaces. Unfortunately the benefit of an improved user interface is very subjective, and a developer may have trouble convincing management that it's worth the time and money to build. However, the second reason Silverlight is becoming more prevalent is much less subjective... in fact it is the only viable course of action, given the right requirements. You see, SharePoint 2010 has a new featured called Sandboxed solutions. Sandboxed solutions allow you to deploy code into SharePoint that is isolated from the outside world. Essentially that code can only interact with the site collection that it is deployed into. Sandboxed solutions also allow code usage to be monitored. So for example, say an IT company has a charge back model to its business units. In SharePoint 2007, IT could only charge based on Disk usage, # of sub-sites, or number of site collections. If one business unit has more requests per second, for example, and put a heavier load on their infrastructure, there was no way to monitor that. Now with Sandboxed solutions, IT can monitor the usage of code, such as web parts, but monitoring CPU cycles, etc.

Another important reason sandboxed solutions are being adopted is because infrastructure teams want to keep their servers clean, and "out-of-the-box". Sandboxed solutions allow you to keep a vanilla infrastructure, but still deploy custom code such as custom Web Parts.

It is easy to see why a lot of companies are adopting sandboxed solutions, but here is the problem. What if you want the benefits of Sandboxed solutions, but you still need custom code that can access external systems, such as invoke a web service? Remember, a .NET sandboxed web part can only interact within the site collection that it resides in.

And here is the benefit of Silverlight that a standard .NET sandboxed web part cannot boast - it has the ability to access external systems, even when deployed inside a sandboxed solution! So you see... in SharePoint 2007, Silverlight was "neat" and "cool", but you didn't have a hard and fast reason that would necessitate it. But now in SharePoint 2010, there's a specific use case that brings Silverlight skills for SharePoint Developers into the limelight.

So now that you're convinced of the "why", lets get to the fun part, the "how".

Up until this point we really haven't seen anything that a standard .NET web part can't do (albeit, the animations would be hard in .NET). Let's change the pace by taking changing our Silverlight app to call a WCF service to get it's text. Again, this is not allowable in a Sandboxed solution.

Just like newbies for Silverlight, I'm going to assume I may have some newbie for WCF, and we'll quickly walkthrough how to create a WCF service that returns the string "Hello WCF". We'll then add another TextBlock, but this time it'll read it's string out of the result from the WCF call.

Start by adding a new project into our existing solution. Use the WCF Service Application template.
Paste the following service method above the auto-generated GetData method:

public string GetSilverlightString()

{

return "Hello WCF!";

}
in the service interface, IService1.cs, paste the following above the GetData contract:

[OperationContract]

string GetSilverlightString();
Rename IService1 to "IHelloService" and rename Service1 to "HelloService" - use right click, rename. Also rename the .cs files in the solution.
Build the WCF project and right click, then click View in Browser. You'll then be taken to the Directory listing page. Click on HelloService.svc, and then copy the address URL.
With our HelloService built and ready to test, we can now add a reference to our Silverlight project. Go back to the Silverlight project and right click References, and choose Add Service Reference. Then, Paste the URL of the HelloService service and click Go. Lastly, click HelloService under Services, change the Namespace to HelloService, and lastly click Ok:
With our service reference in place, we can now invoke the service in our Silverlight application. Go back to your MainPage.xaml, and just before the end of the constructor paste the following code to invoke the service:

HelloService.HelloServiceClient hs = new HelloService.HelloServiceClient();

hs.GetSilverlightStringCompleted += new EventHandler
     <HelloService.GetSilverlightStringCompletedEventArgs>(hs_GetSilverlightStringCompleted);

hs.GetSilverlightStringAsync();

This code instantiates the service, and sets up another asynchronous call by registering the Completed method. Then, we call the Get-Async method to invoke the service, and thereafter our "hs_GetSilverlightStringCompleted" method is called with the result of the call. All the following method to update our TextBox text with the result of our service call:

void hs_GetSilverlightStringCompleted(
    object sender, HelloService.GetSilverlightStringCompletedEventArgs e)

{

    Dispatcher.BeginInvoke(() =>

        {

            Text.Text = e.Result;

        });

}
TEST! Build your Silverlight app and update your XAP (either by overriding XAP in document library, or by deploying as described in section 6 of this article). After you update your XAP you'll see that your Silverlight web part is now... BROKEN!

Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET4.0C; .NET4.0E; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Timestamp: Sat, 22 Jan 2011 01:56:59 UTC

Message: Unhandled Error in Silverlight Application An exception occurred during the operation, making the result invalid. Check InnerException for exception details.   at System.ComponentModel.AsyncCompletedEventArgs.RaiseExceptionIfNecessary()
   at HelloWorldSilverlightApp.HelloService.GetSilverlightStringCompletedEventArgs.get_Result()
   at HelloWorldSilverlightApp.MainPage.<>c__DisplayClass2.<hs_GetSilverlightStringCompleted>b__1()
Line: 1
Char: 1
Code: 0
URI: http://dev.farm.com/default.aspx

SO WHAT GIVES????? The problem is with cross-domain access. You see, Silverlight applications can only access resources in their current domain, eg, if your SharePoint site's URL is http://intranet, but your WCF service is on http://extranet, you'll get this annoying "making the result invalid" error. The there's a easy fix! What you can do is tell your WCF service to ALLOW cross domain access! To do this you drop a clientaccesspolicy.xml file at the root of your WCF service directory. This xml file specifies what domains are allowed to connect to the service. If you use a "*" asterisk, all domains are allowed. Note - this is a huge topic, that I can't do justice in this article, so I recommend reading up on Network Security Restrictions in Silverlight, as well as Making a Service Available across Domain Boundaries.
So then to get past this error, our last step is to create our clientaccesspolicy.xml file. In Visual Studio, inside your WCF project, add a new XML file titled clientaccesspolicy.xml and paste in the following xml:

<?xml version="1.0" encoding="utf-8"?>

<access-policy>

  <cross-domain-access>

    <policy>

      <allow-from http-request-headers="SOAPAction">

        <domain uri="*"/>

      </allow-from>

      <grant-to>

        <resource path="/" include-subpaths="true"/>

      </grant-to>

    </policy>

  </cross-domain-access>

</access-policy>
Now with this policy in place, simply go back to your Silverlight web part and refresh... and presto!!!!

4) Deploying a Silverlight Web part for a Sandboxed Solution via a Feature

To be perfectly fair - up until this point you've been working out of a document library with the out-of-the-box Silverlight viewer web part, which is fine. However, not all your web parts are going to be Silverlight web parts. You'll likely have standard .NET web parts along side Silverlight web parts. Why deploy them in 2 different ways? Let's consolidate by having one standard approach. Plus - you'll see in section 7 this deployment approach is very much a necessity.

So to summarize, you're going to create a new SHAREPOINT project. Along side that project, you'll going to create a new Silverlight project in the same solution. In the SharePoint project you'll create a feature that deploys the XAP file into a gallery, and instead of the out-of-the-box Silverlight reader web part, you'll going to create our own reader so end users won't have to bother with the URL property - simply drag-n-drop the web part!

Much cleaner approach, huh? I think so...

To get started, create a new Visual Studio project titled Contoso.SharePoint.WebParts, and leave the project as a Sandboxed Solution when prompted. With this selection, when we deploy the WSP package will be deployed to our site collection's solutions gallery, rather than the farm gallery in Central Administration.
Straight away, add a second project in the same solution. User the Silverlight Application template like before. Name the project Contoso.SharePoint.PictureApp.
Now - to keep things simple and since in section 1 I already went through a lengthy example, I'm just going to replace the Grid in the MainPage.xaml with a Image:

<Image x:Name="CatPic" Source="http://www.katzy.dsl.pipex.com/LOLCats/lolcat-i-question-the-general-assumption-that-feli1.jpg" />
The next thing to do is get the XAP file generated in this project deployed by our SharePoint project. To do this we need a feature and a model. On the SharePoint project, right click the Feature folder and choose Add Feature. Then, right click the project and click Add->New Item, select the SharePoint tab, and select Module. Name the Module PictureAppXAP:
The next "trick" we need to do is tell the module to include the output of the Silverlight project. Right click the Module, and select Properties, and then click on the Project Output References collection property. This will load a popup. Click the Add button to add a new reference and change the reference project to be your Silverlight project. Lastly, change the Deployment Type to be ElementFile:

Credit: I first saw this tip on Andrew Connell's blog.

After you click OK, your module will have a new File in its XML. You'll want to change the URL property of the file to the URL of a Document library that the XAP file should be deployed into, for example:

<?xml version="1.0" encoding="utf-8"?>

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

  <Module Name="PictureAppXAP">

    <File Path="PictureAppXAP\Contoso.SharePoint.PictureApp.xap"
         Url="Documents/Contoso.SharePoint.PictureApp.xap" />

  </Module>

</Elements>
Before we go too far, let's test our deployment. Right click the SharePoint project and click Deploy. Then, go to your SharePoint site and check the library and ensure the XAP file was deployed on your behalf. Alternatively, you can build the project, and then right click and click Package. This will generate the WSP which can be uploaded to the solution gallery manually, and thereafter you can manually activate the feature.

Note - Sandboxed solutions must be enabled in Central Admin. If you get the following error, from Central Admin, services on server, start the "Microsoft SharePoint Foundation Sandboxed Code Service":

Error occurred in deployment step 'Activate Features': Cannot start service SPUserCodeV4 on computer 'DEV01'
With our XAP getting deployed properly, it's now time to create a standard web part to render the Silverlight application. This will allow our users to simply drop the web part on the page, without having to worry about entering the XAP URL. To get started, right click the SharePoint project and choose Add->New Item->Web Part (not Visual WP) and name it PictureAppWebPart.
Within CreateChildControls of the new web part, add the following code to render the Silverlight application (make sure to update the URL to the XAP):

StringBuilder o = new StringBuilder();

o.Append("<object data=\"data:application/x-silverlight-2,\"
                  type=\"application/x-silverlight-2\" width=\"100%\" height=\"100%\">")

    .Append("<param name=\"source\" value=\"/Documents/Contoso.SharePoint.PictureApp.xap\" />")

    .Append("<param name=\"background\" value=\"white\" />")

    .Append("<param name=\"minRuntimeVersion\" value=\"4.0.50826.0\" />")

    .Append("<param name=\"autoUpgrade\" value=\"true\" />")

    .Append("<a href=\http://go.microsoft.com/fwlink/?LinkID=149156&v=4.0.50826.0\
                     style=\"text-decoration: none\">")

    .Append("    <img src=\http://go.microsoft.com/fwlink/?LinkId=161376\
                     alt=\"Get Microsoft Silverlight\" style=\"border-style: none\" />")

    .Append("</a>")

.Append("</object>")

.Append("<iframe id=\"_sl_historyFrame\"
              style=\"visibility: hidden; height: 0px; width: 0px; border: 0px\"></iframe>");

Controls.Add(new LiteralControl(o.ToString()));

note - This code is a bit ugly, but since we're in a sandboxed solution we can't use the Visual Web Part, otherwise it would've been slick to stick this HTML into the ASCX.
That should be it! Deploy your project again, and that will deploy the new web part into the sandboxed solution. Then, drop the web part on the page and you should see you Silverlight Image app!

5) Debugging a Silverlight Web Part in SharePoint

Debugging a Silverlight app is pretty straight forward - when SharePoint isn't in the equation. Before you deploy to SharePoint, try to do as much debugging as possible in the Silverlight project, because it is easy to set a breakpoint and hit F5.

When you get into the context of SharePoint you'll need to do a few more things. First off, you MUST deploy your XAP via a feature, thus following the steps outlined in section 4 of this article. Also a must - your breakpoints will never hit until you tell your SharePoint project to debug Silverlight. Right click your project and click the SharePoint tab. Then at the bottom check the Enable Silverlight debugging checkbox:

Now, simply open your SharePoint site to the page that has you Silverlight application on it. Then, click Attach to Process... and select your browser's process. Make sure to select the one with the Type of Silverlight, x86:

That's It!

6) A Faster Option: Piggyback on the HTML Bridge

Silverlight can be chatty. When a browser does a GET, the server then POSTs the page back to be rendered. It's at this point that Silverlight loads, after the first round trip to the server and back. This is also the point when Silverlight calls your custom code, such as invoking a service or using the Client Object Model. When your Silverlight app runs this custom code it is taking a second round trip to the server. These subsequent round trips is an areas we you may able to be more efficient.

The basic strategy is to build a standard .NET web part that sticks the data that the Silverlight web part needs on the page in hidden fields. Then, the Silverlight app can access the page's DOM and retrieve the data off the page, and skip the trip to the server. This is what's called the "HTML Bridge", or piggyback. More generally, you can do some of the following things (among others) on the bridge:

Access DOM from SL
Call JS from SL
Call Silverlight code from JS
Send and receive types from JS/SL

This is a significant topic and I recommend reading this MSDN article for further study. However, that article is kind of an abyss of information, so my goal in this section is to demonstrate the most common scenario of accessing the DOM from a Silverlight app. What we're going to do is create a standard web part that renders a hidden field which stores a url to an image. This URL is pulled from a SharePoint List. Then, our Silverlight app will look for this hidden field, rather than do a round trip to the server to lookup the URL from the SharePoint list... aka one less round trip and a faster load time.

In section 4 of this article you built a Silverlight web part that was deployed via a feature. This silverlight app simply rendered a Image of a cat. Instead of hardcoding the image url, let's stick the url in a hidden field and change the web part to look at the hidden field. To render the hidden field, paste the following code at the end of CreateChildControls:

SPWeb web = SPContext.Current.Web;

SPList list = web.Lists["CatPics"];
SPListItem item = list.GetItemById(1);

string imageurl = item["Title"].ToString();

o = new StringBuilder();

o.Append("<input type=\"hidden\" id=\"SharePointData\" value=\"" + imageurl + "\" />");

Controls.Add(new LiteralControl(o.ToString()));

This code simply reads a SharePoint list and pulls the url out of a title column in the first list item. Then, it sticks that url in a hidden field, which is rendered via a LiteralControl.

The next step is to change the Silverlight app that was created in section 4 to use this url in the hidden field, from the hard coded url in the Image Silverlight control. In the PictureApp project, go to the code view of the MainPage.xaml and paste the following code into the Initialize method:

HtmlDocument doc = HtmlPage.Document;
HtmlElement field = doc.GetElementById("SharePointData");
string source = field.GetProperty("value") as string;
CatPic.Source = new BitmapImage(new Uri(source, UriKind.Absolute));

This code uses a HtmlDocument object to access the Silverlight's page's DOM to grab the hidden field called "SharePointData". The value of the hidden field is then retrieved, and the Image source property is updated, thus updating the UI.

So you can see that this process of HTML Bridging is very easy, and is a great way to make your Silverlight applications perform faster.

Posted at 07:42 PM in .NET Development, Branding & UX Development, SharePoint Development, Silverlight Development | Permalink | Comments (1)

Technorati Tags: Client Object Model, HTML Bridge, REST, Sandboxed Solutions, SharePoint Development, Silverlight, Silverlight Web Part, WCF

06/22/2010

Building SharePoint Event Receivers in 2010

If you need some action to occur when a user deletes a document, for example, you may right away think you need a workflow when in fact an event receiver will do. The main difference between the two is a workflow is typically long running, whereas an event receiver is immediate.

Why would you want an event receiver? What if all you wanted to do is execute a piece of code when a document is being deleted. Say you wanted with code to archive that document when a user goes to delete it. This is a great example where an event receiver is nice, because that deleting event can trigger your custom code. You could do this with a Visual Studio workflow that just has one activity in it, but that's a lot of overhead for something that an event receiver does with a lot less effort. Alternatively, you could use a SharePoint Designer workflow, but with SPD you can't move documents across the site collection boundary, so custom code is the only way to go. The table below shows more comparisons between workflows and event receivers:

Comparing a workflow with an event receivers

Event Receivers		Workflows
Immediate fire	Versus	"Long running"
Lives and dies (no state)	Versus	Maintains "state"
.NET code only	Versus	.NET or SharePoint Designer
No human interaction	Versus	Typically involves human interaction
Before or after events	Versus	Only After events
Executes on sites, features, lists, and list items	Versus	Executes on Sites, items, and content types.

You really can't say one is better than the other. It depends entirely on your business requirements. Besides when documents are deleted, there are many other events you can respond to. The events fall into six categories as shown in the table below. Each category has a few of the more common events shown in the second column, but note there are many more events available as well.

Six event receiver categories

List Events	Adding/ed a new list, field. Updating/ed a field.
List Item Events	Adding/ed a new list item or document. Document checking/ed in or out. Adding/ed an attachment. Deleting/ed an item or document.
List Email Events	A list received an email.
Web Events	Deleting/ed a site collection or site. Creating/ed a new site collection or sub site.
Feature Events	Feature activating/ed or deactivating/ed.
List Workflow Events	A workflow is starting/ed, postponed, or completed.

You'll notice two things in this table. First is that there are a ton of events that you can have custom code respond to, and secondly that most events have a "before" and "after" (adding/added) event associated with it. As shown in Figure 1, before events happened before the change is committed to the SharePoint content database. This is helpful when you may want to cancel a change before it is saved. The event receiver for when a site is being deleted is a good example. Before the site is deleted, you could back it up first. On the other hand, there's a corresponding event receiver for after the site was deleted.

Figure 1 Events typically have a "before" and an "after" event, corresponding to when the event happens in relation to when the source is committed to the database.

To demonstrate how to build an event receiver, we're going to use the Workflow events as an example. The previous table shows how there are four events under the List Workflow Events category. We can respond to when a workflow is starting and when it has started, when a workflow is postponed, and when a workflow has completed. To keep the example simple, let's write an event receiver that creates an announcement when a new calendar event is created.

Start by creating a new project in Visual Studio 2010. You'll notice under the SharePoint tab that there's a new project template called Event Receiver (Figure 2). You can use this template to create any of the afore mentioned event receivers.

Figure 2 Visual Studio 2010 now has a new project template you can use to easily create new event receivers.

After you create the project, you'll get a dialog menu asking you to specify the URL of the site where you want to deploy and unit test your event receiver. Specify the URL and click next. Afterwards you'll be prompted to specify what type of event receiver you want to create (Figure 3). The drop down will contain the event types for each of the six categories except for the feature events category. Feature events are created by right clicking the feature from within the project after it's created. For the announcement example, select the List Workflow Events category:

Figure 3 There are six main event categories (five shown).

After you select the event category, you'll need to specify the event source. This tells the feature that is to be created what events you want to respond to. Notice in Figure 4 you can handle events from announcements, document libraries, and many others. Select the Calendar source:

Figure 4 You'll need to specify the event source that will raise the event and call your event receiver.

Next you want to specify what workflow event we want to handle. Specify the A workflow has started event. Now our code will execute any time a workflow is started on a calendar (Figure 5):

Figure 5 After you choose the event source, you need to specify the actual event you want to respond to. In this case we want to execute our code when a workflow has started.

After you create the project, you'll be sent to a method named WorkflowStarted. This is where we can add our code to create our announcement. Enter the code found in below to create the announcement:

if (properties.ActivationProperties.List.Title == "Main Calendar")

{

string siteurl = properties.ActivationProperties.Site.Url;

SPSecurity.RunWithElevatedPrivileges(delegate()

{

using (SPSite site = new SPSite(siteurl))

{

using (SPWeb web = site.RootWeb)

{

SPListItem item = web.Lists["Announcements"].Items.Add();

item["Title"] = "The workflow has started!";

item.Update();

}

});

}

The first thing this code block does is look at the activation properties to determine which calendar the event came from. Remember that our source was "Calendar" which just means any calendar on the site will raise this event when a workflow is started. If we have more than one calendar on the site we'll want to determine which calendar the event came from.

Next we elevate the privileges of the running use to be the service account. We don't know for sure if the running user has Contribute rights on the announcements list, so we elevate their permissions to be safe. Next we create the announcement, assign a title value, and commit the announcement to the database.

With this code in place, all we need to do is deploy the solution. Right click the project name in Visual Studio, and click Deploy. This will deploy the feature and assembly on our before. Next go and create a new calendar entry and start a workflow on that event. Afterwards, a new announcement will show up in the announcements list on that site.

Phil

Posted at 07:26 PM in SharePoint Development | Permalink | Comments (0)

Technorati Tags: Event Handlers, Event Receivers, SharePoint 2010, SharePoint Development

06/10/2010

SharePoint Workflow Versioning with Visual Studio 2010

So you just built this compelling Visual Studio workflow and deployed it into production. Things go great for a few months, but then the business requests a small change to the workflow. You go back into the workflow code, add a few activities to fulfill the request, and redeploy the workflow into production. To your shock, all the workflows start breaking! You're frantic because you're certain you adequately unit tested the changes, and can't figure out what might be going wrong. If this is you, you didn't version your workflow.

Workflow versioning is a very important technique. When a workflow goes idle, the state of the workflow is and saved (hydrated) into the database. This saving of a workflow's state is called hydration. When the workflow resumes, the state is dehydrated out of the database and the workflow starts processing again. Versioning is important because if you change the assembly while the workflow is hydrated (saved in the database), there's no guarantee that when the workflow dehydrated it will match the construct of the new assembly. If it doesn't match the construct upon de-serialization, the workflow will break. Changes like adding or removing activities and changing property values may necessitate a new workflow version. The best practice is to create a new version every time rather than just push the assembly and cross your fingers.

A new workflow version is essentially a new workflow. The basic technique is to make your assembly increment the version number with each build (rather than just leave it at 1.0.0.0 forever). Then, for each upgrade you create a new feature for that "version" of the workflow, pointing to the new assembly. You add the new assembly into the GAC alongside the old assembly. Lastly you specify that the old version cannot start new instances of the workflow and you add the new workflow onto the list. This way the old version of the assembly never changes, so there's no risk of hydrated workflows breaking when they are dehydrated. All you ever do is deploy another version of the assembly and add the new workflow to the list and disable previous versions. You don't want to remove the previous versions because that will orphan those running instances. For the full set of procedures, follow these steps to create a new version for an existing workflow:

Note: Old version overwritten
If you do not create a new version, and rather just upgrade the solution, all running instances of the workflow will be deleted. The old version of the workflow will be removed, and the new version will be added with zero running instances. Don't upgrade without creating a new version unless you're entirely sure you don't need to retain the running instances.

STEP 1 Create version 1.0.0.0 in your workflow's elements file

A) In the Elements.xml file of your workflow, replace $assemblyname$ in CodeBesideAssembly with the following:

[assembly name], Version=1.0.0.0, Culture=neutral, PublicKeyToken=[token]

B) Replace [assembly name] with your assembly name.

C) Replace [token] with your public key token. You can do this by finding your assembly in the GAC (c:\windows\assembly) and right clicking it, choosing Properties, and coping the token.

D) Change the name of the workflow in the Elements file to reference the new version.

Note: this is just so the user working with the workflow knows what version it is… it has no technical implications. For example:

E) Add a copy of version 1.0.0.0 to solution package by double clicking on the Package, and under the Advanced tab, add an existing assembly and browse to your 1.0.0.0 assembly version:

Note: notice how the Location and Source of the assembly is in a path under "Version 1.0.0.0". When the package is created, the 1.0.0.0 version is put in its own path because it cannot be in the same path as the current version since they both have the same name.

STEP 2: With version 1.0.0.0 established, you can now simulate the need to create version 2.0.0.0. Change the version of the assembly to 2.0.0.0

A) Under the Properties folder in the solution, open the AsseblyInfo.cs file.

B) Scroll to the bottom of the file and change the two versions to be 2.0.0.0.

STEP 3: Update the workflow's Elements.xml file to reference both the version 1.0.0.0 workflow and now the new 2.0.0.0 version.

A) Under the workflow, open the Elements.xml file.

B) Copy the Workflow element in its entirety and paste it directly after the </workflow> tag.

C) Change the name and the version (in the CodeBesideAssembly) of the second workflow to reference version 2.0.0.0.

D) Change the ID in the 2.0.0.0 version to be a new GUID. You can create a new GUID by using the Create GUID tool under the tools menu.

E) Build and deploy the solution.

STEP 4: Activate version 2.0.0.0

A) Within the root site in the site collection click Site Actions and click Site Settings.

B) Click Site Collection Features.

C) Deactivate and reactivate your workflow's feature.

STEP 5: With version 2.0.0.0 deployed and activated, we now need to prevent any new instances of version 1.0.0.0 from being created:

A) Navigate to the workflow settings page of the List or Site you're working on.

B) Click Remove a workflow.

C) Change version 1.0.0.0 to not allow new instances and click Ok (figure below)

Phil

Posted at 07:23 PM in SharePoint Development, Workflow Development | Permalink | Comments (3)

Technorati Tags: SharePoint, SharePoint workflow versions, Versions, Workflow

11/04/2009

Changing a Document in SharePoint Over HTTP Programmatically

Note: this post was derived from a solution first built by Wictor Wilen and Eric White, please reference this article for the complete write-up

There are many ways to programmatically retrieve documents from within SharePoint. Some choices are more obvious, like for instance when you're within a web request that has a SharePoint context. When that is the case the best approach is to leverage that SPContext (SPContext.Current.Site…) and pull out an SPFile object that contains the byte array of your document's content. However, some of the less obvious choices come when you don't have an SPContext. These are as follows:

Option 1) Leveraging the SharePoint API and specifically the SPFile Object (AGAIN)

Even without a SPContext you can get at the SharePoint API if your code is running on one of the farm's web front ends. In this case you'll have a SharePoint DLL available to you in the global assembly cache, and you can code against the API, eg: SPSite site = new SPSite("http://intranet");

Option 2) Leveraging the SharePoint Web Services

If you're not on the web front end, it would be a better choice to use SharePoint's web services to get at SharePoint data. For instance, with the Lists.asmx web service you can do stuff like download/upload a document, instantiate a new List, check out a document, etc. The only problem with the SharePoint web services is the goofy XML you got to deal with – making "batches", as they call them, can be daunting for newbies.

Option 3) Keep it simple with HTTP

A third and not well known approach is simply to use web requests to get at data over HTTP. If you know the URL to your SharePoint data, simply create a web request/response to that data and do something with it. The WebClient object makes this very easy:

using (WebClient wc = new WebClient())

{

wc.Credentials = new NetworkCredential("domain\\username", "password");

byte[] doc = wc.DownloadData("http://intranet/documents/documentA.docx");

MemoryStream mems = new MemoryStream();

mems.Write(doc, 0, doc.Length);

// Make some Edit to the stream here...

wc.UploadData(url, "PUT", mems.ToArray());

}

Notice how I'm passing credentials into this WebClient, and thus authenticating to secure SharePoint data. Then I call the DownloadData mehtod and pass a URL, this returns a byte array that contains my data/document from the web response. In essense these are the bytes of a document if that URL is the URL to a document in SharePoint, otherwise it would be the bytes of a SharePoint page or list.

Next I load that byte array into a stream, in which case I could make all kinds of alterations to that document that I want. Afterwards, I can call the UploadData mehtod to save my changes back into SharePoint.

Pretty easy huh? I guesss there's 2 morals to this story – 1) don't make things more complicated than they ought to be, and 2) HTTP web requests/responses still have their place. Truth be said, I often leverage all three mechanisms quite oftent, and the architecture usually dictates which approach is best. The order though makes sense. My first preference is option one. Then the second option is usually needed for more complicated functions. If it is simple I go with option 3.

Now with all that said – the Client Object model that comes new with SharePoint 2010 sure mixes this up a lot. But more on that later…

Phil

Posted at 11:23 AM in SharePoint Development | Permalink | Comments (0)

Technorati Tags: HTTP, Programmatically, SharePoint Development, SharePoint Documents

10/21/2009

Building an Event Handler and Custom Error Page in SharePoint 2010

What's in this post:

How to build a Event Handler in SharePoint 2010 from scratch
How to leverage a custom error page when canceling an event

Example leveraged: This walkthrough builds an event handler that executes when a site is being deleted in a site collection. When such as action occurs, the handler cancels the action and redirects the user to a custom error page where it informs them that sites shouldn't be deleted, but rather they should be archived.

STEP 1) Create a new Visual Studio 2010 project. Use the Empty Project template and specify the .NET 3.5 framework:

STEP 2) Type the URL to the Site Collection you want to deploy your project to as well as specify you want to deploy as a full-trust solution:

STEP 3) In the newly created solution, open the Feature and the feature designer will appear. Change the Scope to Site. This will make it so the event handler will be deployed across the entire site collection:

STEP 4) Add the event handler to the project. Right click the project and choose Add, New Item…

Select the Event Handler item template:

Select which event you want the handler to listen for (for this demo, we're capturing the Site Deleting event under Web Events):

STEP 5) Add code to the event handler. Open the code file, and enter your logic. For example:

properties.Cancel = true;

properties.Status = SPEventReceiverStatus.CancelWithRedirectUrl;

properties.RedirectUrl = "/_layouts/CustomEventErrorHandler/CustomErrorPage.aspx"

In this example, the Site Deletion is terminated and the user is redirected to a custom error page. This is accomplished by specifying the Status property and assigning it to the CancelWithRedirectUrl enumeration within SPEventReceiverStates. Other options include:

SPEventReceiverStatus.CancelNoError, cancel action but don't raise an error to the user
SPEventReceiverStatus.CancelWithError, cancel action and show default error dialog box (default)
SPEventReceiverStatus.CancelWithRedirectUrl, cancel error and redirect user to custom error page. Note that a RedirectUrl MUST be specified
SPEventReceiverStatus.Continue, do not cancel the action, even if properties.Cancel is set to true…

To Setup the Custom Error Page, Continue… (otherwise Deploy)

STEP 6) Add new application page by right clicking the project, and choose Add, New Item. Select Application Page:

Notice it creates a Layouts "Mapped Folder" that gets packaged up in the Feature/Solution…

STEP 7) Add page verbiage and other logic. In my example, I add some language that describes to end users that they need to archive sites (through some external process) rather than delete them:

STEP 8) Deploy and test the new Feature. Right click the project, and click Deploy:

Note – this will automatically activate the feature on the Site collection specified in Step 2.

Now, attempt to delete a site within that Site Collection:

SO EASY!

Phil

Posted at 11:17 AM in SharePoint Development | Permalink | Comments (1)

Technorati Tags: Event Handlers, Event Receivers, SharePoint Deployment, SharePoint Development

10/20/2009

New Event Handlers in SharePoint 2010

With SharePoint 2010, there is now a new host of event handlers that Developers can leverage to interject custom code into their sites when end users perform various actions. To be precise, there are 12 new event handlers available. Notice the chart below, highlighting what is new:

List Events

A field was added

A field is being added

A field was removed

A field is being removed

A field was updated

A field is being updated

A list is being added

A list is being deleted

A list was added

A list was deleted

List Item Events

An item is being added

An item is being updated

An item is being deleted

An item is being checked in

An item is being checked out

An item is being unchecked out

An attachment is being added to the item

An attachment is being removed from the item

A file is being moved

An item was added

An item was updated

An item was deleted

An item was checked in

An item was checked out

An item was unchecked out

An attachment was added to the item

An attachment was removed from the item

A file was moved

A file was converted

The list received a context event

List Workflow Events

A workflow is starting

A workflow was started

A workflow was postponed

A workflow was completed

List Email Events

The list received an e-mail message

Feature Events

A feature was activated

A feature is deactivating

A feature was installed

A feature is being upgraded

Web Events

A site collection is being deleted

A site is being deleted

A site is being moved

A site is being provisioned

A site collection was deleted

A site was deleted

A site was moved

A site was provisioned

Of particular interest is the site provisioning event handlers. I believe this greatly opens the doors for corporations to interject their custom site approval or request workflows into SharePoint, and the obvious, run some custom code on a site after it has been provisioned. Notice that now you are no longer depending on "feature stapling" to execute code on a site after it is provisioned. You can now just attach this web event.

If you recall, feature stapling was/is the action of editing the ONET.xml file within a site definition, adding features to the "WebFeatures" element which would auto-activate features upon provisioning. People would use that functionality to execute code upon site provisioning via a feature activating/ed event receiver, but that is now no longer necessary. Much simpler with this new event!!

Another great improvement to event handlers in SharePoint 2010 is with the improvements to Visual Studio 2010, and what it takes to create them. Notice, when you add a new item into a Visual Studio project, three is an Event Receiver template you can choose from:

When you choose that template, you get a dialog box allowing you to choose what event you want to capture, as well as what content type you want to associate the event receiver with:

After you click finish it will stub out all the code for you! Very slick!

Also notice how Visual Studio 2010 will also stub out all the necessary features and Solution Packages necessary to deploy into SharePoint. Literally all you have to do is hit F5, and then navigate into SharePoint and unit test your event receiver. SO COOL:

It is really great to see Microsoft place such a significant effort on enabling Developers to customize the product, as well as make it so easy to do so (which is so easily seen with their improvements with Visual Studio 2010). Thanks MS!

Phil

Posted at 11:15 AM in SharePoint Development | Permalink | Comments (0)

Technorati Tags: Event Handlers, Event Receivers, SharePoint 2010

10/19/2009

How to Enable the Developer Dashboard in SharePoint 2010

What is the developer dashboard you may say? Well – the developer dashboard in SharePoint gives developers the ability to monitor how well their code base is performing – on a page by page basis. For instance – when enabled, at the bottom of every page you'll see a report of all the custom code that has ran on that page, as well as how long it took to run. This becomes very valuable information especially when querying SharePoint content. You may have several web parts on one page all querying information from across your Farm, and the SharePoint developer dashboard helps you know how well each performs, which can help you identify if one is becoming a bottle neck for your whole page.

Notice this example (the report always shows at the bottom of the master page):

The report shows the following information:

What controls loaded and how long each took to load
What specific database queries executed and the execution time of each
Events that were fired during the page load
Order of the page lifecycle and time during each stage

How to Programmatically Activate the SharePoint Developer Dashboard

Via Command Prompt

Create a new console application visual studio project, and in Program.cs, add the following code:

SPPerformanceMonitor perfmon = SPFarm.Local.PerformanceMonitor;

perfmon.DeveloperDashboardLevel = SPPerformanceMonitoringLevel.On;

perfmon.Update();
Ensure that .NET version 3.5 is specified (SP 2010 is not yet .NET 4.0 compatible)
Also – in project properties Build tab, ensure "Any CPU" is specified (defaults to x86, but SharePoint 2010 is x64 only)
Build, Execute, and Enjoy!

Via Power Shell

$snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'}
if ($snapin -eq $null) {

Write-Host "Loading SharePoint Powershell Snapin"
Add-PSSnapin "Microsoft.SharePoint.Powershell"

}
$farm = Get-SPFarm
$perfmon = $farm.PerformanceMonitor
$level = [Microsoft.SharePoint.Administration.SPPerformanceMonitoringLevel]::On
$perfmon.DeveloperDashboardLevel = $level
$perfmon.Update();
Write-Host "Sucess"

Cheers!

Phil

Posted at 11:14 AM in SharePoint Development | Permalink | Comments (0)

Technorati Tags: Developer Dashboard, Diagnostics, SharePoint Developer Dashboard

09/11/2009

Connected Web Part Mechanisms Compared

Are you looking to connect two custom SharePoint web parts to each other? Did you know there is more than one way to accomplish this? From what I've seen and heard from the developers around me is that most only know of one way, and in this post I'd like to discuss and compare this commonly known way with 2 other ways that are less known…

Approach #1: SharePoint Web Part Infrastructure Connections

This first approach to connectable web parts is by far the most widely known in the SharePoint community. Essentially, you can tap into the SharePoint Web Part infrastructure's connection interfaces to pass and receive data from one web part to another. The setting up of the connection is done through the UI, simply upload the web part(s), edit, and connect:

MSDN Walkthrough: http://msdn.microsoft.com/en-us/library/ms469765.aspx

Strengths

By far the easiest approach to implement from an architecture understandability perspective
By far the least amount of lines of code required
End users can setup/remove the connections, allowing solutions to be built at run time.
ISVs can build generic data points that can interact over the common web part infrastructure with your proprietary web parts or out of box web part.

Weaknesses

Post-backs are necessary (no ajax or client side script)

Approach #2: Client Side SharePoint Web Part Infrastructure Connections

Similar to approach #1, but it supports a client side (javascript) connection without the need to post back to the server when actions occur. If extreme usability is important, going with this approach is worth looking at, but developer beware, it takes more than a "Hello World" to implement client side connections. Here's a good write-up though:http://www.synergyonline.com/blog/blog-moss/Lists/Posts/Post.aspx?ID=20

Strengths

No post backs
End users can setup/remove the connections, allowing solutions to be built at run time.
ISVs can build generic data points that can interact over the common web part infrastructure with your proprietary web parts or out of box web part.

Weaknesses

Complicated implementation for most developers
Not supported in System.Web namespace, must use Microsoft.SharePoint V2 namespace (supportability?)

Approach #3: Client Side Callbacks

Using client side callbacks to connect web parts is not a commonly known or understood method, yet it remains one of my favorite and most frequently used techniques. The basic premise behind the technique is the Consumer web part drops a javascript method onto the page that can callback to the server to execute .NET code. Then, any other web part on the page, even a content editor web part (CEWP), can call that method and pass a parameter into that method, and in essence "Provide" data and "Connect" the two web parts together. Actually, any HTML object on the page can "Provide" data, since it's just javascript we're dealing with. It doesn't even have to be a web part!

For example, the screen shot below shows a data grid, and when a row in the data grid is selected, the "Item Details" web part shows the full details for that row:

Essentially, all that happens is when a user clicks the row in the data grid, a javascript method is called which was put onto the page by the Item Details web part. That Item details web part, on the client side, calls back to the server and executes a stored procedure and returns the result of that call and updates a DIV with that result.

1 - Javascript method dropped on page by "Consumer" web part is called by the "Provider" web part or sundry html object. (in this case when the user clicks a row in the grid view)
2 - "Consumer" web part calls back to server
3 - Web server requests some data
4 - SQL box returns some data
5 - "Consumer" web part updates a div on the page with the result of the callback from the web server

What's great too about this method is it is all ajaxically performed, and in my example I load up a progress bar while the callback is executing:

Strengths

No post backs
AJAX made easy with NO server side dependencies besides.NET 2.0 (not even web.config settings needed!)
Any HTML object on the page can "Connect" to the web part. (think quick launch, top nav, CEWP, C# web part, etc.)

Weaknesses

Complicated implementation for most developers
Isn't apart of the connection "Infrastructure" – so ISV web parts won't know how to connect to your web parts.
End users most likely won't be setting up these connections at run time – these connections typically are built/designed at design time by developers.

Here's a good write up to help you get started with client side callbacks:http://www.beansoftware.com/asp.net-tutorials/client-side-callback.aspx

Phil's Recommendation When to use Which

If you are…

Going to need to allow your end users to setup the "Connections" in the browser:

Approach #1 if you don't care about post backs, and Approach #2 if you do…
You want an AJAX user experience and your end users won't be configuring the connections themselves:

Approach #3 (much easier than #2 to implement)

Cheers!

Phil

Posted at 11:06 AM in SharePoint Development | Permalink | Comments (0)

Technorati Tags: Connectable Web Parts, SharePoint, SharePoint Web Parts, Web Part Connections, Web Part Development

09/08/2009

SharePoint Cross Site Lookup Columns with jQuery

Ever want to use a lookup column in SharePoint to lookup data in a list, but that list resides in a different site collection or site than the one you're in? Well – out of box this isn't possible, but with the help of jQuery and an event handler, it certainly is possible!

The basic idea behind the solution is to use a text column instead of a lookup column, and as the user starts typing in the text column, a Web Service request will fire to the remote site via jQuery to retrieve a list of "Lookup Values" to present to the user in an Auto-Suggest box.

For example – say you have a site with a list in it that contains a list of Projects. Then, in another site that contains Project Documents, you want to associate a particular document with a Project ID from that other site.

All you have to do is start typing the project name in the ProjectID column for that document and the Auto-Suggest box will populate with suggestions based on your search term.

Then when you click an item in the Auto-Suggest box, it will put the Project ID into the Project ID column.

Pretty slick huh? There is one more important aspect of the solution however. As you can tell, a user could easily type in something that is not a valid project ID – so I also included an event handler that executes after the user hits OK. This event handler queries the lookup column list for the value that was typed, and if it is not found, it presents an error to the user that they didn't type a valid ID.

To Download my Visual Studio Project

http://blog.philwicklund.com/CrossSiteLookups.zip

Installation Instructions

Download project and open the LookupProjectID.js file under TEMPLATE\Layouts\Happenings. Edit the following fields to point to the SharePoint list you want to lookup data from:

var urlToWeb = "http://localhost:82";

var listName = "Project List";

var lookupValue = "Title";

In the same file, edit the callingColumnName to specify what text field in your edit form(s) is performing the lookup (this is how the Auto suggest box knows where to position itself):

var callingColumnName = "ProjectID";

Under the EventHandlers folder in the visual studio project, open the ConfirmLegitProjectID.cs event handler. Edit the following values to point to the SharePoint list you want to lookup data from:

public override void ItemUpdating(SPItemEventProperties properties)

{

// EDIT THIS!

string lookupListName = "Project List";

string lookupSiteURL = "http://localhost:82";

string lookupWebURL = "";

In the same file, edit the callingColumnName to specify what text field in your edit form(s) is performing the lookup:

string callingColumnName = "ProjectID";

Build the Visual Studio Project (this spits out a wsp solution file at c:\wsp). Add the solution to SharePoint (stsadm -o addsolution). Deploy the solution via central admin (or -o deploysolution). Activate the feature on the site(s) you want to lookup the data:

DONE!

Credits

I have to give credit to Timothy Groves for providing the jQuery Auto-Suggest box, as well asJan Tielens for his write-up on jQuery and web service calls.

Cheers!

Phil

Posted at 11:04 AM in Javascript Development, SharePoint Development | Permalink | Comments (0)

Technorati Tags: Cross-Site Lookup, Javascript, jquery, Lookup Column, SharePoint, SharePoint scripting

Fail Forward Fast

Become a Fan

Top Tech Links

Recent Posts

SharePoint Development

03/23/2011

External data, Parent-Child workflows, but in SharePoint Designer? Heck yes!

01/21/2011

Developer's Guide to Silverlight in SharePoint

06/22/2010

Building SharePoint Event Receivers in 2010

06/10/2010

SharePoint Workflow Versioning with Visual Studio 2010

11/04/2009

Changing a Document in SharePoint Over HTTP Programmatically

10/21/2009

Building an Event Handler and Custom Error Page in SharePoint 2010

10/20/2009

New Event Handlers in SharePoint 2010

10/19/2009

How to Enable the Developer Dashboard in SharePoint 2010

09/11/2009

Connected Web Part Mechanisms Compared

09/08/2009

SharePoint Cross Site Lookup Columns with jQuery

Search

My Books:

Categories