The BRIM™ State Transition Engine (STE) Syntax

A process flow consists of the identification and representation of the processing steps associated with a business event. The business events themselves are represented as classes in the UML model.

The process flows associated with business events are described using a State Transition Engine approach similar in structure to a UML activity diagram. These diagrams are not unlike the old data flow diagrams or even older flowcharts. The process flows use different types of flow elements:

A. States: States represent a particular point in the process flow where an action might occur. Modifying a state implies that the process flow is modified.

B. State Events: Each state may have a number of sub-events associated with it that can trigger various activities

C. Transitions: These transitions represent how a business event changes its state

D. Tasks: Tasks represent traditional program logic, which may be associated with various state events or with the transitions themselves.

BRIM™ states are richer than traditional STE states or flowchart boxes. One BRIM™ state may replace up to 50 states in a traditional design environment.

Traditional OO modelers might be tempted to represent business events as methods for other classes. For example, the “Hire Employee” event could be a method on the Employee class. However, experience has shown that the “Hire Employee” event is itself an item of interest to the organization with its own attributes and associations to other classes. Therefore, “Hire Employee” is best represented as its own class rather than a method on the Employee class.

1. States

States can be divided into two groups: manual and automatic. With manual states, the business event stays in the state after the associated process is performed. It is possible for a business event to remain in a manual state for an indefinite period of time (minutes, hours, days, permanently) until some action occurs to move the event to another state. Events may end up in a termination state indefinitely.

With automatic states, business events only reside in those states long enough for the tasks (code) to be executed before moving to the next state. Automatic states are inherently transient.

There are eight (8) specific types of states that are either structurally or semantically different from one another:

Manual States: Begin, End, Inbox, Wizard, Suspend, Error

Automatic States: Automatic, Auto Begin

1.1 Begin

A Begin state is the usual initial state for a business event. Every time a new business event is created, it is always created in an initial state. Each business event has one and only one Begin or Auto Begin state. If an event subsequently reaches a Begin state (by transitioning from another state), it will automatically close.

The Begin state is where the initial data entry for the event occurs. Depending upon a specific condition, or if significant pre-processing is required for an event, an Auto Begin state may be used (See Auto Begin section).

The Begin state is represented in the process flow diagram as shown below:

1.2. End

An End state is a final resting place or termination point for a business event. A flow for a business event may have any number of end states. When a business event reaches the End state, it will never subsequently change states unless directly forced to by an abnormal system event.

Events close when they reach an end state.

The End state is represented in the process flow diagram as shown below:

1.3. Inbox

The Inbox state is the primary manual state. When a business event lands in an Inbox state, it waits for some manual intervention. A business event may have any number of inbox states. When an event reaches an Inbox state, it automatically closes.

Security measures control who is allowed to open a business event in an Inbox state.

The Inbox state is represented in the process flow diagram as shown below:

1.4. Wizard

A Wizard state is similar to an Inbox state insofar as the business event halts and awaits additional user input. This additional input releases the event for further processing. When an event reaches a Wizard state, it remains open.

Wizard states differ from Inbox states in that a Wizard state is encountered in the context of a single processing session. Therefore, there is no security associated with a Wizard state.

Typically, in the user interface, a business event will land in an Inbox state and wait for a user to open it. While the user is processing the business event, it may pass through several Wizard states before ending up in another Inbox or End state.

A business event may have any number of Wizard states associated with it.

The Wizard State is represented in the process flow diagram as shown below:

1.5. Suspend

A Suspend state is used when the business event waits for something other than a user intervention to occur. The event will either expire or a listener event (not implemented in this version) will trigger it. When an event reaches a Suspend state, it will automatically close.

A suspend state is functionally equivalent to an inbox state.

The Suspend State is represented in the process flow diagram as shown below:

1.6. Error State

Error states occur when there is an abnormal problem in the process flow or the users are unable to determine the appropriate action and perform a Bail operation during a processing session. Under normal circumstances, no business event should ever be in an Error state. When an event reaches an Error state, it will automatically close.

