It seems to me that this falls into 3 reasons:

1. They don’t realise the effort involved in the different approaches.
2. They don’t have the vision for small, targetted applications.
3. They feel ’safe’ having a box with a brand.

Comparisons of effort

I believe that enterprise web applications are becoming more complex. The latest one I’m working with - SharePoint 2007 - is vast, so much so that it’s now hard to imagine that a single person can be familiar with all of it’s features. This is, I believe, due to it being designed to ‘fit all’ needs. Consequently, configuring and administering it, well, that’s going to take skill and effort. It isn’t like just installing some application.

That’s fine if you want a lot of it’s features - but if you don’t, then let’s look at a custom application. While industrial grade web apps have been getting bigger and more complex, creating web applications has become simpler. There are various frameworks - Rails, Struts, .NET - designed to make this easier. It used to be that I’d have to write a login system for each site I built - nowadays, such things are given. This has the upshot of reducing the effort of building a bespoke application, while at the same time the effort of using a big web application is increasing.

As a side note, I guess that that is what the fuss over web services is, really. Building small, comparitively simple web applications that can be assembled into bigger applications.

Knowing what you want

I think that knowing what they want is where most customers fall down. It’s a typical feature of the Dilbert cartoons, and I think everyone in IT recognises it. Really, this falls into my person obsession - the specification. The specification is everything - all of the technical task of actually developing an app is fluff next to knowing exactly what it is you want to do.

Sadly, many customers don’t like to think too hard about what it is they want. They might have a strong vision for the system, but fail to communicate it. They might not really know what they want the system to do. They might not even review the specification at all, as they’ve told the development team what they want, and this was clear to them, so the developers should understand too.

Anyway, my point here is that the vast ‘fits all’ type of application has the advantage that, to a degree, you can make up how you’re going to use it as you go along. You’ve got all theses features - now you just choose to use them. The disadvantage is that you’re constrained by those features too - if you want to do something a little different to what they were designed for, well, making that happen can be ‘fun’, and that’s where I make a living.

The safety of the box and the brand

Boxes and logos seem to hold a near religious faith in some organisations. Personally, I’m unconvinced, though I can see their argument. For example, big companies - Microsoft, Sun, Corel, whatever - aren’t going to vanish overnight. Hell, some of them seem to be steaming along on momentum quite comfortably. Buying from a small company, well, that’s more risky. What if they go bust? Are you left with a legacy app and no way out? What if they project goes terribly wrong - how do you sue for tens of millions? How big is their support department?

Personally, I think all of these things have easy enough answers. What if they go bust? Well, why not keep the code in escrow - if the supplier goes under, the customer gets the code and documentation on exactly how the system works, specifically so that they don’t get stuck in some technological blind alley. What about big legal claims? Well, isn’t that what insurance is for? Factor that into the cost of the project. And as for support - well, when was the last time you got much assistance from Microsoft? (That’s not meant to be anti-Microsoft - just a recognition of the fact that they have the biggest support nightmare on the entire planet). Even smaller suppliers can often only give much support to their bigger customers.

I suppose I should state my sources too. I started by following the MSDN Webcast ‘Developing Workflows for the 2007 Version of the Microsoft Office

SharePoint System and Windows SharePoint Services 3.0‘. It’s well worth watching - it’s the most complete demonstration I’ve seen - but found that I couldn’t get the InfoPath forms to show for tasks. I figured this one out (see below) based on a blog post ‘My Key Note Demo - SharePoint v3 OM, SharePoint v3 Workflow, InfoPath and Office 2007 Client Add-Ins‘. See the demo code.

Use the Visual Studio SharePoint Workflow Project Templates - Sounds obvious, I know, but you might not know that there is such a thing. Indeed, I believe that this hasn’t been released to the public yet (I’m not entirely sure how we laid our hands on them), and I didn’t know that such a thing existed at the time. I tried using normal workflow projects - a bad idea. Don’t do that.

