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

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.

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

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.

What he said was:

With OnTaskChanged there is the BeforeProperties and AfterProperties variables.

In the event can’t you set the AssignedTo in the AfterProperties?

This seemed perfectly reasonable - and I hadn’t thought of it already, so it was worth a try (wood/trees obscuration).

I created a workflow that consisted of 3 steps - a Create Task step, a While Loop (that is always true) and in the While, I put an onTaskChanged event step.

Creating the task, you set the assignee using an SPWorkflowTaskProperties object. Here is my line for doing that:

TaskProperties.AssignedTo = "MOSS\\Domain Users";

That’s pretty clear. I then wrote code to set the AfterProperties of the onTaskChanged event:

TaskAfterProperties.AssignedTo = e.Identity;

Typically, e.Identity is something link “MOSS\\burnsa”. I’ve checked. And that’s what I’d expect it to be.

So, the workflow enters the while loop - which as I say, deliberately never exits - an the workflow awaits a change in the task. When that change comes, I’m going to look at the AssignedTo field of both the BeforeProperties, and AfterProperties. Oh, yeah, and I deliberately WASN’T changing the assignee within the task.

BeforeProperties - Expected: “MOSS\\Domain Users” - Actual: null

AfterProperties - Expected: “MOSS\\Domain Users” - Actual: “16″

…and setting the AfterProperties with e.Identity did damn all. WTF?

I could understand that setting AfterProperties with e.Identity might not work - although it seems a reasonable thing to try and do - but the AssignedTo fields being null, and then 16? Don’t make no sense.

Oh, further - I tried again, but this time setting the assignee as my change to fire the onTaskChanged event. This time the AfterProperties assignedTo field was ‘13′, so clearly it is some sort of identity - just not an obvious or particularly useful one.

Conclusion: Well, it has basic RM functionality, but the guy taking the presentation did comment that it doesn’t fulfil all the legal requirements for some of the countries in Europe. Nobody was entirely sure which ones, though, and I’m not sure about the UK. Because of the structure of the system, I did find myself wondering if you might not end up with absurdly large lists of documents (see below). It should be possible, to some degree, to plug into the RM facilities of the system, and the use of the workflow foundation on the expiry of the retention schedule is nice as it should provide a good degree of flexibility.

Okay, so how does it work? First, a little about the structure of SharePoint sites and lists. Then we’ll consider content types, and then policies and RM.

So SharePoint is made up of Site Collections, which are collections of, well, Sites. Sites contain Lists and, potentially, subsites. This is kind of a difficult concept coming from the Livelink world, and the analogies of folders or projects don’t really fit. It’s almost that sites provide the hierarchy, while lists are the folders, discussions, task lists, etc., that you get in Livelink. Sites can contain many lists of the same type. So, for example, you might have a structure like

• Organisation SharePoint 2007 system
  • Organisation Site Collection
    • Accounts Site
      • Travel Expenses List
      • Documents In List
      • Documents Out List
      • Discussion List
      • …
    • Invoice Site
      • Travel Expenses List
      • Invoice Forms List
      • …
    • Pensions Site
      • Travel Expenses List
      • Pensions Documents List
      • Complaint Documents List
      • Pensions Form List
      • Project Deathrattle Sub site
        • Project’s Documents List
        • Projects News List
      • …

(For some reason, Documents Lists and Forms Lists are actually called ‘Libraries’ in SharePoint terminology. I’m going to call them lists though).

Okay, next concept - content types. This is basically a definition of ‘columns’ of metadata that we want to capture. These definitions can then be applied to Lists throughout the site. For example, we might want to define a ‘Travel Expenses’ content type, which we could apply to the ‘Travel Expenses’ lists in each of the 3 sites in the example above. It could define metadata like, date of travel, cost, destination, etc., and we could make this mandatory. Thus, we define what we want to capture for multiple lists.

Content types are important as they control where a document ends up in the Record management system. We’ll see this in a bit.

