Ariel Schapiro » Windows Workflow Foundation

WF 3.5 Certification exams design session

aschapiro — Mon, 28 May 2007 05:06:23 +0000

Last week I’ve been participating on the design of the upcoming TS (Technology Specialist) certification exams for WF 3.5. (formerly known as "70-504: TS: .NET Framework 3.5 – Windows Workflow Foundation")

The sessions have been organized by the Microsoft Learning team and hosted by Howard Dierking, who did a great job on helping us to discuss about the most important aspects of WF to test.

He explained the refactoring of the exam stack and how having TS exams which are specific to a single technology and then PRO exams which are more scenario oriented can help software companies on measuring their applicants skills.

From left to right, the Subject Matter Experts that worked on that design sessions are: Ariel Schapiro, Serge Luca, Alfred Myers, Brian Myers (author of "Introduction to Windows Workflow Foundation" book) and Mark Dunn.

It was really interesting to see how many points of view around the same subject help enormously in the design of an exam; good work guys!

Two more southies (Matias Woloski and Johnny Halife) participated in the WCF design sessions that took place one week before WF’s.

SaaS Workshop

aschapiro — Fri, 30 Mar 2007 07:07:24 +0000

Fred Chong, Gianpaolo Carraro, Erik Weis and Matias Woloski gave a 3-day workshop on SaaS, at Microsoft HQ in Redmond.

Attending Microsoft employees and ISVs used a SaaS reference application based on LitwareHR to get inside of the architectural challenges solutions for data model configuration, tenant provisioning, workflow configuration and security.

Check Matias’s post for more details.

Beta 1 to Beta 2 bumpy road…

aschapiro — Mon, 27 Mar 2006 10:42:00 +0000

As every WF follower, I also made
the upgrade from beta 1 to beta 2.
I needed a state machine workflow using a persistence store, but I realized
that beta 2 doesnâ€™t exactly “extends” beta 1 when I started
seeing some building errors like this one here regarding the persistence store:

System.Data.SqlClient.SqlException
was unhandled
Message=”Procedure or function InsertWorkflow has too many
arguments specified.”

So I turned to some forum help and got the SQL scripts I had to run in order
to create beta 2 SQL persistence store, which by the way, once you have
installed the beta 2, you can find here: C:\WINDOWS\WinFX\v3.0\Windows Workflow
Foundation\SQL\EN (remember to run first schema, then logic script for each
database).

If you think that your beta 1 code
will build ok on your beta 2 you may be probable wrong if you donâ€™t take in
count the changes. Because many of them are more than just an upgrade and make
beta 1 code simply doesnâ€™t work! (Take a look at the advice section).

Another big addition to beta 1 may
be the StateMachineWorkflowInstance class, which you can use to query state
machine workflow instances about their current state, which states they can
transition to, get all the workflow states, etc. Itâ€™s very useful if you want
to get control of many state machines currently running just like in an
ordering system case.

The most useful conclusion I find for readers may be a short but powerful
advice list:

Take a look at Paul
Andrewâ€™s guide of changes from beta 1 to beta 2 and read carefully the
aspects of your project that may change.
Get the
labs.
Visit the Win FX
WF home.
And last but absolutely not the least: keep an
eye on the WF
Forums; theyâ€™ll save you a lot of time!!!

Using Workflow Monitor: tutorial, example and analysis.

aschapiro — Tue, 08 Nov 2005 22:34:00 +0000

Monitoring workflows is going to become an essential functionality in almost every BPM implemented with Windows Workflow Foundation. It allows administration users to get a fast and smart track of what’s going on with their multiple running workflows. This way, they can get a better control, summarized information and customized reports about running or closed workflows.

Here is a little example on how to configure and use the Workflow Monitor, using a simple workflow launcher solution to make a brief analysis of what can Workflow Monitor do for us.

This WM is an application that let you see the running or completed workflows, all along with some information like their activities and even a design view of the selected workflows.

