SharePoint Place

SharePoint 2010 Workflow: Dealing with events in custom activities

2011-06-18T20:14:00.000+01:00

Introduction

In the past few months I've been responsible for designing a workflow solution to support the automation of an asset management acquisitions process for a customer in the US. The last time I worked on a large workflow project, which touched thousands of users and had a truly global reach, was back in December 2009. I was a little bit rusty and have spent one or two days in the last month getting back up to speed. In this blog post, I'd like to talk about a common scenario which will prove as much of a reference for me in the future as anything else.

The common scenario I'd like to deal with is one where there is a requirement to assign a task to users who will only be known at runtime. Further, when these tasks are assigned, depending upon the actual task/form which is in use, you may want to perform different actions.

The Requirements

Provide task management for 1 or more users who will only be known at runtime

Provide a customized summary report to an individual, who will only be known at runtime, which outlines what tasks were assigned, to whom, and what their response was.

If you are familiar with the MOSS 2007 ECM Starter Kit workflow examples then you have probably seen the widely referenced WssTaskActivity custom activity within the ECM Activities solution. This solution was fine for MOSS 2007 but I actually found it a little heavy in terms of code for a lot of scenarios. A much nicer, cleaner and relevent example is the one which has been put together by Scott Hillier. I would point you to his article at

http://www.shillier.com/archive/2010/08/04/CreatingMultipleandParallelTasks%20inSharePoint2010Workflow.aspx

and recommend you read that and become comfortable with the concepts before reading this article further.

The Problem

The main advantage of custom activities in workflow is to increase reusability and repeatability. Using the SPTaskActivity custom activity from the article posted above is a great starting point, but there's something missing. Quite often, what we need to do is provide some notification in the workflow which hosts the custom activity that something has happened e.g. a task has changed. It is possible to deal with all events relating to the custom activity within the custom activity itself but this doesn't provide reusability. We need to achieve this within the host.

The Solution

The solution to this problem lies in the use of DependencyProperty objects to raise a custom event within the host workflow.

Create a custom EventArgs class

Create a DependencyProperty which points to a generic EventHandler

Raise the event at the appropriate point e.g. onTaskChanged_Invoked from within your Custom Activity

Handle the event within your host workflow

Create a custom EventArgs class

First we need to decide what information we need to pass back to the host. For the purposes of this blog post, I've used the TaskEventArgs class from the MOSS 2007 ECM starter kit. The class is very simple and is given below. Create a new class file within your workflow project and paste this code.

[Serializable()]
public class TaskEventArgs : EventArgs
{
   #region Private Variables

   private SPWorkflowTaskProperties beforeProperties = null;
   private SPWorkflowTaskProperties afterProperties = null;
   private bool result = false;
   private string executor = null;
   private ExternalDataEventArgs externalArgs = null;

   #endregion

   #region Public Properties

   public SPWorkflowTaskProperties BeforeProperties
   {
       get
       {
           return this.beforeProperties;
       }
       set
       {
           this.beforeProperties = value;
       }
   }

   public SPWorkflowTaskProperties AfterProperties
   {
       get
       {
           return this.afterProperties;
       }
       set
       {
           this.afterProperties = value;
       }
   }

   public bool Result
   {
       get
       {
           return this.result;
       }
       set
       {
           this.result = value;
       }
   }

   public string Executor
   {
       get
       {
           return this.executor;
       }
       set
       {
           this.executor = value;
       }
   }

   public ExternalDataEventArgs ExternalArgs
   {
       get
       {
           return this.externalArgs;
       }
       set
       {
           this.externalArgs = value;
       }
   }

   #endregion

   #region Constructors

   public TaskEventArgs(SPWorkflowTaskProperties before, SPWorkflowTaskProperties after, string executor, ExternalDataEventArgs externalArgs)
   {
       this.beforeProperties = before;
       this.afterProperties = after;
       this.executor = executor;
       this.externalArgs = externalArgs;
   }

   #endregion

}

Create a DependencyProperty which points to a generic EventHandler

This is pretty simple, and we can use code snippets to create this for us. You will want to ensure you specify that it is a generic EventHandler based on the TaskEventArgs class you've previously added to your workflow project.

