XDS Main Page

From IHEWiki

Jump to: navigation, search

This site helps with the testing of XDS.a, XDS.b, XCA, and XDR profiles as well as ATNA as it supports these profiles.

The three primary profiles, XDS, XDR, and XCA are sometimes refered to as XD* because it is shorter and easier to type.

Contents

Background

This test facility part of a larger effort to test IHE Profiles. Two important links for those interested in the bigger picture are:

Navigating_MESA_Software - which discusses the history and general structure of IHE Profile testing.

Pre-Connectathon/MESA_Software - which lists all the software and tests supported by IHE North America and IHE Europe.

How To Test

This section lists IHE Profiles and actors whose testing is documented on this site. Each section documents tests, tools, and overall approach to testing. This site contains the reference list of tests and test descriptions that are loaded into Gazelle/Kudu.

First a few Perspectives on XDS Testing

Server Testing

If you are testing a server, your server, then you probably have your software running on a development machine that is expecting to receive a network connection from the same machine or another local machine. Since you don't want to deal with firewalls (and corporate policies dealing with firewalls) it would be easier if a test client could be run locally on your development machine to exercise your server. That test client is called xdstest and is discussed more here.

Client Testing

If you are testing your client, a piece of software that expects to initiate a network connection, then you would rather test against a server on the Internet since you don't have to install and maintain the software representing the server. If the communications between your client and the test server on the Internet use standard ports and protocols then your corporate firewall is not going to get in the way of your testing, hopefully. The test server for XDS/XDR/XCA is called the Public Registry Server and will be discussed more below.

Other

There is actually a third category. If you implement a server that accepts a connection and then turns around and initiates a connection to another service. A good XDS example of this is the Document Repository actor which accepts connection requests from a Document Source and then initiates a connection to a Document Registry. This testing pattern is covered by a combination of the Server Testing and Client Testing procedures alluded to above.

Document Consumer (XDS.a and XDS.b)

All transactions for this actor are tested against the Public Registry Server. Generic WS endpoints are documented here. Individual tests may define specific required endpoints be used.

The Document Consumer actor is a client so it is tested against the Public Registry Server, specifically the Document Registry and Document Repository implementations.

Transaction specific tests are documented:

Transaction Tests
Query (SQL) (XDS.a) tests
Stored Query (XDS.a) tests
Retrieve (XDS.a) tests
Stored Query (XDS.b) tests
Retrieve Document Set (XDS.b) tests

All transactions are required to generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.

Document Source (XDS.a and XDS.b)

The Document Source actor is a client so it is tested against the Public Registry Server, specifically the Document Repository implementation. Some of the tests defined below require that the Document Source actor be bound with a Document Consumer actor, allowing queries. Most of the Life Cycle option and Folder option tests are like this. A specific testing event may only require a subset of these tests to be performed.

Generic WS endpoints are documented here. Individual tests may define specific required endpoints be used.

Transaction specific tests are documented:

Transaction Tests Tools
Provide and Register (XDS.a) tests Public Registry Server
Provide and Register.b (XDS.b) tests Public Registry Server

All transactions are required generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.

Document Registry (XDS.a and XDS.b)

All transactions for this actor are tested using the downloaded XDSToolkit and Testkit. Transaction specific tests are documented:

Transaction Tests
Register (XDS.a) here
Register.b (XDS.b) here
Stored Query (XDS.a) here
Stored Query (XDS.b) here
SQL Query (XDS.a) here

All transactions are required generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.

Document Repository (XDS.a and XDS.b)

Transactions for this actor are tested using both the downloaded XDSToolkit and Testkit as well as the Public Registry Server. Transaction specific tests are documented:

Transaction Tests
Provide and Register (XDS.a) and Register (XDS.a) (together) here
Provide and Register.b (XDS.b) and Register.b (XDS.b) (together) here
Retrieve (XDS.a) here
Retrieve Document Set (XDS.b) here

Submissions are tested by:

  • Configuring the Document Repository under test to forward to the Document Registry actor on the Public Registry Server
  • Using xdstest, submit a Provide and Register to the Repository under test, this results in a Register transaction to the Document Registry
  • Using xdstest, query the Document Registry to get the deposited metadata to evaluate it

