Real World Examples of WF and WPF Interaction

Question

I'm looking for some good real-world examples of interaction between Windows Presentation Foundation and Workflow Foundation. Most of the WF tutorials I see demonstrate use within console applications. I'm more curious about applications that use a rich WPF interface and WF. Particularly if they allow user defined workflows (allow users to design and run their own workflows on the fly).

Answer 1

This is a sort of self promotion since the link is mine, but have a look.

Answer 2

The question is pretty vague but here is a possible awnser in this blog post I wrote. Basically I am rehosting the workflow designer to let end users change workflows as needed and let them run them right there and then. Of course you question could mean pretty much anything, like how to call a workflow service from a WPF form.

Answer 3

I'm not sure what exactly you're looking for, but here are some links to information about actual real world applications using Workflow in desktop (WPF) applications in one way or another:

• Sample Real World WF4 Integration
• Infinity Workflow (there's a lot of info in the linked Word file)
• Aderant Enterprise Workflow (also presented at PDC Windows Workflow Foundation Futures session)

Answer 4

Let me take the example of trying to make two workflows communicate with each other.

1. First you need to write a host. This is an extremely loaded proposition, because for two WF hosts to talk to each other, you will then also need to know WCF, and all mushy concepts of threading.
2. Then your WF will need to communicate with other WFs via the hosts. This makes sense because a WF doesn't keep running in memory for 3 months, when it is waiting for another WF to send an event. The WF sits in the database, and the communication occurs through the hosts.
3. Okay, even for simpler scenarios, for local in-process communication, you have the CallExternalMethod activity, and HandleExternalEvent activities. Even in this case, you have to talk via the host, because the WF might have been passivated to the database. So in order to do so, you have to remember to do 3 things, decorate your interface with the ExternalDataExchangeAttribute, eventargs needs to derive from ExternalDataEventArgs, and event args is serializable.
4. If you mess up in any of the items in #3, you get a very non-intuitive "InvalidOperationException". Sure the message says, "Service does not implement an interface with the ExternalDataExchange attribute", but it isn't until you look at the inner exception, that you really know what happened - i.e. you forgot to make it serializable. doh! But I did mark it as serializable. Actually, everything needs to be serializable, even the sender.
5. Then you have to connect the WF activities, via the proper interface names and method names you are using to communicate.
6. Finally, for even in-process WF communication, you have to remember to add your service to the ExternalDataExchangeService, and not the WF runtime. Otherwise, it will look like nobody is subscribing to the event. Not to mention, that this is one of those bug, that doesn't really throw an error. i.e. hard to track down!

So, in short, for the simplistic scenario of trying to make two workflows communicate, you need to have a good handle on the following:

*Writing windows apps (for the host), *Threading, *WCF, *OOP Concepts, *All concepts of serialization, *Plenty of hooking up and non-intuitive details of WF itself, *Ninja debugging skills.

Source:http://blah.winsmarts.com/2008-2-I've_been_here_before.aspx

Answer 5

Here is a sample project I did, which combines WF and WPF to simulate a ATM machine. The code works on some issues like handling the bookmarks, how to keep the workflow alive, and how to manipulate the UI from the workflow.

https://wpfwf.codeplex.com/