Data Integrity Module Transfer Checks

This page only applies to versions of Data Integrity Module up to 1.1.3. This feature is no longer included in versions 2.0+.

Introduction

The Data Integrity Module is capable of importing several checks via an XML file and upload the specified checks to the database in one go. This feature is useful in scenarios where large amounts of checks will be needed to added to the module. Furthermore the module is also capable of exporting one or more of the checks stored in the module. The exported file is a zipped XML document. This page gives the reader information regarding the use of transfer check feature (exporting and importing checks)

Importing Checks

As mentioned in the introduction, check import is done via an XML file. Let us now look at the structure of a valid XML document which is supported by the module. A check has a number of properties which determines how it gets executed and so on. These properties are:

  • The type (The module only supports the type 'SQL' yet. Future implementations of the module may support more types such as 'Groovy', 'Java' etc will be supported)
  • The name
  • The code (For the type 'SQL', the code needs to be an SQL query)
  • The result type
  • The Fail Operator and the Fail Directive (which determines on what criteria the check should be failed)
  • The Repair Type and the Repair Directive (which determines how a failed check can be repaired)
  • The Parameters (which enables the user to provide runtime parameters to the check as inputs)

A typical XML document containing all the above mentioned properties will be like follows:

<?xml version="1.0" encoding="UTF-8"?>
   <checks>
     <check type="sql">
       <name>Number Greater Than Check</name>
       <code>SELECT number_column FROM numeric_table</code>
       <resultType>number</resultType>
       <fail operator="greater than">4</fail>
       <repair type="link">http://www.google.com</repair>
       <parameters>@checkid@</parameters>
     </check>
   </checks>

A single XML document can be used to import multiple checks at once as well. You can use an XML document as follows to achieve the needful.

<?xml version="1.0" encoding="UTF-8"?>
  <checks>
   <check type="sql">
     <name>Number Greater Than Check</name>
     <code>SELECT number_column FROM numeric_table</code>
     <resultType>number</resultType>
     <fail operator="greater than">4</fail>
     <repair type="link">http://www.openmrs.org</repair>
     <parameters>@checkid@</parameters>
   </check>
   <check type="sql">
     <name>Number Less Than Check</name>
     <code>SELECT number_column FROM numeric_table</code>
     <resultType>number</resultType>
     <fail operator="less than">10</fail>
     <repair type="instructions">Ask the admin</repair>
     <parameters>@checkid@</parameters>
   </check>
   <check type="sql">
     <name>Number Equal Check</name>
     <code>SELECT * FROM numeric_table</code>
     <resultType>count</resultType>
     <fail operator="equals">5</fail>
     <repair type="none"></repair>
     <parameters>@checkid@</parameters>
   </check>
  </checks>

Allowed Values for the Tags

At the moment you can only enter "sql" for the "type" attribute in the "check" tag.

You can enter one of "number", "count", "string" or "boolean" for the "resultType" tag. Other than the "count" result type the others denote the data type of the columns returned by the query.

If you enter either "number" or "count", the valid values for the "operator" attribute in the fail tag are: "greater than", "less than", "equals" and "not equals".

If you enter "string", the valid values for the "operator" attribute in the fail tag are: "contains", "not contains", "equals" and "not equals".

If you enter "boolean", the only valid value for the "operator" attribute in the fail tag is: "equals"

For the "repairType" tag, the valid values are "link", "instructions", "script" and "none". The repair directive must be provided in accordance with the provided repair type.

If the code contains more than one parameter, the values entered in the "parameters" tag must be separated by a ; sign.
e.g: If the code is such that "SELECT patient_id, name FROM patient WHERE time(date_created) > time(' (date_one)') AND time(date_created) < time(' (date_two)')", the values entered in the parameters tag need to be in the form  (date_one); (date_two)

To get a thorough understanding about the different data types used in the XML, the user can first create checks via the "Add New Integrity Check" page and export them from the "Transfer Checks" page. By looking at the exported file the user will realize the different values to be used for the tags to achieve the optimum results.

Exporting Checks

Exporting checks is a breeze. In the "Transfer Checks" page all the stored checks are listed. The user can check all the checks he/she wants to export, provide a name for the exported file and then hit the Export button. The selected checks are put into an XML file, zipped and then downloaded to the user's computer. If the user does not provide a name for the exported file, the default name "IntegrityChecks.zip" will be used.

Note: If the user opts to provide a file name for the exported it must be noted that no spaces are allowed for the file name.

Back to Main Page