Modify the install.bat file - It tells you how to do this at the top, but this one caught both myself and other guy out - I thought it would have changed the values in it to the appropriate values, and my colleague didn’t realise that something in there would have to change at all. It’s not hard - just find and replace stuff- and this is described in the batch file itself.

Configure up the Features and Workflow XML files - There are snippets to help do this, although I’m not entirely sure I understood how I added them. It was from the ‘Tools’ > ‘Code Snippets Manager’, but my notes are vague after that. My colleague says his were already configured. Anyway, the snippets themselves are pretty useful, and have reasonable instructions themselves.

Sign the code - You need to sign your code using this keys thing in .NET. (Yes, I’m a .NET rookie, but I recognised this from Java). This allows you to put the assembly in the GAC and also find….

PublicKeyToken - Don’t forget to fill this in on the Workflow.xml file. There are more instructions in the snippet about what goes there.

Do all your GUIDs - Do all the GUIDs in the XML files, and make sure they’re all different.

Specify the InfoPath Forms you want included - These must be installed with the workflow feature, and not installed separately by hand. If you do that, then you’ll get an error “This form cannot be opened. It is not workflow enabled.” I went to the ‘Manage Forms Templates’ page in SharePoint Central Admin - and yes, there’s a column marked ‘Workflow Enabled’, and no, my form was not enabled. That seemed likely to be the problem then, but I couldn’t find anywhere to set the workflow to ‘enabled’ anywhere in SharePoint, or (for that matter) Infopath.

Turns out it isn’t possible - it is defined by how the form was installed. Some silly bugger (me) had forgotten - in the features.xml file we have the XML:

<Property Key="RegisterForms" Value="*.xsn" />

This means that any forms in the root of the Visual Studio Project will be added in to SharePoint when you run the Install.bat file. Install your XSN files this way, and they’ll be workflow enabled.

Accessing the form data - This bit took a bit of figuring out, but I found a good example from 7 Development Projects with the 2007 Microsoft Office System and Windows SharePoint Services.pdf. It’s a little out of date in some of it’s code examples, it appears, but this seemed to work.

SPWeb aSite = new SPSite(workflowProperties.SiteId).OpenWeb(workflowProperties.WebId);
SPListItem anItem = myWeb.Lists[workflowProperties.ListId].GetItemById(workflowProperties.ItemId);

//Log Item Name, and what List the form is in
Log(”Running against: ” + anItem.Name.ToString() + ” in ” + anItem.ParentList.ToString());

//Log some properties.
Log(”PropertyA: ” + anItem.Properties["PropertyA"].toString() );
Log(”PropertyB: ” + anItem.Properties["PropertyB"].toString() );

//Update properties as you would update a normal SharePoint item through code
anItem.Properties["PropertyA"] = “Some Fixed String”;
anItem.Properties["PropertyB"] = TaskProperties1.ExtendedProperties["PropertyB"];

anItem.update();
Deserialize Initiation Data - Initiation form data comes in from an Infopath form as a serialized XML string. It needs deserialised, and used. I used xsd.exe to create a .cs file defining a class (WFTaskForm) of the same format as the xsd for my InfoPath XSN file. See the webcast mentioned at the top for an example. To deserialize:

String initData = workflowProperties.InitiationData;

XmlSerializer serializer = new XmlSerializer(typeof(WFTaskForm));
XmlTextReader reader = new XmlTextReader(new System.IO.StringReader(workflowProperties.InitiationData));

WFTaskForm wfTask = (WFTaskForm)serializer.Deserialize(reader);

_Text1 = wfTask.Text1;
_Text2 = wfTask.Text2;

Creating Workflow Tasks - This seems to involve a little code. You have to Assign a GUID, etc.. In this instance, I’m assigning the task to the workflow originator.

