A note to myself – don’t ever use TaskProperties properties in your workflow class. Just use a public variable. Using properties causes some weird null pointer exception. I know, that makes no sense, but it’s true…
SP2007 Workflow
Custom activities in SharePoint Workflow
Custom SharePoint aware Workflow Activities
Don’t forget to add into the System.Workflow.ComponentModel.WorkflowCompiler section of the web.config file.
There is a known issue with Delay activities
Apparently there is a fix. Bit late for me.
Nintex workflow extensions…
Angus Logan raves about Nintex workflow extensions. Design workflows over a web interface? How cool is that!
It’d be interesting to see how it works, but if it lives up to it’s promise, that’s a very cool product!
Comments from my old blog:
Product has launched and the feedback has been great. I think we have lived up to the promises.
More on Delay Activities, Workflow, and Beta 2 Tech Refresh
I’m coming to the conclusion that Beta 2 TR has broken Delay Activities…
What I did was build a test workflow. I’d got delay activities that weren’t working, and I wanted to investigate the possible factors involved.
I know that they were working just fine in Beta 2. I thought the difference here from what I was doing in Beta 2 was that I was setting the TimeoutDuration at runtime, through the InitializeTimeoutDuration function.
So I built a test workflow with 2 different parallel branches. One had a ‘static’ (design time) configured delay, and the other had a ‘dynamic’ (runtime) set delay. Both had an InitializeTimeoutDuration function set, though for the ‘static’ case all this did was log that it had been invoked.
I ran the workflow. My log file showed that the workflow ran both the InitializeTimeoutDuration functions, and nothing else.
Previously, I’d not run that function at all, so I tried configuring both Delays to not call InitializeTimeoutDuration. I ran the workflow, and again, nothing after the delays ever happened.
So I thought maybe it was because I had 2 delays. I disabled one sequence, and added a new second sequence that just contained a code step. I ran this – and again, anything after the Delay activity was never run.
In the end, I took one of the sequences outside the Parallel Activity. The workflow was now OnWorkflowActivated – Code – Delay – Code. And the second code step never runs.
I know this worked in Beta 2 – has the Tech Refresh broken this?
Comments from my old blog:
I got the same impression 😉 – Beta 2 TR has broken Delay Activities…
The frustration of Parallel activities
So, I came across an interesting situation.
I have be told to look at trying to build the workflow I’ve been working on (a state machine workflow) as a sequential workflow.
In this workflow, I need to run two parallel tasks. On one side, I wait for a task to be completed, and on the other, I want to have a delay step followed by an email activity, to send the reminder email after a delay.
The problem is, the ParallelActivity step will only complete when BOTH branches have completed. I can’t stop the branch with the email. In other words, the user finishes their work on the step, but the workflow won’t continue until the reminder email sent!
Equally, if the delay step was some sort of escalation process (rather than an email, it wouldn’t be able to escalate until the user had finished with the step!
There has to be a way around this, I’m not sure what I’m doing wrong though.
Comments from my old blog:
Hi,
you have to use an Listen activity, probably inside a while activity.
Note: the createTask activity you have to put outside the while.
Yup, I realised I was being a bit slow – and that an event listener activity could have multiple branches, and completes when any of the events is done. I don’t think I’d need a while loop, though.
I was just using the wrong activity type.
Setting DelayActivity.TimeoutDuration at runtime in WSS3 workflows
I need to use DelayActivity steps to ‘hold’ the sending of some notification emails until the correct time. That time is to be set at runtime.
However, it appears that in State Machine workflows the TimeoutDuration of a DelayActivity can only be set at design time. Trying to set it at runtime causes the DelayActivity to never expire.
I tried the same for a sequential workflow, and it worked okay. It seems this only affects State Machine workflows in SharePoint 2007 (MOSS)
EDIT: correction, it DIDN’T work okay in a sequential workflow. I’m sure I did this before, though. Perhaps it’s broken in Beta 2 TR, or maybe my memory is failing.
When attaching forms to workflow tasks…
Follow the correct procedure… …it makes a difference.
STILL trying to update the Task Assignee
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.
Even more on Updating SharePoint Workflow Tasks
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…
Andy Burns' Blog 