public static DependencyProperty InvokeEvent = DependencyProperty.Register("Invoke", typeof(EventHandler<TaskEventArgs>), typeof(SPTaskActivity));

   [Description("Invoke")]
   [Category("Invoke Category")]
   [Browsable(true)]
   [DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
   public event EventHandler<TaskEventArgs> Invoke
   {
       add
       {
           base.AddHandler(SPTaskActivity.InvokeEvent, value);
       }
       remove
       {
           base.RemoveHandler(SPTaskActivity.InvokeEvent, value);
       }
   }

The result should look something like the below

Raise the event at the appropriate point e.g. onTaskChanged_Invoked from within your Custom Activity

The next thing we need to do is actually raise this event. In this instance, I wanted the Custom Activity to really do nothing when onSPTaskChanged_Invoked was fired, I needed this to be handled externally by the host workflow. We can achieve this by first raising the event in the following way:

private void onSPTaskChanged_Invoked(object sender, ExternalDataEventArgs e)
      {
          TaskEventArgs args = new TaskEventArgs(SPBeforeProperties,
                                                  SPAfterProperties, null, e);

          base.RaiseGenericEvent<TaskEventArgs>(InvokeEvent, this, args);
      }

Handle the event within your host workflow

We then need to handle the event in the workflow. Inspect the properties of your custom activity and notice you now have a new event which you can handle.

private void InvokedFromSPTaskActivity(object sender, TaskEventArgs e)
   {
       bool result = Boolean.Parse(e.AfterProperties.ExtendedProperties["Result"].ToString());
   }

The result should look something like the below:

Summary

We have seen how we can leverage a DependencyProperty based generic EventHandler to add more reusability and flexibility to our custom activities within workflow. This is an important technique and one that, at first, may not seem straight-forward but is surprisingly simple.

Deploying InfoPath 2010 forms for custom workflow with SharePoint 2010 and Visual Studio 2010

2011-05-05T12:42:00.001+01:00

I've spent a little time recently structuring a solution in Visual Studio and TFS for an upcoming project that relies heavily on workflow. There are a couple of nuances that I thought I'd document given that the information out there at present seems fragmented at best.

The aim of this blog post is to provide guidance on how to structure a Visual Studio 2010 SharePoint workflow project that includes the deployment of InfoPath forms. This article will not repeat advice which is already in abundance that relates to core workflow development concepts. I assume you're familiar with writing custom workflow in Visual Studio 2008 and MOSS 2007.

Above we see the default solution structure for a state machine workflow.

Add a new Module named "InfopathForms"

You can remove the "Sample.txt" placeholder file. When you do this, notice that Elements.xml for the module will update automatically.

Add your InfoPath form to your InfopathForms module

Double check to ensure that the "Deployment Type" property of your InfoPath form is set to Element File and that the path is "InfopathForms\".

Your elements .xml file should now look like the following

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

</Module>

</Elements>

By default, your feature.xml will look like the following:

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

</Properties>

</Feature>

Now we need to modify our feature.xml to register the location of the forms we want to use and set the correct feature receiver. If you were used to using VSeWSS when developing workflows for MOSS 2007, these steps will have been undertaken for you automatically, you may have had to do little more than modify the path for the RegisterForms property below.

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

<Feature xmlns="http://schemas.microsoft.com/sharepoint/" ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver">

</Properties>

</Feature>

There are two additions here. The first is:

This tells our feature the location of the forms we want to deploy. In this case it is all of the .xsn files within the InfopathForms module.

The second modification is the feature receiver assembly and class:

ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver"

This is necessary in order for the forms to be present within the "Manage Form Templates" screen within Central Administration and is a necessary precursor to making your forms "Workflow Enabled".

At this point there is a ton of other work you need to do around building your workflow, registering your form URNs within the workflow elements file and any deserialization activities you need to do in order to take data from your initiation or association form into your workflow. None of this information is repeated here and I would point you towards MSDN and the numerous blog articles out there on these subjects.

Once you've deployed your solution, your form should now be registered in the correct location. Below we can see our IniitationForm at the top of the list within Central Administration.

Using Modules in this way to manage form templates means we simply need to drag and drop new xsn files into our Module and they will be automatically deployed with our solution. We still of course need to modify the workflow elements file to register the URNs etc but it's one less thing to think about and certainly makes deployment easier.

I hope you've found this article useful and that it saves you some time when transitioning from workflow development using VSeWSS in MOSS 2007 to Visual Studio 2010 with SharePoint 2010. Thanks for reading.

Migrating from Lotus Notes 8.5 to Microsoft SharePoint 2010: Real-world tales from the trenches

2011-05-04T16:58:00.001+01:00

I've just published a new blog post on Nothing But SharePoint which outlines a real-world migration from Lotus Notes 8.5 to SharePoint 2010. I actually went live with this project on the day of the SharePoint 2010 global launch.

European SharePoint Best Practices Conference 2011

2010-11-14T14:11:00.000Z

I am honoured to be contributing to next year's European SharePoint Best Practices Conference 2011 as a speaker.

The conference takes places on April 11th - 13th 2011 at the Queen Elizabeth II Conference Centre, London.

The conferences features 96 sessions , 69 speakers (includes the 15 community track speakers and sessions) and this excludes the sponsor partner sessions, It will be the SharePoint conference to attend in Europe in 2011 no other conference outside Microsoft’s in the US will have this many talented SharePoint speakers in one conference. Exhibitor Party / Conference Party / SharePint night and full set of Video Recorded,MP3 and PowerPoint DVDs sent out after the conference, We are expecting the conference to sell out so booking early is recommended.

More information at http://www.sharepointbestpractices.co.uk/index.html

Self-Service BI and PowerPivot Session @ SharePoint UK User Group - 2nd September 2010

2010-08-30T22:47:00.000+01:00

I'll be delivering another session at the Leeds/Bradford SharePoint UK User Group on 2nd September 2010 on Self-Service BI and PowerPivot. I'll update this post to provide a link to the slide deck after the session. In the meantime, see the agenda below:

Agenda:

- What is PowerPivot?

- Architecture – PowerPivot for Excel and PowerPivot for SharePoint (Analysis Services & Vertipaq mode)

- Installing PowerPivot (Dev/Prod build considerations)

- The client tools – Excel-Add In for PowerPivot

- Connecting to back end line of business applications with a worked example

- Modelling data in PowerPivot with a worked example

- PivotTables/Charts

- Slicing and Dicing data in PowerPivot

- Custom queries using DAX

- Publishing PowerPivot applications to SharePoint

A note on SharePoint and Windows Update KB938444

2010-06-26T08:08:00.000+01:00

A Windows Update security patch (KB938444) has been known to cause a number of issues within a SharePoint farm after its application. Errors such as:

- HTTP 404
- Server Error
- Cannot connect to the configuration database

can appear after applying the patch. You should read Microsoft’s statement on the SharePoint blog and a complete description of the problem from the Small Business Server team at the following locations:

http://blogs.msdn.com/b/sharepoint/archive/2010/06/22/installing-kb938444.aspx

http://blogs.technet.com/b/sbs/archive/2010/06/18/companyweb-and-sharepoint-central-admin-not-accessible-after-installing-kb983444.aspx

Custom Ranking Models with SharePoint 2010: Background, Value and Administrative Overview

2010-06-21T15:11:00.001+01:00

Introduction

At a recent SharePoint user group session, where I spoke on Enterprise Search in SharePoint 2010, I was introduced as discussing the "black art" of search. The reason, I think, that search was described in that way reflects the way in which most people think about search: something that is pervasive and quickly yields the information required, usually on the first page of results. It's fair to say that the average user doesn't comprehend the complexity and effort required to maintain relevancy, and nor should they need to.

With the accuracy, power and flexibility of the big-name internet search engines comes a certain expectation from end users in terms of search engine performance behind the corporate firewall. Striving to achieve the same level of fidelity of search results behind the firewall with most Enterprise Content Management (ECM) systems presents a major challenge and administrative headache. SharePoint 2010 alleviates some of this pain and provides the ability to override the default ranking model for enterprise search results. This enables the development of application and organisation specific enterprise search applications which provide contextual results.

This article is the first of a series I'll produce on custom ranking models with SharePoint 2010. The aim of this article is to provide a background on custom ranking models, why they're important and how SharePoint 2010 supports the implementation and management of custom ranking models through PowerShell and XML configuration files.

Background on Custom Ranking Models and SharePoint 2010

The ranking model that SharePoint 2010 uses is based upon BM25F. BM25F is actually BM25, a ranking function originally implemented at London City University, with field weighting and per-field length normalisation and provides support for weightings for managed properties/metadata amongst other things. It is at this point that I would strongly urge the reader to investigate the references at the end of this article. There is an extent to which the successful implementation of custom ranking models depends upon foundation knowledge of BM25F.

There are nine ranking models available out of the box with SharePoint 2010 and these are:

Main Results Default Ranking Model
Expertise Social Distance Ranking Model
High Proximity Ranking Model
Main People Social Distance Model
Expertise Model
Name Social Distance Ranking Model
Name Model
Main People Model
No Proximity Model

There is no support to modify these ranking models and you must create your own. For reference purposes, these can be viewed within the MSSRankingModels table of the SSA Admin DB as shown below:

I would urge you to 'look' at these ranking models in a development environment because that will give you an idea of the power and flexibility that you can leverage through XML files alone.

Why are custom ranking models important?

Custom Ranking Models are important because they allow search results to be tailored based upon what we know is already important within our organisation. Consider an Enterprise Search Center for a Sales division within an organisation. Sales people are sales driven and have an much greater interest in specific content types and information than others e.g. a PowerPoint slide deck relating to a SharePoint sales pitch rather than an extensive Word document along the technical aspects of SharePoint Enterprise Search. Ranking Models, simply put, allow us to define what is appropriate and relevant within a specific organisation and promote/demote search results based on the criteria that we define.

The Ranking Model Schema

Microsoft provide a ranking model schema, given below, which provides a blueprint on which to validate your custom models.

</queryDependentFeatures>

</categoryFeature>

</queryIndependentFeature>

</queryIndependentFeatures>

</rankingModel>

This basic blueprint will be explored in future articles as we discuss the actual development of custom ranking models. For now, I would draw your attention to the QueryDependantFeature and QueryIndependantFeature XML elements.

Query Dependant Features within the ranking model provide the ability to define managed properties which supports dynamic ranking. Query Independent Features are static ranking properties that apply irrespective of the query issued or the results returned. Why is this important? Well… we may want to stipulate that we always want to rank PowerPoint presentations above Word documents. We could then express this as a Query Independent Feature.

Administrative Overview

The power of custom ranking models becomes even more impressive when we realise that developer intervention is not necessary for their implementation and management. The necessary tools to implement and manage custom ranking models are PowerShell and XML.

Managing custom ranking models with PowerShell

There are four PowerShell cmdlets that provide the functionality to manage existing, and implement new, ranking models.

Get-SPEnterpriseSearchRankingModel	Returns a ranking model
New-SPEnterpriseSearchRankingModel	Adds a ranking model to a shared search application
Remove-SPEnterpriseSearchRankingModel	Deletes a ranking model
Set-SPEnterpriseSearchRankingModel.	Sets the properties of a ranking model for a shared search application

These speak for themselves and I won't discuss each in turn any more than the descriptions given above. Suffice to say, I urge you to look at those cmdlets within PowerShell and take some time to understand their parameters.

Applying custom ranking models in Enterprise Search

Once you have a custom ranking model applied, using the aforementioned PowerShell cmdlets, there are three ways in which you can test the effects that other ranking models have on search results.

Add rm={GUID} parameter to your search centre query string

This is the easiest way to test the effects that a custom ranking model will have on search results and is probably the route you will take during development and testing. To quickly see how search results change based on different ranking models, you can take one of the GUIDs from the ModelId column in the MSSRankingModels table and apply that.
Export Core Results WebPart, modify RankingModel parameter and reimport

This is useful when developer intervention is not required or available. A standard out of the box Core Results Web Part can be exported to a .webpart file. An administrator is then able to modify this file and insert the GUID of the ranking model to use before reimporting the file into the page or Web Part gallery.
Inherit the Core Results Web Part and wire up your ranking model in code

This is the most likely option when there is already a development effort underway or there are other specific customisations to the Core Results Web Part needed.

What's next?

The next article will explore the development of custom ranking models. This would benefit from an entire blog post of its own. For now, and before you embark on developing custom ranking models, I would urge you to begin to understand the fundamental concepts of BM25F and begin to identify what information is important to your organisation that you can use to influence ranking.

References

Microsoft Cambridge at TREC–14: Enterprise track
http://trec.nist.gov/pubs/trec14/papers/microsoft-cambridge.enterprise.pdf

Slide deck from SharePoint User Group -18th May 2010 - Enterprise Search and SharePoint 2010 - What's New?

2010-05-24T08:11:00.000+01:00

I presented at the SharePoint User Group UK in Nottingham on 10th May 2010. I covered Enterprise Search in SharePoint 2010 from a "What's New/?" perspective around architecture, development and administration.

The demos were how to create a Custom Connector for BCS and Search and Administering Custom Ranking Models using PowerShell and XML. Feedback is welcome, as always.

Download my slide deck here

UserSelectionMode issue when extracting Person/Group field definitions in WSS 3.0/MOSS 2007

2010-03-23T10:57:00.001Z

An issue exists when extracting Person or Group fields from SharePoint, specifically using SPSource but I'm guessing this issue transcends the use of SPSource due to the following article from http://support.microsoft.com/kb/934613.

The issue is that when you've extracted a field you may see an 'invalid' attribute value in UserSelectionMode="PeopleOnly". Basically this value should be 0 for people only as the schema defines this as an int. If you attempt to deploy a field definition in XML via Elements.xml you'll see the following error:

Feature definition with Id xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx failed validation, file 'ECM.SiteColumns\Columns.xml', line 17, character 98:

The 'UserSelectionMode' attribute is invalid - The value 'PeopleOnly' is invalid according to its datatype 'http://www.w3.org/2001/XMLSchema:int' - The string 'PeopleOnly' is not a valid Int32 value.

ECM.wsp: The Solution installation failed.

The value for UserSelectionMode should be set to 0 for PeopleOnly or 1 for PeopleAndGroups. I haven't tested yet, but I wonder whether this would be valid if the field was provisioned programmatically using AddFieldAsXml() method. This would then yield consistent behaviour with the <Customization> child element bug discussed on the SharePointDev wiki @ http://sharepointdevwiki.com/display/public/SharePoint+Custom+Fields?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SharepointDevWiki+(SharePoint+Dev+Wiki+RSS+Feed)

First article published on EndUserSharePoint.com

2010-03-05T15:47:00.001Z

Head on over to www.endusersharepoint.com and read my thoughts on the business value of SharePoint, and why we need to understand how that value changes when we apply SharePoint to different levels of an organisation.

Developing Custom SharePoint Timer Jobs and the importance of separating SharePoint development from SharePoint deployment

2010-02-24T20:04:00.001Z

The catalyst for me writing this blog post was a pretty standard requirement for a daily timer job on a Web Content Management (WCM) project for a customer last week. I spent the best part of a day writing the logic for the timer job inside a Console Application project where the debug cycle is far greater reduced. I then spent 5 minutes packaging that up and deploying. I then decided I needed to modify the schedule which was originally set via the Feature Receiver but I didn't want to redeploy or reactivate, and nor should I. This reminded me of how many more junior SharePoint developers I see who forget very basic rules about not confusing the development process with the deployment process. This blog post discusses the resources, and methods I used to quickly wrap a piece of SharePoint functionality into a timer job, deploy it to a WSP and modify its schedule via the UI.

So, after you've got your logic written in your Console Application and you want to package that up into a timer job, then what? Well, that's pretty simple. Visit Andrew Connell's blog and read his article on Creating Custom SharePoint Timer Jobs. This isn't groundbreaking, complex code but quite simply put; it works. In the interests of brevity I'm not going to repeat any content here. One thing you will notice is that the scheduling for the job is inside the FeatureActivated() event within the Feature Receiver. This is fine if you know the schedule at the time you deploy. The chances are however you're going to want to modify the schedule after you've deployed when the customer inevitably changes their mind about when, and how often, a specific piece of functionality runs. For this, there's an awesome tool on the CodePlex website called SharePoint Timer Job Administration. This is an awesome piece of software that gives you a link within SharePoint Central Administration called "Manage Timer Jobs" where you can modify the schedule and disable/delete timer jobs. Simply modify the UI and restart the Windows SharePoint Services Timer Service (OWSTimer.exe) and you're good to go.

So my point? By 4:30pm last Thursday I had a piece of code written and tested. By 5pm that code was wrapped in a timer job, packaged inside a WSP and deployed into a customer environment. From that point its schedule was modified multiple times via the browser. Even though I understand how to write timer jobs and how to package SharePoint artefacts into deployable solutions, I would have wasted a great deal of time if I was deploying code into SharePoint inside a timer job from the beginning. Imagine how much timer I'd have wasted if I didn't understand SharePoint timer jobs and I did that? We need to think about what it is we're testing when we write SharePoint code and be absolutely sure to separate functional testing of SharePoint artefacts (Content Types, Site Columns, Timer Jobs) from their deployment. Tools such as the SharePoint Solution Generator, and more recently SPSource, make it so much easier to separate development from deployment and we should take full advantage of them. These tools allow us to generate entire publishing solutions via SharePoint Designer and the SharePoint UI and extract them afterwards. I wrote a tweet today on how the variety and quality, in general, of CodePlex tools make the life of a SharePoint consultant so much easier. I meant it, too.

Programmatically creating Word documents in SharePoint with the OpenXML SDK

2009-12-22T18:30:00.001Z

A requirement on a recent SharePoint workflow development project involved the programmatic creation of a formatted Word document. The Word document itself was simple: a title and a table. The table contains rows for each SPListItem in an SPListItemCollection object. I spent a little while looking at how to achieve this without the use of Word automation/Interop before deciding to examine how quickly I could achieve this using the OpenXML SDK and streaming the contents of the XML into an SPFile object. This blog post describes the chosen approach.

Caveats: This post focuses on concepts rather than posting hundreds of lines of code. The idea is that you can take away a good understanding of the tools available to quickly generate OpenXML compliant documents and write them back to SharePoint. This post assumes a good level of knowledge of the SharePoint API and refactoring complex, auto-generated code from productivity tools such that it's production ready. This post also does not focus on using a .dotx template which in hindsight, would have been more appropriate. We'll leave that as a task for the reader :)

