TABLE OF CONTENTS

• Introduction
• The form for setting up Validation
• Adding a new Validation Rule
• An example to see how it works in "real life"
• The result from running the Upload and Download

Introduction

The filter feature can be used to limit the data uploaded, but the Validation feature can ensure that certain quality aspects of the filtered data is monitored and acted upon for both upload and download. 

In short: By setting up validations for an IEA, you can safeguard against "undesired" data being transferred.  
There you can specify the following for both sender and receiver:

• The condition for the validation, expressed as a formula, that evaluates to True (pass) of False
• The message you want the user to see if triggered (False result in formula)
• If it should result in a warning in log or if the upload/download should stop (and be marked as "failed")
• Any number of such validations can be made for anIEA

The form for setting up Validation

If you are a representative for the IEA, you can press the "pen icon", and this form will open:

Pressing the "pen icon" opens the form below for editing Validations.

Item	Description
1	Select which "direction" (tab) you wish to make validations for (Sender/Receiver). Note: You will only be able to define the side(s) you have access to here - i.e. you will not be able to change the receiver's validations if you are sender and vice versa.
2	Button for adding a new validation (resulting in new row in grid (5)). See next section for more information on the form.
3	Search "box" for filtering the rows in grid.
4	See separate article for more info on the Common Grid Features.
5	These are the columns in the grid (but can be customized by user): Planning Object Type: The type of planning object you are setting up validation for.Name: The (short) name you choose to give the Validation. Formula: The formula to be evaluated in order to determine if Validation is violated or not. If evaluated result is True, this means "Validation passed", and False consequently means "Validation failed". Stop Transfer: Yes if transfer is stopped, No if only warning given. Message: The message to inform user about the cause of the validation breach. If you wish to edit or delete a row, you must press the "three dot"-menu at the right of each row:
6	"Save"-button to save the changes (if any) to validations.

Adding a new Validation Rule

When pressing the "New Rule"-button, this form is seen:

The form for defining a Validation Rule.

An example to see how it works in "real life"

In the following example we will look at validations for an IEA having a Safran to Safran transfer.

The Safran schedule being uploaded where we have missing dates (1) and a blank calendar (2)

Our goal here is to warn on upload if there are missing dates (both Start and Finish are blank - (1)), as well as warning if there are any activities having a "blank calendar" (2). We then want to stop the download if there are any missing dates.

This is how we set up the Sender rules to achieve this:

The Sender rules warning about blank dates and blank calendar in Safran.

The formula for checking the dates is:

EarlyStart != Null && EarlyFinish != Null

The formula for checking if calendar is blank is a Safran specific construction that needs a bit of explaining:

For Safran, IDE automatically assigns a "synthetic calendar" with 24/7 work pattern to any activity having a blank calendar. This is the reason:

Safran will internally handle such a case as a 24/7 calendar, but we need to make this explicit to the receiving schedule, so therefore we assign this "synthetic calendar" called "_ILAP_24/7" in these cases. That is why the formula will look like this:

calendar.ToString() != "_ILAP_24/7"

NOTE: In reality it would be natural to not just warn about these 2 rules on upload, but actually set "Stop Transfer" to "Yes" - making the entire upload fail. The reason for having "Stop Transfer" to "No" is simply to demonstrate the effect of "Receiving rules"...otherwise we would never get to the download part of the transfer. 

The rule of thumb for validations is:
"It is better to catch a problem near the source where the sender can correct it, than to have it cause problems downstream".

This is how we set up the Receiver rules to achieve this (same validation formula as for upload):The Receiver rules stopping blank dates from being downloaded (the formula would work for any receiving Host system).

The result from running the Upload and Download

When running the upload we see this log (warnings only):

Two warnings shown on upload due to Validation violations.

And when running the download we see this log (validation stops the download):

Running download stops due to Validation violation.