private void createTask1_MethodInvoking(object sender, EventArgs e)
{
Log("Creating Task");

TaskId1 = Guid.NewGuid();
TaskProperties1.AssignedTo = workflowProperties.Originator;

//Note the double escape, or use an @ - otherwise your AssignedTo will be mangled.
//TaskProperties1.AssignedTo = “SOMEDOMAIN\\SOMEUSER”;

//This is important later - see below
TaskProperties1.TaskType = 0;
TaskProperties1.Title = “AutoTask: ” + _Text1 ;
TaskProperties1.DueDate = DateTime.Now.AddDays(4);

TaskProperties1.ExtendedProperties["Text1"] = _Text1;
TaskProperties1.ExtendedProperties["Text2"] = _Text2;
}

Attach your Infopath forms - This was a right bugger to figure out. I’ll include the entire workflow.xml file from my test project:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Workflow
Name="HelloStateSharePointWorkflow"
Description="This workflow creates a task, which is completed when it is changed."
Id="{8F80610C-DF9F-49e4-8C6F-4B4822610086}"
CodeBesideClass="HelloStateSharePointWorkflow.Workflow1"
CodeBesideAssembly="HelloStateSharePointWorkflow, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=bc5e740d61a52a8d"
TaskListContentTypeId="0x01080100C9C9515DE4E24001905074F980F93160"
ModificationUrl="_layouts/ModWrkflIP.aspx"
InstantiationUrl="_layouts/IniWrkflIP.aspx">

<Categories/>
<!– Tags to specify InfoPath forms for the workflow; delete tags for forms that you do not have –>
<MetaData>
<Instantiation_FormURN>
urn:schemas-microsoft-com:office:infopath:Template1:-myXSD-2006-06-08T14-13-41
</Instantiation_FormURN>
<Task0_FormURN>urn:schemas-microsoft-com:office:infopath:Template1:-myXSD-2006-06-08T14-13-41</Task0_FormURN>

<StatusPageUrl>_layouts/WrkStat.aspx</StatusPageUrl>
</MetaData>
</Workflow>
</Elements>

So, first off, let’s look at the ‘TaskListContentTypeId’. This took me ages to figure out. I tried reading the MSDN documentation on how to do this, but that doesn’t seem to work for me. It also seemed substantially different to the web-cast mentioned above - there was nothing to do with Content types in the webcast, but it seems core to the MSDN documentation about this. Anyway, I reverse engineered mszcool’s post, and found I was missing this attribute from the Workflow tag.

I was a little puzzled as to what content type value to put in the attribute. Looking at the Task list I was using, I discovered that if I went to ‘Advanced Settings ‘ and allowed management of content types that the settings page now exposed the Content Types available to that list.

These were ‘Task’, ‘Workflow Task’, and ‘Workflow Task with InfoPath form’. I copied the content type id for ‘Workflow Task with InfoPath form’ from the url of the ‘List Content Type: Workflow Task with InfoPath form’ page, used that, and reinstalled the workflow. This didn’t work, so I tried the content type id that was the same as in the demo. As the ID I’d just tried had the same first 42 characters as the entire of the id in the demo, this wasn’t as random as it seems. This worked, and my InfoPath form was displayed!

Naturally, I wondered why this was the case. I went back the the ‘List Content Type: Workflow Task with InfoPath form’, and was puzzled by the ‘Parent’ being ‘Workflow Task with InfoPath Form’. Clicking on that took me to ‘Site Content Type: Workflow Task with InfoPath form’, and this has the ID that I’d just used. Note that that is a SITE content type, not a list one, and it appears to be in a ‘_hidden’ group, which might explain why I didn’t find it when looking at Site Content Types.

What I think is happening is that the new TaskListContentTypeId attribute tells the workflow that it’s tasks should display infopath forms, and that this was lacking before. I’m hoping that someone might be able to elaborate - and tell me how I find out what other ‘hidden’ content types there are in SharePoint.

