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.
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.
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.
Follow the correct procedure… …it makes a difference.
This was just bound to not work
So, the project I’m working on needs a repeating section in an InfoPath form, which is being used as the display form for a Workflow Task. (Well, apparently it is ‘required’).
InfoPath forms hand back their data into a SPWorkflowTaskProperties object, and custom data – including all the fields on the form – gets put in the ExtendedProperties ‘Dictionary’ (or Hash table, if you’re like me).
The thing is, the items in that hash table are keyed by the name of the field on the form. For example, the following would get the value of the ‘name’ field:
x = AfterTaskChangedProperties1.ExtendedProperties["name"];
The thing about repeating sections, though, is that those field names will be repeated. But the hash key must be unique. So how are repeating sections represented.
I built a form to test this out. When the task was changed, I logged the key and value of everything in the Extended Properties. There were some other things in their – ‘standard’ extended properties – and I’ve stripped them from the log below.
What I did was I opened up the form. I filled in the fields. The repeating section was shown once – one line on the ‘UsersLog’ section. I filled it in, added 2 rows, and filled them in. I then submitted the form. Here’s what the log said:
"DocumentURL" = "Kumquat"
"UsersLog" = "
<ns1:User xmlns:ns1="urn:soj-deltascheme-com.invoiceapproval">
<ns1:NetworkId>1234567890</ns1:NetworkId>
<ns1:Name>AndyData1</ns1:Name>
</ns1:User>
<ns1:User xmlns:ns1="urn:soj-deltascheme-com.invoiceapproval">
<ns1:NetworkId></ns1:NetworkId><ns1:Name></ns1:Name></ns1:User>
<ns1:User xmlns:ns1="urn:soj-deltascheme-com.invoiceapproval">
<ns1:NetworkId></ns1:NetworkId><ns1:Name></ns1:Name></ns1:User>
"
"InvoiceId" = "Juggernaut"
"InvoiceCategory" = "34134"
So, the repeating section gets handed in as a chunk of XML. Great! That could be really useful – except…
Except that it is missing the data from 2 of my lines! It’s got the correct number of ‘ns1:User’ nodes (3), but only the first one ever has data. I’ve repeated, this seems to always be the case.
Bug. Let’s hope the tech refresh fixes it, ‘cos I can’t build the workflow I’ve been asked to with Beta 2.