Retrieves are tested by

  • Configuring the Document Repository under test to forward to the Document Registry actor on the Public Registry Server
  • Using xdstest, submit a Provide and Register to the Repository under test, this results in a Register transaction to the Document Registry
  • Using xdstest, query the Document Registry to get the deposited metadata
  • Using xdstest, retrieve and evaluate the document from the Document Repository

All transactions are required generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.

Document Source (XDR)

The Document Source actor is a client so it is tested against the Public Registry Server, specifically the Document Recipient implementation. The Document Source actor in XDR is different from the Document Source actor in XDS in that it cannot be bound to a Document Consumer actor giving it the ability to perform Stored Query or Retrieve Document Set transactions. Thus, the following operations, normal for a Document Source in XDS cannot be performed by a Document Source in XDR:

  • Submit Document Replace/Append/Transform
  • Add to an existing Folder

The Document Recipient implementation on the Public Registry Server performs the following duties:

  • Validate that the submission is valid by the rules of XDR (above list)
  • Forward submission on to the Document Repository/Registry implementation for local storage (where more basic XDS validations are performed).

Because the XDR submissions are forwarded on to the XDS Repository and Registry, they can be:

  • Queried via Stored Query transaction and retrieved by Retrieve Document Set transaction even though this behavior is beyond the scope of XDR.
  • More importantly, these XDR submissions can be found in the Test Log just like XDS submissions which aids in diagnosing problems during testing.

Generic WS endpoints will be documented soon. Individual tests may define specific required endpoints be used.

The only transaction used in XDR is Provide and Register Document Set which requires MTOM/XOP web service formating for both request and response (example). Examples of metadata contents, contents of the RegistryObjectList element, are:

  • Submission of one DocumentEntry (discussion, [http: example])
  • Submission of two DocumentEntries (discussion, [http: example])
  • Submission of a Folder containing a single DocumentEntry (discussion, [http: example])

There is a page in the IHE Implementation Guide discussing XDR that can be found here.


Transaction specific tests are documented:

Transaction Tests Tools
Provide and Register.b (XDR) here Public Registry Server

All transactions are required generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.

Document Recipient (XDR)

Transactions for this actor are tested using both the downloaded xdstoolkit and testkit. Transaction specific tests are documented:

Transaction Tests
Provide and Register.b (XDR) here

Submissions are tested by:

  • Using xdstest, submit a Provide and Register transaction to the Document Recipient under test

There is a page in the IHE Implementation Guide discussing XDR that can be found here.

Initiating Gateway (XCA)

All transactions for this actor are tested against the Public Registry Server. Generic WS endpoints are documented here. Individual tests may define specific required endpoints be used. Transaction specific tests are documented:

Transaction Tests
Cross-Community Query here
Cross-Community Retrieve here

All transactions are required generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.

Responding Gateway (XCA)

All transactions for this actor are tested using the downloaded xdstoolkit and testkit. Transaction specific tests are documented:

Transaction Tests
Cross-Community Query here
Cross-Community Retrieve here

All transactions are required generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.

Secure Node (ATNA)

The test collection for each of the above transactions includes requirements to test the transaction over a TLS protected connection as well as demonstrating the generation of appropriate audit messages.

Tool Overviews

For the testing of XDS/XDR/XCA there are basically two tools, the Public Registry Server and the XDS Toolkit. The Public Registry server is good for testing client software (software that starts by initiating a network connection). This server/service is available on the Internet year-round. The XDS Toolkit is a downloadable toolkit for testing your own servers (software that starts by accepting an incoming connection). This section gives an overview of these tools.

Public Registry Server

Internet site hosting reference implementations of:

  • Document Registry (XDS.a and XDS.b)
  • Document Repository (XDS.a and XDS.b)
  • Document Recipient (XDR)
  • Responding Gateway (XCA)
  • Audit Record Repository (ATNA) (as it applies to XDS/XDR/XCA only)

The Public Registry Server is itself the largest tool used in testing XDS/XDR/XCA. The key thing to know about this tool is the collection of Web Service Endpoints. They are documented here.

The rest of the tools, listed below have more technical documentation that can be found here.

