AuditQuery and AuditLogging

Owned by Tran Tang
Last updated: Aug 27, 2019 by Eric McDonald
5 min read

AuditQuery Test Details:

Overview: 

AuditQueryLog Service project is used to test audit search functionality for each service.  It is accomplished by passing required query parameters to audit query service and by validating query results.  Testing will be done in standard and pass through mode with Database logging turned on. CONNECT by default uses Database logging and Log4j logging will be turned off. This project have five test suites and each test suite consists of QueryAuditEvents service with different services. 

QueryAuditEvents TestCase:

This test case is used to test audit query based on the request type elements that are passed  in auditquery service. This means, auditquery service request has UserId, EventTypeList, EventOutcomeIndicator, EventBeginDate and RemoteHcidList element values. When this suite is executed, the script will insert required data into the auditrepo.auditrepository table and then audit search performed based on the elements that are passed in request. Returned results are verified using assertion checks. 

It is not mandatory to pass audit query elements in SoapUI request message. If there are no elements passed, audit query service returns all the rows that are available in audit repository table.


QueryAuditEventsBlob TestCase: 

This test case is used to test audit query based on blob request type element that is passed in SoapUI request. When this suite is executed, the script will insert required data into the auditrepo.auditrepository table and then audit search performed based on auditId that is passed in request. Returned results are verified using assertion checks. 

It is mandatory to pass auditId elements in SoapUI request message.


QueryAuditEventsEmptyBlob TestCase: 

This test case is used to test audit query's empty blob response message. When this suite is executed, the script will insert required data into the auditrepo.auditrepository table and then audit search performed based on auditId that is passed in request. If there is no matching auditId in auditrepo.auditrepository table, then audit query service returns an empty response. Returned results are verified using assertion checks.

It is mandatory to pass auditId elements in SoapUI request message.

QueryAuditEventsByMessageID TestCase: 

This test case is used to test audit query based on messageId element that is passed  in SoapUI request. When this suite is executed, the script will insert required data into the auditrepo.auditrepository table and then audit search performed based on messageId that is passed in request. If there are no matching messageId in auditrepo.auditrepository table, then audit query service returns an empty response. Returned results are verified using assertion checks.  

It is not mandatory to pass messageId element in SoapUI request message. If there are no elements passed, audit query service returns all the rows that are available in audit repository table.

QueryAuditEventsByMessageID&RelatesTo TestCase: 

This test case is used to test audit query based on messageId and relatesTo elements that are passed  in SoapUI request. When this suite is executed, the script will insert required data into the auditrepo.auditrepository table and then audit search performed based on elements that are passed in request. If there is no matching messageId & relatesTo entry in auditrepo.auditrepository table, then audit query service returns an empty response. Returned results are verified using assertion checks.  

It is not mandatory to pass messageId element in SoapUI request message. If there are no elements passed, audit query service returns all the rows that are available in audit repository table.

Preparation & Execution:

  1. Deploy CONNECT ear (mvn clean install -P AD,PD,DQ,DR,DS,X12)
  2. In audit.properties, make sure LogToDatabase=true, LogToFile=false and other services are true (ex: QueryForDocuments=true)
  3. In AuditRepositoryProxyConfig.xml make sure to have securedImplementation are javaImplementation.
  4. Make sure to have auditquerylog entry in \\nhin\properties\ InternalConnectionInfo.xml file. 
  5. In SoapUI, load ValidateAuditQueryLogService project and execute.
  6. Make sure all five suites are passed and green.
  7. Test in Standard, Passthrough mode.

Audit Logging Test Details: 

AuditLogging via Database Test:

AuditLogging-Standard and AuditLogging-Passthrough projects are used to test audit logging functionality. It is accomplished by querying audit entries from auditrepo.auditrepository table and by adding assertion checks on blob elements and(or) attributes for each service. Testing should be done in Standard and Passthrough modes. By using audit.properties file auditing can be turned on/ off for any service (except AD) and for any specific transaction. CONNECT by default uses Database logging and Log4j logging will be turned off. AuditLogging-Standard, AuditLogging-Passthrough projects are implemented using CONNECT's default logging. These projects also verifies Database audit off functionality for all services (except AD). 

AuditLogging-Standard:

