OdeToCode IC Logo

Answers to WF Interview Questions

Thursday, November 1, 2007

Due to popular demand, here are some answers to the questions.

Well, not answers exactly ... just some pointers to the get you in the right direction...

1. Are there advantages to building workflows using only XAML? Are there disadvantages?

See Keith Elder's blog on "Leveraging Workflow Foundation", particularly the section on storing workflow definitions in the database.

Also, see Matt Miler's Templates for Windows Workflow XAML activation projects

2. What are the pros and cons of using an ExternalDataExchange service versus going directly to the WorkflowQueuingService?

Sam Gentile: Windows Workflow 102
3. When are attached dependency properties useful in WF programming?

See: Dependency Property Notes
4. What behavior does the default scheduling service provide?

Hosting Windows Workflow
5. How can my code participate in a database transaction with a workflow instance?

Advanced Workflow: Workflows and Transactions
6. Why would I use a tracking service?

Follow the links in Tomas Restporo's WF Tracking Services Explained.

7. Describe a scenario where the WF runtime will cancel an executing activity.

I'd be looking to hear, for example, what happens inside a Listen activity. Also, see Matt W's Implementing the M of N Pattern in WF

8. Describe a scenario where I'd need to spawn a new ActivityExecutionContext.

Matt Milner: ActivityExecutionContext in WF.

9. Tell me why I'd use a compensation handler.

Guy Burstein explains the essence: Compensating and Fault Handling.

10. Tell me about the following activities: Replicator, Parallel, and Policy.

Advanced Workflow: Replicator Tips and Tricks

Kirk Allen Evans: Understanding ParallelActivity in WF

Sahil: Composite Activities in WF.

WF: Rules and Conditions

Dmitry Naumov Thursday, November 8, 2007
Why not to talk about disadvantages of XAML-only workflows?
1. You really can't do anything more complicated then "Hello, world!" workflow. Or you should have very rich activity library. Or you have something like scripting activity (for ex. PowerShell) which allows you to do most of things you want.

2. Having workflow with delayActivity1 and writing declarative condition in, for example, IfElseBranch, you can't refer to delayActivity1 as this.delayActivity1.Timeout > .... which is allowed when you have code separation. You have to write awful things like ((DelayActivity)this.GetActivityByName("delayActivity1")).Timeout which obviously leads to many problems if delayActivity1 is renamed etc.

3. You can't write any simple line of code.
4. Of course no event handlers.
5. No workflow-level properties - how to pass input parameters on workflow creation if I, for example, need to pass timeout value for one of workflow's DelayActivity.

To be continued... :)
Gravatar Russ Blaesing Wednesday, October 28, 2009
I agree with the XAML comment. As time goes on I continue to look for higher level ways of getting work done. Graphical workflow tools are becoming excellent at doing very sophisticated workflows in a fraction of the time as working with Visual Studio (which I continue you to). If interested, check out http://www.spsworkflow.com and a (simple/high-level) video of this different approach at http://www.spsworkflow.com/workflow-development.aspx.

I have yet to encounter a workflow that can't be handled this way.
Comments are closed.