Error states should only be used for two situations:

· Abnormal process flow problem

· User is unable to make the program perform as expected and chooses to abort the business event.

An error state is functionally equivalent to an inbox state.

The Error state is represented in the process flow diagram as shown below:

1.7. Automatic

Automatic states are used to perform automated code functions associated with the business event. When a business event lands in an Automatic state, it performs tasks associated with that state and immediately moves to another state.

A business event will never stay in an automatic state longer than is necessary to execute the code associated with that state.

Automatic states are represented in the process flow diagram as shown below:

1.8. Auto Begin

This state is a specially flagged automatic state that will serve as the initial state when a business event of that type is created. Execution of the business event begins immediately upon creation and continues until the event reaches a non-automatic state.

Auto Begin states are represented in the process flow diagram as shown below:

1.9 Adding States

States are added by right clicking on the STE diagram name in the Navigator. The user interface for adding a state to a diagram is shown in Figure 1

Line Callout 3: Right-click on a Diagram name to add a State

Figure 1:STE User Interface – Add a State

2. Events

As mentioned above, each state may have a number of associated events. Depending upon the type of state, different types of events are applicable. Not all types of events are allowed to be associated with all types of states. Each instance of an event is associated with exactly one state.

The Events/decisions with associated figures in this section are the only ones for which there are graphic representations.

The following event types are listed in the order in which they may occur:

2.1. ON_SET

ON_SET events occur immediately when a business event enters a particular state. Tasks may be associated with an ON_SET event. ON_SET events are applicable for all state types.

There is no visual representation of an ON_SET event.

2.2 EXPIRATION

For manual states (any state where the business event may remain for some time), a state event may need to trigger some activity after a specified period of time. For example, a business event may sit in the Inbox state for a period of time. If no one operates on the business event, after a certain length of time, some automatic action such as moving the business event to another state may occur. Such behavior is triggered by an expiration event. An expiration event is equivalent to attaching a timer with a fixed expiration date and time.

When an expiration business event is created, the rules governing when events reaching the associated state expire must be declared. There are two mechanisms for accomplishing this:

