Validate EDI objects

It is essential that valid documents are exchanged between trading partners. Accuracy is one of the benefits that EDI provides over paper document processing and estimates suggest that providing accurate data results in 30% faster delivery time.

The EDI standards define the format of all messages that need to be exchanged as part of each business process. Each of these messages need to conform to the rules outlined in the EDI Spec for that transaction set and version.

ediFabric allows you to quickly establish if a message is valid or not, and provides you with the exact position and reason of any inaccuracies. To determine this it uses our custom validation attributes to check for mandatory items, too many or too few repetitions and the correct length, data type or EDI code for every data element.

A message is validated in isolation and not as part of a group or interchange. The validation does not detect duplicates, semantic discrepancies or issues with control segments. It purely validates that the format of the message adheres to its EDI Spec.

All elements in our EDI Specs can be annotated with validation attributes. Without them the spec can still be used for reading and writing but the validation functionality will not work. These attributes can be applied to the properties in the spec, just above the PosAttribute. To enable validation follow the rules below:

All mandatory items are annotated with RequiredAttribute

[Required]
[Pos(2)]
public BIG BIG { get; set; }

This attribute can be applied to any property.

To control the number of repetitions annotate lists with ListCountAttribute

[ListCount(100)]
[Pos(3)]
public List<NTE> NTE { get; set; }

The first parameter is the upper limit of how many items are allowed in the list.

You can also set the minimum limit if needed by using the constructor with two parameters. The first one is the minimum and the second one is the maximum.

This attribute should only be applied to properties of type List otherwise it will be discarded.

To control the length of data elements annotate them with StringLengthAttribute

[StringLength(1, 10)]
[Pos(1)]
public string NumberofIncludedSegments_01 { get; set; }

The first parameter is the lower limit of the string length.

The second parameter is the upper limit of the string length.

This attribute should only be applied to properties of type string otherwise it will be discarded.

To set the data type of data elements annotate them with DataElementAttribute

[DataElement("96", typeof(X12_AN))]
[Pos(1)]
public string NumberofIncludedSegments_01 { get; set; }

The first parameter is the EDI identifier of the data element.

The second parameter is the type of the data element.

This attribute should only be applied to properties of type string otherwise it will be discarded. If the referred type is annotated with EdiCodesAttribute, the data element value will be validated against the list of allowed EDI codes.

Combine the attributes

[Required]
[StringLength(1, 10)]
[DataElement("96", typeof(X12_AN))]
[Pos(1)]
public string NumberofIncludedSegments_01 { get; set; }

Combine attributes to apply multi validation to items.

Messages are validated by calling IsValid method of the base EdiMessage class. It will traverse the spec and check the real values against the validation attributes. The output is a comprehensive context containing the details of all failures if any.

Validate EDI object

MessageErrorContext errorContext;
var result = msg.IsValid(out errorContext);   

IsValid returns true or false and the error context will contain errors when IsValid is false.

You can validate EDI objects that were either read or created for writing. When the latter, use the SkipTrailer flag because the trailer wouldn't have been set at this stage. A structural validation is always applied to the message header and trailer segments to ensure they are valid.

Validate EDI object and skip trailer validation

var m810 = new TS810();
// construct the message ...
                                    
MessageErrorContext errorContext;
var result = m810.IsValid(out errorContext, true);   

The context gives you additional information such as the name and control number of the message, the error code for the failure reason and the collection of segment errors. The context represents a hierarchical structure with the message at the top, then drills a level down for a collection of segment errors grouped by segment and then another level down for data element errors per segment, grouped by the data element.

All error codes are the standard compliant codes used in EDI acknowledgments.

The error context will also contain configuration errors such as when the specs assembly cannot be found or if the required spec cannot be found. It will also report on duplicate specs being defined in the same assembly and any parsing errors.