
State Model
To enforce a specific workflow, the eADF has a predefined, but customizable, state model. Each flight can have the following states:
- When it’s created by the IOP service.
- When the user edits the flight.
- When the user finishes the edit.
- In case there is an error.
- When the Civil Aviation Authority (CAA) user approves the flight.
- Exported to the billing system.
Each state transition can be made by a specific group of users (airline employee, handler, civil aviation authority employee).
Robust
eADF uses the following technologies:
- Microsoft SQL Server or Oracle RDBMS
- Spring Framework
- Apache Tomcat
- Apache HTTP Server
Logging
The system holds detailed log for every significant event such as database CRUD operations, logins, data export from UI etc.



Data export
All arrival and departure data can be exported through the web UI in various formats such as XML, JSON, Excel or delimited text. A complex filtering mechanism is also provided to reduce the exported data.
Messaging
eADF provides two kinds of messages:
- Flight related messages. eADF users can exchange messages regarding a flight. These messages are visible on the flight admin screen.
- System related messages. Created by the admin to notify the users in case of an upgrade, downtime etc.
Contracts & Reporting
- Contracts between the airport and the main airlines can be handled through eADF. Service lines, attachments, price lists and related contacts are some of the detailed entities that can help you manage the business.
- eADF has out of the box models for the most popular BI systems such as Qlik View and Microsoft Power BI.
