Streaming Integration

Introduction

The format error report is generated when uploading a format file which contains errors and/or warnings.

Errors cannot be handled by I/O Pack readers and will always result in a database rollback for the file that contained the errors. No value objects will be persisted in the database for a file that contains errors.

Warnings do not result in reader failure, but are a result of checks performed, e.g. syntax validations, checksums or text patterns.

The configuration described here works for both the streaming and the classic format implementations.

Interaction between Streaming and Validations

In the classic approach, validations were hardcoded. This meant that all validations were statically added and if changes were required within a custom AvantGard Trax implementation, it was necessary to create a custom version of the AvantGard Trax format. In the streaming approach, this is no longer necessary. The supplied validations can be activated or deactivated and custom validations can be added to the format definition via the GUI.

When reading data in either streaming or non-streaming mode, there are four possible outcomes:

Valid: everything is correct

Error category: an error occurred when reading the data.

Warning category: a validation has failed.

Unexpected category: Any problem not covered by the other outcomes.

Classic (Non-Streaming) Handling

Standard validation will be TRUE by default.

Read errors will result in an error level

Validation errors will result in a warning level

custom validations will result in a warning level.

Streaming Handling

Standard validation are all reading errors

Format XML validation is always on

Via the GUI, other validations can be (de)activated

When “Fail on warning” is activated, every warning will be handled as if it was an Error level.

Compared to the classic handling:

Read errors will result in an error level

Validation errors will result in a warning level

Custom validations will result in a customizable level.

When an error occurs, the communication will have failed and there will be no business object (envelope) available. The error will be written to file as parameter. When a warning occurs, the communication object will be ok and the envelope will have been persisted.

Writing

When data is written, it will always be subject to strict validations.

I/O Pack errors and exceptions

To accomplish this for the classic formats, a refactoring of the I/O Pack errors and exceptions was needed.

The following exceptions were removed:

com.trax.iopack.validation.exception.ReadException

com.trax.iopack.api.xml.SyntaxException

com.trax.iopack.validation.error.Error

com.trax.iopack.validation.error.ReadError

com.trax.iopack.validation.exception.CompareException

com.trax.iopack.validation.exception.DomainValidationException

com.trax.iopack.validation.exception.ExpectedSyntaxMissingException

com.trax.iopack.validation.exception.FieldFormatException

com.trax.iopack.validation.exception.GarbageAtEndOfFileException

com.trax.iopack.validation.exception.GarbageBeforeConditionException

com.trax.iopack.validation.exception.NoReadableQualifiesException

com.trax.iopack.validation.exception.RequiredBlockMissingException

com.trax.iopack.validation.exception.SizeSplitException

com.trax.iopack.validation.exception.SizeValidationException

com.trax.iopack.validation.exception.StartOfBlockMissingException

com.trax.iopack.validation.exception.StructureValidationException

com.trax.iopack.validation.exception.ValidationExceptionSet

com.trax.iopack.validation.exception.WrongLineLengthException

In favor of the new com.trax.iopack.validation.exception.FormatException.

This FormatException contains one or more FormatError(s):

Figure 95 Format Error Implementations

The following error interface, implementation and obsolete collector were removed as well:

com.trax.iopack.validation.error.Error.java

com.trax.iopack.validation.error.ReadError.java

com.trax.iopack.validation.error.ValidationErrorCollector

For backwards compatibility with existing formats the following Exceptions & Error have been deprecated (but are never thrown), will be removed.

com.trax.iopack.validation.exception.TraxValidationException

com.trax.iopack.validation.exception.ValidationException

com.trax.iopack.validation.error.ValidationError

Custom I/O Pack formats

No changes to existing format validators and mappers are needed but it is strongly recommended to remove the use of deprecated classes & methods, because they will be removed in next AvantGard Trax releases.

Please note that custom I/O Pack formats will have to be regenerated, only source code compatibility is tested.