i:0#.w|Ali.Mazaheri : Workflow

Patterns and practices for SharePoint is published on MSDN

AMazaheri — Fri, 07 Nov 2008 07:17:00 GMT

This guidance helps architects and developers design, build, test, deploy and upgrade SharePoint intranet applications. A reference implementation that is named the Contoso Training Management application demonstrates solutions to common architectural, development, and application lifecycle management challenges.

This guidance discusses the following:

Architectural decisions about patterns, feature factoring, and packaging.
Design tradeoffs for common decisions many developers encounter, such as when to use SharePoint lists or a database to store information.
Implementation examples that are demonstrated in the Training Management application and in the QuickStarts.
How to design for testability, create unit tests, and run continuous integration.
How to set up different environments including the development, build, test, staging, and production environments.
How to manage the application life cycle through development, test, deployment, and upgrading.
Team-based intranet application development.

Using nested StateActivity to send regular reminders in Visual Studio SharePoint State Machine Workflow

AMazaheri — Sat, 26 Jul 2008 23:44:35 GMT

Note. I want to thank Daniel Odievich for providing the content of this post, a must read!

When developing SharePoint workflows, one often needs to send email notification for a task, and then keep sending regular reminders for this task at scheduled intervals. When developing workflows in SharePoint Designer, one can use DelayUntilActivity and DelayForActivity, but those were not designed for in Visual Studio workflows.

When using State Machine workflows, the implementation for regular reminders is quite different than that in Sequential workflow. One can use put in EventDrivenActivity with DelayActivity but it will only execute once so you can only have one-time reminder, instead of regular reminders. If you try to wrap DelayActivity in a WhileActivity, the EventDrivenActivity won’t compile because its first child must be IEventActivity (such as DelayActivity).

Unlike with the Sequential workflow, ConditionedActivityGroupActivity cannot be used in State machine EventDrivenActivity. Also, one cannot write a loop around DelayActivity as it is supposed to be the first child of EventDrivenActivity.

The approach that can be taken is to use WF ability to reenter the same StateActivity over and over and thus reset the workflow. It is suggested here http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3553632&SiteID=1 but the following discussion adopts it for the SharePoint reality of task correlation tokens.

One common way to use StateMachineActivity in SharePoint is to create a task in StateInitializationActivity, register for OnTaskChanged or OnItemChanged event using EventDrivenActivity and use EventDrivenActivity with DelayActivity to send reminders. When using State Machine and SharePoint tasks, you most likely expect to reenter this state over and over, creating more tasks of the same kind (one common scenario is multi-stage approval with ability to send back the approval to previous people for re-approval). If you expect to reenter this task, you must set the all-important correlation tokens for the task should be set to use the containing StateActivity as a parent. Following is the structure you might create:

</StateInitializationActivity>

</EventDrivenActivity>

</EventDrivenActivity>

</EventDrivenActivity>

</StateFinalizationActivity>

If you run this code, you will notice the following sequence of events:

1. <CreateTask CorrelationTokenParent=“MyCustomTaskState” />

2. <SendEmail Type=“Task Created” />

3. <OnTaskChanged CorrelationTokenParent=“MyCustomTaskState” /> - register

4. <OnItemChanged /> - register

5. <DelayActivity /> - sleep

The workflow will then go to sleep and wait for either OnTaskChanged event, OnItemChanged event or for DelayActivity to elapse.

If OnTaskChanged or OnItemChange event wakes up workflow before DelayActivity has ever elapsed, and the user action causes workflow to move to another state everything is going to run correctly. However, once DelayActivity elapses, it wakes up and the following sequence of events occurs:

1. <DelayActivity /> - wake

2. <SendEmail Type=“Reminder” />

3. <SetStateActivity Target=“MyCustomTaskState” />

4. <CompleteTask CorrelationTokenParent=“MyCustomTaskState” />

5. <SendEmail Type=“Task Completed” />

6. <OnTaskChanged CorrelationTokenParent=“MyCustomTaskState” /> - register

7. <CreateTask CorrelationTokenParent=“MyCustomTaskState” />

8. <SendEmail Type=“Task Created” />

9. <OnTaskChanged CorrelationTokenParent=“MyCustomTaskState” /> - register

