Tracking i WF4.0

I tidigare versioner av WF har vi fått med SqlTrackingService som på ett enkelt sätt ger oss möjligheten att skriva ned den data vi behöver för att spåra våra workflows till en sql-databas.

I WF4.0 är det ETW som gäller, dvs Event Tracing for Windows som funnits som en standardkomponent i windows i några generationer nu.

Vad innebär detta för oss? Antagligen kommer några att själv skapa en SQL tracker eller också anser alla att ETW är nog så bra. Hur som helst stöder arkitekturen i WF4.0 att vi skapar egna tracking participants som ni kan se på bilden nedan.



Vad är det då som sparas i vår tracking participant?
Workflow instance tracking records: Här sparas de stora händelserna, dvs start stop och fel.

· Activity tracking records: Här sparas de enskilda aktiviteternas händelser, dvs om de är schemalagda eller har något fel.

· Bookmark resumption tracking record: I WF4.0 finns begreppet bookmarks som vi pratat en del om tidigare, här sparas dessa

· User tracking records: Här sparas egen data, dvs upp till dig och mig :-)

Källa: The .NET endpoint

TheWorkflowWay - Grymt dokument av David Chappell

Här finns ett bra och beskrivande dokument som tar upp varför WF är en bra teknik och hur vi kan utnyttja den i våra lösningar. Informationen är krispig och tar även upp dublin samt WF4.0

Jag har själv använt WF som applikationsmotor i ett projekt där vi gjorde en stor migrering från en plattform till en annan. I det fallet styrde WF hela migreringen och vi kunde nyttja alla de fördelar som detta dokument tar upp.

WF 4 Migration Guidance

Nu har några riktigt intressanta white papers sett dagens ljus, dessa är:

WF Migration Best Practices.docx
WF Migration Overview.docx
WF4 Rules Guidance.docx
WF4 State Machine Guidance.doc

Samtliga kan laddas hem här

Vi kan mycket riktigt lägga märke till att codeactivitys fortfarande är en big no-no och att vi får byta ut state machine mot flowcharts.

Förutom detta kan vi även se att våra gamla flöden kommer att fungera i .NET4.0 då hela runtimen finns kvar och allt det nya finns i nya namespaces. Detta innebär alltså att befintliga projekt kan välja .NET4.0 utan att vara nervös för om WF skall lira eller inte.

The .NET 4 release of WF has, from the beginning, had two fundamental high level objectives:
1. Maintain full application compatibility: all WF solutions built on .NET 3.0 and 3.5 must run, without requiring redesign or source artifact migration, on .NET 4.

2. Address customer feedback and enhance the capabilities of WF, particularly around: customer adoption blockers; key missing features and usability issues; utilization of complementary .NET technologies.
The first objective cannot be compromised, as it resides squarely within the overall application compatibility goals of the .NET Framework.
Given this, the team could address goal #2 either by continuing to make incremental (non-breaking) changes on top of the WF3 technology, or by developing new workflow technology.
After analysis of pros and cons, the team chose the latter approach.

Värt att notera är att dessa dokument inte är färdiga utan kommer att förändras så detta är en sida som är värd att bevaka.