Auto-Cleanup of Workflows in MOSS

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).

SharePoint Workflow and when to use it…

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

Workflow Correlation tokens

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.

Error: The event receiver context for Workflow is invalid

This is an obscure error:

Error in commiting pending workflow batch items: System.InvalidOperationException: The event receiver context for Workflow is invalid.
at Microsoft.SharePoint.SPEventReceiverDefinition.ValidContext()
at Microsoft.SharePoint.SPEventReceiverDefinition.ValidReceiverFields()
at Microsoft.SharePoint.SPEventReceiverDefinition.

GetSqlCommandToAddEventReceivers(IList`1 erds)
at Microsoft.SharePoint.Workflow.SPWinOESubscriptionService.

CommitNewSubscriptions(Transaction txn, IList`1 erds)
at Microsoft.SharePoint.Workflow.SPPendingWorkBatch.

ProcessWorkItemBatch(Transaction transaction, Work method, IList`1 workItemBatch)
at Microsoft.SharePoint.Workflow.SPPendingWorkBatch.

Commit(Transaction transaction, ICollection items)

Let’s skip over wondering what an erd is (event receiver definition maybe?)- the solution to this is simple, but not obvious. Check you have created properties for TaskID, TaskProperties and Correlation Token. I found this solution at Robert Bogue’s blog. As a side note it is a REAL pain in the ass that setting up TaskIDs and TaskProperties is so manual – or at the very least that tasks with unassigned values for these do not appear with the red ‘warning’ exclamation mark in Visual Studio.

Good synopsis of SharePoint Workflow

“To MOSS or not to MOSS”. That is a question…

Edit – apparently K2 Black Pearl is out – must get a copy and take a look. I saw a demo, oh, November last year. It bored our management, but blew our developers away…

PPS – note to self – get access to k2underground.com

Comments from my old blog:

K2Underground is quite good, but keep an eye on my blog – I’m going to start writing about K2 in the development section.

It’s good, but it doesn’t help solve some long standing issues to do with storing data in workflow engines. I have had to implement my own data storage system alongside the K2 workflow in the project I have been working on for the last 6 months.

By Jonathan at 20:39:36 Friday 7th September 2007

Office and Workflow Integration – Version WTF?

Dear Microsoft – The word Ultimate means ‘Final’. Somehow, I suspect there will be future versions of Office and Windows – what do y’reckon?

Okay, so I’m a simple man really…

I’d been asked to demo a custom workflow to a customer. They’d some fairly clear requirements, and we just wanted to knock up a prototype. It was all about filling in ‘fields’ in a word document. “Great”, I thought, “we can allow them to do this entirely within Word”. And, looking at the marketing bumpf, the demos and the docs, yeah, we could. The workflow task could be displayed in MOSS, and the document properties pane would expose any other fields they needed.

Except… …I couldn’t get the ‘Edit this Task’ button to appear in Word. I know it should be able to – but it wasn’t. I tried everything; nope, nothing. In the end, I ran out of time – but one of my colleagues, of a slightly curious nature, kept plugging away at it.

It turns out, it was the wrong version of office. It used to be that versions of things were simple – there only was one for each ‘iteration’ of the software. Then we started getting ‘Home’ and ‘Professional’ – which was okay, and seemed sensible, to be honest. I liked that – it was simple, just like me. Continue reading

UpdateTask Activities, and SPWorkflowTaskProperties

So, I had an email from a guy called Maxim Semyonov, asking about getting an UpdateTask activity to, well, update a task, and did I have an example? Well, I did, although it didn’t really seem to help him very much – of course, there were problems between versions of SharePoint, installing InfoPath forms is always a giggle, and so on – but he did track down the issue, and it is an interesting ‘gotcha’.

What he was doing way using the same SPWorkflowTaskProperties for the OnTaskUpdated.AfterProperties, and the UpdateTask.Taskproperties. This seems natural enough – he wanted all the updated task data (in AfterProperties) in the task properties, so why not use the same object for them both?

Naturally, this doesn’t work . The result was that the task didn’t update, and he was getting the error “Task update was not accepted“. Why, I don’t know – what Maxim was doing seems perfectly reasonable. Instead what you’ve got to do is write code to copy across all the properties you want. Crazy.

To be sure (i.e. to confirm what he told me) I was going to create a test workflow as he’d described – but I’d a vague feeling that I’d seen this before – and looking though my notes (yes, I keep notes. Rough ones. With doodles) I find that yes, this was the first thing I discovered when trying to use the UpdateTask activity. I’d just forgotten (and probably hoped it was a Beta thing). I wonder how many other folks have been caught out by the same problem?

It also explains why I wasn’t doing things in the way Maxim was describing – ‘cos it did seem reasonable, and a good way to reduce the number of SPWorkflowTaskProperties objects in your workflow…

(Note to self – remember this, and tell others)

Comments from my old blog:

Bless… it works, thanks!

By Sharepointer at 12:12:31 Wednesday 18th April 2007

Hi, Read your article and its useful.
I have a scenerio where i have to use the update Task Activity in a State Machine Workflow.
If you have an Example, i will be highly greatful to you.

Thanks in Advance :)

-Manoj Iyer
Globaltech India.
manoj@thegt.com

By Manoj Iyer at 07:31:05 Monday 4th June 2007