10.<OnTaskChanged /> - register

11.<DelayActivity /> - sleep

As you can see, your task will be completed and immediately new task of the same type will be created and new notification emails will be sent. If you sent link to the original task in the emails, the URLs in the email are no longer valid.

To avoid this, you might be tempted to wrap the activities in StateInitializationActivity and StateFinalizationActivity to avoid completing and recreating the task. If you do, you will discover that after reentering the state, OnTaskChanged events will no longer register correctly with exception indicating that correlation token for the task has not been initialized. This is because the correlation tokens use the StateActivity as a parent, and when it is reentered, they are reset, and you have orphaned your original task. There is no way to preserve those correlation tokens from one entry of StateActivity to another. A different approach is needed.

The correct approach is to use ability of StateActivity to host another StateActivity and break up task creation, task completion and task events into three separate StateActivity entities, and set the correlation token to use the top-most parent StateActivity:

</StateInitializationActivity>

</EventDrivenActivity>

</EventDrivenActivity>

</EventDrivenActivity>

</StateInitializationActivity>

If you run this code, you will notice the following sequence of events:

1. <CreateTask CorrelationTokenParent=“MyCustomTaskState” />

2. <SendEmail Type=“Task Created” />

3. <SetStateActivity Target=“TaskEventsState” />

4. <OnTaskChanged CorrelationTokenParent=“MyCustomTaskState” /> - register

5. <OnItemChanged /> - register

6. <DelayActivity /> - sleep

The workflow will then go to sleep and wait for either OnTaskChanged event, OnItemChanged event or for DelayActivity to elapse. Once DelayActivity elapses, following sequence of events occurs:

1. <DelayActivity /> - wake

2. <SendEmail Type=“Reminder” />

3. <SetStateActivity Target=“MyCustomTaskState” />

4. <OnTaskChanged CorrelationTokenParent=“MyCustomTaskState” /> - register

5. <OnTaskChanged /> - register

6. <DelayActivity /> - sleep

Whenever the task change occurs that indicates that workflow is ready to move to another state, the following sequence of events occurs:

1. <OnTaskChanged CorrelationTokenParent=“MyCustomTaskState” /> or

2. <UpdateTask CorrelationTokenParent=“MyCustomTaskState” />

3. <IfElseActivity>

4. <IfElseBranch Condition=“Task Completed”>

5. <SetStateActivity Target=“CompleteTaskState” />

6. <CompleteTask CorrelationTokenParent=“MyCustomTaskState” />

7. <SendEmail Type=“Task Completed” />

8. <IfElseActivity>

9. <IfElseBranch Condition=“Task Completed”>

10.<SetStateActivity Target=“OtherState” />

Whenever the item change occurs that indicates that workflow is ready to move to another state, the following sequence of events occurs:

1. <OnItemChanged />

2. <SetStateActivity Target=“TaskEventsState” />

3. <IfElseActivity>

4. <IfElseBranch Condition=“Task Completed”>

5. <SetStateActivity Target=“CompleteTaskState” />

6. <CompleteTask CorrelationTokenParent=“MyCustomTaskState” />

7. <SendEmail Type=“Task Completed” />

8. <IfElseActivity>

9. <IfElseBranch Condition=“Task Completed”>

10.<SetStateActivity Target=“OtherState” />

The workflow designer outline of this is shown below:

Overall view of the parent state

Overall hierarchy of all activities

CreateTaskState with creation of the task and events

Properties window of CreateTask activity with correlation token pointing to parent state of all three activities

EventDrivenActivity for OnTaskChanged event

EventDrivenActivity for OnItemChanged event

EventDrivenActivity for DelayActivity and reminder email

CompleteTaskState and transition to another state

www.MSSharePointDeveloper.com launched!

AMazaheri — Tue, 03 Jun 2008 00:52:00 GMT

This is just announced by Paul Andrew:

To help drive adoption of SharePoint by Software Developers we have launched a campaign to .NET Developers at http://MSSharePointDeveloper.com. We’re doing advertising at TechEd Developers USA this week and on www.asp.net. The new material is designed to help .NET Developers to learn the top ten artifacts in SharePoint that are interesting to them. We’ve created a variety of materials with different learning styles to make getting started with these artifacts easy and it’s all based on the Visual Studio extensions for SharePoint – planned to release v1.2 for Visual Studio 2008 this week also (watch for their announce).

