Quelqu'un peut-il donner un bon tutoriel sur le WWF? [fermé]

Question

En particulier, je suis intéressé par: 1) Créer une configuration d’environnement libre pour créer des workflows. 2) Comment utiliser les éléments / états de workflow existants et ce qui en découle.

Merci!

Answer 1

Recherchez-vous un laboratoire virtuel comme celui-ci à partir de MSDN ?

Pour certains tutoriels, essayez de télécharger Travaux pratiques pour Windows Workflow Foundation

Answer 2

The other answers are good, but I think it's important for people to understand why use workflow at all. Many people use WF when there is no need for it, and still others refuse to use when their use case is the most ideal for WF usage.

The best explanation I've ever read on when and whether to use WF is Dave Green's blog post. He was the architect of the first version of Windows Workflow Foundation.

I will paste it here for posterity:

---

What is Workflow, and why bother?

Workflow, of course, is one of those deeply overloaded terms that hinders communication as often as it helps, so I’d better say what I mean by it.

Workflow comes down to just two ideas: that there is work to do, which a workflow sees as opaque units of behavior; and flow, which describes what work gets done when.

So is this a Workflow?

public void HandleLoanRequest (string customerID, Application app)
{
    if (CheckCredit(customerId, app.Amount))
    {
        MakeOffer (customerId, app);
    }
}

Yes, I believe it is. The work is checking the customer’s credit and making an offer – and HandleLoanRequest defines if and when this work is performed.

But the fact that workflow vendors have traditionally felt that something more than this sort of code is required before they declare victory suggests that we’re still missing a key notion.

This, I believe, is that we don’t just need to describe the flow, but describe it in a way that we can inspect, reason over, and manipulate. In short, workflow needs a model.

C# is one way to do this - we can define coding standards that allow us to scan workflow code and draw a graph of the flow, for instance. Or we could define attributes for the developer to use to call out the parts of his code that form the model. This is not the choice that we made for the Windows Workflow Foundation – and I’ll talk about why we chose what we did in later posts – but it would work.

But back to why we might need a model. We’re going to have to put in effort to create it, so why bother? Where’s the payback? (or the beef, as this Englishman abroad is learning to call it).

Well, I think the payback comes from what the model enables -

Visualization Useful for the developer, during both development and maintenance, but also for the workflow user who wants to know why they are supposed to be doing what they’ve been asked to do, or the IT Ops guy who wants to know what some misbehaving app is, or should be, up to.

Expressiveness A workflow model is a Domain Specific Language, specialized to support characteristic problems. An example is a review process where three positive votes out of five reviews mean that the document is good – and any outstanding reviews can be canceled. This is a little tedious to code, but the Windows Workflow Foundation includes out-of-the-box constructions that address such problems.

Execution The runtime can exploit the model to take away the need to solve the same problems over and over again. In the Windows Workflow Foundation we built in support for the knotty problems of long running workflow such as state management and compensation – controlled by simple, expressive model elements.

Monitoring The existence of a model makes it possible to produce an event stream with a meaningful semantic without any additional developer effort. This can then be used to monitor instances of workflows, or aggregates. Windows Workflow Foundation allows also allows declarative decoration of events with application data pulled from the workflow state - so that you can tell that credit check has started for order 14532.

Transformation Models beget models. An example is the transformation of a workflow model into the Message Exchange Pattern required to communicate with it – as Dharma and Don demonstrated so beautifully at the PDC. Another is customization. An ISV ships a workflow, which is customized by a VAR, and then again by a customer. Then the ISV ships a new base version. The use of a shared, well understood model for the workflow makes the consequent 3-way merges much more tractable.

Composition If an application is factored into flow and work, then the atomic elements of work, with their well understood interfaces, can be reused by other workflows. Workflows themselves are valid definitions of work that can also be used by other workflows.

Customization and transformation together enable ecosystems where definitions of work and flow become shared or traded artifacts.

Manipulation Often there are requirements to invent or modify workflows on the fly. If this means changing code, then there are going to be problems with the security folks – even if the users understand how to hack it. Using a model makes possible dynamic manipulation that is both controllable and comprehensible. The Windows Workflow Foundation supports the dynamic modification of both workflow types and workflow instances.

So that’s it (or at least, all that seeps into my mind this Saturday afternoon). That’s why we thought a model was a good idea, and why we think it has great ROI. But if none of these benefits apply in your scenario, then really, coding is still very cool.