The scenario server executes scenarios as follows. Note first of all that scenarios are event driven. Once an event occurs, users can quickly proceed through all the consecutive conditions and actions until they either encounter another event, or exit the scenario. Thus, the scenario server itself is event driven; events in the ATG system are JMS messages, and the scenario server acts as a MessageSink. You can configure it (through Patch Bay) to listen to various events (by default, it receives all the standard ATG events). As each event arrives, the scenario server determines, for each scenario, which user or users are affected, and advances those individuals through the scenario until the next wait is encountered. It then waits for the next event to arrive, and so on.

In order to keep track of where in the scenario the users are, the scenario server must maintain some state for every individual going through the scenario—most notably, it must maintain the individual’s location in the scenario. (Another piece of state is a user-specific map of scenario variables, which can be set via the “Set variable” scenario action; for more information, refer to the ATG Personalization Guide for Business Users.)

Maintaining the per-user scenario state is complicated by forking. The example above shows that, because of forking, a user can be in two different places in the scenario at once, waiting for two different events to occur. A much more complicated scenario might have many forks, and forks inside forks, so that keeping track of all the states associated with just a single user could become quite problematic. To simplify the matter, the scenario server does not actually attempt to execute scenarios the way they are defined. Instead, it transforms each scenario into an equivalent scenario state machine (SSM). This behavior requires an additional processing step when the scenario is first created and started, but it provides some important advantages.

The main virtue of the scenario state machine is that a given individual is always in exactly one SSM state, and progresses through a strictly linear sequence of states with no forking. In addition, the state machine is constructed in a way that provides various useful guarantees concerning its structure.

The state machine for our promotion example can be described as follows. An SSM has two kinds of states: waiting (shown in yellow) and intermediate (green). Waiting states are where the scenario execution must stop in order to wait for the next event (or several events, as is the case with state 4 below).

Intermediate states are used to channel users to different paths through the state machine. For instance, users who arrive at state 2 in the example proceed to either state 3 or state 8, depending on whether they are young or old and female (old males don’t proceed beyond state 2, since there is no transition for them to take). Note that the conditions (or filters) leading out of the intermediate state are always mutually exclusive; thus, any individual user follows a single linear path through the SSM. Scenario actions take place as part of the SSM transitions; for example, a user is given a bike promotion as part of the transition from state 4 to state 5, and so on.