Getting and configuring the WM:
This WM sample comes with Windows Workflow Foundation and you get it this way:
1) Open Windows Workflow Foundation Help: \Documents and Settings\\Start Menu\Programs\Windows Workflow Foundation\Windows Workflow Foundation Help
2) Navigate to: Windows Workflow Foundation Samples -> Application Samples -> Workflow Monitor.

This WM can show workflows details because it reads tracking information from the tracking database, so you must have installed the out-of-box SqlTrackingService. So once you have installed WM, just follow the “Configuring the SqlTrackingService Database” steps of the Windows Workflow Foundation Help up to step 4.

Step 5 is important because adds some stored procedures to the database which WM needs. In step 5, maybe you won’t find the monitor_queries.sql file, but don’t desperate!!! Its on the WorkflowMonitor folder that you just got from the Windows Workflow Foundation Help!!!

WorkflowLauncher installing and configuration:
Download WorkflowLauncher solution from here.
In the App.config file of the WindowsApplication1 from the WorkflowLauncher solution, change the Initial catalog and Data Source properties of the ConnectionString for the SqlTrackingService type of service writing your own catalog and data source strings (Initial Catalog should be "Tracking" if you used the names suggested by the Windows Workflow Foundation Help).

Note the TrackWorkflowDefinition propery is set True!!!
Build the solution.

Making that the Workflow Monitor can see the sampleWorkflow:
You must add the WorkflowProject1 assembly to the WM folder so that it can show you the design of the workflow we are going to run:

Copy
WorkflowLauncher\WindowsApplication1\bin\Debug\WorkflowProject1.dll

file to WorkflowMonitor\CS\bin\Debug folder.

Using the Workflow Monitor:
If you did the 3 last steps, we are good to go. Open the WorkflowMonitor solution, set the active solution configuration to “Debug”, build the solution and start it.
Start the WorkflowLauncher solution. The WorkflowLauncher just launch a simple sequential workflow with a delay of the amount of seconds that you enter on the textbox. You can launch workflows that last as long as you want while you analyze the WM window.

Both windows should look like this:

Turn ON the monitor by pressing the green play button on the WM window. Open the Settings window and set the Polling Interval to 500 ms. Use the WorkflowLauncher to launch a 15 seconds lasting workflow:

As you can see, as the WM reads the Tracking information stored on the SQL database, shows the workflow details including the design of it. It even shows which activities are closed and which ones are running!!!:
When the 15 seconds period finishes, the WM reads the updated information from the tracking service, which says that the workflow is done:

And that’s how you can start playing with the WM…

Some benefits:
This WM works with the SqlTrackingService, so it shows the main information that services provides. But a great advantage is that you can make your own persistence service and make your own monitor to read it.

Imagine that you could organize your workflows by type so you monitor them and see in which step is every one of them or how many of them reached some point, etc…. Possibilities are countless!!!!!

If you start a 60 seconds workflow, you close the WorkflowLauncher window (closing the Runtime) and open it again before the 60 seconds, that workflow will complete right on the 60 seconds time. That’s because when the runtime is started, the persistence services are also started so the runtime can take in count persisted but not closed workflows and continue running them.

Some issues:
Multiple Definitions of the Same Workflow Type:
The SqlTrackingService will persist the workflow markup definition the first time a new workflow type is used. However, if the definition changes and the type version remains the same a new record is not persisted in the tracking database. This will result in the monitor always showing the first definition. You should check the “Workflow” Table on the Tracking database.

Dynamic Update:
The Workflow Monitor does not recognize dynamic changes to a workflow instance. If a workflow instance is changed while executing the Activity Pane will show the correct status information but the Workflow View Pane will not show the updated workflow definition and may not show the correct highlighted activity.

So use it, make your own conclusions and tell me how it was!!!

If you are new to WWF, this simple explanation can help.

Chaining Workflows Synchronously: InvokeWorkflowSync Activity v1.0

aschapiro — Tue, 01 Nov 2005 23:07:00 +0000

The InvokeWorkflow Activity does a great job calling workflows asynchronously. This way you can call a workflow to start from your current workflow and keep going.
But what if you want to start it synchronously? What if you want to chain workflows in a hierarchical architecture and you don’t want to use the "fire and forget" pattern to call your workflows?
That’s why I created the InvokeWorkflowSync Activity. It’s an easy way of calling workflows the way InvokeWorkflow does but with the difference that the main workflow won’t continue until the invoked workflow has completed.
So give it a try and tell me how was it!!!
Using it:
Once you build the ActivityLibrary that contains the InvokeWorkflowSync Activity, drag it from the Toolbox to the workflow you want to use it on:

In this version, you have the same main parameters as the regular InvokeWorkflow Activity has:

TargetWorkflow: Type of workflow to invoke.
Invoking: Event that fired before the workflow is invoked.
Invoked: Event that fired after the workflow is invoked.

Once you run your application, invoking workflows will continue running just after their invoked workflows complete its execution.
You can see it in the demo, where I used 2 InvokeWorkflow activities: the first one invokes a workflow where another InvokeWorkflow activity calls the third and last workflow in the chain. The idea is to make easier a hierarchical chaining system made of workflows.

How it works:
As I first took a glance at InvokeWorkflow activity I realized that its a sealed class so lamentably I had to made my own InvokeWorkflowSync inheriting it from System.Workflow.ComponentModel.Activity.
Execution:
The overriding InvokeWorkflowSync.Execute method is the one that has the activity execution logic, and mainly performs the following tasks:

Get Runtime from the context:

Start listening for passed Workflow to complete:

Start passed workflow:

And once the workflow is completed, goes on:

Validation:

The InvokeWorkflowSync is validated by the InvokeWorkflowSyncValidator class with its Validate method. This one checks that the TargetWorkflow Parameter isn’t null retrieving an indicating smart tag in case it is:

Some issues:

Workflow Parameters: passing parameters to workflows is not allowed in this version. Will be ready for next version.

Time out Parameter: Since workflow is called synchronically, it would be nice to have a time out parameter for which the main workflow would keep its execution terminating the invoked workflow. Will be ready for next version.

Which Workflow Style should I use?: More approaches…

aschapiro — Thu, 27 Oct 2005 00:00:00 +0000

People are asking around which style of workflow should they use for their scenarios and its important to know which workflow type fits best with which scenario, but that’s just the first step!!! Once you get there, there is a whole and exciting world in which open-minded developers started playing a few months ago, a “building blocks game": Windows Workflow Foundation.
This game comes with certain ways of playing it (workflow styles), some rules (you are attached to a certain technology), a booklet (documentation) and of course the building block themselves (toolbox Activities), etc….
Since this game is a building one, it comes with the tools you need to build, and the booklet shows you the best ways of building some sample constructions. This is useful because you get to know which approach you must take in order to build your own construction.
Going back to our real game, there are some questions you can ask yourself in order to know which workflow style is more suitable for your application:

That is how some order approval workflow (where users are in control of the sequence) fits better with a State Machine type and a vendor machine workflow (the machine makes the decisions based on inputted data) fits best with a sequential style… You can find similar ideas in a Dave Green´s great post.
One important thing are some approaches that go hand by hand with each workflow type. And that´s another way of noticing which type of workflow you must use. Because if you have a sequential workflow full of event driven activities, you will solve your problem in a much better way using a state machine style, for example.
Another important approach mentioned in Dave´s post is the Data Driven, which is typically solved by a list of activities executed on a variety of conditions. This approach is implemented by the "Constrained Activity Group" and the "Policy" models, typically found in sequential workflows.
However, as I said before, this is just the beginning…because maybe (you will probably agree with me on this…) you need to combine both of these approaches to solve your scenario. This leads us to custom workflows, which are not another thing than custom activities!!!
Then, one after another, you will find yourself thinking about other aspects of Windows Workflow Foundations that you must implement and in many cases extend.
Some of those could be communication by local connection, communication by web services, workflow persistence services, etc…
As a conclusion we can say that its fundamental to know which workflow style you should use for which scenario. But its even more important to understand that you will probably have to make use of the tools that the game of windows Workflow Foundation gives you to make your own Workflows (in a practical way you can see a workflow as an activity) and arrange the context (host, communications, persistence, etc) to serve the solution…… But the best way of getting to understand this is, like a game, by playing with it!!!
PS: some extending explanations on related stuff comes tomorrow…stay tuned!

