Windows Workflow Foundation – Introductie

In deze blog willen we één van de onderbelichte onderdelen van het .NET Framework eens in de kijker zetten: Windows Workflow Foundation.

Windows Workflow Foundation gaat schuil achter producten zoals BizTalk, SharePoint en MSBuild. In .NET is Workflow sinds versie 4.0 ondergebracht in de System.Activities namespace en kan het met behulp van Visual Studio getekend, ontwikkeld en gehost worden.

Workflow

 

Werken met Windows Workflow Foundation, kortweg Workflow, omvat volgende disciplines

  • Een workflow uittekenen door gebruik te maken van:
    • Activiteiten
    • Flowchart
    • Statemachine
  • Taken uitvoeren wanneer bepaalde stappen in de workflow bereikt worden
    • Standaard Workflow activiteiten
    • Eigen activiteiten geprogrammeerd in C# of VB.NET
    • De workflow met bookmarks pauzeren om extra input te ontvangen
  • Workflow instanties hosten in de Workflow runtime
    • Standaard transient Workflow hosting
    • Standaard persistent WCF Workflow hosting
    • Eigen hosting bouwen met een .NET programmeertaal om zo alle (geavanceerde) mogelijkheden te kunnen benutten

Het mag duidelijk zijn dat Workflow op diverse manieren kan ingezet worden. Dit blijkt ook uit het feit dat Workflow zowel bruikbaar is voor MSBuild, wat eigenlijk een vluchtig (transient) scenario is, alsook voor SharePoint hetgeen een duurzaam (persistent) scenario is. Ook mengvormen zijn mogelijk met zowel transient als persistent scenario’s zoals in BizTalk. Talloze mogelijkheden voor toepassing dus.

Voor het inzetten van Workflow in een transient scenario, zoals MSBuild, waarbij de workflow een middel is om het software build proces aan de lokale noden aan te passen. In dergelijk scenario zijn alle inputs van de workflow bij aanvang gekend, in dit geval namelijk de broncode en de build configuratie. Ideaal dus voor een transient scenario. Want als er tijdens de uitvoering nog op extra input moet gewacht worden, terwijl de workflow slechts kortstondig in het werkgeheugen bestaat, is er kans dat de workflow niet hervat wordt voor het verwerken van deze extra input, omdat de workflow mogelijk al uit het werkgeheugen verdwenen is.

Een persistent scenario daarentegen is wel geschikt wanneer er op extra input moet gewacht worden, zoals bij SharePoint, waarbij een document verschillende stadia kan doorlopen alvorens deze publiek beschikbaar is. Denk bijvoorbeeld aan een approval flow van een document. Hierbij moet telkens gewacht worden op extra inputs zoals een goedkeuring van verschillende verantwoordelijken voor het publiceren van dat document.

Omdat het scenario een grote impact heeft op de wijze waarop Workflow moet gebruikt worden, is het belangrijk dat je bij aanvang een juiste keuze maakt. Ook al omdat niet alle mogelijke opties verenigbaar zijn met het scenario dat je kiest. Bij een persistent scenario kan je duidelijk niet voor transient hosting kiezen en vice-versa. De beschikbare opties worden ook beperkt als je kiest voor een van de standaard hosting opties, omdat die een vast stramien opleggen. Om zoveel mogelijk opties open te houden, ben je aangewezen op maatwerk hosting voor de workflow engine. Daarmee kan je alle implementeerbare scenario’s ondersteunen.

Wanneer het scenario en de hosting keuzes bepaald zijn, kan je beginnen met het opzetten en/of programmeren van de hosting van de workflow. Bij het zelf implementeren van de hosting moet je wel opletten dat de componenten hiervoor multi-threaded zijn. Dit heeft namelijk enkele implicaties:

  • Bij het starten van een workflow of bij het resumen van een bookmark, moet je wachten op bepaalde host events die op een andere thread worden uitgevoerd, alvorens je de workflow verder kan aansturen. Hiervoor kan je gebruik maken van een WaitHandle zoals de ManualResetEventSlim
  • Bij het implementeren van bepaalde hosting features – zoals persistentie – zal je dus met Begin*/End* methode paren moeten werken, die een IAsyncState delen.

Nadat de hosting is opgezet worden de eventuele eigen activiteiten aangemaakt

  • Baseer die op CodeActivity als deze enkel expliciete input uit en output naar de workflow heeft
  • Baseer die op NativeActivity voor alle overige zaken
    • Gebruik van de workflow context
    • Instellen van bookmarks voor het pauseren van de workflow

Tot slot wordt de workflow getekend volgens een zelf te kiezen stijl.

Een voorbeeld van de Control Flow stijl:

Control Flow

 

Een voorbeeld van de Flow Chart stijl:

Flow Chart

 

Een voorbeeld van de State Machine stijl:

State Machine

 

We hopen dat deze blog jou alvast iets meer bijbracht over dit vaak onderbelichte onderdeel van het .NET Framework en een aanzet is om de mogelijkheden en werking van Windows Workflow Foundation beter te begrijpen en toe te passen.