The development of Validex is based on the following design principles.
The premiss for a useful validation is to apply the correct specifications. Depending on the users and the testing use case different approaches may be relevant.
Validex looks through the content of the test file and locates specified variables/values patterns (rule triggers) and uses these to match message to the available rules. For example, if the message is an invoice message and its content identifies it as an Peppol BIS specification then Validex automatically validates the message by using the official Peppol message specification for an invoice. A mix of messages of different type and based on different specification can be simultaneously "dropped" into Validex and Validex will find the relevant rule set for each message and use it for validation or notify if no specification are available.
In cases where the testing party only want a certain set of specification to be used Validex can recognize by who the message is submitted and apply a specific rules set to the message or intelligently select rules sets from a subset of the full specifications that are stored in Validex.
A user may want to test the same message instance with different rules sets to see how it fulfills the different specifications. This is specially relevant when testing customizations made on to general specifications. Then, after testing the message with intelligent recognition to see that the correct customization rules are applied, the tester may want to run another test that forces the general specifications in order to evaluate how the customized version validates against them.
Validex reports the results of the validations in two levels:
A single true/false indicator for the whole message that tells if the message passed all rules or not. This is specially useful when Validex is implemented into a run time process. Then messages that pass all rules can immediately be forwarded to the next step in the process e.g. sent on to the receiver or submitted to a system process but messages that fail a rule can be stopped or flagged for further analysis.
For messages that don't pass all rules a detailed breakdown of the failed rules is provided. The breakdown shows for every failed rule the following information.
The detailed validation report can be retrieved in Jason format allowing the tester to systematically process the rules. As an example when applied by a receiver in a run-time environment he can select what rules are important to him and only stop messages that fail those rules. Alternatively he can assign messages to different processes based on what rules fail.
This functionality also allows a receiver to create his own rules for categorizing received messages and assign them to different processes.
The validation reports from Validex can be provided in two main formats, html for human readable processing and Jason form machine processing. The two formats can be used interchangeably for the same validation report.
When using an API connection to Validex the tester receives the test results in a Jason formatted file. That file may contain either simple Boolean results or both Boolean and details. This report format can be used to automatically route the tested messages in a run-time environment.
Each validation report in Validex is stored for at least 30 days and is uniquely identified. Each report can be retrieved in human readable form as HTML page through the use of an xslt style-sheet. This format is useful when testing messages in an implementation phase of a system, design-time, or for follow up analysis of a run-time test. In which case, when a API/Jason report, reports a failed messages it provides the identifier for the validation report. This identifier can be inserted into a url and the report pulled up in html format. HTML reporting layout can be tailored to customers requests.