Validation Configuration

The Format Definition entity of the AvantGard Trax Message model is extended to support extra configuration for the streaming framework. This configuration is more verbose than it was for the classic approach. This is because each I/O Pack format level or streamed XML element is processed separately to ensure low memory usage.

Figure 91 The main format definition

This complexity is encapsulated in a Format Definition entity and is reflected in the GUI configuration of a format.

Classes that map the input to the AvantGard Trax model and back operate on a single level only.

The implemented validations are also more complex to configure, but this complexity comes with greater flexibility as well.

In the classic approach, validations were defined in the I/O Pack structure XML definition and were linked in during the build. 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 build of the AvantGard Trax format.

One of the benefits of the streaming approach is that the activation of validations is no longer static. The supplied validations can be activated or deactivated and custom validations can be added to the format definition via the GUI.

Figure 92 Streaming level configuration

A streaming approach - by its very nature - does not support in-memory collections of child entities. This implies e.g. that an Envelope object has no access to its collection of Payment objects. A java.util.Iterator implementation is provided on supported top-level value objects to retrieve persisted child value objects in batches. The batch size of this iterator can be specified globally via an AvantGard Trax application property.

However, for streaming cross field validations, it is no longer possible to iterate through such a collection. Instead, an event mechanism is introduced to support communication between the different format levels.

For example, implementing a validation that checks for total fields checksums is no longer performed by iterating through the collection of payments and counting the amounts, but by sending events with amount information from the payment levels to the higher envelope levels.

Please note that both a streaming and classic implementation of an AvantGard Trax format can coexist.

However, it involves 2 implementations of the mappers and validations, and a subclass of the top-level structure must be created in which the non-streaming validators are statically added to the respective structure classes. As soon as this subclass is loaded, it is no longer possible to use the streaming approach in the same VM, because validations will produce incorrect results.

Figure 93 Streaming Validation Configuration

Aside from the necessary syntax-specific validations that the I/O Pack requires to parse and interpret the input data, all validations can be activated and customized separately. These validations are typically referred to as "Cx" and "Dx" validations.

The screen shown in Fig. 12.3 “Overall Validation Configuration” presents an overview of this configuration.

Figure 94 Configuration of a single validation

When a validation configuration is selected, the reported error code, error level and description can be modified separately as shown in “Figure 94 Configuration of a single validation”.

When a specific format definition is loaded, it is used by the streaming framework to generate code at runtime, which is then cached for subsequent requests.

Please note that modifications to the Format Definition entities of already loaded formats require a restart of the server-side AvantGard Trax application to be reflected in this generated code.

XML-Specific Level Configuration

By default, child elements are written to the output stream at the XML event "beforeEnd" of the parent element.

E.g. in case of pain.001.001.02, all payments of a batch (XML elements <CdtTrfTxInf/>) are written to the output stream before the end tag of the batch is written (XML element </ PmtInf>).

If the format requires another position for the child elements, the XML Specific Level Configuration tab can be used to customize this intercepting behavior. This is e.g. the case for the batches (XML elements <PmtInf/>) of a format envelope (XML element </Document>), that have to be written before the end of XML element </pain.001.001.2>.

The XML Specific Level configuration contains two input fields. One text field "ElementName", which contains the wrapper element to intercept and a drop-down list "InterceptWriterPosi- tion", which contains the position to intercept (beforeEnd, afterEnd, afterStart, beforeStart).