Anyway, this seems to tell SharePoint to use an InfoPath form, but which one. In the exmpale above, we have a tag <Task0_FormURN>. The ‘0′ in the tag name matches the TaskType we set in the task properties (see the section above). If we wanted a second form for a different step, it would be <Task1_FormURN> and we would set the TaskProperties2.TaskType = 1;.

That seems to work nicely!

What I still can’t do:

Start a workflow when a new Item is created - I keep getting an error, and I’m not sure what. I’ve looked in the logs, and the error I have is:

06/20/2006 12:00:28.75 OWSTIMER.EXE (0x064C) 0x0D08 Windows SharePoint Services
Workflow 72et Exception

System.ArgumentNullException: Value cannot be null.
at Microsoft.SharePoint.Workflow.SPWorkflow.GetReservedItemId(SPList list, Guid taskId, Boolean createNew)
at Microsoft.SharePoint.Workflow.SPWinOEItemEventReceiver.CreateListItemSubscription(Guid subscriptionId,
SPWorkflow workflow, SPList list, Guid channelTypeId, Guid staticCorrelationId, Guid dynamicCorrelationId,
Guid subEventType, SPEventReceiverType rt, String assemblyName, String className, String eventName,
Int32 itemId, Boolean fReserveId)
at Microsoft.SharePoint.Workflow.SPWinOETaskService.CreateSubscription(MessageEventSubscription sub)
at Microsoft.SharePoint.Workflow.SPWinOESubscriptionService.CreateSubscription(MessageEventSubscription sub)

I’ve searched on Google, and I get nothin’! If I create a workflow without ‘Create Task’ activities, it runs just fine. I’m not sure what the issue here is.

I’ll try and update my site when I discover new stuff - and hopefully not quite as much as in this post…

Info:

I found these links recently - they’re quite handy:

InfoPath forms for Workflows

How to: Design an InfoPath Form for a Workflow in Office SharePoint Server 2007

Upcoming info:

MSDN Webcast: Developing SharePoint Workflows Using Visual Studio 2005

Comments from my old blog:

Okay, so I know I just made that comparison so that it wasn’t like-for-like by excluding cost, but it seems to me that tailors are a good analogy - and that the shopping habits of the well dressed man and the well equiped company are quite different.

Consider the suit. You can buy one ‘off the shelf’. It won’t fit as well as one made specially for you, but it might fit well enough. Sure, the legs might be a little long, and it’s a little broad across the back, but hey, it’s a lot cheaper.

Another option would be to get a bespoke suit. Bespoke it a wonderful word that makes me think of bicycles, but here I mean it as ‘made to measure’. You suit will be unique, comfortable and well fitting, and it’ll cost much, much more. I know I’ll have made it when I get a bespoke suit.

The third option is to get the cheap suit, and have some alterations done. That is, you get someone to make small changes to the cheaper suit, so you get a better fit, and it still costs less.

Software is the same. It can be made for you, you can buy it off the shelf, or you can buy it and hack it until it does what you want it to. (I mean ‘hack’ in the old school way, not the illegal way).

Most people, when they buy suits, just keep shopping until they find one that fits. The luck few (or those unlucky enough to have unusual measurements) get them made for them.

Companies and software doesn’t seem to be the same though. They’re in all shapes and sizes, and as profitability often depends on good software enabling your processes, they all want suits that fit very, very well.

Lucky companies can find a bit of software that fits just perfectly, and within specialised fields, there are products like that. This is great - the suit is cheap and fits well. However, most companies have oddities that mean, for certain applications, no software fits very well. I guess, companies have less regular measurements than people.

So, now they’ve got a choice - bespoke, or get something and customise it. Actually, here the analogy breaks down a bit - there is a third option. Some software is built to be highly flexible and adaptable, so that it can fit many jobs. I kind of think of this as a ’shrink to fit’ suit - I know, it’s straining. Humour me.