This project is used to test CONNECT's audit logging functionality for PD, DQ, DR, DS, PDDeferred and DSDeferred services. This project got g0, g1 suites with one test case for each service. When this project is executed, there is a script for each test case which validates number of audit entries logged in auditrepo.auditrepository table. The script will also fetch and validate the blob message to make sure it is complying as per sequoia project checklist and Exchange spec. When auditing turned off using a script, it is verified that there are no entries in auditrepo.auditrepository table. 

AuditLogging-Passthrough:

This project is used to test CONNECT's audit logging functionality for PD, DQ, DR, DS, X12, PDDeferred, DSDeferred, Batchrequest and Batchresponse services. This project got g0, g1 suites with one test case for each service. When this project is executed, there is a script for each test case which validates number of audit entries logged in auditrepo.auditrepository table. The script will also fetch and validate the blob message to make sure it is complying as per sequoia project checklist and Exchange spec. Using a script, when auditing turned off, it is verified that there are no entires in auditrepo.auditrepository table. 

Preparation & Execution:

  1. Deploy CONNECT ear (mvn clean install -P AD,PD,DQ,DR,DS,X12) 
  2. In audit.properties, make sure LogToDatabase=true, LogToFile=false and other services are true (ex: QueryForDocuments=true)
  3. In AuditRepositoryProxyConfig.xml make sure to have securedImplementation are javaImplementation.
  4. In SoapUI, load AuditLogging-Standard / AuditLogging-Passthrough project and execute.
  5. Make sure all test cases for g1, g0 are passed and green.
  6. Test in Standard, Passthrough mode. ( Note: While testing in Passthrough mode make sure to enable Passthrough mode for service in gateway.properties)

AuditLogging via Log4j File Test:

AuditLogging using Log4j file functionality is tested by running a CONNECT-ValidationSuite. It is accomplished by turning Log4j file logging property "LogToFile" to true. Testing should be done in Standard and Passthrough modes. By using audit.properties log4j file auditing can be turned on/off for any service (except AD) and for any specific transaction without requiring a database. When Log4j  - LogToFile property turned on, it will log complete ATNA audit message, with timestamp in a separate file that is configured in Log4j.properties using  "log4j.appender.AUDIT.File" property. 

Preparation & Execution:

  1. Deploy CONNECT ear (mvn clean install -P AD,PD,DQ,DR,DS,X12) 
  2. In audit.properties, make sure LogToDatabase=false, LogToFile=true and other services are true (ex: RetrieveDocuments=true)
  3. In AuditRepositoryProxyConfig.xml make sure to have securedImplementation are javaImplementation.
  4. In SoapUI, load CONNECT-ValidationSuite project and execute.
  5. Make sure all test cases for g1, g0 are passed and green.
  6. Verify audit messages are logged in audit.log file. ( default audit.log will be present under //logs/Audit.log). 
  7. Test in Standard, Passthrough mode. (Note: While testing in Passthrough mode make sure to enable Passthrough mode for service in gateway.properties)

AuditLogging via Log4j File and Database Test:

AuditLogging functionality is tested by using Log4j and Database configuration. It is accomplished by turning Log4j file logging property "LogToFile" to true and  "LogToDatabase" to true. Testing should be done in Standard and Passthrough modes. Auditing can be turned on/off for any service (except AD) and for any specific transaction. When "LogToFile" and "LogToDatabase" properties are turned on, it will log complete ATNA audit message, with timestamp in database as well in the file that is configured in Log4j.properties using "log4j.appender.AUDIT.file" property. 

Preparation & Execution:

  1. Deploy CONNECT ear (mvn clean install -P AD,PD,DQ,DR,DS,X12) 
  2. In audit.properties, make sure LogToDatabase=true, LogToFile=true and other services are true (ex: RetrieveDocuments=true)
  3. In AuditRepositoryProxyConfig.xml make sure to have securedImplementation are javaImplementation.
  4. In SoapUI, load CONNECT-ValidationSuite project and execute.
  5. Make sure all test cases for g1, g0 are passed and green.
  6. Verify audit messages are logged in audit.log file (default audit.log will be present under //logs/Audit.log). 
  7. Verify audit messages are logged in database as well.
  8. Test in Standard, Passthrough mode. (Note: While testing in Passthrough mode, make sure to enable Passthrough mode for service in gateway.properties)