Test Log

Database on the Public Register server that logs all events to the Document Registry, Document Repository, Document Recipient, and Responding Gateway implementations. The Test Log Browser (discussed here) can be used to browse your entries to obtain detailed error status (sometimes beyond what is returned in error codes and error messages). For XDS/XDR/XCA tests requiring interaction with the Public Registry server, the Test Log Browser allows downloading of EVS files, small text files that document your test results. For testing events managed by Kudu/Gazelle, these EVS files are uploaded as proof of completion of the tests. The Test Log Browser is available here.

XDS Toolkit

A downloadable collection of test tools. This toolkit, along with the testkit, are needed to test Document Registry, Document Repository, Document Recipient and Responding Gateway actor implementations. This allows these actors to be tested on a development machine behind the implementer's firewall. A copy of the testkit is included in this download. Download is available from here.

Testkit

A downloadable collection of test scripts that are executed by the tool xdstest. Each test is labeled with a test number (like 11900). Tests for XDS/XDR/XCA are documented here.

xdstest

A command line tool used to test Document Registry, Document Repository, and Responding Gateway, and Document Recipient actors. Xdstest is a language interpreter for the test scripts contained in the testkit. Xdstest is part of the XDS Toolkit.

Audit Log

The Public Registry Server offers an Audit Record Repository (ARR) actor implementation for testing the auditing requirements of IHE actors. This service includes a browser for viewing your audit records. The Audit Log Browser is available here.

IHE Links

Main IHE Testing page

Main IHE Web Site

IT Infrastructure Committee (home of XDS)

Download IT Infrastructure Profiles and Whitepapers

Committee FTP site

Implementation Notes

Official ITI Implementation Guide

Schema files for XDS

XDS.a

XDS.b

Stored Query

XCA

ATNA (FAQ)

Syslog

Metadata Patterns

XDS Notes from 2008 NA Connectathon


Where to ask questions

We have a mailing list dedicated to XDS/XDR/XCA (and related profile) implementation and testing. It is ihe-xds-implementors@googlegroups.com. Discussion of ITI Profiles belongs on the ITI committee mailing list ititech@googlegroups.com. If you need to contact me directly, I have a new email address for IHE work bmajur AT gmail dot com.

Testing

Test Documentation

Test requirements

a table of all the XDS/XDR/XCA tests indexed by the XDS transaction they support. Includes links to the documentation for each test. This link always points to the current year/season. This table is used to load Gazelle/Kudu so if you find discrepancies please let me know.

Detailed Test Descriptions/Instructions for the 2009/2010 season

detailed description of all the tests with instructions for executing. You can look directly here if you know a test number. If you want to look up a test by actor or profile use the link in the previous section.

General

Notes and test documentation for Async profile

All the documenation on testing async web services can be found here.

Notes on the XDS.a Profile

Notes on metadata and Soap with Attachments as used in the XDS.a profile.

XDS FAQ

(Frequently Asked Questions regarding the XDS profile)

UUID Reference Table

table documenting all the UUIDs created by the XDS Profile.

Discussion of XDS Transactions

this page offers discussion on selected topics on XDS Transactions.

Metadata Patterns

this page offers discussion on common metadata patterns

Schemas

All XML Schema files used to validate Registry/Repository related transactions.

Rules for submitting results to Gazelle/Kudu

There are two kinds of result files used in XDS/XDR/XCA testing. Tests executed with the XDSTookit/xdstest are always named log.xml. A single test, such as 11733, can have multiple sections (multiple testplan.xml files) and therefore generate multiple log.xml files. To get credit for your testing, these files must be uploaded into Gazelle/Kudu for the correct test. The evaluation is done by software so you must follow some simple rules or the test will not get labeled as passed.

  • Upload the logs to the correct test (yes, our software does check)
  • Do not upload last year's log files (see above)
  • If a test has multiple sections and generates multiple log files, collect them in a ZIP file for upload. The file names inside the ZIP file are not important, just the content in the files.
  • If a test has only a single section and therefore only generates a single log.xml file, it can be uploaded as is or ZIPed.
  • If you submit logs for tests that failed, don't expect credit (yes, I did have to say that)

