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…
So, I’ve just lost 2 hours over trying to get data into an InfoPath form being used with a workflow. This sort of thing is described here (MSDN) and here (SharePoint Blogs).
I had problems as the file name for the secondary data source has to be called ItemMetadata.xml. I had spelt it ItemMetaData.xml. Why does InfoPath work this way? What the hell is the reason for this? Is this what makes InfoPath so easy to use for workflow development? I mean, I knew about this, but I just made a mistake, and it took ages to track down. Maybe that’s my fault – but I don’t think I’m stupid (mostly), and I wonder how many other folks have been caught out by this also?
Comments from my old blog:
This kind of stuff happens because Infopath is commercial software – and is therefore as good as the price dictates it can be, whereas things like Apache, Samba and Subversion are as good as the developers can make them.
I made the same “mistake”. Glad you wrote this blog item, it hinted me to the solution.
Custom SharePoint aware Workflow Activities
Don’t forget to add into the System.Workflow.ComponentModel.WorkflowCompiler section of the web.config file.
Apparently there is a fix. Bit late for me.
There is no support for tracking services. Or rather, if there is, nobody is saying. You’re stuck with ‘History’ lists, which suck. All I want is a table I can query, and that I’ll expose that via the BDC. But without this, workflow in SharePoint is nothing more than a toy, which isn’t fair given the effort put into it. I know that Microsoft don’t want to step on K2′s toes – fair enough. Truth be told, I was wondering what K2 were going to do, figured that they must be running scared – but having seen Black Pearl, I see that they’ve been running hard, and have a good lead. A SQL tracking service won’t erode that lead.
Repeating fields in Infopath forms are unusable. Nobody knows how to do this. I spent ages working on it, but I didn’t get anywhere. I couldn’t write to these properties through the task properties at all. Indeed, the whole TaskChangedProperties.ExtendedProperties hash is daft. Forcing everything to flatten, well, sucks. Can’t I have a stream? Or a node-child tree of some sort? I mean, is it surprising to want to send InfoPath forms to/from a workflow task and a library? You know, use the workflow for routing, and the xml form in a library as the data store? That should be easy – it’s not.
Debugging workflows is hard. I mean, apart from Visual Studio crashing as I connect it to the appropriate service, there is a question over actually being able to get meaningful error messages out of workflow, and getting it able to breakpoint in the right places. In fairness, this is a complex thing. I have no idea how I’d set about allowing debugging in Visual Studio, say, after a Delay activity had expired. But it would be cool to have something a bit better.
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.
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…
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.
Follow the correct procedure… …it makes a difference.
So, the tech refresh fixes the ‘UpdateTask’ activity. By setting the task properties used by this step, it is possible to update the assigned user for a task. Hurrah! Something fixed by the refresh. All I have to do now is figure out why I’m not able to get data to or from my forms anymore. (Well, actually, ‘to’ never worked, and ‘from’ has a bug with repeating sections).