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

Right, so I had a suggestion from Nick Swan, and it was a good one, so I gave it a try.

What he said was:

With OnTaskChanged there is the BeforeProperties and AfterProperties variables.

In the event can’t you set the AssignedTo in the AfterProperties?

This seemed perfectly reasonable – and I hadn’t thought of it already, so it was worth a try (wood/trees obscuration).

I created a workflow that consisted of 3 steps – a Create Task step, a While Loop (that is always true) and in the While, I put an onTaskChanged event step.

Creating the task, you set the assignee using an SPWorkflowTaskProperties object. Here is my line for doing that:

TaskProperties.AssignedTo = "MOSS\\Domain Users";

That’s pretty clear. I then wrote code to set the AfterProperties of the onTaskChanged event:

TaskAfterProperties.AssignedTo = e.Identity;

Typically, e.Identity is something link “MOSS\\burnsa”. I’ve checked. And that’s what I’d expect it to be.

So, the workflow enters the while loop – which as I say, deliberately never exits – an the workflow awaits a change in the task. When that change comes, I’m going to look at the AssignedTo field of both the BeforeProperties, and AfterProperties. Oh, yeah, and I deliberately WASN’T changing the assignee within the task.

BeforeProperties – Expected: “MOSS\\Domain Users” – Actual: null

AfterProperties – Expected: “MOSS\\Domain Users” – Actual: “16″

…and setting the AfterProperties with e.Identity did damn all. WTF?

I could understand that setting AfterProperties with e.Identity might not work – although it seems a reasonable thing to try and do – but the AssignedTo fields being null, and then 16? Don’t make no sense.

Oh, further – I tried again, but this time setting the assignee as my change to fire the onTaskChanged event. This time the AfterProperties assignedTo field was ’13′, so clearly it is some sort of identity – just not an obvious or particularly useful one.

Okay, so having tried the programmatic route and got stuck, and investigated it, I realised that I’d been dumb.

There is an UpdateTask workflow activity

Okay, so I missed the obvious – that to update a task would require an activity if it is to work in SharePoint Designer. However, I tried adding this to a workflow. When I went to the workflow code, I got the error:

Code generation for property ‘PercentComplete’ failed. Error was: ‘Property accessor ‘PercentComplete’ on object ‘Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties’ threw the following exeception: ‘Object reference not set to an instance of an object’

Phew. Nice error. Then, sometimes, I managed to get the Designer view to have errors – it couldn’t draw the workflow. And build failed – the workflow designer.cs file lacked the line defining the private variable referencing the UpdateTask object. Oh, and trying to set properties of the task to update – more errors.

The short is, in Beta 2, Update Task doesn’t seem to work. I don’t think that there is a lot I can do to fix this…

So, I’ve continued investigating my problems updating a SharePoint Workflow Task. I decided to learn about event receivers, as this is what the message was about.

Event receivers, well, receive events that happen on an item, and process them. I listed the ones on my workflow task list with the following code:

for (int j = 0; j < myList.EventReceivers.Count; j++)
{
SPEventReceiverDefinition d = myList.EventReceivers[j];
Log (d.Assembly + " - " + d.Class + " - " + d.Data + " - " + d.Filter + " - " + d.Name + " - " + d.Type.ToString());
}

This gave the the results:

31/08/2006 11:13:57 – Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c – Microsoft.SharePoint.Workflow.WorkflowTaskUpdateEventReceiver – – – – ItemAdding

31/08/2006 11:13:57 – Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c – Microsoft.SharePoint.Workflow.WorkflowTaskUpdateEventReceiver – – – – ItemUpdating

31/08/2006 11:13:57 – Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c – Microsoft.SharePoint.Workflow.WorkflowTaskUpdateEventReceiver – – – – ItemDeleting

31/08/2006 11:13:57 – – – – – – 32767

It turns out that there is an easier way of list the event receivers, but dumping to a log file works. Interestingly, he also had the same 32767 result, which is weird. It’s (2^15)-1, so presumably the highest value that can be represented by a 16bit signed integer – but what is it doing in my log?

Anyway, I reckon that the ItemUpdating event receiver is killing my update – but don’t effing know why.

Incidentally, this is a good article demonstrating event receivers. Shame about the bugs they’re finding, though.

Problems doing the simplest things. I want to update a task created by the CreateTask activity, when the activity is changed. I have the following function, which is run when the Task list item is edited…

private void onTaskChanged1_Invoked(object sender, ExternalDataEventArgs e)
{
SPWeb mySite = new SPSite(workflowProperties.SiteId).OpenWeb(workflowProperties.WebId);
SPList myList = mySite.Lists[workflowProperties.TaskListId];
SPListItem myTask = myList.GetItemById(TaskBeforeProperties.TaskItemId);
SPUser myUser = mySite.AllUsers[e.Identity];
myTask["Assigned To"] = myUser;
myTask.Update();
}


Everything seems okay, but when I call myTask.Update(), I get the exception “An event receiver has cancelled the request.” And I’m damned if I know why.