Okay.. so lets get started!

You will need to download the OpenXML SDK 2.0 (OpenXMLSDKv2.msi) and OpenXML Productivity Tool (OpenXMLSDKTool.msi) from the following location:

http://www.microsoft.com/downloads/details.aspx?FamilyId=C6E744E5-36E9-45F5-8D8C-331DF206E0D0&displaylang=en

Step 1. Setup your project

Once you have the SDK and productivity tools installed, create a new Console Application and add a reference to DocumentFormat.OpenXml.dll.

Step 2. Generate your base document

The approach I took to quickly generate a document was to create the skeleton layout of the document as shown below. In this instance, I wanted to generate a table with rows comprised of items from an SPListItemCollection.

Step 3. Generate your code stub

The OpenXML productivity tool now allows us to generate a C# stub of code, albeit quite verbose, that represents that document. Open the productivity tool from it's location on the file system (the actual file is OpenXmlSdkTool.exe) and click "Open File" and locate your previously created Word document. Now you need to click on "Reflect Code". The productivity tool will produce a code stub for you. Copy the contents of this file, obviously amending namespaces as necessary etc into your Visual Studio project.

Step 4. Refactor

What you are now able to do is create multiple instances of that document. This of course is no use, so we need to do some refactoring. The extent and nature of the refactoring process depends upon what you want to do. As such, I'm not going to post large amounts of application specific code, rather I'll focus on concepts.