Okay, so, imagine we get some software and decide to customise it. Customisation costs, and it means that what you’ve got isn’t exactly the same as anyone else. You need someone to figure out what needs done, and make the changes for you. The constraints of the system can make some of those changes hard. Indeed, if the software fits poorly enough, you can end up having to rip the whole thing apart and rebuild it to do what you wanted to (Been there, done that). Indeed, you might as well have had it made bespoke.

Alternatively, you could use a ’shrink to fit’ option. I think Microsoft SharePoint 2007 is a great example of that. It’s very flexible, with all sorts of neat bells and whistles, so it will fit many, many different needs. The problem is configuring it, shrinking it so that it fits well is also made very hard by this. Again, you’re into the realms of needing a specialist to help you. And you might not even need all those bells and whistles. At the end of it all, it could be as bad as having someone dismantle it.

So finally, we come to bespoke. You get someone to make it specifically for you. It does the what you want it to, and only that. You’re not paying for bells and whistles, and as it is designed to do just what it does, it is simpler than the other options. Sure, the tailors costs are a little scary - but done right, you don’t get all sorts of extra cost creep in later.

I keep ’seeing’ bespoke solutions. I’m not working on them - I’m probably hacking around with some third-party application again, trying to make it do what the customer wants - and this vision comes into mind of what I could build to solve just that problem. Normally, they solve just a single problem - but do that well. And I wish I could do them. It seems to me that development is become faster, and frameworks are becoming better. Look at Ruby on Rails - it gives so much for free, you can really build an application quickly in it. Even (though I hate to admit it) Visual Studio can give you a lot, sometimes - although it is collapsing under the weight of trying to be all things to all people.

So my question is this - why do companies seem so keen to stay away from an application that just does what they need it to, and yet happy to buy something off-the-shelf and then have to change it to do what they want it to?

I guess I’ll consider that later…

Still, maybe that’s for the best - we’re supposed to be using Infopath 2007, and my colleague working with that has started talking to himself. In a high-pitched voice. It’s not pretty. Seems there is even less documentation about this, and both of us are left with one question - wtf d’you want Infopath for? Yes, it makes XML, but that’s pretty trivial - we’ve all written forms that do that. (Well, all the geeks in the house).

So you can have a rich client for Infopath. Um, why? Lets see, zero footprint web forms, or Microsoft install. The phrase ‘lead or silver’ springs to mind - pay silver for our client, or get shot down with our web forms. And as our form is going to display an image from another document management system, and as the client will not be using the rich client thingy, well, we’re busy puzzling what we get from Infopath over ASP .net forms, apart from heartache and ulcers.

Workflow Task Content Types

By default, all SharePoint task types are assigned content types. If you do not specifically assign a content type to a task type, the task type uses the Task base content type. All task-type content types must be based on the Task base content type.

WTF?

I looked it up. It means ‘end-to-end’. Why not use ‘end-to-end’ then? We all need to avoid strange localisms in our language. I mean, I’ve never finished a meal with nuts. Cheese or coffee, yes, but never nuts.

And the word ‘doable’ is not a word - we’ve already got a word for that anyway, and it is possible.

I’m guilty too - I used “elephant in the room” for a bit of humour. Completely confused my Zimbabwean colleague with that phrase. Presumably, elephants in rooms really was more of a problem for him.

Please fix the Microsoft Passport, or the applications that use it, ‘cos it never works when I try to use it. In fact, it is the most unreliable, useless heap of crap I’ve ever had to use to try to login to a website - and I’ve seen some that are pretty rubbish - but at least they didn’t, in effect, say ‘Site Closed’ all the time.

While you’re at it, please find the monkey who came up with the idea of the Microsoft Passport, and fire them. From a cannon. Into a lake of piranhas. Angry ones.

Fix it or ditch it, I don’t care, just let me at the content I need to do my job.

If a pub always says ‘We’re closed’, I stop going to it.