Controlling dsTest with Automation Tools

dsTest uses an XML schema to control the XML/TCP interactions on the control interface, which is the ONLY way to interact with dsTest. The dsTest Schema section of this documentation is an exact reflection of the XML schema (as it is generated from that schema) and thus contains all of the details required to build compatible XML commands.

Automation With dsClient Terminal

The option to specify a command when dsClient Terminal is launched is provided so that dsClient can be used within other automation tools (i.e. Telnet, TCL, Perl etc.). This allows the user to develop automation scripts in the tool of their choice with embedded execution of dsClient commands.

Refer to /usr/local/devsol/dsTest/lib/ for examples using several scripting languages.

The –c option allows the user to specify a command as part of invoking dsClient as follows:

dsClient -c <command>

In this usage dsClient executes the specified command, prints any response received from dsTest and then exits.

Note that the dsTest commands must be enclosed in quotes if there is a space character in the command.


dsClient -c "hlr:example_hlr start"

starts the HLR Node named example_hlr

dsClient -c "wait 1000" 

causes the a wait period of one second

dsClient -c "hlr:example_hlr action event::cancel rate::10" 

starts a cancel event at the rate of 10 per second on the HLR node example_hlr

The following examples are commands using TCL exec:

The examples below use the variable '$dsClient', which must equate to '/usr/local/devsol/bin/dsClient'.

exec $dsClient -d <IP_address> -c "<node_name> start" 

sends a start command to the node node_name on the dsTest server at IP_address

exec $dsClient -d <IP_address> -c "source ConfigFile.xml" 

sources the file ConfigFile.xml on the dsTest server at IP_address

exec $dsClient -d <IP_address> -c <node_name> "diameter socket ip_address <IP address 2>"

sets the diameter socket ip_address to IP Address 2 on the node named Node_Name on the dsTest server at IP address IP_Address

Refer to dsClient Commands for more information about the syntax used to address elements, attributes, and values.

Using XML over TCP

Another option for automation for those users with a working knowledge of XML is to have the automation application open a TCP socket and send properly formatted XML messages directly to the dsTest server. The XML must match the element sequencing and value restrictions defined by the dsTest schema.

Two ports are used for receiving commands: the high priority port (9998) and the low priority port (9999). Using a scripting tool, dsTest can be controlled by sending XML to these two ports. dsTest processes command in a serial manner and it will complete processing of one command before starting on the next. The high priority port should be use for configuring dsTest and controlling an active test, such as source and action commands. The low priority port should be used to get information from dsTest, such as Operational Measurements or status information. dsTest processes commands received on the low priority port as system resources allow, thereby ensuring that test performance is not impacted.

The first four bytes of every message sent to dsTest must specify the size of the XML message in bytes. Messages sent by dsTest will likewise specify the size of the XML response message.


An optional sequence attribute may be used in the devsol element, and if it is used the response from dsTest will return the same sequence number. This is useful for matching responses to commands if dsTest is also sending notifications to the client.

In this example, dsTest has been configured with an HSS node. To get the status of that HSS node, send a status command as follows:

<?xml version="1.0" encoding="UTF-8"?>

<dst:devsol xmlns:dst="" sequence="88505">








A message trace of a properly formatted message will appear as below. Note that the first four bytes contain the length of the command:

The response to this command will be formatted as below. Note that the first four bytes contain the length of the command response and the returned sequence value:

Your automation tool is responsible for parsing the response to obtain the desired information.

 Also see Automated Test Support in dsTest.