In my case I needed to modify the constructor to take an SPListItemCollection which I then wanted it to use to generate a document and write that back to a document library. As such I modified the signature and behaviour of the CreatePackage() method such that it looked as follows:

public void CreatePackage(string fileName, SPListItemCollection Items,
            string destinationOutputListName)
        {
            this.fileName = fileName;
            this.items = Items;

            SPFolder folder = web.GetFolder(destinationOutputListName);
            using (MemoryStream memoryStream = new MemoryStream())
            {
                using (WordprocessingDocument package = WordprocessingDocument.Create(memoryStream, WordprocessingDocumentType.Document))
                {
                    CreateParts(package);
                }

                SPFile file = folder.Files.Add(fileName, memoryStream, true);
                file.Update();
            }
        }

The next piece of refactoring I did was inside the auto-generated method called GenerateMainDocumentPart1Content(). I created two methods, one called GenerateTable() and another called GenerateTableRows(). By default, the productivity tool will create the Table structure for you, what I needed to do was add multiple instances of TableRow objects to the Table object for my list items.

If you create a basic Word document as I did, and search through the code you'll see exactly how the Table object is being created. Based on the initial structure I had, the auto-generated code stub would create one row for me (the headers) which is great. I simply needed to refactor this code out into it's own method and call it multiple times, with each row being populated from each SPListItem. The end result of this is of course a document that looks something like this:

from a base SPList which may look something like this:

Step 5. Package it up

Exactly what you do here depends also depends upon your requirements. In my case I wrapped up these assemblies to be called from an external workflow, this could easily be a web part or some other SharePoint piece of functionality. Either way, you could quite easily call it in the following way:

        MyWordDoc generatedWordDoc = new MyWordDoc();

                SPListItemCollection items = web.Lists["Links"].Items;

                generatedWordDoc.CreatePackage("MyWordDoc.docx", items,
                    "Shared Documents");

Until next time... happy SharePointing.

AllowInsecureTransport issue with SharePoint 2010 Public Beta Install

2009-11-18T22:01:00.000Z

So, after the brouhaha regarding the public beta release of SharePoint 2010 it seems that installing the product is not straight forward when using Windows 7/Windows Server 2008 R2.

There's an issue with WCF in .NET 3.5.1. where SharePoint relies on an attribute that isn't present, namely AllowInsecureTransport. You can simply remove this from the client.config files but this will break other services. There is talk of other work arounds but at the minute, the official advice if you want to run SharePoint 2010 Public Beta on Windows Server 2008 R2 is to wait for the official WCF Fix from Microsoft.

When this is available, it can be downloaded from: KB976462 at present this is not available.

Note: There is a WCF Fix available for Windows Vista/Windows 2008 which will fix this issue which is available from here KB971831 note that this fix is NOT for Windows 7/Windows Server 2008 and if you attempt to install it you will receive the "This update is not applicable to your computer" error and the install will terminate.

