Developing Solutions’® SmartEvents™ feature allows you to build simple to sophisticated state machines to control, monitor, and validate your message flows. You can easily construct and quickly modify your state machines to match the continuous changes in your testing environment. While SmartEvents can be implemented via XML, using dsClient™ GUI enhances the usability and capabilities of SmartEvents:
- Create a state machine using visual, drag-n-drop diagramming;
- Easily insert, modify, or delete states and event handlers by deleting the corresponding graphical representations on a workspace canvas;
- Modify the behavior of interface applications and coordinate multiple interface applications from within a single state machine;
- Import configuration files created with XML – 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;
- Get automatic validation against the dsTest schema, so that you are ensured that the configuration is schema compliant;
- Customize message flows using our SmartAVP™ feature – add, remove, modify, and validate AVPs in individual messages at different points in the message flow;
- Save the SmartFlow/SmartEvents portion of your configuration as a separate XML snippet, which can be included in other configuration files, saving time when developing new test scenarios;
- Configure different state machines for different subscribers since SmartEvents resides in the subscriber database;
- Produce snapshots of the resulting state flow diagram for importing into external documentation;
- Add custom operational measurements and specify when they are incremented or decremented;
- Add new behaviors to an interface application;
- Trigger events in one interface simulator based on conditions in another interface simulator;
Functional and Performance Testing
SmartEvents provides the capability to test simple to complex message flows. You can perform functional testing of single interfaces between a client and a server to performance testing of complex message flows between multiple nodes in a realistic network simulation.
For example, the protocols and interfaces for delivering VoLTE services are complex, and dsTest simplifies the task of measuring performance and validating message contents.
You can simulate realistic call flows by setting a probability assignment for the number of subscribers that will place voice calls. A load profile can be created that produces the desired volume of simulated voice traffic transactions, thereby triggering the appropriate procedures that would establish dedicated bearers for the traffic.
The shared subscriber database enables the server emulators to be provisioned with the same profiles that supply the emulated client nodes with subscriber identities, service definitions, custom AVPs, and the SmartEvents that define the steps in a complex message flow. Using a common repository keeps configured and dynamic subscriber information synchronized across all devices and applications.
You can shape the aggregate load profile while randomizing the actions taken by a particular subscriber, resulting in a more realistic simulation of subscriber activities.
In the complex testing scenario pictured to the right, this type of load profile would be useful in testing all nodes and interfaces involved with a VoLTE call flow, including the PCRF, HSS, OCS, OFCS, MME, PGW, PCEF, and CTF. Along with VoLTE call flow testing, the inclusion of a DRA can test the Diameter signaling routing in the simulation. dsTest® allows you to easily create complex testing scenarios spanning multiple application interfaces required in this type of scenario. dsClient GUI can be used to configure the test scenarios, producing fully functional and validated XML configuration files ready for dsTest.
SmartEvents uses event handlers to define the state transitions and actions in the state machine. Each transition from one state to another begins with an event and each includes one or more action to be performed.
- An event handler listens for, or “traps,” an event that is fired from an application or from within the SmartEvents profile;
- The handler will trap the event that is fired by the application on receipt of the specified event;
- When the event is received while the profile is in the appropriate state, the specified action is executed;
- State transitions are not required in an event handler- you can trap an event, execute and action, and remain in the same state.
- All of the actions provided for dsTest Interface Applications can be used in event handlers;
- Actions can be directed toward any dsTest node;
- The failure of one transaction does not prevent subsequent transactions from being attempted in an iterative model;
- An OM is pegged every time the enclosing event handler is activated;
- Measurements for the transaction itself are collected in the specific interface application measurements.
Within a handler, the following specific elements are available:
- Current State – The event handler is ignored unless the state machine is in this state;
- Transaction Start Event – Traps the event that is fired from an application when a subscriber enters into a transaction;
- Transaction End Event – Traps the event that is fired from an application when a subscriber’s transaction ends;
- Event Delivered – Traps the event when an event has been successfully delivered from the state machine to the target interface application;
- Event Received – Traps the event when an event has been successfully delivered from the interface application to the state machine, identifying the application and the event of interest;
- Message Received – Identifies an application event to be trapped;
- Start Timer – The amount of time, in milliseconds, that the transaction can remain idle before a “timeout”" event is fired;
- Timeout Event – Traps the event fired when a timer expires;
- Error Event – Traps the event fired when an error is returned from the target application. An interface application will return an error event if it is unable to execute the requested action. An application would return an error, for example, if it was unable to start a new transaction or if the subject subscriber could not enter into the specified transaction.
- Probability (of execution) – Allows a distribution of execution based upon probability of this handler being invoked, given the matching state or event. A random number is generated which has an approximately uniform distribution, and with the probability provided, this handler will be invoked. When not invoked, the next handler defined with matching state/event will be evaluated;
- Smart Conditional – Identifies a condition or set of conditions which must be met prior to processing this handler;
- Increment User Counter – Increments a custom counter identified by the element value. Counters can be named so that the name indicates the specific event being monitored;
- Decrement User Counter – Decrements a custom counter;
- Capture Next Event – The application which triggers this event is prevented from executing the next action (e.g. send a response), and is left in a suspended state;
- Release (Captured) Event – Releases a captured action/event. The application which had an action captured is now triggered to execute the next action (e.g. send a response);
- Reset Pending – Resets the source of a captured action/event. The application which had an action captured is now reset, which will prevent future actions for the related transaction;
- Fail – Fails the application which triggered this event. The application which triggered this event fails the current transaction, which will cause appropriate error messages for the related transaction;
- Reset – Reset the application which trigger this event. The application which triggered this event is reset, which will prevent future actions for the related transaction;
- Smart Modify – Identifies data to be updated prior to invoking the action within the containing handler;
- SmartEvent Actions – Contains the actions when multiple actions are required within a single event handler;
- Action (by applications) – Defines the action to be executed, along with the target application, node, and any supplementary information provided;
- Transaction Complete Action – Indicates that a state machine transaction was successfully completed. When this element is encountered in an event handler, the Transaction Successful counter in the Smart Events OMs is incremented, the resources reserved for the transaction are released, and the state machine is returned to the initial state unless the next state is specified.
- Transaction Failed Action – Indicates that a state machine transaction failed to complete. When this element is encountered in an event handler, the Transaction Failed counter in the SmartEvents OMs is incremented, the resources reserved for the transaction are released, and the state machine is returned to the initial state unless the next state is specified. A failure may be recognized by trapping an Error Event.
- Next State – The state to be entered after an action is executed.
Using dsClient GUI to Build SmartEvents State Machines
Construction of the SmartEvents state machine begins with the drag & drop wizard that is part of dsClient GUI. In this workspace, you can construct the desired message flow state machine by dragging the icons on the left onto the workspace canvas, then adding specific parameters to define the events and flows. The GUI takes care of housekeeping activities such as schema validation and insuring that the state machine has no discontinuities in flow between the defined states.
State machines are part of an overall dsTest configuration. The state machine/message flow can be saved as a separate file (XML snippet) or configured within an overall configuration. By saving it as a separate snippet, the state machine/message flow can be used in other configuration files – for example, it can be used with a different subscriber database, and not have to be recreated for tests that use different sets of subscribers.
Read more about dsClient GUI and how snippets can be used to easily create new, or modify existing, test configurations.
The GUI allows complex state machines to be constructed. In the example to the right, a state machine has been constructed with dsClient GUI that will test the VoLTE message flow diagrammed above.
Major Features of the State Machine
Note the major features of the state machine:
- Multiple states and event handlers that define the desired message flow with multiple interface applications;
- Race conditions may exist where different responses may come back in different order. The state machine can provide parallel processing handling so that you do not lose (and not process) these responses;
- Using timers, call up-time can be simulated where desired throughout the entire message flow;
- Error conditions can be handled within the main flow of the state machine. However, dsTest provides the special ‘Any’ state, where errors will be processed regardless of where they occur within the message flow. This allows a much more maintainable state machine, and allows you to process these errors in one place, cleaning up the subscriber status and protocol, insuring that the subscriber returns to the idle state, ready to be used for another transaction.
- User defined counters can be used throughout the state machine so that you can determine the progress of events as they progress through the message flow.
In the example to the right, an additional feature of SmartEvents is used. There may be instances of message flows that require a probabilistic distribution of message to different legs or section of the state machine. With the Conditional Event Handler, you can add these requirements to your state machines as needed.
With the Conditional Event Handler, you can define a message distribution based upon probabilities. In the example to the right, this Conditional Event Handler will send 60% of the messages through the first leg, and the remaining 40% through the alternate path. In addition to probabilistic distributions, you can also use the Conditional Event Handler to define loops in sections of the state machine, so that multiple events of the same type can be executed for a defined number of times without the need for duplicated event handlers.
Developing Solutions’ SmartAVP feature allows you to modify, delete, or add any AVP in any message processed by the state machine. By dragging the SmartAVP icon to any state that processes an incoming or outgoing message, the AVPs in the message can be modified.
In the example to the left, this SmartAVP will modify a Gx update message by adding a 1006 AVP, with AVP content as specified. Multiple instances of SmartAVPs can be used in each state, so that, for example, the AVPs in the message can first be totally removed then replaced by an alternate AVP. With the SmartAVP, you have complete control over the addition, removal, and modification of the AVP in the current message, positioning the changed AVP however you want. SmartAVP also supports container AVPs.
Other Features Available
The dsTest Complete Diameter Dictionary allows you to define a set of message templates against which all messages can be validated. The Diameter Dictionary can be configured to verify functional compliance to all supported specifications. This capability is highly optimized to run under moderate load levels, which supports compliance validation under load conditions.