ASP.net + WWF Example: Navigation Map with Local Connection approach.

aschapiro — Thu, 20 Oct 2005 17:53:00 +0000

This example intends to show a way of implementing some kind of a navigation map for websites based on workflow.
Because
of the navigation nature of web sites (the user navigates through nodes
without a specific order), the chosen workflow is a state machine type.

For this simple example, we use just two nodes represented by web pages. In the first one (Create step represented by Default.aspx page), the user enters some data that is stored inside the workflow and then retrieved in the second step of it (Show step represented by Show.aspx page):

We are investigating many ways ASP.net and WWF interact so stay tuned for more approaches!!!
Download: ASPNET_NavigationWorkflow.zip
Related URL: James conardÂ´s ASP.NET WebForm Example

Build Workflows outside of the VS2005

aschapiro — Wed, 19 Oct 2005 23:30:00 +0000

An interesting idea that has been getting attention in the past days is the possibility of building workflows outside of the VS Workflow Designer.
The most relevant developed examples of this new possibility are:

Mark SchmidtÂ´s WFPad – Viewing/Editing Workflow’s in XML: application in which you can design workflows in a graphic and an xoml way at the same time. Like XAMLPad but for WWF.
Mick BadranÂ´s Extending Workflows to MS Office: allows a user to design a workflow from within Word. Interesting for collaboration matters.

Windows Workflow Foundation (WWF): Brief Concepts.

aschapiro — Fri, 23 Sep 2005 00:35:00 +0000

This Post intends to be a little first look at Windows Workflow Foundation, with general descriptions and comments. WeÂ´ll be adding some WWF Stuff later on.

There is a version in spanish available here.

Definition: WWF is a model which objective is to develop and
to integrate workflows: a network of activities and conditions that describe a complete business process with software and people actions. The term of "workflow" is
important because unlike the one of "orquestation", it doesnÂ´t only talks about
software work coordination, else, it also includes human work coordination.

Architecture: An application that works like Host (Windows
console, Windows forms, etc.) that it uses the "Worflow Runtime
Engine" (WRE) to instanciate one or more workflows. The Host process
provides services to persist the state of workflows, to handle the transactions
and other functions. Each workflow is made up of activities:

Activities:

They are units of execution and reusability which
solves a defined problem. WWF provides a set of basic activities (Base Activity
Library) like ifElse/Code, etc but it gives the developer the chance to create
others like sendMail, createCustomer, etc…

Activities are implemented in classes: they manage
inheritance, and can contain many others activities and of course they are reusable.

Within Base Activity Library, we can found the most relevant
activities:

Code: it executes C # code of customized actions.
EventDriven: it represents a succession of activities whose
execution is initiated by an event.
EventSink: it allows the workflow to receive information of
Data Exchange Service (DES) registered in workflow Runtime.
Invoke Method: it allows workflow to invoke a method in the
interface to send messages to the DES.
Invoke WebService: it allows workflow to invoke a Web-service.
Invoke workflow: it allows workflow to calls or start another workflow within the "Fire & Forget" model.
Select Data: it
allows workflow to make queries through host indirectly.

Workflow Models: we have 2 existing workflow models: "sequential" and "state machine".

The sequential model executes activities with a predefined pattern
while state machine model only knows about the possible states the system may have, what they do, and what external events they respond to (here, the usual is having sequential-workflow logic).

Sequential Workflow example	State Machine Workflow example

Consuming Data and Communications:
There are two ways of consuming data in a workflow: through parameters and events. The parameters are defined manually in the workflow settings and the events that rise from host are attended by the workflow with EventDriven activity. On the other hand workflows can communicate calling Web services and can also be exposed like such being used by other applications, etc.