novolocus.com

More workflow fun - this time caused by my using the latest Visual Studio project for building SharePoint workflows - at this time it’s the one packaged in the VSeWSS3 version 1.2.

Back in the days of RTM, Workflows had a rubbish Visual Studio Project - I mean, awful. “Some assembly required” is really understating it. However, an improved version came along, and it was alright. Sure, there was some fiddling with batch files, but it worked. You could build it, deploy it, and test it easily, and it was pretty easy to get a simple workflow and some InfoPath forms working.

This is my first time using the 1.2 installer, which looks much more sexy - it’s got a wizard and does the ‘deploy’ bit for you, so no fiddling with .bat files. However, I couldn’t get InfoPath forms to appear for my workflow. The were getting deployed into the FEATURES folder, but when I ran the workflows - just ordinary task views appeared.

Bugger. Read more »

Tags: Content Type, Infopath, Tasks, Visual Studio, Workflow

You can tell you’re using Infopath and SharePoint workflow when nothing works. I was using STSADM to verify a form template, and I kept getting an error. The error I was getting was:

FatalErrorNoThrow : This form template has not been correctly published to be browser-enabled. Open the form template in InfoPath Design mode, and click Publish Form Template in the Design Tasks task pane. Follow the steps in the Publishing Wizard to republish the form template, and then try again.

Gee, thanks. Advice to ‘try again’. Useful.

It transpires that the problem was from when publishing the InfoPath form; you have to make sure that the access path in the publishing wizard is empty. Fortunately, I now know enough about Infopath to have no idea that this is about - but making the access path empty did seem to work…

Make sure that the box highlighted in yellow is empty.

Tags: Error, Infopath, Workflow

So, recently I’ve been looking at .aspx forms in SharePoint workflow. It turned out to be a very hard experience, although there is a project on codeplex that might make life easier. I’d like to try it, and if it works as billed, I’d like to buy it’s author a pint.

Anyway, this set me thinking - why are .ASPX forms not the default way of creating forms in SharePoint workflows?

Infopath has it’s uses. In the last few months I’ve played with it a few times and found it fairly useful for what it was originally designed for - providing forms for people to fill in. It has some nice features, which I must post my thoughts about sometime. And, for what is quite a complex task, it’s relatively simple to use (relative to development, I mean, not relative to using, say, MS Word).

What it’s not designed for is providing workflow forms for SharePoint, and that’s part of the reason this is such an arcane process.

Worse, one of InfoPath’s selling points is that ‘power users’ can create and use forms without needing developer input. However, creating SharePoint workflows through Visual Studio is clearly a developer activity - no non-techy is going to manage it. So what are we using InfoPath forms for, rather than ASPX forms which we can also write in Visual Studio?

Finally, InfoPath forms don’t work with WSS3. With the lack of documentation and tooling for using ASPX forms, this effectively cripples writing custom workflows for WSS3. The cynical amongst us might suggest that this is a way of trying to force companies to cough up for MOSS (which contains InfoPath form server), but to be honest, I think it’s just an oversight.

Curiously, InfoPath forms seem to work much better in K2’s BlackPoint than with SharePoint’s workflows. Building InfoPath form tasks in K2 was simple compared, and worked with little effort. Unfortunately, the simplicity comes with a price tag, and as SharePoint already ‘does workflow’, few companies are that keen to pay for it.

So please, please, for Office 14 make ASPX task pages the default workflow building scenario, and make InfoPath the ‘alternative’. That’s in addition to making InfoPath forms actually work properly in workflows… …and maybe take some lessons from K2.

Tags: ASP.NET, Infopath, Workflow

So, Robert Brogue has posted some comments on InfoPath, and Maurice Prather agrees but doesn’t want to sound like he’s going too far.

I actually think that Maurice didn’t go far enough in criticism of InfoPath, at least in a workflow context. And I have used it. Read more »

Tags: Infopath

Details about it on the Microsoft forums. Neat.

Tags: Infopath, Tasks

You’ll need that to be able to use it in SharePoint. Also, when publishing, remove the alternate access path. The publisher wizard will then complain. Do not cancel. Publish anyway, it’ll be fine.

Tags: Infopath

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.

Tags: Infopath, Workflow

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.

Tags: Infopath, Workflow

So, I had been asked to write some code to update an Infopath form’s data as it passed through a workflow. This data was being declared as a column in SharePoint, and we wanted the columns value to update. A long struggle ensued… Read more »

Tags: Infopath, Workflow

So, I’ve been tempted to throw my machine out the window lately, working with the Windows Workflow Foundation, InfoPath and SharePoint - and as I’ve said before, at least I’m not the only one frustrated. Maybe that’s not fair - it is in beta after all - but if you’re going to release a beta, you could at least release beta documentation. Anyway, here’s what I found… Read more »

Tags: Infopath, Tasks, Workflow