Datasheet

Chapter 1: Workﬂ ow Programming Principles

Keep in mind that the Initialize method of an activity is invoked only once in the lifetime of the activity.

This is important considering the fact that the lifetime of an activity could span multiple threads,

processes, or machine boundaries and could last an indefinitely long period of time.

Also keep in mind that initializing an activity as a logic program statement in a workflow as a logical

program is different from initializing the Common Language Runtime (CLR) object that transiently

represents the activity in memory. Object initialization is a CLR concept, whereas activity initialization is

a WF concept. The same activity or logical program statement may be represented by numerous CLR

objects during its lifetime, whereby each CLR object is initialized when it springs into life. While

numerous CLR initializations could be associated with the same activity or logical program statement,

only one WF initialization is associated with the activity.

This has an important consequence. You must not contain one - time initialization logic of your activity

in the constructor of your activity class, because the contructor of your activity class is invoked every

time a new CLR object springs into life — that is, every time your activity resumes its execution after an

external entity deposits data. If you include the one - time initialization logic of your activity inside the

constructor of your activity class, your activity will be initialized multiple times during its lifetime.

That being the case, you must contain all your activity ’ s one - time initialization logic inside the Initialize

method.

At this point, you may be wondering how an external entity accesses a workflow queue. As mentioned,

you can think of a workflow as a logical program, somewhat like a C# program, and its constituent

activities as logical program statements, somewhat like C# program statements. Just as you can have

multiple instances of the same C# program running in memory, you can also have multiple instances of

the same logical program running. Every running instance of a logical program in WF is represented by

an instance of a class named WorkflowInstance.

The WorkflowInstance class exposes a method named EnqueueItem, which an external entity can use to

deposit data into a workflow queue with the specified name:

public sealed class WorkflowInstance

{

public void EnqueueItem(IComparable queueName, object item,

IPendingWork pendingWork, object workItem);

}

The external entity simply passes the workflow queue name as the first argument of the EnqueueItem

method, and the data that needs to be deposited as the second argument of this method.

Note that workflow queue names are treated as IComparable objects in WF. This means that you can use

any IComparable object as the workflow queue name. However, a string generally does the job.

As you can see, the external entity needs to know the name of the workflow queue in which it needs to

deposit the data. It also needs access to the WorkflowInstance object on which it needs to invoke the

EnqueueItem method. You do not have to worry about this in SharePoint because SharePoint provides

you with a convenient layer on top of WorkflowInstance that enables you to deposit data into the

appropriate workflow queue much more conveniently. This will all be clear later in the book.

c01.indd 9c01.indd 9 8/25/08 4:02:54 PM8/25/08 4:02:54 PM