Testing routes
Route specifications are the paths where messages flow from source threads to destination threads. Construct route specifications using a "From the Connection" approach.
Use the Routes tab to simulate the translation thread. Given a message, it determines the transaction ID and brings up the appropriate route configuration. This tool gets most of its configuration information from the Network Configurator.
The Route Testing Tool supports testing route configurations that contain DICOM transactions.
hciroutetest runs any inbound TPS for the source thread before it passes the messages to route and translate. This is necessary because the TPS often sets up metadata that is required for further processing.
If possible, then configure and verify complex routes without TPS modules. As the route is verified, add the modules in a logical order. The systematic insertion of TPS modules into the route specification makes isolating potential problems quicker.
It is important to verify each route. Valid message record formats for a thread and valid translations do not guarantee that the messages arrive at their correct destinations.
Test the route specifications for a particular source thread before starting the engine, after all message record formats and translations that are used by that thread are verified.
For hciroutetest to run translate procs in startup mode, select the check box on the Process Configuration dialog box. This is found at in Network Configurator.
$$
(double dollar) has a
confict with the shell special variable, which has meaning as the current PID on
Linux/AIX platforms. To use a global variable in the Testing Tool on Linux/AIX
plaforms, escape the $$
using one of these forms.
For example:- hciroutetest -a '$$variablename'
- hciroutetest -a \$\$variablename
On Windows, use hciroutetest -a $$variablename.