The second type of test result is generated by the Public Registry Server for tests that are run against that server. The Test Log Browser and Syslog Browser offer a link to download an EVS file. EVS stands for External Validation Service. These are small (10 lines or so) XML files that document what was accomplished and offer a link back into the log database (for validation). To get credit for this style of test:

  • Run the test against the Public Registry Server
  • Find your results in the Test Log Browser or Syslog Browser
  • Click on the EVS link (right side - top) to download this small file
  • Upload the file into Gazelle/Kudu

Testing Tools

xdstest2 testing tool

Renamed to just xdstest, this is a command line tool that acts as Document Source, Document Consumer, Document Repository or Initiating Gateway for testing partner actors. It is now packaged inside a larger collection of tools which are collectivly called XDS Toolkit. This toolkit can be downloaded from here. Xdstest is really just a script interpreter for a small XDS-oriented test language. The actual scripts which make up individual tests are packaged in the testkit (see below) for distribution. A FAQ is maintained here.

XdsTools

a web page with a collection of tools that operate on the Public Registry Server. It includes the following tools:
  • Patient ID allocator for the Public Registry
  • A Web page for uploading your metadata for validation (a step that happens on every submission as well)
  • Simple browser for querying the Registry and retrieving from the Repository
  • Test Log browser - browse the content you submitted - useful for debugging and obtaining test results for Kudu upload
  • Syslog browser - the Public Registry server has a Audit Log repository you can submit to. This browser lets you view your submissions.

Test Log Browser (documentation)

a web based tool for browsing the test logs maintained on the Public Server. It detects the IP address from your browser connection and only shows log entries for transactions sent from that IP address. Test results files (aka EVS files) can be download for subsequent upload into Gazelle/Kudu to document sucessful testing during Pre-Connectation (aka MESA) testing.

SysLog Browser

a web based tool for browsing audit log entries sent to the audit repository on the Public Server. It detects the IP address from your browser connection and only shows log entries for transactions sent from that IP address. Test results files (aka EVS files) can be download for subsequent upload into Gazelle/Kudu to document sucessful testing during Pre-Connectation (aka MESA) testing.

Test Kit

This test kit contains scripts for testing server-based actors like Document Repository, Document Registry, and Receiving Gateway. It uses the xdstest tool to execute the scripts. The test kit is published here. Always download the most recent version. This testkit contains three main directories of test material: testdata directory containing scripts for initializing Registry and Repository actors for other tests; tests directory which are the tests; and examples directory which really are examples of things Document Source, Document Consumer, and Initiating Gateways have to do. Each test is contained in a directory with a number like 11745 which correspond to IHE tests documented in Gazelle/Kudu. Individual test documentation can be found on the wiki page here. A FAQ for this tool is maintained here.

XD Async Testing

Facilities for testing asynchronous interactions with XDS.b and XCA. A FAQ is maintained here.

Public Registry Server Configuration

The Public Registry is a server maintained on the Internet and is generally always available for private or IHE sponsored testing.

It resides at ihexds.nist.gov (129.6.24.109).

Configuration

Affinity Domain Configuration (XML)

that defines the Public Registry Affinity Domain configuration. This includes definitions of acceptable codes, mime types etc. The Metadata Validator tool (web page) is available for you to manually test your metadata. The same validator is used to check every metadata submission to the Public Registry (ProvideAndRegisterDocumentSet and RegisterDocumentSet transactions). Specifically, it passes the submitted metadata through Schema validation and then metadata validation. Metadata validation has two parts: validate that the metadata is structured according to the rules of XDS (which are more strict than ebXML Registry standard) and that the codes used in the metadata are consistent with the configuration of the Affinity Domain. Updates to this table are made on request to support community activities.


Test Event Configuration

The proper endpoint to use for testing is determined by the following:

  • The service (Registry vs. Repository vs. a specialty service designated for a specific test)
  • Which version of the Technical Framework you are testing against
    • tf5 - Technical Framework version 5
    • tf6 - Technical Framework version 6
  • Which testing event you are preparing for. Each event issues its own collection of certificates for TLS so using the proper endpoint will give you access using your issued certificate.

In the tables below, these issues are reduced to three 'variables':

