novolocus.com

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.

By Sandro Pereira at 10:54:19 Monday 11th December 2006

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.

By Andy B at 15:32:23 Monday 11th December 2006

Tags: Workflow

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.

Tags: Workflow

Neat tip for .NET development. Put the Lutz Reflector into the context menu in windows.

Some useful links to things to remember in testing in Coding Horror. I agree; developers are poor testers, and the guy who wrote it is the worst person to do testing.

Described on Mark Harrison’s Blog (notice the typo mentioned)

Edit: And more about integrating with a website’s own search

So I’m not really familiar yet with .NET, and the Dataset object had the Java programmer in me a bit puzzled - but this article is actually quite good at highlighting some of the potential issues and dealing with them.

Heatmaps are apparently the next thing in web site statistics - and what a clever idea. For a while I worked on a JS file that would report the mouse moving over, out, and clicking on DOM elements in a page, but to be honest, that was a bit excessive - and much harder to visualise.

Follow the correct procedure… …it makes a difference.

Tags: Infopath, Workflow

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).

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