Using the PortalSiteMapProvider to query data from large lists

2009-11-12T18:31:00.001Z

Okay folks, one from the archives but certainly worth rediscovering.

Working with Large Lists in Office SharePoint Server 2007 from Microsoft. The performance metrics for querying large lists in SharePoint using the PortalSiteMapProvider object are quite impressive. I often see customers wanting to manage large lists in SharePoint but hardly ever see implementations using the PortalSiteMapProvider. Well worth a (re)read!

VHD Boot and Windows Server 2008 R2 for SharePoint 2010 Development

2009-10-25T17:13:00.000Z

OK, I think I may have came to the party slightly late with VHD Boot. It's one of those things that I've been meaning to look at for quite a while but never got around to. The performance hit that my VM took when running SharePoint 2010 on Windows Server 2008 inside VMWare/Sun VirtualBox served as something of a catalyst.

Simply put, VHD Boot allows you to boot from a VHD running Windows 7/Windows Server 2008 R2 operating system natively. My base setup is a Dell Latitude D630 with 4GB RAM running Windows 7 as the host OS. The steps I took were as follows:

Booted from a Windows Server 2008 R2 CD
Chose the "Repair my Computer" option
Opened diskpart from the command prompt
Created and mounted a new VHD file on my local disk, note: not an external USB drive, by doing the following:

