Using Automatic Verification process

Sometimes you are required to run a group of preset modules [automatically] based on the results of a previously run module. For example, you may want to update the status information in a header record after all of the related data is downloaded (successfully or unsuccessfully) to the client machine. Here the two steps are:

  1. Run a module that downloads the data to the client machine.
  2. Based on whether the data is successfully or unsuccessfully downloaded, the tool automatically runs a set of preset modules that update the status of the header records.

If you enable the autoVerify feature for any given module, the tool sets three additional preset modules that are defined with the base module. Out of these three preset modules, one or all are called, based on the download results of base module. The three preset modules follow this fixed naming convention:

  • <base module Name>Success: This module is called if the base module download is successful.
  • <base module Name>Fail: This module is called if the base module download is not successful. Ideally, this module attempts to successfully download the data again.
  • <base module Name>Abort: This module is called when all the download attempts fail.

AutoVerfiy: This is the feature that enables this mechanism in the XMDBTool. If the AutoVerify feature is set in the server, then you can use this feature by using the autoVerfiy parameter.

To turn on this feature from the client side, you need to set the autoVerify parameter located in xmdbtool.properties, as autoVerify = <moduleName>.

The autoVerify parameter can also have multiple associated modules as this:

autoVerify = <moduleName1>::<moduleName2>, that is, autoVerify = ER::TP::TS::PR

This ensures that the selected modules are autoVerify ready. This diagram provides an overview of the autoVerify parameter operational flow:


Configuration Parameters

There are various parameters, some mandatory and some optional that can be set for download_data.bat/sh. All these parameters can be specified in the xmdbtool.properties file located in the <XMDBTool_Root_Install_Directory>/conf directory. Optionally, it can also be specified as command line arguments to the batch files.

  • downloadTableName: This is a mandatory parameter if a single table is to be downloaded. The user needs to specify the table name from where the data is to be exported / downloaded to the customer machine. For example, downloadTableName = alex_application_filter. Here the alex_application_filter is the table from where the data is exported. The downloaded data files reside in the auto-created folder DownloadedData. Optionally along with the table name, name – value pair can also be passed to the server. These name-value pairs are used to replace the placeholders in the SQL queries that run on the server against the specified table. The table name must be separated from the name-value pairs by the special character ~. For example, downloadTableName = t1~var=20. Here, t1 is the table to be downloaded and the variable var is passed to the table with the value 20. On the server, the SQL queries against this t1 table is scanned and any placeholder named var is replaced with the value of 20. In case of multiple variables, each variable can be separated by comma (,).

    downloadModule: This is a mandatory parameter only if modules need to be downloaded. In this parameter, specify the name of the module that needs to be downloaded. For example, downloadModule = ER. Here, ER is the module that needs to be downloaded.You can specify multiple modules that need to be executed. Each module name is separated by colon [:]. Each module is picked up from left to right and executed iteratively. For example, downloadModule = ER:TP. Here, ER and TP are the two modules to be downloaded. If required, along with each module, name – value pair can also be passed to the server. These name-value pairs are used to replace the placeholders in the SQL queries that run on the server against all the tables present in this module. For example, downloadModule = ER ~var=20. The SQL queries against all the tables present in the ER modules are scanned and all placeholders with the name of var are replaced with the appropriate values that are sent from the client side.

    Note: If downloadTableName and downloadModule are both specified, then the downloadModule has precedence over the downloadTableName parameter
  • downloadFolderName: This is an optional parameter. Users need to specify the name of the folder location where the downloaded data and the log files are to be placed. For example, downloadFolderName = C:\\FolderName. If this parameter is not specified, the downloaded/exported data files and log files reside in the parent directory of the directory from where the download_data.bat has been run. This is generally the bin folder.The downloaded data files always reside in the auto-created folder DownloadedData. If this parameter is specified, the DownloadedData folder can be found in the location specified in this folder.
  • autoVerify: This is an optional parameter and is used to specify modules which require automatic verification. Multiple modules can be specified. The modules are executed iteratively picked from left to right. Each module is separated by a colon (:). For example, autoVerify=ER
  • ex_delimiter: This is an optional parameter and is used to specify the file delimiters when exporting data. For example, if the delimiter required is TAB, then ex_delimiter must be set as ex_delimiter = TAB. By default, the delimiter is bar.
  • The output of an export file can be generated in the .csv format, using the XMDBTool client. For generating the output in the .csv format, set the value of the ext parameter to csv in the properties file.