The Top Ten SharePoint Artifacts of interest to .NET Developers being promoted

· Web Parts

· Data Lists

· Event Handlers

· Workflows

· Silverlight Web Parts

· Page Navigation

· Page Branding

· Web Services

· Content Types

· User Management

At the site (which is hosted on microsoft.com) we have:

· An Introductory Whitepaper

· Benefits of SharePoint for Developers

· A Small Public VPC

· Hosted MSDN Virtual Labs in C# and VB.NET

· Video Interview with SharePoint MVPs

· Screencasts

· Web Casts with SharePoint MVPs (incredible 1705 live attendees in just the first four WebCasts)

· Quickstarts

· Labcasts

· Presentation Download

· Hands on Labs Download

· Additional Resource Links

The site encourages developers who use the content to also take a next step and go on Instructor Led Training, Get Certified, and Download an evaluation copy of Microsoft Office SharePoint Server.

http://MSSharePointDeveloper.com

New whitepaper on Workflow and SharePoint

AMazaheri — Sat, 03 May 2008 01:15:00 GMT

A new whitepaper on Workflow titled "Developing Workflow Solutions with Microsoft Office SharePoint Server 2007 and Windows Workflow Foundation" by a good friend of mine Daniel Odievich and truly yours is now published (as of 05/23/08) on MSDN.

Update: Whitepaper's sample projects (sequential and state machine) source code should be accessible for download soon.

Setting Workflow Status to custom value

AMazaheri — Fri, 08 Feb 2008 08:37:00 GMT

To set the Workflow status to a custom value add your custom Status values to workflow.xml under <MetaData>:

<ExtendedStatusColumnValues>
<StatusColumnValue>Rejected</StatusColumnValue>
<StatusColumnValue>Failed Verification</StatusColumnValue>
</ExtendedStatusColumnValues>

Using SetState activity and SPWorkflowStatus you can set the status programmatically as follows:

private void setState_MethodInvoking(object sender, EventArgs e)
{

    if (!this.changeApproved)
    {
        //Set workflow status to Rejected
        this.workflowState = (int)SPWorkflowStatus.Max;
    }
    else
        //Set workflow status to Failed Verification
        this.workflowState = (int)SPWorkflowStatus.Max + 1;
}

Using Delay activity in WSS 3.0 custom Workflows (Lessons learned)

AMazaheri — Fri, 08 Feb 2008 07:12:00 GMT

WF's DelayActivity is best suited for scenarios such as sending Reminders or if you want to force your WF to dehydrate for a batch update on Item's column(s), as you may know a .NET 3.0 hotfix or SP1 needs to be installed so that the Delay activity works.

Scenario:

You use DelayActivity and set the TimeoutDuration property to 5 minutes, after running the WF you notice that the Delay activity still does not work. In WSS 3.0, Delay activity gets triggered by a timer job (Job-workflow) which by defeat runs every 15 minutes and that explains why your WF instance never wakes up by Delay activity. Fortunately you can modify the setting for this timer job as you do not want to wait for 15 minutes while debugging your code! In order to change the default setting you need to run the following command:

STSADM -O SetProperty -pn "Job-Workflow" -pv "Every 5 minutes between 0 and 59" -url [url of the Web application]

Note.

Make sure that you do not change this setting in Production environment as it may have some performance hit and use the above command only for debugging purposes in your Dev environment.

How to get the name of the user changing a Task in a Custom workflow code

AMazaheri — Mon, 28 Jan 2008 02:13:00 GMT

I was asked by one of my colleagues on how to have access to the name of the user who is modifying a task programmatically within the Workflow code. Every time a task gets modified by a user (SPTaskProperties.AssignedTo) the OnTaskChanged activity populates the OnTaskChanged.ExecutorProperty and the name of the user can be retrieved by referencing this property.

Note:
SPWorkflowActivationProperties.Web.CurrentUser.Name has "System Account" as value as by design all custom Workflow instances (Implemented by Visual Studio 2005/2008) run under that account.

Next post: Setting Workflow related properties in MOSS/WSS 3.0 using stsadm.exe