Data Transformation Engine Type Designer Reference Guide

Chapter 12 - Error Detection and Recovery Error Recovery
The example input data looks like this:
x
1
, y
1
, z
1
x
2
, a, z
2
x
3
, y
3
, z
3
x
4
, y
4
, z
4
x
5
, y
5
, b
x
6
, y
6
, z
6
There are two invalid records in this data: the second and the fifth. The Y of the
second record does not match the type definition of Y. The Z of the fifth record
does not match the type definition of Z.
Existence indicators and restart attributes determine how data is validated and
mapped.
Example 1
: There is no restart attribute contained in the File definition. Record
exists only if it is valid or if all its required components exist: X , Y, and Z.
In this example, the system finds Record 1 to be valid. It looks to see if all
components of Record 2 exist. It notices that Y is in error. When all of the
components of Record 2 are found, the system knows that Record 2 exists.
Validation continues on the remaining Records, finding Record 3 and Record 4
to be valid, Record 5 to exist with a Z in error, and Record 6 to be valid.
x
1
, y
1
, z
1
x
2
, a, z
2
x
3
, y
3
, z
3
x
4
, y
4
, z
4
x
5
, y
5
, b
x
6
, y
6
, z
6
Because there is no restart attribute assigned to Record, the occurrences of
Record that are in error causes the system to mark the File object to be in error,
it contains data objects in error. In this example, the message One or more
inputs was invalid occurs. No data would be mapped to the output.
Example 2
: Suppose the Record component of File has the restart attribute. This
time, validation proceeds as in Example 1, but the fact that Records 2 and 5 are
invalid does not make File invalid. File is marked as valid but containing errors.
Records 1, 3, 4, and 6 are mapped to their output form.
Bad data
Bad data
Record exists, mark errors
Record exists, mark errors
Bad record,
continue
Bad record,
continue