Nick Swan of Lightning Tools ran a survey of SharePoint usage. It’s quite an interesting read, but he was surprised by the prevalence of workflow. I’ve gotta be honest – I’m not surprised… Continue reading
I got a slightly obscure error message when trying to run a DeleteTask activity in my workflow:
System.InvalidOperationException: Correlation value specified does not match the already initialized correlation value on declaration taskToken for activity deleteTask1.
Hmm. I checked the correlation token though – and it was fine. And what’s it doing initialising another token? Found the answer though, courtesy of Matt Morse - I’d not set the task ID property for the delete task activity.
This did lead me around to wondering why I have to? I mean, we’ve a correlation token for the task. The correlation token contains the TaskID. And yet I have to specify both of these things to the DeleteTask activity to identify the task I want deleted? Something ain’t right there…
More workflow fun – this time caused by my using the latest Visual Studio project for building SharePoint workflows – at this time it’s the one packaged in the VSeWSS3 version 1.2.
Back in the days of RTM, Workflows had a rubbish Visual Studio Project – I mean, awful. “Some assembly required” is really understating it. However, an improved version came along, and it was alright. Sure, there was some fiddling with batch files, but it worked. You could build it, deploy it, and test it easily, and it was pretty easy to get a simple workflow and some InfoPath forms working.
This is my first time using the 1.2 installer, which looks much more sexy – it’s got a wizard and does the ‘deploy’ bit for you, so no fiddling with .bat files. However, I couldn’t get InfoPath forms to appear for my workflow. The were getting deployed into the FEATURES folder, but when I ran the workflows – just ordinary task views appeared.
Bugger. Continue reading
You can tell you’re using Infopath and SharePoint workflow when nothing works. I was using STSADM to verify a form template, and I kept getting an error. The error I was getting was:
FatalErrorNoThrow : This form template has not been correctly published to be browser-enabled. Open the form template in InfoPath Design mode, and click Publish Form Template in the Design Tasks task pane. Follow the steps in the Publishing Wizard to republish the form template, and then try again.
Gee, thanks. Advice to ‘try again’. Useful.
It transpires that the problem was from when publishing the InfoPath form; you have to make sure that the access path in the publishing wizard is empty. Fortunately, I now know enough about Infopath to have no idea that this is about – but making the access path empty did seem to work…
Make sure that the box highlighted in yellow is empty.
I’m with Bob Mixon – Business Process Management Does Not Equal Workflow. Go read that post now.
Like him, I hear the terms ‘Workflow’ and ‘BPM’ used interchangably, but he is right – workflow is a technology that can be used to support a business process. It’s not the only technology, though, and it isn’t always appropriate to use. Too often I see workflows with some horrible process in them for dealing a with a variety of edge cases where actually all the customer needs is to record that this is an exception to their normal process, and that it was sent to Joe Bloggs to deal with.
I’m a big fan of allowing human intelligence a role in the process. But I digress…
The point I was leading around to is that you don’t have to use just workflow to support a business process. You can actually achieve quite a lot with views, and you can provide some of the automation with just event handlers. Or, if you’re brave, you can use workflow – but Keep It Simple, Stupid! A lot of the example workflow projects are pretty simple, and short – keeping yours the same seems a safer plan.
Also, I do think keeping workflows short and simple, and having a number of them supporting a business process is generally a good idea.
We did a project just after SharePoint RTM was released where I was supposed to be using workflow. I’d been trying to build this particular workflow since the Beta 1 release, but there were still a lot of issues in the TRM version, Continue reading
So, recently I’ve been looking at .aspx forms in SharePoint workflow. It turned out to be a very hard experience, although there is a project on codeplex that might make life easier. I’d like to try it, and if it works as billed, I’d like to buy it’s author a pint.
Anyway, this set me thinking – why are .ASPX forms not the default way of creating forms in SharePoint workflows?
Infopath has it’s uses. In the last few months I’ve played with it a few times and found it fairly useful for what it was originally designed for – providing forms for people to fill in. It has some nice features, which I must post my thoughts about sometime. And, for what is quite a complex task, it’s relatively simple to use (relative to development, I mean, not relative to using, say, MS Word).
What it’s not designed for is providing workflow forms for SharePoint, and that’s part of the reason this is such an arcane process.
Worse, one of InfoPath’s selling points is that ‘power users’ can create and use forms without needing developer input. However, creating SharePoint workflows through Visual Studio is clearly a developer activity – no non-techy is going to manage it. So what are we using InfoPath forms for, rather than ASPX forms which we can also write in Visual Studio?
Finally, InfoPath forms don’t work with WSS3. With the lack of documentation and tooling for using ASPX forms, this effectively cripples writing custom workflows for WSS3. The cynical amongst us might suggest that this is a way of trying to force companies to cough up for MOSS (which contains InfoPath form server), but to be honest, I think it’s just an oversight.
Curiously, InfoPath forms seem to work much better in K2′s BlackPoint than with SharePoint’s workflows. Building InfoPath form tasks in K2 was simple compared, and worked with little effort. Unfortunately, the simplicity comes with a price tag, and as SharePoint already ‘does workflow’, few companies are that keen to pay for it.
So please, please, for Office 14 make ASPX task pages the default workflow building scenario, and make InfoPath the ‘alternative’. That’s in addition to making InfoPath forms actually work properly in workflows… …and maybe take some lessons from K2.
So I’ve got a big project that is, apparently, to be based around workflow coming up. I’m a little scared of this, to be honest. I’ve noticed a few things:
- The most viewed item on my blog is currently ‘Blood, Sweat, and Windows Workflow in SharePoint‘.
- There are so many questions on the SharePoint UK user group about workflow.
- There are so many questions on the Microsoft forums.
So, anyway, my boss was wise enough to give us some time to refresh ourselves about SharePoint workflow, and to try out some things we didn’t do before (like using ASPX forms). It seems to me that some things have moved on – the projects in Visual Studio have got better (although I’m not sure I like the ‘deploy’ thing in the Visual Studio 2008 templates – what if I have other steps to perform? Is the deploy the same as what I would do if I was deploying a new WSP? It doesn’t seem so – it appears to be too fast!)
However, some things still really don’t work:
- We can still see odd (and incorrect) behaviour for infopath forms that use Repeating groups. One of my colleague gave this a look – it still doesn’t work.
- Still no proper tracking and auditing – I guess we’ll have to build it into the workflow ourselves.
- Still a general lack of documentation about workflow, and this is 18 months after release.
Anyway, I’m off to try using ASPX forms – I remember reading that that was possible. Wish me luck (for the ASPX and for the project). I’ll blog about how it goes
Previously I’d pointed out an article about a problem with SharePoint workflows where the data gets ‘disconnected’ from the user interface after a number of days. Robert Bogue wrote a nice summary of it, explaining why it behaves this way and how to get around it. Anyway, I was catching up on my RSS feeds, and I came across a follow up post that I just had to respond to.
Read his post first; this is just my thoughts. Done? Good.
Robert Bogue makes some good points. I totally agree with him on the second point – Workflow History isn’t an Audit. However, this does sort of highlight the crux of the issue – that there is no Audit. One is mentioned in his previous post, but I’ve never managed to figure out what he meant by that, or to find a decent audit in Workflow that I didn’t have to build myself. And I just keep thinking that this is something that a plug-in tracking service ought to be able to provide…
I guess my ‘What were they thinking!’ isn’t that there is the auto-cleanup, but rather why didn’t Microsoft offer an audit mechanism out of the box. I asked Lawrence Liu about that once at a SUGUK meeting – he said that SharePoint Workflow “wasn’t intended to be an enterprise solution”. Fair enough, if that’s what they want to do (and to leave space for the likes of K2 and Skelta), but then stop advertising SharePoint as having user configurable workflows.
A number of our customers have gone through the logic of:
- SharePoint is an Enterprise level system
- It has workflow built into it
- Therefore we can use workflow to support our enterprise’s processes
They’re pretty disappointed to discover that it lacks pretty basic things like audit. I can’t say I blame them either. But I digress.
Regarding his first point about configuring the timeout – writing an application isn’t a good general option. I’ve no doubt it works, but SharePoint administrators are necessarily programmers. Even if they are, there’s no guarantee that they’re good SharePoint programmers. The setting in the manifest – that I like. Don’t depend on your users being able to code their own solutions. Further, I don’t know how this would apply to SharePoint Designer workflows, though personally I steer clear of them.
So yes, I’d agree with Robert – it’s not a ‘Huge Issue’, but it is a problem.
This problem proved a real puzzler for me – but the guys on the K2 underground came through with a good answer – the Application Pool Identity of the Moss Site Collection must be part of the Farm Administrators group. (Which makes sense when you think about it. The K2 web services are running under the App pool identity of the site collection, and they’re trying to deploy features to the farm…)
Unfortunately, I then suffered a second problem – and error of ‘Value cannot be null’ when trying to deploy a workflow associated with a SharePoint Content Type. Sadly, all this was worked on last minute just before Christmas, so I’ve forgotten a lot of what I did to my machine. I met with some of the guys from K2 who were very helpful, and we did quite a lot. My memories are:
- Installed SP1 for [blackpearl]
- Installed Office 2007 (I was in a hurry and forgot, okay?)
- Stopped trying to associate the workflow with a content type and instead associated it with a specific list – which worked for the demo, but associating with the content type is a far, far cooler idea.
- Changed my form to allow “Cross-Domain Access for User Form Templates” and changed the data connection timeouts in SharePoint to be longer – as several of the guys in the thread noted, this does seem to be an issue with K2 workflows in VMs – but then my 2GB RAM machine was running a VM with MOSS, SQL2005, K2 and a DC, SMTP and POP services on it.
- Gave more rights to K2 to some of the users. I had to give the App pool more permissions than I had, in order to allow it to display worklists, which also makes sense.
- Sorted out a misconfiguration in IIS.
I’m sure I’ve missed other things, but it was so long ago now, I can’t quite remember. The only other thing I can remember doing was sitting around a lot waiting for everthing to work. The applications were quick enough when they’d been compiled, but that meant that the first time I hit some of the pages, well, there was a lot of waiting. And errors from timeouts. Particularly we had problems with contacting SQL Reporting Services from some of the K2 wizards, but found that if you waited a moment or two and then tried again then they were okay.