State Machine Workflow: Esoteric Techniques & Patterns Everyone Should Buy presented by Mike Fitzmaurice
0 likes•4,265 views
This session discusses the design and implementation of state machine workflows, emphasizing their practical benefits over traditional sequential workflows. It illustrates the flexibility, visibility, and control that state machines offer, making them suitable for complex processes like bug tracking and expense approvals. The presentation highlights how users can better understand state machines by using familiar terminology and concepts to facilitate exception handling and workflow management.
State Machine Workflow: Esoteric Techniques & Patterns Everyone Should Buy presented by Mike Fitzmaurice
- 1. State Machine Workflows: Esoteric Techniques or Something Everyone Should Be Using?
- 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. Consider A Press Release • • • • Author Management Legal department Publisher
- 4. You May Think Like This
- 6. What About • Getting professional editorial help? • Other outcomes? – e.g., Legal wants to clarify a point with Management
- 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. 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. State Machines • States • Events • Transitions State Switched On Event Transition Button Click Transition Button Event Click Switched Off State
- 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. Bug Tracking Example How you think it works • Tester opens bug • Developer fixes bug • Tester approves fix
- 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. 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. 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. 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. 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. 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. 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. Sequential Flow Using State Machines • Define the rules correctly • State machine workflow will follow a predictable path • Until you need it not to
- 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. 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. 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. 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. 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. 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 – http://wf.codeplex.com/releases/view/43586
- 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