SmartFlow/SmartEvents State Machines


You can create SmartFlow/SmartEvents state machines for your testing configurations using the visual, drag-n-drop wizard. With the wizard, you draw a state machine diagram on the canvas and dsClient Desktop will build the corresponding XML configuration.  See this video for an Introduction to SmartEvents, and these Tips for using SmartEvents.

Produce your SmartFlow or SmartEvents state machine by dragging and dropping state definitions and event handlers on a canvas;

Easily insert, modify, or delete states and event handlers by deleting the corresponding graphical representations on the canvas;

Modify the behavior of interface applications and coordinate multiple interface applications from within a single state machine;

Import configuration files – the existing state flows can be easily modified using the drag-n-drop tool;

See visual indications of logical errors and omissions within the state flow such as dead ends or unreachable states in addition to the standard XML validation;

Get automatic validation against the dsTest schema, so that you are ensured that the configuration is schema compliant;

Produce snapshots of the resulting state flow diagram (png or gif) for importing into other documentation;

Annotate the purpose, expected results, and other information regarding your event handlers and configuration;

Save the SmartFlow/SmartEvents portion of your configuration as a separate XML snippet, and can be included in other configuration files.



Drag and drop the states and event handlers onto the canvas. You can rename the states from the default names (State 1, State 2, etc.). When you drag an event handler onto the canvas, define the actions that are to be taken by that event handler. Using the mouse, connect the two ends of the event handler to the appropriate states. dsClient Desktop will automatically update the current and next states for the handler. Icons will remain red until the all parameters are correctly configured (compliant with dsTest schema).

The values available for an event element or attribute in SmartEvent event handlers and SmartAVP are filtered based on the application selected. In some cases - when application is optional - "none" will be an available event when application is not set; otherwise application must be set in order for any events to be available for selection.

The icons include:

State Definition;

Event Handler - used to define state machine events required to move between states;

ANY State Definition - a special state that can be used to process an event that may occur at any time, such as a protocol failure;

SmartAVP - Allows custom AVPs to be defined and inserted into messages as needed;

Conditional Event Handler - Allow the definition of an event handler with conditions, such as a loop counter or random distribution of events.



A correctly configured SmartFlow/SmartEvents state machine will look similar to the diagram below.



Note that the Idle state is a special state that should start every state machine. It should never be renamed. As shown above, it is designated with a grey color to remind you of its special function.


Tips for Configuring SmartEvents

The following guidelines should be followed when configuring SmartEvents state machines. See this video for an Introduction to SmartEvents and our SmartEvents web page.

Annotate the test case: Use the 'notes' element to describe your test case and SmartEvents event handlers so that another person can determine the object of the test and SmartEvents and the intended outcome.

Subscribers: Every subscriber has an instance of the state machine, so it defines the actions that will be taken for an individual subscriber one time through the state machine..

SmartEvents handler order of processing: When an event occurs on a subscriber, dsTest will start at the top of the state machine and inspect each state for a match for the application event that has occurred for that subscriber. The first state definition that matches the subscriber, application and event will be executed. If no match is found, no action is taken. The first match will be taken, so multiple handlers with the same criteria after the first will never be executed.

Progression through the state machine: Once a handler is executed, dsTest proceeds to the next state immediately and waits for the event defined in that state for that subscriber. This is important for event handler definition, including the use of SmartAVP/SmartIE/SmartTCAP. If you are inserting a custom AVP into a message, you must be sure that you stay in the state in which the message is generated so that dsTest can insert the custom AVP in the message before the state is advanced to the next state.

Cleaning up the Subscriber's state: If subscriber is to be used multiple times during the test, the subscriber must always be returned to the idle state at the conclusion of the state machine with the use of 'Transaction Complete', or 'Transaction Failed' . This will insure that the subscriber is available for the next time it is to be used. If the subscriber is not in the idle state, it will not be available for use, and will be skipped the next time it is up for use.

Handling errors with the ANY state: dsTest provides special states named "ANY". This state name is available for use to allow an event to be handled regardless of the current state of the state machine. If the event described in the ANY state is received, the ANY handler will be executed regardless of where the subscriber is currently at in the state machine. This is especially useful for cleaning up the subscriber state and returning in to idle if an error occurs. See the discussion above regarding the return of the subscriber to the idle state. Multiple ANY states are allowed in the state machine. All other state names must be unique, and can not be named "ANY".

Event receipt within the state machine: When constructing your state machine, it is not required that each and every response (or other received messages/events) to an initiated action have an event handler defined to act upon the response(s) caused by the action. dsTest node emulators automatically respond to messages as depending upon its configuration, and an event handler for a response is only required if a specific action is to be taken upon the receipt of that response.

Race Conditions: Certain test situations can cause multiple events to be delivered to the state machine. These race conditions must be handled by parallel paths in the state machine if it is important to have different actions taken upon the receipt of the messages. An example of this is in a Gx/Rx test, whereby the sending of a Gx Update (CCR-U) to a PCRF which will cause a Gx update response (CCA-U), and probably a Rx ReAuth Request (RAR) to be returned. Since the order of the the CCA-U and the RAR depends upon the PCRF and network conditions, each will have to have an event handler, if it is important to the test that different paths be taken depending upon the order of the responses.

Node/event synchronization: dsTest provides a mechanism whereby the node used for a subscriber in a multi-node test case can be used for all actions taken within the current instance of the state machine. When specifying the name of the node that will execute an action, use "LAST NODE" (non stateful interfaces) to indicate that the last node selected from a range is to be used for this event. "CURRENT NODE" (stateful interfaces) is used to indicate the node currently in use by the selected protocol, based on the last interface on which traffic was sent/received for this instance of the state machine. In addition, it is possible to synchronize a node group with other node groups. When this attribute is set, actions using groups of nodes will always use the same index into each group.

Initiating SmartEvents: When using SmartEvents, it is recommended (but not required) that a SPR node be used to define the subscriber database, including the SmartEvents state machine(s) that are contained in the subscriber database. If you want to initiate SmartEvents actions, you must use a SPR, as SmartEvents actions can only be initiated from an SPR node, and the SPR node must be in a 'started' state.

Timer/Timeout Events: SmartEvents allows you to set a timer in a state that will cause a timeout event. The timer is the amount of time that will pass before the timeout event is fired. Any change of state (including exiting) will cause the timer to be canceled. It is important to realize that this feature is not a "delay" feature. When a timer is set at the end of a state, dsTest goes immediately to the next state. If a timeout event is not expected in that next state, the subscriber may not proceed as expected through the state machine.

Conditional Event Handlers: dsTest provides a conditional event handler feature that allows you to identify a condition or set of conditions which must be met prior to processing the handler. Multiple legs can be defined so that different paths/set of actions can be taken depending upon the conditions specified in the handler. The conditional event handler can be used to implement a loop count for a section of the state machine, and/or used to execute sections of the state machine based upon probability. When using multiple legs with assigned probability, it is important to remember that the probability assigned to each leg of the conditional event handler is relative to the probability assigned to the previous legs. For example, if you have two legs and you want the subscriber to take each leg 50% of the time, the first leg is assigned a 0.5 probability, and the second leg is assigned 1.0 probability (100% of the remaining times though the handler).

Drag-n-Drop - Event handlers and SmartAVPs can be copied using a drag-n-drop technique (Ctrl + drag). Click once to select the component, then press Ctrl and drag the component to create a copy. Event handlers can be dropped anywhere on the canvas. AVPs must be dropped on a existing state.