Overview

Online demo

Features - Usage

The module's interface is shown below:

Usage: TAP_Validator <options>
where options must include:
        -i   inputTapFileName
and optionally, any of:
        -o createdTapFileName
                TAP file containing non severely errored calls
        -saveCallIndex
                Save original call indexes to createdTapFileName OperatorSpecInfos
        -report reportFile
                Detailed validation report per-error (if missing, goes to STDERR)
        -iv redefinedValidations.xml
                customization of validation process
        -s summaryFile
                Log validation summary in a file
        -rtf rtfFile
                Consise validation report in .RTF output
        -rap createdRapFileName
                RAP file containing errors (generated only when severe or fatal errors exist)
        -rapVer createdRapFileVersion
                RAP file version, e.g. "1.5"
        -rapFSN createdRapFileSequenceNumber
                RAP file sequence number, e.g. "10000"
        -rapPartner createdRapFileRoamingPartner
                Optional RAP file roaming partner, e.g. "DEUD2"
        -rapExtraCalls callFile
                Optional file with call indexes for calls to be included in RAP
        -rapAckIn inputRapFile
                Optional input RAP file (for generation of RAP Acknowledgement file)
        -rapAckOut outputRapAckFile
                Optional output RAP Acknowledgement file
        -V
                output version number
        -v
                increase verbosity (you can use it more than once, e.g. -vv)
        -h
                this help message
  

Notice that there is only one mandatory input argument, the TAP3 input file. The optional arguments can be used to fine-tune the validation process as follows:

• By using the RAP related options, you can generate a RAP (1.4 or 1.5) file with the validation errors (severe and fatal). The generated RAP file can be extended with additional calls, read from an external file that specifies calls (based on index: see option "-rapExtraCalls").
• By using the "-o outputTAP3file" argument, you can request a cleanup of severe calls; all calls causing severe errors will be removed, and AuditControlInfo will be updated to reflect the changes caused by these removals. The original input file remains unharmed; all these changes are performed in the outputTAP3file passed in the argument.
• All the errors and warnings identified by the validation procedure are sent to the standard error output of the application, unless you use the "-report reportFile.txt" argument to redirect it to a file.
• Many validations are checking to see if a value is inside a set of allowed values. Perhaps your organization is using a new value not anticipated by the standard, and you want to ignore these reports. Or perhaps, a specific validation depends on bilatteral agreements with a specific PMN, and you want to have different validation rules per PMN. Then again, maybe a specific validation rule is a well known issue with your billing system and you want to ignore it, because you've reached an understanding with the receiving PMN and they don't complain about it.

  You can control all that and more, through a powerful mechanism: a configuration XML file you pass the validator through the "-iv ConfigurationFilename.xml" argument.

• The validation output is rather verbose: it pinpoints all the details of the specific errors. If you want a less verbose ASCII summary, request one with "-s summaryFile.txt".
• Perhaps you want the summary to be nicely formatted: instead of "-s", use "-rtf rtfFilename.rtf" and the summary report will be nicely formatted inside an RTF (Rich Text Format) file.
• You can create RAP Acknowledgment files for incoming RAP files.

• Toggle (enable/disable) for a specific validation rule.
• Change the severity of a rule (e.g. from 'severe' to 'warning' or to 'fatal')
• Change the set of permissible values for value range checks
• Change bilaterally agreed parameters (as defined in TD57 standards, where bilateral refers to the two PMNs, the sender and the recipient)

• 0 if no fatal or severe errors or warnings were found
• 1 if at least one warning was found
• 2 if at least one severe error was found
• 3 if at least one fatal error was found