A key to customized and efficient content validation
A test profile is our concept for chaining a number of validation operations seemlessly together. It enables complete message validation, both structure and content checks, at once.
Test profiles can be created for all structured data. For outgoing messages it helps to ensure that implementation & documentation are aligned especially after system/version updates. For incoming messages it helps to provide an enhanced message validation as a self-service for senders (trading partners).
Test profiles can be created on various levels to ensure maximum interoperability:
- Requirements common for all users of a message format.
- Additional requirements common to a user group.
- Detailed organization specific requirements, usually published by the receiving organization.
A test profile may contain any number of preprocessing steps to manipulate input file before performing validation. Preprocessing includes, for example, unwrapping of a message envelope and pretty-printing of a message to assign a unique line number for each element.
2. Test phase
Validation consists of any number of test phases. Each test phase is based on a schema (DTD or W3C XML Schema) or a set of test assertions.
Each test phase has a "importancy" parameter which defines how errors affect on test execution and final test result:
- Must be passed to continue validation any further.
- Must be passed to pass a whole validation acceptably.
- Informative test phase to inform about best practices and forthcoming requirements.
Business and technical requirements are specified as test assertions. A test phase may contains any number of test assertions. If message does not pass a test assertion, a related test phase is marked with "failed" status.
Test assertions are used to fulfill requirements not covered by a message schema. Number of test assertions required depends on a desired accuracy.
Test assertion categories
Test assertions can be divided roughly into four categories (below description and example of each):
- Data cardinality:
- A message schema contains usually optional data elements which are mandatory in practice. These gaps must be filled with test assertions.
- "Invoice contains a due date."
- Data format:
- Simple data format constraints can be specified on a DTD/XSD schema but its expression power is very limited. For example, many identifiers contain computational check digits which can't be checked by a schema. It's also common that message formats support a generic method for stating an identifier where identification scheme is provided as a qualifier (XML attribute). These data relationship cannot be checked using a schema but are easily implemented as test assertions.
- "Legal business ID is stated using a format nnnnnnn-n, where a last number is a computational check digit."
- Allowed codes:
- Use of coded data values (codelist / enumeration) is a common practice in electronic data interchange. Message schemas can be used to specify a full list of acceptable codes where as test assertions can be used to specify valid codelist subsets for each context.
- "Country code is specified according to ISO 3166-1 alpha 2 and valid codes are 'FI', 'DE' and 'FR'."
- Data integrity:
- Message schemas are lacking ability to describe data dependencies and relationships. The most common integrity checks are related to computational sum checks and rationality of dates.
- "A total VAT amount specified in an invoice summary matches a sum of VAT amounts on each line."
Test assertion may include preconditions to match more complex requirements. Preconditions help to cover a number of scenarios with a same test profile.
Postprocessing actions can be added as supplementary features for different purposes:
- Visualized invoice messages as "A4 document"
- auto-generated order responses for order messages
- Deliver messages to own system to complete further inspection
- Need something else? Please ask!