YEAR
which really means the version of the Technical Framework (tf5 vs tf6)
EVENT
the non-TLS port number to use
SEVENT
the TLS (secure) port number to use


Important URLs / WS Endpoints

Event Configurations

Event Name YEAR EVENT SEVENT Available
North American Connectathon in Chicago in Feburary 2009 tf5 9080 Yes
European Connectathon in Chicago in April 2009 tf5 9080 9001 Yes
North American Connectathon in Chicago in Feburary 2010 tf6 9080 9085 Yes

Endpoints

Transaction non-TLS TLS
XDS.a
Provide and Register http://ihexds.nist.gov:EVENT/YEAR/services/xdsrepositorya https://ihexds.nist.gov:SEVENT/YEAR/services/xdsrepositorya
Register http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistrya https://ihexds.nist.gov:SEVENT/YEAR/services/xdsregistrya
Stored Query http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistrya https://ihexds.nist.gov:SEVENT/YEAR/services/xdsregistrya
XDS.a and XDS.b Stored Query only differ by their SOAP requirements (See TF section 3.18.3)
SQL Query http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistrya https://ihexds.nist.gov:SEVENT/YEAR/services/xdsregistrya
Non-TLS SQL Query will return a non-TLS URI. TLS SQL Query will return a TLS URI.
XDS.b
Provide and Register - b http://ihexds.nist.gov:EVENT/YEAR/services/xdsrepositoryb https://ihexds.nist.gov:SEVENT/YEAR/services/xdsrepositoryb
Register - b http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistryb https://ihexds.nist.gov:SEVENT/YEAR/services/xdsregistryb
Retrieve Document Set http://ihexds.nist.gov:EVENT/YEAR/services/xdsrepositoryb https://ihexds.nist.gov:SEVENT/YEAR/services/xdsrepositoryb
Stored Query http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistryb https://ihexds.nist.gov:SEVENT/YEAR/services/xdsregistryb
Multi-Patient Stored Query http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistryb https://ihexds.nist.gov:SEVENT/YEAR/services/xdsregistryb
XDS.a and XDS.b Stored Query only differ by their SOAP requirements (See TF section 3.18.3)
Non-TLS Stored Query will return a non-TLS URI. TLS Stored Query will return a TLS URI.
XCA Receiving Gateway
Cross Gateway Query http://ihexds.nist.gov:EVENT/YEAR/services/rg https://ihexds.nist.gov:SEVENT/YEAR/services/rg
Multi-Patient Cross Gateway Query http://ihexds.nist.gov:EVENT/YEAR/services/rg https://ihexds.nist.gov:SEVENT/YEAR/services/rg
Cross Gateway Retrieve http://ihexds.nist.gov:EVENT/YEAR/services/rg https://ihexds.nist.gov:SEVENT/YEAR/services/rg
Initiating Gateway with Affinity Domain option
Stored Query http://ihexds.nist.gov:EVENT/YEAR/services/xcaregistry https://ihexds.nist.gov:SEVENT/YEAR/services/xcaregistry
Retrieve Document Set http://ihexds.nist.gov:EVENT/YEAR/services/xcarepository https://ihexds.nist.gov:SEVENT/YEAR/services/xcarepository
Asynchronous Web Services
Provide and Register - b http://ihexds.nist.gov:EVENT/YEAR/services/repositorybas https://ihexds.nist.gov:SEVENT/YEAR/services/repositorybas
Register - b http://ihexds.nist.gov:EVENT/YEAR/services/registrybas https://ihexds.nist.gov:SEVENT/YEAR/services/registrybas
Stored Query http://ihexds.nist.gov:EVENT/YEAR/services/registrybas https://ihexds.nist.gov:SEVENT/YEAR/services/registrybas
Retrieve Document Set http://ihexds.nist.gov:EVENT/YEAR/services/repositorybas https://ihexds.nist.gov:SEVENT/YEAR/services/repositorybas
Cross Gateway Query http://ihexds.nist.gov:EVENT/YEAR/services/rgas https://ihexds.nist.gov:SEVENT/YEAR/services/rgas
Cross Gateway Retrieve http://ihexds.nist.gov:EVENT/YEAR/services/rgas https://ihexds.nist.gov:SEVENT/YEAR/services/rgas

