For many years, EMG has been able to log incoming and outgoing data into human readable log files, showing the protocol specific fields and their data (a “pdu”, a protocol data unit). This data is similar to what you can get from Wireshark, but the EMG logs only show the data on the application level. Our tool pdurunner, included in the EMG distribution files as of version 7.2.28, can be used to take this data and feed it back to EMG, while verifying its responses. Internally at Braxo this is used for testing, but it could also be used to resend messages that were incorrectly rejected.
The pdurunner starts its own emgd instance, so it can redirect outgoing connectors as needed back to the pdurunner application. You therefore first need to create a new base directory for this new instance. This directory should contain a license file, a server.cfg file, etc. There must be an incoming MGP connector so the emgstat command can work. Using DBCONFIG is not recommended. For outgoing connectors that should be handled by the pdurunner, you can skip the ADDRESS line, as that will be replaced automatically (using environment variables). Connectors that should connect to external systems, or loop back to the same emgd instance, can be configured as usual. Please be careful when connecting to external systems so they do not bind in TRX mode, receiving MO messages and delivery reports that were intended for the production EMG system.
Next, you prepare a new directory, which we call “input”, containing the pdu log files to run. They should contain data for connectors using the protocols MGP, SMPP, UCP, or CIMD2. All entries are executed in the relative order given by the timestamps. This respect for the relative order means it will respect the window size shown in the log files, which will be 1 for files created by emgd. As they show what should happen from the emgd perspective, they are run “inverted”. In other words, “Incoming connection” means the pdurunner should connect to emgd, “Read” that it should send data to emgd, and so on.
The instance numbers are respected. This means you can have an input file with data for multiple parallel connections.
Normally, for connector “x”, the file name should be “pdu.x”. Alternatively, the input files can also contain entire test cases involving several connectors. So, they can be called “pdu.test_send_via_smpp_get_dlr_via_ucp”, as long as the connector name and instance number on each line is correct. This gives a better overview of each test than when each connector has its pdus in separate files. To tell the pdurunner that it should handle the traffic on an outgoing connector, despite there now perhaps not being a pdu file for it, you need to run export PDURUNNER_HANDLE_connectorName=1, for each one of the relevant connectors, before starting the pdurunner. Adjust this if your shell has another syntax for setting an environment variable.
In the input files, a few special constructions are needed.
- The value “*” means the field should be present in the data sent by emgd, but its value should be ignored. This is useful for when validity period uses an absolute time, for example.
- The format
$nameis used to capture data from emgd, so it can be used later. This is useful for the message id field when messages are sent to emgd. If we expect a delivery report, we can then use the same construct with the same name for the field that says which message the delivery report belongs to. The same syntax is used when sending the matched values back to emgd. The list of these variables is global. - If you want to verify the contents of the message body in a delivery report, you can use the syntax
$#{id1}. This will match the value of the “id1” variable, encoded in hex. As neither “$” nor “}” are valid hexadecimal characters, this construct can be part of a longer hexadecimal string with contents both before and after it.
We recommend starting with a single input file, only containing the “Incoming connection” line. Once that works, you can extend it with bind operations, messages, additional input files, etc. You can use the newly created logfiles in $EMGDIR/log to verify that everything works as expected.
Now you can start the pdurunner, giving it two important parameters. The first one is “--emgd /path/to/emgd“, telling it what to run to start the emgd process. This can either be just your normal emgd binary, or a shell script that starts emgd using Valgrind, etc. The second parameter is “--logdir /path/to/input/files“. Normally this path would be $PWD/input, but you can use this parameter to select one of multiple input directories. Once all entries in the input files has been processed, the emgd process will be stopped (running “emgd -stop“), and pdurunner will exit. As always, examine log/general for errors and warnings, and adjust your setup as necessary.