1. Specify the amount of time that should elapse before the expiration event fires. This is done using two values: a unit of measure and a number. Allowable units of measure are: seconds, minutes, hours, calendar days and business days. The second field (number) indicates the amount of the given unit. The number need not be an integer value; however, it must be greater than or equal to zero. (Note that a value of zero indicates that the timer event will fire as soon as the timer process searches for and processes activated timers (not necessarily immediately).

2. Specify the name of a date attribute on the business event with the assumption that the business event will calculate when the timer would fire as part of its flow. In this case, the designer must specify the name of the attribute in the business event. When the timer reaches the state with an EXPIRATION business event, ON_SET tasks will fire first. Next, the value of the field indicated will be examined and set as the date/time when the business event will expire. Calculations for the expiration date of the expiration event can be performed in the ONSET tasks for that state.

NOTE: Setting the expiration date to a particular point in time does not guarantee that the business event will fire at exactly that time. There is a background process that periodically looks for business events that have expired timers in order to execute the appropriate expiration tasks and move events to their new states.

Depending upon the frequency of this process, the time lag within which the business events will be executed after expiration will be indicated. For example, if the system architect directs the system to only search for expired tasks nightly, business events that have expired timers will not be executed until the evening.

Expiration events are indicated as shown in Figure 2.

Line Callout 3: Expiration state event

Figure 2:Graphical representation of Expiration Events

2.3. BEFORE_OPEN

For all manual states, the designer may allow the user to open the business event for viewing or processing. BEFORE_OPEN events occur as the event is being opened and might include logging who is opening the event. There can be tasks associated with BEFORE_OPEN events.

There is no visual representation of a BEFORE_OPEN event.

2.4. MANUAL_PROCESSING

A manual processing event is only associated with manual sates. These events are used to declare the edit privileges for the attributes associated with a particular business event. When a user opens a business event, this determines which variables can be viewed or edited.

There is no visual representation of a MANUAL_PROCESSING event.

2.5. AUTO_BAIL

This event is not implemented in the current version.

This event is triggered by a catastrophic program error not explicitly handled in the called procedures. Auto-bail events may be attached to any type of state.

There is no visual representation of an AUTO_BAIL event.

2.6. BAIL

Bail events may only be attached to manual states. This corresponds to some user interface (perhaps a Cancel button) element, which triggers the Bail event.

Bail events occur when the user has been inadequately trained or a program bug does not allow the user to select the desired alternative and the business event must be terminated.

Bail events are attached to the upper right hand corner of states.

A graphical representation of the Bail state is shown in Figure 3.

Line Callout 3: Bail state event

Figure 3:Graphical representation of Bail state

2.7. Manual Decision

When a user has finished working with a business event in a particular state (Ex. by clicking on a “Done” or “Process” button) and is presented with a series of alternatives to select from, this is a manual decision event. If no list of alternatives is to be presented, the Automatic Decision event should be used (see below).

If there is no manual processing event, the Manual Decision is triggered immediately after the BEFORE OPEN state event.

A graphical representation of a Manual Decision event is shown in Figure 4.

Line Callout 3: Manual Transition Event

Figure 4:Graphical representation of Manual Decision state

2.8. Automatic Decision

Automatic decision events may be associated with any state type. This type of event is triggered differently when associated with automatic or manual states.

For automatic states, as soon as the ON_SET event activity associated with the state is completed, the Automatic Decision event is triggered.

For manual states, the Automatic Decision event is triggered by a user interface action such as pressing a button (“Done,” “Next,” “Process”). If there is no manual processing state event, the Auto Decision is triggered automatically, immediately after the BEFORE_OPEN event.

When the automatic decision event is triggered, one of several alternatives is automatically selected and the business event passes to a new state.

A graphical representation of the Automatic Decision state is shown in Figure 5.

Line Callout 3: Automatic Transition

Figure 5:Graphical representation of Automatic Decision state

2.9. Listener Events

Listener events are not currently implemented.

2.10 Events Allowed for Specific States

Table 1 below shows which types of business events are allowed for which types of states.

EVENTS STATES	ONSET	EXPIRA-TION	BEFORE_ OPEN	MANUAL PROCESS-ING	AUTO BAIL	BAIL	MANUAL DECISION	AUTO DECISION

BEGIN	X	X	X	X	X	X	X	X
END	X	X	X	X	X	X
INBOX	X	X	X	X	X	X	X	X
WIZARD	X	X		X	X	X	X	X
SUSPEND	X	X	X	X	X	X	X	X
ERROR	X	X	X	X	X	X	X	X
AUTOMATIC	X							X
AUTOBEGIN	X							X

Table 1: Events allowed by State

2.11 Adding State Events

State events are added by right clicking on the state in the Navigator.

3. Transitions

Transitions allow business events to move from state to state. The start of the transition is always attached to a state event. States always transition to new states in the context of an event. Not all types of state events accept transitions.

There are two types of transitions: manual and automatic. Manual transitions are always attached to a manual decision event. Manual transitions are attached to all state types except Automatic and Auto Begin. All other transitions are automatic.

3.1. Manual Transitions

Manual transitions can only be attached to manual decision events. A manual decision event has one or more transitions attached to it that connect the event to a new state as shown in Figure 6.

Line Callout 3: Manual Transition

Low - 30

Med - 20

High - 10

Figure 6:Manual Event with Transitions

As shown above, there are four states: A, B, C and D. The small rectangular box indicates a manual decision event. The connection lines indicate transitions. Manual transitions are shown as solid lines. In this case, after working with State A and submitting the business event for processing, the user is presented with a list of alternatives corresponding to the transitions ordered by their order number (ORDER_NR). Depending upon the option selected (High, Medium or Low), a business event will move to state B, C, or D.

Manual transitions have zero (0) or more rules associated with them. (There is no visual representation of a rule.) A rule is a Boolean expression whose truth value is evaluated when that option is selected. If any of the rules fail, the selection of the option is disallowed, the rule’s error message is displayed, the event’s rule-fail tasks are executed, and the business event is left in the current state. If all of the rules are evaluated as “true,” the event’s rule-succeed tasks are executed and the business event is transitioned to the new state.

3.2. Automatic Transitions

Automatic transitions are shown as dotted lines as shown in Figure 7.

Line Callout 3: Automatic transition

Figure 7:Automatic Transitions

Automatic transitions act differently from manual ones. has Auto Decision, Expiration, Bail and Auto Bail state events have one or more automatic transitions associated with it. The automatic transitions act like an IF-THEN-ELSIF-ELSE construction in PL/SQL. Transitions are added as shown in Figure 8.

Each transition (except the last one) has a Boolean expression associated with it that is entered as a rule. One or more rules can be associated with the transition and are logically connected by a Boolean AND operator. The transitions are ordered and the rules associated with each of the transitions are checked in that order. The business event automatically selects the first transition (based on the transition ORDER_NR) where all of its rules succeed (evaluates to “True”). The business event transitions to the next state and tasks associated with that transition are executed.

Line Callout 3: Right-click on one of these types of Events to add a Transition to another State or Decision Event

Figure 8:User Interface for adding Transitions

4. Tasks

Tasks are lines of code that are executed by the system. Basically, the lines of code are all either assignment statements such as:

Salary:=$5,000;

or, procedure calls such as:

Create Journal Entry (Self OID);

Since these tasks are being implemented in an Oracle system, standard Oracle database functions, procedures and operators are all supported. It is strongly suggested that such functions, procedures and operators not be used in order to make the code more flexible and portable to other environments. Where Oracle functions are used, a wrapper function should be added and called instead of the source Oracle function.

More complex programming structures such as IF-THEN statements, loops, etc. are not supported. To use these constructions, we recommend creating procedures or functions that are called using the simple line syntax. The goal is to keep the code readable by non-technical users.

Tasks can be attached in various places during the processing of a state:

1) Directly to a business event – These tasks execute as soon as the business event fires. This is true for ONSET and BEFORE_OPEN business events.

