Resolution:
Description:
============
Are there any best practices for designing state machines?

Environment:
============
TIBCO BusinessEvents - 4.x
OS - all

Resolution:
============
Here are some guidelines from our Field team in designing state machines.

Apply the following best practices for designing state machines to maximize performance and throughput:

1).  Usually correlate an event or other instance to the “key/id” of  the State Machine’s enclosing instance.

2). There are some cases where rules are completely independent from each other and using a state model imposes an unnecessary ordering condition on these rules as well as additional state history maintenance overhead.  When this is the case, consider using only standalone rules

3).  Use condition-less transitions to exit out of composite states to prevent interrupt behaviour when the transition condition evaluates to true (unless this is the desired behaviour). One can use a called state machine instead of a composite state to avoid this without having a dummy state following the transition.

4). Explicitly delete concept instances when a State Machine ends. Unlike events, concept instances are not automatically deleted (retracted) from working memory when a state machine ends. You must explicitly delete concept instances in your rules using Instance.deleteInstance.

5). Keep all rules that interact with the state machine within the state machine transitions rather than adding them as standalone rules. This facilitates reviewing the flow of the state model by future developers.

6.      Lambda (condition-less) transitions are taken immediately after entering a Simple State, thus they should be used with care. Also, for simple states with an outbound lambda, it doesn’t make sense to have other transitions.

Best practices for designing state machines in TIBCO BusinessEvents.