create vdisk file="d:\vhdboot\sp2010.vhd" type=expandable maximum=40960

select vdisk="d:\vhdboot\sp2010.vhd"

attach vdisk
I then closed the command prompt window, closed the repair options and went back to setup
The newly created drive was available as a resource to install to
Install Windows Server 2008 R2 as usual
Your boot menu will now have Windows Server 2008 R2 available as a bootable resource

Enjoy all

Extending Enterprise Search: Programmatically creating Keywords and Best Bets from existing business data

2009-08-15T22:25:00.001+01:00

I've been working with a number of customers lately on strategies to increase the value that enterprise search delivers to their users. I'm interested in "quick wins" with SharePoint: Low cost, high visibility solutions that increase user adoption and add real value to a customer's implementation. I recently had a conversation with some members of the SharePoint community who said that Enterprise Search was a good example of a quick win. I disagree strongly on this point. Simply enabling search within SharePoint will not, in my experience, enhance user adoption or deliver an intuitive and helpful user experience. The implementation of enterprise search is an iterative process of plan, design, implement and review. The correct implementation of keywords, best bets, scopes, managed properties and any number of customisations make search work in an individual environment but it is close to impossible to get enterprise search working optimally first time around. Today I'm going to talk about keywords and best bets and why there is value in creating these programmatically.

