TransactionLogging
- 1 Summary
- 2 Requirements
- 3 Test Cases
- 3.1 PD-DQ-DR (FR 9, 9.1-9.5, NFR 9)
- 3.2 DS Deferred Req and Resp (FR 9, 9.1-9.5, NFR 9)
- 3.3 PD Deferred Req and Resp (FR 9, 9.1-9.5, NFR 9)
- 3.4 DS and AD (FR 9, 9.1-9.5, NFR 9)
- 3.5 PD Deferred Req and Resp - 2 RelatesTo (FR 9, 9.1-9.5, NFR 9)
- 3.6 DS Deferred Req and Resp - 2 RelatesTo (FR 9, 9.1-9.5, NFR 9)
- 3.7 DQ Fanout (FR 9, 9.1-9.5, NFR 9)
- 3.8 HIEM (FR 9, 9.1-9.5, NFR 9)
- 4 Manual Testing
- 5 Related To
Summary
The testing for Transaction Logging is contained in the regression test TransactionIDTest-soapui-project.xml, located in the SoapUI_Test/RegressionSuite directory. Each test case (described in detail below) creates message and transaction IDs from random values for the messaging and clears the transaction logs. The messageID or relatesTo ID is included in the header of the message(s) in the test case, along with the transaction ID. The messageID and/or the relatesToList are included in the assertion of the test message. The assertion values are passed to the NHIN message. This allows for the test to get the appropriate message IDs logged in the transaction database for the NHIN response messages.
The regression test project is divided into two test suites, Entity and Message Proxy. The tests are the exact same in both suites with the exception that the messages are targeted to different endpoints (entity vs. message proxy). The message proxy test suite also doesn't contain the Document Query fanout test because of limitations to the gateway's functionality. All CONNECT interfaces including entity/passthrough and synchronous/deferred are tested.
Requirements
The regression suite project fulfills the following requirements: FR 9, FR 9.1, FR 9.2, FR 9.3, FR 9.4, FR 9.5, and NFR 9. FR 9, allowing for a correlated identifier (the transaction ID) for a group of transactions, is tested for a different set of messages per test case. FR 9.1, modify all interfaces for correlated identifier, can be traced through each transaction in the server log after running each test case. The transaction ID header element is an optional element which fulfills FR 9.2, correlation ID will be an optional element, and NFR 9, allowing for backward compatibility (this last requirement is met by the use of the fact the element is optional and that the interfaces remain unchanged due to the use of the transaction handler classes). The project as a whole (including all test cases) tests every CONNECT interface from entity to pass-through and synchronous to deferred, fulfilling FR 9.3 (include for all supported message types) and FR 9.4 (include entity, pass-through, synchronous, and deferred). Each test case verifies the logging of the transaction correlations in the transaction log, FR 9.5 (allow for database entries for taking further performance metrics and also allow for server logging). A manual verification of the server logs upon running the test project by the tester will complete the FR 9.5 testing.
Test Cases
*each test case includes the requirements covered in parentheses
PD-DQ-DR (FR 9, 9.1-9.5, NFR 9)
The test case sends Patient Discovery (PD), Document Query (DQ), and Document Retrieve (DR) messages with the same transaction ID and different message IDs. The test asserts that there are 6 total items in the transaction database created by this string of related messages.
DS Deferred Req and Resp (FR 9, 9.1-9.5, NFR 9)
The test case sends Document Submission (DS) deferred request and response messages with the request message containing a unique message ID and transaction ID and the response containing a unique message ID and a relatesTo ID that equals the request messages messageID. The test asserts that there are 4 total items in the transaction database created by this string of related messages.
PD Deferred Req and Resp (FR 9, 9.1-9.5, NFR 9)
The test case sends Patient Discovery (PD) deferred request and response messages with the request message containing a unique message ID and transaction ID and the response containing a unique message ID and a relatesTo ID that equals the request messages messageID. The test asserts that there are 3 total items in the transaction database created by this string of related messages. The assertion for 3 is due to an issue that was discovered that PD Deferred response acknowledgement message does not contain a relatesTo value. The issue is reported here: GATEWAY-3029
DS and AD (FR 9, 9.1-9.5, NFR 9)
The test case sends Document Submission (DS) and Admin Distribution (AD) messages with the same transaction ID and different message IDs. The test asserts that there are 3 total items in the transaction database created by this string of related messages. AD is a one way message so no response message will be logged.
PD Deferred Req and Resp - 2 RelatesTo (FR 9, 9.1-9.5, NFR 9)
The test case sends Patient Discovery (PD) deferred messages, 2 deferred requests and a response message. Each request message contains a unique message ID and unique transaction ID and the response contains a unique message ID and 2 relatesTo ID values that equals the 2 request messages messageIDs. The test asserts that there are 3 total items for each of the unique transaction IDs (6 altogether).
DS Deferred Req and Resp - 2 RelatesTo (FR 9, 9.1-9.5, NFR 9)
The test case sends Document Submission (DS) deferred messages, 2 deferred requests, and a response message. Each request message contains a unique message ID and unique transaction ID and the response contains a unique message ID and 2 relatesTo ID values that equal the 2 request messages messageIDs. The test asserts that there are 4 total items for the first unique transaction ID and 3 for the second (7 altogether).
DQ Fanout (FR 9, 9.1-9.5, NFR 9)
The test case recreates a Document Query (DQ) fanout scenario. There is a UDDI Connection replacement file (uddiConnectionInfo_TRANS_Fanout.xml) in the regression suite containing 3 HCIDS (2.2, 6.6, 7.7) that will be targeted in the fanout. The test replaces the UDDI connection file in the server with the fanout uddi file. The Document Query message contains no targeted value, so it will fanout. The Document Query message contains a unique transaction ID and message ID. The test asserts that there are 7 total items in the transaction database, 1 for the original entity request message and 2 each (total 6) for each targeted HCID, request, and response.
HIEM (FR 9, 9.1-9.5, NFR 9)
The test case sends Subscribe and Notify messages with the same transaction ID and different message IDs. The test asserts that there are 3 total items in the transaction database created by this string of related messages. Notify is a one way message so no response message will be logged.
Manual Testing
It is recommended that in addition to running the tests that the tester review the logs for each test case ran, to confirm that the messageID and transactionID values are appropriately appended to the server log output (an example of which is in the Transaction Log approach document).