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…
Well, I said I’d blog about how well I managed with using SharePoint Workflows with ASPX forms. The short answer – badly. Continue reading “SharePoint Workflow with ASPX forms”
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.
I just read an interesting blog post about how MOSS Workflows lose their association with their history after 60 days.
I guess it sort of agrees with my conclusion of MOSS workflow – that the auditing is awful. I mean, I get that ‘Workflow History’ items fits nicely with the SharePoint ‘item’ idea, but couldn’t we have a table for this? Or at least an implementation of Workflow Foundation that lets us plug-in our own tracking providers?
If I could get a week free, I’d write one and stick it on codeplex (for the glory).
A good article about the limitations of SharePoint Designer workflows…
When building SharePoint workflow solutions you need to be very careful in only using it for small, single document-centric processes, and you need to try to avoid the ‘pain points’. For processes that push the boundaries of what workflow can do, you should consider redesign of the solution to reduce the workflow element or alternative products.
In a collaboration and publishing system like SharePoint, some sort of support for standard business process is essential. SharePoint workflow supports that for simple processes, but it is not enterprise grade workflow (yet). Indeed, out of the box it doesn’t work (at least, not fully). I’ll explain some of the issues with SharePoint Workflow later, but first I want to describe what SharePoint workflow is. Continue reading “SharePoint Workflow and when to use it…”
I just found a post where someone had gotten confused about tokens in MOSS workflow:
- Workflow Correlation Tokens are used to identify the Workflow an event should be routed to.
- Task Correlation Tokens are used to identify the Task in the workflow the event is about.
- Each task must have its own token.
- A workflow token should never be used with a Task.