Manual

The development of Validex is based on the following design principles.

• Support for automation in the processing of messages and in error handling.
• User friendliness that minimizes the users need to build specialized knowledge of messages specifications and testing procedures.
• Smooth and flexible integration into customers business processes.
• Flexibility in adding specifications.

Rule recognition

The premises for a useful validation is to apply the correct specifications. Depending on the users and the testing use case different approaches may be relevant.

Intelligent message recognition.

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.

Originator driven.

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.

Forced rule set

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 customization 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.

Results reporting

Validex reports the results of the validations in two levels:

A simple Boolean (true/false)

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.

Detailed breakdown of rules

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.

• Rule identifier.
• The rule statement.
• Exact location of the failed rule in the message also for multiple instance classes. This is specially useful when locating errors in messages with multiple lines where a single line fails.
• A textual explanation of the rule that can be used to help the tester to find what is wrong and to correct it.

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.

Report format

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.

Jason

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.

HTML

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.