View
102
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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.
Citation preview
State Machine Workflows: Esoteric Techniques or Something Everyone Should Be
Using?
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
Consider A Press Release • Author • Management • Legal department • Publisher
You May Think Like This
Or Perhaps This
What About • Getting professional editorial help? • Other outcomes?
– e.g., Legal wants to clarify a point with Management
How About This?
Authoring Manager Approval
Legal Review
Publishing
How About This?
Authoring Manager Review
Legal Review
Publishing
(re)Submit?
Mgr Rev
YesNo
Choice
Mgr Apr
Forwardto Legal
Auth
Requestchanges
Choice
Mgr Apr
Requestclarification
Auth
Requestchanges
Pub
Approve
Deploy to Public SharePoint Site
EndEnd
Or Even This?
Authoring Manager Review
Legal Review
Publishing
(re)Submit?
Mgr Rev
YesNo
Choice
PR
Approve
Auth
Requestchanges
Choice
Mgr Apr
Requestclarification
Auth
Requestchanges
Pub
Approve
Deploy to Public SharePoint Site
EndEnd
PR Polishing
Choice
Leg
Approve
Auth
Draft Changes
PR
Requestclarification
State Machines • States • Events • Transitions
Switched On
Switched Off
Button Click
State
State
Event
Transition
Transition
Event Button Click
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
Bug Tracking Example How you think it works
• Tester opens bug • Developer fixes bug • Tester approves fix
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.
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
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
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
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
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
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
Sequential Flow Using State Machines
• Define the rules correctly • State machine workflow will follow a
predictable path • Until you need it not to
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
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
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
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
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
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
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
Questions & Discussion
References • http://msdn.microsoft.com/en-us/library/gg508985.aspx • http://msdn.microsoft.com/en-us/library/dd692929.aspx • http://odetocode.com/code/460.aspx • http://srisharepointdevelopment.blogspot.com/2010/06/state-machine-vs-
sequential-workflow.html • http://vtonms.blogspot.com/2010/01/nintex-workflow-smart-restart-workflow.html • http://blogs.msdn.com/b/davegreen/archive/2005/10/20/483309.aspx • http://blogs.msdn.com/b/pravin_indurkar/archive/2005/09/25/473826.aspx