Interoperability Testing

Version History:

Environment and Overview

As of CONNECT 5.3, interoperability testing utilizes Amazon EC2 instances on the AWS platform. Each CONNECT release will be tested against select earlier versions to ensure compatibility and interoperability with these versions. The following tests will be performed:

• CONNECT X.X (Hub) to and from the following nodes: JBoss EAP 7 (4.7), WebLogic 12.2.21 (4.5), WebSphere 8.5 (4.5), WildFly 8.2.1 (4.2)

Testing approach

 Figure 2: Interop Testing Process

The testing approach employed is grounded in being repeatable and fully auditable. The overall approach is presented in Figure 2. In short, a pair of servers is configured for testing. A SoapUI testrunner script, similar to the following, is executed from one server (e.g. the hub) against the other server (e.g. the node) with the test results written to the hub's result location. The validation suite execution is specific to the Hub's suite available when it was released. For CONNECT 3.2.2 and later, this is the same validation suite used during unit, verification, and regression testing and tests all of the CONNECT services, not just a limited set of services.

testrunner.bat -f [result file location] -a C:\vs\newvs\ConnectValidation-soapui-project.xml -Djava.awt.headless=true

Many services are deprecated in CONNECT 3.3 and above and have been removed from execution of prior CONNECT releases if those validation suites actually tested those services. Examples include: Audit Log Query, Document Query Deferred Request/Response, Document Retrieve Deferred Request/Response, and Reidentification. Additionally, HIEM (Subscribe, Unsubscribe, and Notify) had been removed during CONNECT 4.2 interoperability testing.

There are four virtual servers hosting four different versions of CONNECT (5.2, 4.7, 4.5 and 4.3.2). When all test pair test scenarios are complete, all test runner results are captured and the final Interoperability test report is generated manually.  

Additional Info

Lessons Learned Connecting CONNECT

Configuring the Interoperability lab to support all of the test scenarios while emulating all of the federal partner and most common community environments always reveals unforeseen integration details and setup challenges.  Results for these efforts are included in this section as a lessons learned that may prove helpful to others implementing CONNECT. The items below are NOT intended to replace the detailed installation instructions found on the CONNECT Installation wiki, in addition this should not be considered as an "all-inclusive" list but rather some helpful time saving hints.

General Advice

Sync time between servers

Message level security implemented by CONNECT specifies that a message is only "good" for a certain time window, therefore there is a time synchronization dependency between CONNECT servers. If the servers have system times that are off, "connection refused" messages will appear in the server log.  It is best, when starting to test, to ensure that the system times of the two servers are synchronized.

SoapUI and SoapUI Validation Suite

The CONNECT Product Team experienced several challenges with SoapUI when testing CONNECT.  These may have been isolated issues, but they are detailed herein to assist other implementers who may encounter similar issues.  With the introduction of Java 1.7 in CONNECT 3.3, SoapUI version 4.5.1 is the minimum product version that may be used because of the Java dependency.  Older versions of CONNECT, leveraging Java 1.6, may still use SoapUI version 3.5.1.

Mysql and Fileutils JAR issues

The CONNECT installation instructions detail that the FileUtils and mysql-connector-java JAR files should be copied to the SoapUI installation bin\ext directory. For the majority of instances this works fine.  However, there are occasions when a SoapUI JDBC or SQL error will appear in the SoapUI error log. To resolve this issue, an implementer must do two things.  First, copy the FileUtils and mysql-connector-java JAR files to the SoapUI installation lib directory. Second, edit the soapui.bat (soapui.sh fir *NIX) and add the following to the SET CLASSPATH line.  Note: This is a Windows example and the actual JAR file names may be different.

%SOAPUI_HOME%\lib\FileUtils-5.1.0-SNAPSHOT.jar;%SOAPUI_HOME%\lib\mysql-connector-java-5.1.10.jar

Execute command line testrunner in "headless" mode

The headless option must be included on a testrunner command run in the Linux environment.  This will avoid display library conflicts or missing libraries.  However, it does not hurt to include the parameter when executing testrunner in Windows or Solaris.

The -Djava.awt.headless=true parameter should be added to every testrunner script execution.

Set the GatewayPropDir

The GatewayPropDir custom property in the CONNECT 5.3/5.2/5.1/5.0/4.7/4.6/4.5/4.4/4.3/4.2.1/3.3.1.3 Validation Suite must be set or the Validation Suite test will fail.  This property must point to the file location of the CONNECT  adapter.properties, gateway.properties, exchangeInfo.xml, and internalExchangeInfo.xml files.

Change the LocalHCID, LocalAA, RemoteHCID, and RemoteAA Custom Properties

The default values for LocalHCID/LocalAA are 1.1 and the defaults for RemoteHCID/RemoteAA are 1.2, 1.3, 1.4 and 1.5.  The LocalAA and LocalHCID values must match the HCID in the adapter.properties, gateway.properties and internalExchangeInfo.xml files. The RemoteAA and RemoteHCID must match the values in the exchangeInfo.xml files. Failure to make these custom property changes will lead to no communications registered in the node gateway's server log and NullPointerExceptions in the requesting/hub server's server log.

Copy the exchangeInfo.xml and internalExchangeInfo.xml files from the CONNECT properties directory to the location of the Validation Suite

Copy the exchangeInfo.xml from the CONNECT properties directory to exchangeInfo_g0.xml and exchangeInfo_g1.xml.  Copy the internalExchangeInfo.xml from the CONNECT properties directory to internalExchangeInfo_g0.xml and internalExchangeInfo_g1.xml. Failure to to perform this step will typically result in selected Validation Suite passing the first time and then never passing again as the key files get overwritten in the CONNECT properties directory during test execution.  Additionally, Null Pointer Exceptions will appear in the server log where the Validation Suite is run.

Setting the HCID in the internalExchangeInfo.xml and exchangeInfo.xml 

This internalExchangeInfo.xml file should only contain endpoints local to your gateway. The setting for the HCID is at the bottom of the file:

It is not the businessKey at the top of the file:

For the exchangeInfo, ensure that all the "uddi:testnhieonenode:" parameters map to the remote gateway's HCID. Also, the HCID setting for the remote gateway should be set with the following: