Tag Archive for WWF

Word 2007 and Sharepoint Workflows

I’ve got a couple of questions about Word 2007 integration with Sharepoint 2007, and several problems that occur because of it:

The Mysterious Checked-Out Error

Let’s say I have a workflow attached to a document library which creates a data collection task, and when that task is completed updates the document metadata with the task data (say, “Ask for Comments”). For some reason if I leave the document open in Word and complete the task, I get an error in the workflow claiming the document is checked out and can’t be updated.

Needless to say, the document isn’t. Word only checks out the document before the actual save operation, not whenever it’s open. If my workflow updates the metadata directly, without a data collection task, it does work. If Word is closed – it does work.

Even more strangely – if instead of updating the metadata I try to delete the item, it works without a hitch. Update – no. Delete – no problem.

I’m pretty much stumped here, and I’d appreciate any idea.


Automatically Closing Word’s Connection

Now we have a different workflow – once I’ve saved my document to the library, a workflow evaluates the metadata and moves it to a new folder depending on the context. Copied aside and then erased, or possibly renamed based on some bit of metadata. The workflow works fine and the document vanishes from the library, but Word is still open and still points to the original location. If the user corrects a single word and presses Ctrl-S, the document will be resaved to the original location, the workflow restarted an a new copy made.

Is there a way to force Word to update the folder or file it’s pointing to? Alternately, a way to cause Word to close the document after saving?

MOSS Workflows are versioned

I was asked today about MOSS’s behavior when workflows are changed midstream. Say I have a document library with a Workflow attached to it, start a few long-running (non-immediate) workflows, then change the workflow before they’re completed – will they keep running? Will they use the new workflow or the old, from that point on?

I had hoped for the former, but expected the latter. You can’t switch flow in midstream (if you’ll pardon my mishmash of similar metaphors), since a newer activity might rely on a variable created by a previous action – one that never took place.

Armed with a burning scientific curiosity and a lack of something to do while the motorway was jammed due to an accident, I set out to check my hypothesis:


1) Create a document library with three fields – two text fields and a Yes/No field. The two text fields represent actions taken before and after the change, while the yes/no field is to simulate a long-running workflow that requires other user’s interaction:


2) Create a simple workflow that updates the Step1 field and then waits around until the Waiting field is set to No:


This worked fine, of course – a new document would start the workflow and get its field set to Step1, then wait until I unchecked the Waiting field and then completed. I created another document and left it in the Waiting state.

3) Update the workflow and add another action after waiting – simply setting a value to the post-wait Step2:


4) Try it out. I created a new document and verified that Step1 was set before waiting, and Step2 set after waiting. Then I unchecked the Waiting flag on the old document, created with the original workflow.

As expected, Step2 did not get assigned for that document. Despite the fact that the latest version of the workflow had a new action after the Wait, the document was attached to the older version of the workflow, and not the newer. This was also true when I added the second action in a different Workflow Step, rather than a second Action in the same step.

This can be easily seen inside Sharepoint Designer, where we can see that the Workflow’s XOML file is just another file stored in just another document library – and like any other document library, it supports file versioning:



This is a potential cause for confusion – if we have many workflows active and are then required to make a change to it, it’s hard to know which workflow is running for which document. The ideal solution would be to complete or terminate all workflows before making a change, but that’s hardly a realistic solution for modifying production systems.

Some thoughts on uninstalling Sharepoint ’12’ Beta 1

I’m uninstalling an old beta of the Sharepoint servers from a VPC I have on my computer to make room for the newer Beta 2 servers, and I noticed several things:

1) The installation originally required a then-current build of Windows Workflow Foundation to install. However, it appears that it also requires it to UNINSTALL. I had to find the old installation of WWF Beta 1.2 and reinstall it. It is no longer available on Microsoft Downloads except as part of the 100MB package containing the Visual Studio extensions. Actual package size – 2.5Mb.

2) Uninstallation CRAWLS under VPC (512MB RAM, running on a USB2.0 external harddrive).

3) Is it my imagination? Does it… is it…
No, it’s true. The progress bar for the uninstallation actually does go BACK a few pixels every once in a while. You probably won’t notice it if it isn’t crawling on a background VPC, but it’s true. It’s rocking back and forth. Weird.