Many tests use specialty URLs representing special testing services. These are documented in the individual tests.

This server is configured to accept/return the following configured values

repositoryUniqueId is 1.19.6.24.109.42.1.5

homeCommunityId is urn:oid:1.19.6.24.109.42.1.3


TLS

The Public Registry Server and the XDSToolkit support only two cryptographic cyphers for TLS:

TLS_RSA_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA

We impose this limitation for a couple of reasons:

  • It slightly simplifies the debugging of TLS connection problems since fewer cyphers are exchanged (yielding smaller log files)
  • We have not yet found a system that did not have one of these available in their default set (if necessary we will add to this list in the future)

North American and European Connectathons typically utilize different style certificates. North America usually issues self-signed certs while Europe usually employs a certificate authority. Usually the issued certificates are valid for a period of one year (until next year's testing season). A TLS-enabled port is available for each certificate set.

Updated certificates are loaded onto the Public Registry Server each season. Likewise, a new version of the XDS Toolkit is issued each season containing the new certificates.

Syslog Facility

The Public Registry server has a syslog facility to be used with joint XDS/ATNA testing.

It accepts syslog messages at ihexds.nist.gov (129.6.24.109) port 8087 on UDP.
A browser (here) is available to view your audit messages. This browser will only display your audit messages to you. It does this by sensing your IP address and only displaying entries generated from that IP.

The browser includes a validator that evaluates the content of a syslog message against the requirements published in the Technical Framework. To validate one of your messages:

  1. Find your message in the browser and select it with the mouse
  2. Details of your message will appear on the right side of the screen
  3. Select the Validate link on the top of the right side
  4. The validation results will be displayed in a separate browser tab/window

NOTE: The validator is limited to the following transactions. Other transactions, when validated, will give a large list of meaningless errors. The validator currently understands the audit log requirements of the following transactions:

ITI-14
ITI-15
ITI-17
ITI-18
ITI-41
ITI-42
ITI-43

A mechanism for you to get credit for your audit message during Pre-Connectathon testing (also called MESA testing) will be published soon.

Test Data

Test data available in the Public Registry is documented here.


Understanding EVS

XDS and related tests require the vendor to upload evidence files to Kudu/Gazelle for evaluation. Successful evaluation results in tests being marked as passed. This section describes the process of evaluation and how to use it.

Tests that can be auto-evaluated have a button NIST Validation on the Connectathon Manager's Mesa Log Return page. It is found in the Logs column. Pushing this button does:

  1. The uploaded log files are bundled into an EVS request to the NIST Public Registry Server.
  2. The result of this request is displayed as XML at the top of the page.
  3. If the result is Success then the relevant test is marked Ok.
  4. If the result is Failure then the ugly XML displayed must be scanned for the first <error> element. The text content of this element is the error message.
  5. For Connectathon Managers, this error text should be evaluated to see if it is a tooling problem or a vendor testing problem:
    • If the error text looks like Validating test 11995, which contains section eval but no log for that test/section was submitted, found [11994/rplc, 11994/xfrm, 11994/submit, 11994/eval] instead. then the problem belongs to the vendor.
    • Other typical vendor mistakes are wrong endpoint used on the Public Registry server and results include tests that failed
    • Most other error messages are really tooling problems
  6. Vendor error messages should be copied into the Comment box and the test marked as Failed
  7. Tooling problem messages should come back to me to investigate
  8. There is one class of tooling problem messages that should go back to the vendors. The Java platform I use has a well known bug decoding some ZIP files. This occurs if the ZIP compression uses a particular type of coding. The error indicates that the tool cannot decode the ZIP file. This seems to occur in one out of twenty ZIP files. In this case all that can be done is for the vendor to remove the ZIP file from the upload area and in its place upload the individual log.xml files. They will need unique names (within their set of files) but the file names are not important to validation. When the Java platform posts an update that fixes this bug this error will no longer appear. Error messages that are shown because of this bug are:
    • EvsWrapper#getLogsByTest: found 2 Test elements in log, the testlog file must be corrupted

Open Source

The code for the Public Registry Server is Open Source See http://ihexds.nist.gov for details.

Personal tools