N.B. for examples of how to achieve this programmatically, please see Stefan Goßner's blog post listed in the references at the end of this article.

Keywords and Best Bets

Keywords provide a way to supplement search results to deliver a context specific definition for a specific search term. Best bets provide a way to add URLs to these keywords that point to where the user is most likely going to want to go to find the information, given their original search term. The screenshot below shows Keywords and Best Bets in action.

Figure 1: Keywords and Best Bets in action

Why create them programmatically?

The reason to create keywords and best bets programmatically is to increase the value of enterprise search by supplementing search results with information the user is likely to want to know from information that already exists within the business – and there may be a large number of these! This point is worth examining a little further. SharePoint delivers true enterprise search capable of connecting to a number of different types of data sources. In practice every data store in the business is hardly ever indexed by SharePoint, so there is nearly always a gap between what the business knows and what SharePoint knows.

Exactly what keywords and best bets you will need to create will of course depend upon what data you have and whether that is already indexed by SharePoint. One good example is to create keywords of all customers from a CRM system, An internal user then can search for "Customer ABC" and be immediately presented with the customer's name (Keyword), the customer contact details (Keyword Description) and a link to the customer BDC profile page or some other location within SharePoint. The ability to make enterprise search ubiquitous in SharePoint means that users can tap in a customer name from anywhere in SharePoint and immediately get important contact information and links to additional information about the entity.

This is one example and the real value is how this works in individual scenarios with real data. The important "take home" point is that we should think about how we can use keywords and best bets to enhance the user experience with information we already have available. This information may reside within SharePoint already, it may exist in the SharePoint index via BDC crawls or it may exist completely outside of SharePoint altogether. Wherever it exists the important thing is that we make best use of it to extend enterprise search functionality and enhance the user experience.

References

Stefan Goßner: How To: create Keywords and Best Bets for MOSS Search programmatically
(http://blogs.technet.com/stefan_gossner/archive/2007/03/28/how-to-create-keywords-and-best-bets-for-moss-search-programmatically.aspx)

Figure 1 Image sourced from http://technet.microsoft.com/en-us/library/bb905371.aspx

Finally...

2009-08-08T17:44:00.001+01:00

Blogging is something that I've played around with a few times in the past, and never really followed through on. The principal reason for this is that there has never really been a focus. Well, all that is to change!

As some of you may, or may not know, I'm a Microsoft SharePoint consultant working for a leading Gold Partner in the UK. The work I undertake with customers ranges from helping them develop a business case for SharePoint, through to infrastructure/health-check work and development. The emphasis of the development work I'm currently involved in is around Enterprise Search and general WCM and Publishing. Naturally, there are a lot of things that I see during my time working with customers where I think "you know... I think some other folks really would be interested in that". This blog will serve as a place for recording them in the hope they may help others. More soon...