Enterprise library och workflows

Jag har testat att kombinera Enterprise Library 4.0 med workflows och det är naturligtvis inga större konstigheter till att börja med.

Då jag själv gillar AOP och ville använda policy injection blocket i enterprise library blev jag tvungen att låta mina affärsentiteter ärva från MarshalByRefObject (vet att det går att köra med ett interface också men det hör inte hit) samt skapa/wrappa dem genom PolicyInjection blocket för att få tillbaka den transparent proxy som motsvarar mitt objekt.

[ValidationCallHandler] public void Deposit([RangeValidator(typeof(Decimal), "0.0", RangeBoundaryType.Exclusive, "0.0", RangeBoundaryType.Ignore)] decimal depositAmount) { balance += depositAmount; }

Mitt typiska flöde/aktivitet har ofta en eller flera affärsentiteter kopplade till sig och dessa skall naturligtvis vara serialiseringsbara för att kunna persisteras (genom exempelvis SqlWorkflowPersistenceService )

Nu uppstår problemet.. tyvärr inte med alla objekt utan bara vissa och problemet verkar bero på att serialiseringen smäller vilket i sin tur innebär att flödet är helt trasigt. Hela problemet verkar ha med den transparent proxy som skapas vilket gör att problemets fokus ligger rakt i kärnan på hur funktionen är designad.

Lärdom, använd inte Policy injection för de entiteter som skall serialiseras med ditt workflow.

Resultatet blev att Enterprise Library åkte ut och PostSharp åkte in (utan några problem hittils och inga krav på att ärva från en viss klass eller köra någon wrappning)

.NET 4.0 / OSLO

Som ni säkert sätt börjar det läcka ut nyheter kring .NET 4.0 / OSLO i lagom tid inför PDC.

Ett problem som finns med dagens WF/WCF-lösningar är att den svarande parten (WCF) i princip måste få veta vilken nästa aktivitet i flödet är (vilket motverkar ett av syftena med workflows)

Citat från Matt W's blogg

The first time I did this I spent days working on it saying to myself "surely you don't have to do this... surely you don't have to tell the target service which *activity* you want it to talk to next". But you do. It makes me sad inside.

matt: Our general goal is not to introduce more misery into the world. At this point in time, doing duplex requires the explicit management of the context token. We're working to make it better, so hopefully around PDC time, you will no longer be sad inside

Här är en dragning som jag garanterat skall gå på
http://channel9.msdn.com/pdc2008/TL06

Ska bli kul att se vad mer som finns i .NET 4.0, 3.5 var smaskens men trots allt inte en major version på samma sätt som 3.0 var =)

Long running processes

Att hantera krav på skalbarhet, felhantering, undantagshantering för processer som kan ta lång tid på sig kan vara en utmaning. Ett exempel kan vara en import eller export av data som kan ta allt från minuter till dagar beroende på storlek, nätverk, lagring.

Tänk en flytt av allt innehåll i exempelvis sharepoint där vi har webbar med underwebbar, listor, documentbibliotek och så vidare.

Hur löser vi denna typ av problem på ett effektivt sätt där vi kan korrigera eventuella problem utan att starta om processen från början? Helst med ett automatiskt retry-beteende om exempelvis nätet skulle få hicka.

Svaret är naturligtvis workflow foundation =)

Ofta när vi pratar om workflow foundation så handlar det om processer där människor är inblandade men som tur är så finns det andra användningsområden också.

Med hjälp av persistence kan vi spara ned vårt nuvarande state efter varje operation (ex flytt av ett dokument), vi får även på köpet ett bra verktyg för skalbarhet eftersom vi kan skala ut över flera maskiner utan att skriva någon extra kod för ändamålet (sql-persistence sköter detta åt oss)

Nästa sak på listan är naturligtvis att skapa lite egna aktiviteter, exempelvis en för att hantera en site, en för ett document library och så vidare. I site-aktiviteten lägger vi sedan en repeater som hanterar undersiter, en repeater som hanterar alla listor osv. Dvs vi skapar med väldigt lite kod ett inituitivt flöde med kod som är enkel att underhålla.

Den sista aktiviteten vi bör kika på är naturligtvis en egen retryaktivitet som klarar av att ha en childaktivitet och har ett retry-beteende. Om vi sedan genomgående stoppar våra site, documentlibraryaktiviteter etc. i vår retryaktivitet så slipper vi begåva varje enskild aktivitet med detta. Vi kryddar naturligtvis med loggning och konfigurering.

Workflow foundation är en cool kamrat för oss utvecklare / arkitekter :-)

Match with the Target Type

Råkade ut för en skön grejj i VS 2008's designer för workflow, jag var mitt uppe i lite rejäl refactoring och helt plötsligt kunde jag inte binda en dependency property...

Path resolved to Referenced activity Property 'MyProperty' whose PropertyType 'MyNamespace.MyCustomType' does not match with the Target Type 'MyNamespace.MyCustomType'

Frustrationen växte och jag började fundera över allt möjligt
* Kan det bero på att jag gömt konstruktorn för typen?
* Kan det bero på enterprise library's policy injection?
* Kan det vara min factory som ställer till det?

Vad var då lösningen? Stäng ned visual studion, hämta en kaffe och starta om studion igen. Tydligen är detta ett resultat av någon caching i VS2008 (mer prestanda men tydligen en del buggar kvar..)

Då jag inte tänkte på omstarten direkt tyder det trots allt på att denna typ av problem börjar bli mer sällsynta, måste tänka positivt =)

Tillbaka!!

Nu är föräldraledigheten slut för denna gång och jag har sedan i måndags börjat på ett nytt uppdrag. Att fördriva två månader med min son var ett grymt beslut och vi har byggt grunden till en underbar relation =)

Hur som helst har jag turen att arbeta med ett projekt som involverar workflow foundation. Anledningen till att jag valt den tekniken i projektet skall jag försöka förklara i ett inlägg framöver.
Detta innebär naturligtvis även att några av mina trevliga kollegor kommer att få knacka WF-kod i mängder närmaste tiden och det skall bli kul (för mig i alla fall, hoppas att de tycker det också)

I höst skall jag hålla två WF-utbildningar på addskills och jag hoppas att intresset är större än förra gången (den kursen blev tyvärr inställd)

Har precis läst M.Deurell's blogg och inser att han verkar rätt hooked på powershell (inte så konstigt då det r0xxar), det kanske är ett bra verktyg för att hålla koll på WF också.. vem vet