22 January 2007

More on WF: Getting Started

Continuing with the research on Workflow Foundation, here goes just a couple of things to get started with.

1- Quickly create your first sequence workflow

[See my previous post about the requirements for developing .Net framework 3 features.]

I am not going to put many details here, but to create your first workflow you need to select one of the workflow project templates in Visual Studio 2005. Just to start select the Sequential Workflow Console Application template. This generates a project with the references to the WF assemblies, the workflow itself and a test program.

By clicking on the workflow class the workflow is shown in the designer. Here is where you can drag activities from the toolbox. For example drag a CodeActivity. In the CodeActivity ExecuteCode property, type a method's name and press enter. VS will generate the method stub for you. Just write hello world to console there. Pressing the "view code" tab, the partial class with the workflow code (wfl properties, event_handlers, methods, etc) appears. You can see that the workflow inherits from SequentialWorkflowActivity.

So far we have the workflow defined with a set of activities. What we need now is to host the workflow and execute it. The generated program shows us how to do it:

using(WorkflowRuntime workflowRuntime = new WorkflowRuntime()) {

...

WorkflowInstance instance = workflowRuntime.CreateWorkflow(typeof(WorkflowConsoleApplication1.Workflow1));

instance.Start();

...

}

So, just press F5 and see the greeting message!

2- Get a feel of the Pre-build Activities

Some of the pre-build activities I have been experiencing with:

  • CallExternalMethod
  • Code
  • Delay
  • IfElse
  • Listen
  • Sequence
  • HandleExternalEvent

They are more or less self explained...I only want to mention one thing that may be a constraint in some circumstances:

The CallExternalMethod activity needs the following properties to execute:

  • InterfaceType
  • MethodName
  • Parameters

and the HandleExternalEvent similar properties:

  • InterfaceType
  • EventName
  • Parameters

In both cases the InterfaceType must be an Interface decorated with the ExternalDataExchange attribute, only this type of interfaces will be listed by the object browser. So the presence of that attribute is what I think may be a restriction as you can't use just any already built assembly.

3- Pass data to the WF:

There are two general approaches for receiving data into a workflow when it is started. They are Parameters and Events. With parameters, a list of parameter names and types are defined with the workflow. These parameter values are passed in by a host when it starts a new instance of the workflow type. With events, workflow authors add an activity that receives an event and data associated with the event. Events are generally specific to the host and custom activities that have been designed to handle the event.

The parameters can be passed in the CreateWorkflow method as shown here:

using(WorkflowRuntime workflowRuntime = new WorkflowRuntime()) {

...

Dictionary<string, object> parameters = new Dictionary<string, object>();
parameters.Add("FirstName", "Tom");
parameters.Add("LastName", "Sawyer");

WorkflowInstance instance = wr.CreateWorkflow(typeof(HelloWorldWorkflow.Workflow1), parameters);
instance.Start();

...

}

4- Make use of Conditions

A rule condition is a condition statement that is created in a dialog and stored as XML with the workflow. It can include predicates that compare workflow state and Boolean algebra combining multiple predicates. The conditions can be used in various activities including IfElse, While, ConditionedActivityGroup, and Replicator.

Take for example the IfElse activity. A condition can be set to one or both of its branches using the activity's properties. You can specify a CodeCondition or a DeclarativeCondition. In the first case you just enter the method's name. When you press enter the condition handler will be generated and shown in the code window. Put your logic in there, for instance:

public void If_Condition(object sender, ConditionalEventArgs e){

e.Result = this.reviewArgs.Review.Approved;

}

When using the DeclarativeCondition, you can use the Condition Editor to create it. You can access the workflow properties by intellisense.



16 January 2007

My turn in the blog-tag game!

As I’ve been tagged by my boyfriend, I suppose it’s my turn in this blogger’s game to play. So, here goes 5 things some people may don’t know about me:


  1. I went to live on my own a few months ago, to a very cute apartment in Almagro, 5 blocks from my parents. It can’t actually be said a live “alone” since I have this eternal, and of course very welcome and lovely visit, my boyfriend.

  2. I have a degree in Electronic Engineer from the University of Buenos Aires, but I’ve never worked as such. I have always worked as a software developer, nowadays in a great software company: Lagash Systems.

  3. I have always like Maths. I kind of have it in the blood since both my parents are mathematicians. I’ve always teach math, first giving particular lessons and since many years now at the university, where I still teach “Algebra II” and used to teach “Probability and Statistics” too.

  4. When I was young I studied music for many years (since I was 6 till 15) at the National Conservatory. I played piano and flout. Unfortunately I have a very bad memory and can’t remember a single piece of music. But I can still play if I’m in front of the sheet. I play mostly classic, despite for some Queen songs I learned when I was a teen and a great fan of them.

  5. In my free time? I like to walk, dance, and go biking a lot. I try to go by feet everywhere whenever it is possible. I don’t like to stay much inside, I prefer to take some air. I really enjoy going anywhere with my boyfriend, going to the country house on Sundays with the family and hanging out with my friends.