2) To an automatic transition – (attached to an automatic business event) Tasks in this situation are automatically executed when the automatic transition is selected by the system

3) To manual decisions – In this context, there are two types of tasks:

· Rule success: If all of the rules associated with the transition succeed, then the Rule Succeed tasks will execute.

· Rule fail: If any of the rules associated with the transition fail, then the Rule Fail tasks will execute.

Currently, these are the only places where tasks can be placed in the system. Code that modifies attributes in a business event can also be placed in the applications that process these business events. However, we strongly advise against placing code that manipulates attribute values within the application. By adhering to this standard, virtually all programming logic can be stored in a single, easy to maintain part of the system.

Figure 9 shows the user interface for adding tasks to transitions.

Figure 9:User interface for adding Tasks to Transitions

5. Associated Guidelines

There are some additional guidelines associated with States, Events and Transitions:

· All business events that may be associated with a transition (manual decision, auto decision, expiration, bail, auto bail) must have at least one transition.

· With automatic transitions, the last transition should have no rule associated with it (equivalent to an “ELSE” in an IF-THEN statement).

· If no valid transition is found on an automatic state, a catastrophic program exception is raised and the AUTO_BAIL event is triggered. [not implemented]

· Every manual state should have a BAIL event associated with it to support user training problems and process flow bugs.

· Automatic states must have an associated automatic decision event. Otherwise, the business event will remain stuck in one state.

· Manual states (except Inbox) may have an associated automatic or manual decision but not both.

· Inbox states will always have an associated automatic or manual decision but not both.

Figure 10 shows the user interface for adding a rule or connecting States to Transitions.