XDSI Test - User Guide ******** Introduction ******** This first release of the XDSI Test Tools is mainly intended to establish the basic infrastructure needed by the tests. Due to the amount of details, there will probably some problems encountered during the installation process. If this is the case, or there is simply a question or a comment about usability contact immediatly Stephan Friese . Almost everything can be clarified by a quick communication. The rest consists of bugs and it is also good to hear about them. As mentioned in the installation guide: USE THE SCRIPT 'XDSITEST_HOME/xdsitest/setenv' TO INITIALIZE EVERY NEW SHELL YOU CREATE! ******** Document Source ******** A Document Source has the possibility to send its produced SOAP requests to a repository. For the moment only the correct XML structure will be tested in order to get started. The request may also be send directly to the registry. This registry is a pure ebXML registry. The adaptor functionality will be, as far as needed, integrated in the repository service. In order to do these tests the following steps are required: - Start the database server. - Start the web container. - Configure your application to send data to the repository or the registry. The addresses can be found in 'XDSITEST_HOME/xdsitest/conf/xdsitest.properties': http://localhost:8080/xdsitest/repository/soap http://localhost:8080/ebxmlrr_xdsi/registry/soap - Send SOAP requests and examine the response. As mentioned before, there are only basic properties tested. These tests will be updated in short intervals. ******** Document Consumer ******** The tests for a Document Consumer are for the moment focused on those consumers working with DICOM instances because the sharing of these objects is the main focus of XDSI. A Document Consumer has the following peers to communicate with: - a registry which can be queried in order to locate published Key Object Selection Documents; - a repository holding these documents; - an IM/IA holding the referenced DICOM instances; - a WADO server allowing access to these instances via HTTP. The Document Consumer needs the following configuration information (look in 'XDSITEST_HOME/xdsitest/conf/xdsitest.properties'): - URL of the registry: http://localhost:8080/ebxmlrr_xdsi/registry/soap. - The network parameters of the IM/IA. These can be found in the above mentioned configuration file (prefix 'wadoserver.server.upstreamServer'). The consumer must also be known to this entity. In order to enable this, edit the file 'XDSITEST_HOME/data/imagectn/imagectn.cfg'. Append the triple (AETitle, Hostname, Portnumber) describing your application to the line at the end starting with 'IMAGECTN_XDSI'. The list of triples is comma separated. - URL of the WADO server: http://localhost:8080/xdsitest/wado. To test the ability of the Document Consumer to communicate with these peers, the following steps are required: - Start the database server. - Start the web container. - Start the imagectn. There is a facility which allows to publish arbitrary DICOM images. For such a publication the following steps are required: - Choose a DICOM image which is on the imagectn. You may put a new one. - Create an empty directory referenced from now on as 'PUB_DIR' (Look at the example 'XDSITEST_HOME/data/sample_submission' and execute the follwoing steps using this directory.). - Create a file 'publication.properties' with the information identifying the chosen instance. - Issue the command: java ca.etsmtl.ihe.xdsitest.docsource.SimplePublisher PUB_DIR An error during execution is in most of the cases due to a server not running. In 'PUB_DIR' you find at the end a lot of intermediary files created during the publication. The two interesting are 'submission_set.xml' and 'document_entry.xml'. These files describe the attributes of the newly submitted XDS objects. These must now be used in order to retrieve the published DICOM instance.