Now it's time to tag another 5 people: RodolfoF, Zaiden, PabloC , Cyn and Pede.

05 December 2006

First steps in Workflow Foundation

I have started to play with Windows Workflow Foundation (WF) a few days ago. So far it seems very interesting, shipping with handy pre-build activities, persistence and tracking services, prity designers for visual studio, the capability of hosting these designers anywhere else…web services interaction, etc. Promising.


I just want to take down some notes here so I don't forget what I've learned.


Some Material

Some Concepts
  • Windows Workflow Foundation (WF): Set of components, tools, and a designer that developers can use to create and implement workflows in .NET Framework applications. It is part of the Microsoft .NET Framework version 3.0.
  • Workflow: a set of activities that are stored as a model that describes a real-world process. A workflow is designed by laying out activities.
  • Activity: A step in a workflow. The unit of execution, re-use and composition for a workflow.
  • Types of workflows (Here is a post about how to decide which type to use):
    • Sequential: Consists of activities that execute in a predefined order. Has a clear direction of flow from top to bottom, although it can include loops, conditional tests, and other flow-control structures.
    • State-Machine: Consists of states and transitions that change a workflow instance from one state to another. Although there is an initial state and a final state, the states have no fixed order, and an instance can move through the workflow in one of many paths.
    • Data-Driven: Is usually a sequential workflow that contains constrained activity groups and policies. In a data-driven or rules-based workflow, rules that check external data determine the path of a workflow instance. The constrained activities check rules to determine the activities that can occur.

The framework component model

The WF framework consists on 3 assemblies, containing the following namespaces:

  • System.Workflow.Activities
    • System.Workflow.Activities: Defines activities that can be added to workflows to create and run an executable representation of a work process.
    • System.Workflow.Activities.Configuration: Provides classes that represent sections of the configuration file.
    • System.Workflow.Activities.Rules: Contains a set of classes that define the conditions and actions that form a rule.
    • System.Workflow.Activities.Rules.Design: Contains a set of classes that manage the Rule Set Editor and the Rule Condition Editor dialog boxes.
  • System.Workflow.ComponentModel
    • System.Workflow.ComponentModel: Provides the base classes, interfaces, and core modeling constructs that are used to create activities and workflows.
    • System.Workflow.ComponentModel.Compiler: Provides infrastructure for validating and compiling activities and workflows.
    • System.Workflow.ComponentModel.Design: Contains classes that developers can use to build custom design-time behavior for workflows and activities and user interfaces for configuring workflows and activities at design time. The design-time environment provides systems that enable developers to arrange workflows and activities and configure their properties. The classes and interfaces defined within this namespace can be used to build design-time behavior for activities and workflows, access design-time services, and implement customized design-time configuration interfaces. It includes the TypeBrowserEditor, a cool feature that can be reused.
    • System.Workflow.ComponentModel.Serialization: Provides the infrastructure for managing the serialization of activities and workflows to and from extensible Application Markup Language (XAML) and CodeDOM.

  • System.Workflow.Runtime
    • System.Workflow.Runtime: Classes and interfaces that control the workflow runtime engine and the execution of a workflow instance.
    • System.Workflow.Runtime.Configuration: Classes for configuring the workflow runtime engine.
    • System.Workflow.Runtime.DebugEngine: Classes and interfaces for use in debugging workflow instances.
    • System.Workflow.Runtime.Hosting: Classes that are related to services provided to the workflow runtime engine by the host application.
    • System.Workflow.Runtime.Tracking: Classes and an interface related to tracking services.

Wix install sequence

I am trying to figure out the exact behavor of the install sequence in the setup, as defined in a wix .wxs file. The confusion comes from the presence of the InstallUISequence and the InstallExecuteSequence tags, leaving aside the fact that there are actually four tags related to the actions sequence (AdminUiSequence and AdminExecuteSequence are used in administrative installs). As it is said in the wix turorial, "InstallExecuteSequence is always consulted by the installer to determine the actions, InstallUISequence is only considered when the installer runs in full or reduced UI mode." So, if executing without user interface, the order is determined for the InstallExecuteSequence and no doubts remain. But, if executing in full or reduced UI mode, both sequences are consulted. So, what is the resulting order of execution? If an action is placed in both sequences, it is executed twice?

As for the executing order, what I suppose happens is that all actions in the InstallUISequence are run first (since they gather the information required for the installation) and then those from the InstallExecuteSequence. But it is possible that some actions need to be executed before any UI dialog, so then we should place them in both sequences.

If an action is placed in both sequences, they will be apparently executed twice. Al least one exception for this rule is the AppSearch action. In the schema reference it says: “AppSearch should be authored into the InstallUISequence table and InstallExecuteSequence table. The installer prevents The AppSearch action from running in the InstallExecuteSequence sequence if the action has already run in InstallUISequence sequence.”

For custom actions, the execute attribute can be used for preventing the double execution.