State Machine Workflow: Esoteric Techniques & Patterns Everyone Should Buy presented by Mike Fitzmaurice


Published on

State machines are an approach to workflow design that allows a lot more flexibility, a lot more readability, and a lot less chaos to almost any process model. In a very real sense, almost all workflows would benefit from being redesigned as state machines, but certain use cases fit this design model particularly well. This session will explain what state machines are, why to use them, how to create them in Visual Studio and other products, and how to redesign a number of workflow models as state machines instead.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

State Machine Workflow: Esoteric Techniques & Patterns Everyone Should Buy presented by Mike Fitzmaurice

  1. 1. State Machine Workflows: Esoteric Techniques or Something Everyone Should Be Using?
  2. 2. Setting Expectations • This session is about workflow design – I want to advocate a way of thinking – Plenty of resources exist for coding; this isn’t one of them • If you already understand state machines, and you already like them, this session might not be for you • I will indeed use Nintex Workflow for some demos – I know it well and can illustrate a concept quickly with it – But this is not a session pitching Nintex Workflow – Other products can do state machines, too
  3. 3. Consider A Press Release • • • • Author Management Legal department Publisher
  4. 4. You May Think Like This
  5. 5. Or Perhaps This
  6. 6. What About • Getting professional editorial help? • Other outcomes? – e.g., Legal wants to clarify a point with Management
  7. 7. How About This? Authoring Manager Approval Legal Review Publishin g
  8. 8. How About This? Authoring Manager Review Legal Review Publishin g (re)Submit? Choice Choice Deploy to Public SharePoint Site No End Yes Mgr Rev Request changes Auth Forward to Legal Mgr Apr Request changes Auth Request clarification Approve Pub Mgr Apr End
  9. 9. Or Even This? Authoring Manager Review PR Polishing Legal Review Publishin g (re)Submit? Choice Choice Choice Deploy to Public SharePoint Site No End Yes Mgr Rev Request changes Auth Approve PR Draft Changes Approve Request changes Request clarification Auth Auth Approve Request clarification Leg Pub Mgr Apr PR End
  10. 10. State Machines • States • Events • Transitions State Switched On Event Transition Button Click Transition Button Event Click Switched Off State
  11. 11. • State Machines vs. Sequential Workflow Sequential Workflow – – – – – • Predictable Wait, then march forward Workflow is in control of the process Most decisions happen within the workflow Workflow’s job is to direct State machine workflow – – – – – Event driven No concept of “waiting”; workflow is in one state until it isn’t Actions are in control of the process Most decisions happen outside of the workflow Workflow’s job is to govern
  12. 12. Bug Tracking Example How you think it works • Tester opens bug • Developer fixes bug • Tester approves fix
  13. 13. Bug Tracking Example What really happens • A tester opens a bug, and assigns it to Bill. • Bill says, “no not me, this is Clive’s”, and reassigns the bug to him. • Or Bill says, “this tester is not in this case quite correct” (or words to that effect), and rejects the bug as nonsense. • Or Bill asks the tester for clarifying information. • Or even, if he’s in a good mood, Bill fixes it and hands it back to the tester. – Or, if the original tester is out, another tester. • Or the tester withdraws an erroneous bug (surely not) • And so on.
  14. 14. Bug Tracking Example: Sequential Tester T creates instance of bug workflow T adds bug details T assigns to developer D LabelB: Switch D assigns to developer E: Goto LabelB D rejects bug to T: Switch T accepts rejection: Exit T updates bug and assigns to developer F: Goto LabelB End Switch D requests info from T: T submits info Goto LabelB D submits solution to T: GoTo LabelB T withdraws bug: Exit End Switch
  15. 15. Bug Tracking Example: State Machine • • • • • • State: Initial – Action: T adds bug details – Action: T assigns to developer D; new state = Fixing State: Fixing – Action: D assigns to developer E – Action: D rejects bug to T; new state = Rejected – Action: D requests info; new state = Pending Info – Action: D submits solution; new state = Pending Approval – Action: T withdraws bug; new state = Closed State: Rejected – Action: T accepts rejection; new state = Closed – Action: T updates bug and assigns to developer F; new state = Fixing State: Pending Info – Action: T submits info; new state = Fixing State: Pending Approval – Action: T rejects solution; new state = Fixing – Action: T accepts solution; new state = Closed State: Closed
  16. 16. Even “Obvious” Sequential Processes Can Be Secret State Machines • Expense approval – Usually, if any problem, reject and restart • No way to track how long it takes to get an eventual outcome – Model back-and-forth into the workflow • Escalation • Return for clarification • Leave approval – Allows negotiation to be factored in to the process
  17. 17. When Do You Use a State Machine? • When you need – Flexibility • You can add new states with minimal impact • You can modify steps within a state without fear of wide impact – Visibility • The more complex, the harder sequential workflows are to read • Harder to visualize graphically, but very easy to read a log – Control • Counterintuitive • You can easily define how to skip steps • You can more easily manually induce a revert-to-state, skip-to-state • Actually, almost always
  18. 18. Why State Machines are Useful • We want workflows to follow a predictable path – We find that real-world demands get in the way • Without state machines, you’ll wind up with: – – – – A lot of If-Then-Else conditions A lot of looping Lots and lots of arrows to the point of “Spaghetti” Graphical “goto” statements • Most workflows actually wait for people to do something – That’s a “decision outside of the workflow” scenario • The current state is useful for status reporting
  19. 19. Sequential Activity Inside a State • Inside of a state, sequential actions take place – – – – – Evaluate conditions Transform data Process transitions Branch based on conditions Assign tasks • Technically, some of these a mini-state changes • You can nest state machines inside of states
  20. 20. Sequential Flow Using State Machines • Define the rules correctly • State machine workflow will follow a predictable path • Until you need it not to 
  21. 21. Can Users Understand This? • Don’t call it a “state machine” • Call them “stages” instead of “states” • Call it “moving back and forth” rather than “transitions” • Users love being able to handle exceptions • Users love being able to change rules
  22. 22. Using State Machines for Exception Handling • Add “Error Encountered” state • Have workflow actions change state upon exception • Have “Error Encountered” state: – Undo earlier work – Create compensating actions if necessary – Report error to process owner
  23. 23. Using State Machines to Restart a Workflow Where It Last Left Off • Add a field to a list item; leave it out of most views – “Internal Workflow State” • Workflow begins in “Evaulate Initial State” state – Checks InternalWorkflowState variable – Transitions to correct state accordingly
  24. 24. Can You Loop? You Can Simulate a State Machine • You will need: – Variable – Loop – Switch • Steps: – Set variable to initial state immediately before loop – Put a switch inside a loop • Switch evaluates variable and branches accordingly – When you need to change state, change the value of that variable and wait for looping to occur – Make sure at least one of the states causes the loop to end
  25. 25. You Can Even Do This In SharePoint Designer (Sort of) • Warning – this is for entertainment purposes only • One field to store current state • One startup workflow, plus one workflow for each state – Last step of each workflow sets a field value – All state workflows started by modification to item (except for the workflow that caused the change to take place, of course) – Each workflow first checks state field, exits if not target state • This isn’t practical, though – It effectively starts all state workflows (other than the current one) with every change – Plays havoc with the audit trail
  26. 26. Windows Workflow Foundation 4.0 • Microsoft removed state machines from WF 4.0 • Introduced a Flowchart workflow type instead – Still consisted of states – Graphical paths between states – Worked for many use cases • Backlash ensued! • Microsoft later introduced a State Machine activity – Posted to CodePlex –
  27. 27. Conclusion • State machines sound esoteric – they’re not • State machines have genuine practical benefits • This is a way of designing, not coding – State machines can behave sequentially if need be – Sequential workflows can behave like state machines if need be • Many products can do this • A lot of content exists to help
  28. 28. Questions & Discussion
  29. 29. References • • • • • • •