Andy Burns’ SharePoint Blog

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 I’ve got a big project that is, apparently, to be based around workflow coming up. I’m a little scared of this, to be honest. I’ve noticed a few things:

• The most viewed item on my blog is currently ‘Blood, Sweat, and Windows Workflow in SharePoint‘.
• There are so many questions on the SharePoint UK user group about workflow.
• There are so many questions on the Microsoft forums.

So, anyway, my boss was wise enough to give us some time to refresh ourselves about SharePoint workflow, and to try out some things we didn’t do before (like using ASPX forms). It seems to me that some things have moved on – the projects in Visual Studio have got better (although I’m not sure I like the ‘deploy’ thing in the Visual Studio 2008 templates – what if I have other steps to perform? Is the deploy the same as what I would do if I was deploying a new WSP? It doesn’t seem so – it appears to be too fast!)

However, some things still really don’t work:

• We can still see odd (and incorrect) behaviour for infopath forms that use Repeating groups. One of my colleague gave this a look – it still doesn’t work.
• Still no proper tracking and auditing – I guess we’ll have to build it into the workflow ourselves.
• Still a general lack of documentation about workflow, and this is 18 months after release.

Anyway, I’m off to try using ASPX forms – I remember reading that that was possible. Wish me luck (for the ASPX and for the project). I’ll blog about how it goes

Tags: 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

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.

By Jonathan at 17:15:57 Sunday 22nd April 2007

I made the same “mistake”. Glad you wrote this blog item, it hinted me to the solution.

By Jan Willem at 10:19:25 Friday 22nd June 2007

Tags: Infopath, Workflow

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

Follow the correct procedure… …it makes a difference.

Tags: Infopath, Workflow