[AccessD] State machines

Thanks for that link Gustav.  I am reading it now.

John W. Colby
www.ColbyConsulting.com


Gustav Brock wrote:
> Hi John
> 
> With that enthusiasm of yours, WWF - Windows Workflow Foundation, must represent nothing less than a Christmas present for you:
> 
>   http://msdn.microsoft.com/en-us/magazine/cc163281.aspx 
> 
> I'm still looking for a good project to put it into action ...
> 
> /gustav
> 
> 
>>>> jwcolby at colbyconsulting.com 10-06-2008 20:42 >>>
> How many of you know what a state machine is?
> 
> http://en.wikipedia.org/wiki/Finite_state_machine 
> 
> More generically a state machine is a structure (hardware or 
> software) that stores the current "state" of something and 
> uses stimuli to cause changes from the current state to some 
> other state.  State machines prevent and allow state changes 
> from a specific state to another specific state.
> 
> IOW from this state you can only move to "these other 
> states" and which state you actually move to will be 
> determined by something that occurred.
> 
> I wrote a state machine for my disability call center software.
> 
> During the processing of claims, EVENTS happen.  Events can 
> be (pretty much) anything that the client wants to call an 
> EVENT, IOW it has to be programmable by the client.  Some 
> actual EVENTS from the event table:
> 
> New Claim Notice
> Approve
> Pend
> Terminate
> Deny
> Re-Open
> Suspend
> Delete This Event
> Receive
> Appeal
> Uphold Denial
> Uphold Termination
> Transfer In
> Transfer Out
> Not Received
> 
> There are MANY MANY more.
> 
> Events MAY or may not cause STATUSES.  Some actual statuses 
> from the STATUS table:
> 
> CS_Status
> None
> First Notice
> Open
> Pending
> Terminated
> Denied
> Re-Opened
> Suspended
> Received
> Appeal
> Upheld Denial
> Upheld Termination
> Transfer In
> Transferred Out
> Determined at IDE
> Archived
> Not Received
> 
> Now, obviously EVENTS and STATUSES are NOT the same thing. 
> Events MAY CAUSE a status change, however there are RULES 
> about what STATUS can be "moved to" from the current status. 
>   For example you cannot go to the CLOSED status unless the 
> claim is OPEN.  You cannot RE-OPEN a claim that is ALREADY 
> in the OPEN state.  APPEAL can move to UPHELD DENIAL, UPHELD 
> TERMINATION or OPEN, and so forth.
> 
> So you have to have a transition table that maps the current 
> status to "POSSIBLE" status, IOW "where can you go from 
> here".  You also have a stimulus table that maps "this event 
> can cause this status (or causes NO status change)".  An 
> OPEN event causes an OPEN status, but a "DOCUMENT RECEIVED" 
> or a "LETTER SENT" event does not cause a status change.
> 
> And finally you have a table that says "this event can 
> happen when in this state".
> 
> Then of course you have a class system that enforces the 
> rules.  It loads all of the tables into class instances 
> which are then stored in collections.
> 
> The tables are "the rules" for the state machine and are 
> fully programmable by the client.  The user is presented a 
> list of "possible events" in a combo box.  Basically the 
> current status is discovered and used to filter the list of 
> events to those that can occur in that state.  The user can 
> therefore only select an event if the system says that it 
> can occur while in the current state.
> 
> State machines are wonderful devices for mapping business 
> rules where "this process can only happen in these cases".
> 
> In my case, there is a table of events that have occurred in 
> the claim.  These events display the entire history of the 
> claim and are the focal point of the claim processing.  The 
> events channel the user, allowing them to do what makes 
> sense given where we are in the processing sequence, and 
> preventing doing things that make no sense given the current 
> state of the claim process.
> 
> The user can examine the event table and see what events 
> have transpired, the sequence of events, the dates, memos 
> about those events etc.  We even create events from outside 
> processes such as the mail merge process creates an event 
> "letter sent" with the name of the letter, who it was sent 
> to etc.
> 
> State machines, check them out.  They might just solve that 
> thorny process control problem that you are facing.
>