TABLE OF CONTENTS

• Introduction
• What Can ILAP Data Exchange Transfer
• ILAP Data Exchange Conceptual Overview
  • Connector 
  • Template
  • Config
  • IEA (ILAP Exchange Agreement)
• Key Roles and Terms in IEAValue Transformation & Why you may need it

Introduction

This article introduces the core building blocks of the ILAP Data Exchange (IDE) and explains how they work together to enable seamless schedule and planning data transfers between systems. Together, the connector, template, config, and exchange agreement form an integrated system that drives the entire process. By understanding these elements, users can better navigate and implement data transfers with accuracy and confidence.

What Can ILAP Data Exchange Transfer

ILAP Data Exchange transfers not only the essential schedule data—referred to as Core Terms—but also additional, customizable information known as ILAP Terms.

Core Terms

Core Terms are the foundational data fields like ActivityID, Description, Start Date, Finish Date, and % Complete. Since these values are fundamental to any schedule, they are automatically part of every transfer—regardless of how the rest of the transfer is set up.

ILAP Terms  

ILAP Terms provide additional flexibility by allowing the inclusion of extra schedule-related data tailored to specific project or organizational needs. Examples include Area, Discipline, Phase, and other user-defined fields.

Content control of ILAP Term at different levels

Unlike Core Terms, ILAP Terms are optional and fully configurable. They are managed by System Admins (the Global list of ILAP Terms) or Tenant Admins (for tenant specific ones), and are also subject to content control rules. This helps enforce consistency, validate field values, and ensure that only acceptable data is transferred between systems.

ILAP Data Exchange Conceptual Overview

The building blocks of ILAP Data Exchange (IDE)—Connector, Template, Config, IEA, and the roles of Owner and Partner—form a structured framework for executing reliable, repeatable schedule data transfers. Let’s take a closer look at what each building block does and how they work together.

Overview of the building blocks

Connector 

A Connector is responsible for linking the IDE to data systems, such as a Safran Database. It retrieves schedules and user field definitions necessary for data transfer. It defines the location where a host system stores its data, including authentication information. Connectors use APIs to access planning data stored in databases or file locations. Read here to find out more about connector.

Template

Template acts as a blueprint outlining the data elements to be transferred. It includes a list of information that is included in transfers and defines what will be transferred in addition to Core Terms. Users can choose from the defined ILAP Terms (e.g., Area, Discipline, Phase). The principle of "create once, use many times" ensures that Templates are created once and can be used multiple times. Core Terms (e.g., Description, Start, Finish) are always transferred. Additionally, Templates are shared between tenants, allowing for consistent data transfer across different system. Checkout this to learn more about templates.

Config

Config connects template to the appropriate schedules in the connector, detailing where the requested schedule information is located. If the schedules (e.g., Safran Schedules) have uniform user fields, one Config suffices; otherwise, multiple configurations may be necessary. It designates whether the configuration is for sending or receiving and applies direct mapping wherever possible (e.g., mapping Discipline to R3). More about configs click here.

IEA (ILAP Exchange Agreement)

An ILAP exchange agreement (IEA) enables the scheduled transfer of planning data between actors and across different scheduling systems. It is created by the Owner, who invites a Partner and determines the roles of Sender and Receiver. The Owner selects the appropriate Connector and Template, specifies the Schedule ID, Start/Finish parameters, and transfer Frequency. The agreement is finalized with signatures from both parties, triggering the automated creation of transfer events in the executing component. Learn more about IEA from click here. 

Key Roles and Terms in IEA

• Owner: Has the necessary privileges to create an IEA. They invite the Partner for schedule data exchange.
• Partner: Participates in the IEA when invited, regardless of also holding Owner privileges.
• Sender: Responsible for sending schedule data when the IEA is executed. This role is assigned by the Owner.
• Receiver: Responsible for receiving data upon execution of the IEA. Owner of IEA decides this role
• Upload: The Sender's executing component uploads schedule data from the scheduling system to the ILAP Data Exchange. 
• Download: The Receiver's executing component downloads the data from IDE to the host system, ensuring complete importation of schedule and data.
• More definitions can be found from Glossary. 

Value Transformation & Why you may need it

There may be cases where the Template enforces strict value constraints on specific ILAP Terms, allowing only predefined values during data transfers. When incoming data contains an invalid or unexpected value, value transformation is applied to map it to an acceptable equivalent.

For example, the Template might require that the ILAP Term "Discipline" accept only the following valid codes:

• E – Electro
• I – Instrument
• T – Telecom

How value transformation can help transferring data.

If a Safran Schedule contains a non-compliant value—such as "J" in the field R3—a transformation rule is applied to convert it to a valid code (e.g., "J" → "I"), as defined by the content control in the config. This ensures that all transferred data complies with the expected standards and can be correctly interpreted by the receiving system.