Records Management adds a special ‘Records Repository’ site to the SharePoint system - I’m not clear if this is on a system or site collection level. This site is optimised for RM - options on menus, etc., are geared towards RM actions and stuff.

What we do is create an Information Management Policy (retention schedule) for either a content type, or a particular document list. For example, we could define a policy just for the Pension ‘Complaint Documents List’, or if we created a policy for our ‘Travel Expenses’ content type, then all 3 lists using it would have an information policy defined.

The information policy has features like Labels, auditing, Barcodes, expiration dates and rendition to other formats. We didn’t really go into these options. Expiration has a number of ’standard’ options (like deleting the document), or you can create a Windows workflow to run when expiration occurs.

Having defined a source, we define a destination in the Records Repository (see here). This will be a list, with a content type specifying the metadata to capture. I don’t think that this HAS to be the same as the content type in the source list, though that would be a logical choice.

Defining the source and destination like that populates a ‘routing table’. A user can then select a function from a document’s menu to save a copy of the document as a record. It is worth noting, it IS a copy of the document. SharePoint looks up the document’s content type, and routes it (based upon the ‘routing table’) to the appropriate list. There are special lists for ‘unclassified’ documents (those without a routing), and for documents with incomplete mandatory metadata (these can be completed and put into the right lists)

So, for example, we might have a ‘Travel Expenses Records’ list, and have any document with a content type of ‘Travel Expenses’ that is declared as a record gets put in this list. Thus, travel expenses records from all 3 departments would end up in this list. ‘Complaint Documents’ might be routed to a different list.

So, we’ve got a bunch of documents in our lists, and they have retention schedules, which will eventually expire and delete/archive the documents. When we’re sued, though, we might want to ‘hold’ documents related to the case, so they don’t get deleted.

First, we create a hold (giving it a name, details, etc.), and then we add documents to it. Documents and holds have a many-to-many relationship - a hold can apply to many documents, and documents can be part of many holds. If a document has any holds applied, it can’t expire or be deleted. It is possible to perform a search, and then hold all documents returned by the search.

The other part of the demonstration looked at declaring a document as a record twice. This would create 2 records in the Records Repository, even if the document is unchanged - i.e.. EVEN IF THE TWO RECORDS ARE THE SAME. So, the second part of the demo looked at adding to the ‘routing stack’ - a series of things that happen when a document is declared a record. Basically, what this did was add a ‘filter’, which recorded which items had been stored as records, and rejected attempts to store an item that had been recorded already. See here for more details.

There is an UpdateTask workflow activity

Okay, so I missed the obvious - that to update a task would require an activity if it is to work in SharePoint Designer. However, I tried adding this to a workflow. When I went to the workflow code, I got the error:

Code generation for property ‘PercentComplete’ failed. Error was: ‘Property accessor ‘PercentComplete’ on object ‘Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties’ threw the following exeception: ‘Object reference not set to an instance of an object’

Phew. Nice error. Then, sometimes, I managed to get the Designer view to have errors - it couldn’t draw the workflow. And build failed - the workflow designer.cs file lacked the line defining the private variable referencing the UpdateTask object. Oh, and trying to set properties of the task to update - more errors.

The short is, in Beta 2, Update Task doesn’t seem to work. I don’t think that there is a lot I can do to fix this…

Just in case I ever need this (and the page goes missing):

<style>
.squiggle
{
background-image:url("squiggle.gif");
background-repeat:repeat-x;
background-position:left bottom;
padding-bottom:2px;
vertical-align:text-top;
font-style:italic;
}
.container
{
border:1px solid #a5a5a5;
overflow-x: hidden;
width: 100%;
color: windowtext;
height: 18px;
background-color: window
}
</style>
<div class="container" contenteditable="true" tabindex="0">
<span class="squiggle" contenteditable="false" tabindex="-1">
<div style="DISPLAY: none" displaytext="here"></div>
<span contenteditable="true" tabindex="-1">unresolved!</span>
</span>
</div>