[AccessD] State machines

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.

-- 
John W. Colby
www.ColbyConsulting.com