Aviation API – Airline and Airport Webservices

The term API (Application programming interface) is not new, basically a defined access to a set of methods, subroutines and data-types made available by one component/service to be used/consumed by another component or application. You can think of API as the car manual and the library being the engine under the hood.

Since the early days of tinkering with the Windows DLL hell more than 20 years have passed, we have better tools and standards by now. In the space of native apps for Windows, Android and iOS we still work with libraries and SDK’s (still can be challenging when resolving dependencies and deployment).
In the world of web applications today we look mostly at RESTful Webservices responding in JSON or XML, a rather straight forward implementation, the only complexity depends on the authorization mode or the mapping of attributes. A lot of websites, portals, services or products expose their WS for usage by third parties, from Salesforce, Ebay, Amazon to Twitter and infinite more. While these mentioned samples operate independently or work as standalone services there is not much need for standardization of the payload, aka the structure of attributes, naming conventions etc. For others business domain there is a need of standardization of such, despite the availability of AIDX, AIDM and a few more data exchange models, there is no standard widely used in the (public) WS space in aviation.
I have to highlight in ACI ACRIS a Semantic Model is being actively developed and the Open API Shop exists as project as well.

I researched what webservices are currently offered to the public by airports and airlines, excluding the API’s of system vendors and travel platforms.
So far I found these webservices (last update 2018-07-06):

Airline

International Airline Group British Airways, Iberia, Avios	https://developer.iairgroup.com/
Lufthansa	https://developer.lufthansa.com/
Airfrance, KLM	https://developer.airfranceklm.com/
Alaska Air	https://developer.alaskaair.com/
Transavia	https://developer.transavia.com/
FlyDubai	https://developer.flydubai.com/
Virgin Australia	https://developer.virginaustralia.com/
Ryanair	https://developer.ryanair.com/
Turkish Airlines	https://developer.turkishairlines.com

Airports

Schiphol Airport	https://developer.schiphol.nl/
San Francisco Airport	https://www.flysfo.com/api
Frankfurt Airport	https://developer.fraport.de/
Svedavia Airports	https://apideveloper.swedavia.se/

Others

FAA US	https://app.swaggerhub.com/apis/FAA/ASWS/1.1.0
Flightaware	http://flightaware.com/commercial/flightxml

The usage terms and price models vary but basically all give some kind of developer access to evaluate the services and data at no cost.

To compare a few of the services using a flight status related call, omitting the authentication. The lack of standard, putting aside JSON response format and date format, is quite obvious. It might not be relevant in the space of individual apps to have the same response format, but if you want to combine data from various sources you have to handle the formats separately. Even the request format with the query parameter differs.

British Airways

https://api.ba.com/rest-v1/v1/flights;departureLocation=FRA;startTime=06:00;endTime=11:00

Swedavia Airports

https://api.swedavia.se/flightinfo/v2/query?filter=airport eq ‘ARN’ and scheduled eq ‘180713’ and flightType eq ‘A’ and flightId eq ‘DY4572’

Lufthansa

https://api.lufthansa.com/v1/operations/flightstatus/LH778/2018-07-13

I also tried with RyanAir (still waiting for approval to get api key), Turkish Airlines (no flight status API), Schiphol (no webservice test available on the website).

Image: Creative Commons, Robert Yarnall Richie Photograph Collection, “Models with Oldsmobile Automobile, Lockheed 10B Electra, Delta Air Lines, 1940”

Read My Boarding Pass App

In the previous blog post I discussed the underlying standards of the BCBP (Bar Coded Boarding Pass) following IATA Reso 792. Today I will built an Android mobile app that scans the PDF417 barcode and shows the raw content as well the decoded fields.

The are 3 main challenges for building the app, scanning/reading the barcode and decoding the text to individual attributes and as last, not to use any internet connection (to assure the user the users privacy and avoid any potential identity theft discussions)

As we build a native Android app we can rely on third party libraries to scan and decode barcodes. There is a number of commercial libraries in the market, but as I build a free app I will use the zxing-android-embedded library, which is a port of the ZXing (“Zebra Crossing”) barcode scanning library for Android with added embedding features, ZXing only provides the decoding logic. Both are licensed under Apache 2.0, ZXing can decode all the common types, such as EAN-8, EAN-13, UPC, ITF, PDF417, QRCode, Aztec, Data Matrix and a few more.

Integration Barcode Library ZXing

With the library the integration becomes as simple as adding a few lines of code only.

Add the dependency to the build gradle file

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
        exclude group: 'com.android.support', module: 'support-annotations'
    })
    compile 'com.android.support:appcompat-v7:25.3.1'
    compile 'com.android.support.constraint:constraint-layout:1.0.2'
    testCompile 'junit:junit:4.12'

    compile 'com.journeyapps:zxing-android-embedded:3.5.0'
}

Trigger the scan and read the result

public void scanCode(View view){
        new IntentIntegrator(this).initiateScan();
    }

    @Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        IntentResult result = IntentIntegrator.parseActivityResult(requestCode, resultCode, data);
        if(result != null) {
            if(result.getContents() == null) {
                System.out.println("Scan failed or cancelled.");
            } else {
                System.out.println(result.getContents());
            }
        } else {
            super.onActivityResult(requestCode, resultCode, data);
        }
    }

For now, the app (“ReadMyBoP – Read My Boarding Pass”) does nothing but scan the barcode, identify if it is a valid boarding pass barcode, display the raw content and makes the content more human-readable. You can download from Google Playstore. It works with Android 4.1 and above.
There is one extra feature for now, it decodes the IATA fare codes (First, business, economy classes and the various discounted codes, it follows IATA Reso 728 if you want to look for the complete codeset.

Decoding the Raw Text

Given the fact, this is a fixed-length field text, it is no big deal to split the relevant info by substring’ing it using the decoding table that we started in the previous post. As basic validation we can use the mandatory “M” on position 1 and a length of not less than 59 characters (mandatory fields).

#	Element	Mandatory	Size	Sample	Remark
1	Format Code	M	1	M	Always “M”
2	Number of legs encoded	M	1
3	Passenger Name	M	20
4	Electronic Ticket Indicator	M	2	E
5	Operating carrier PNR Code	M	7
6	Origin IATA Code	M	3	FRA	Airport Code
7	Destination IATA Code	M	3	SIN	Airport Code
8	Operating carrier IATA Code	M	3	LH	Airline
9	Flight Number	M	5	3456
10	Date of Flight	M	3	280	Julian Date
11	Compartment Code	M	1	B	First, Business, Economy
12	Seat Number	M	4	25A
13	Check-in Sequence Number	M	5	0012
14	Passenger Status	M	1	00
15	Size of optional Block	M	2	5D	hexadecimal
16	Start Version Number		1	>	Always “>”
17	Version Number		1	5
18	Field Size of follow ing structured message		2
19	Passenger Description		1
20	Source of check-in		1
21	Source of Boarding Pass Issuance		1
22	Date of Issue of Boarding Pass (Julian Date)		4
23	Document Type		1
24	Airline Designator of boarding pass issuer		3
25	Baggage Tag Licence Plate Number 1		13
26	Baggage Tag Licence Plate Number 2		13
27	Baggage Tag Licence Plate Number 3		13
28	Field Size of follow ing structured message		2
29	Airline Numeric Code		3
30	Document Form/Serial Number		10

Is there a roadmap ? For sure, if I find the time I will add the optional fields, an airline and airport code dictionary (must check the size of a local sqllite db if we want to stay offline). Maybe add baggage tag reader feature and local barcode image storage for boarding. Stay tuned !

Application Disclaimer: The application is for educational and research purpose. It is provided as-is, no warranty included. It does not transmit data over the internet and does not store any data upon exiting the app.

What’s in my boarding pass barcode ?

Since more than 10 years passengers are used to the barcode imprinted on the traditional ticket boarding pass slip, the home printed boarding pass or the boarding pass displayed in the mobile app provided by the airline. To be more precise the 2004 IATA Passenger Service Conference approved Resolution 792 setting the BCBP (Bar Coded Boarding Pass) standard as part of the STB (Simplify The Business) program.

The barcode simplifies passenger handling as the barcode can be read automatically by barcode readers along the passenger journey for bag-drop, security check area access and boarding. It significantly reduces the error rate to the time before barcode and eventually saved millions of Euros/Dollars due to mishandling and delays. Today we see self-boarding gates that remove the need for an agent, though business and first class passenger are still welcomed by a human gate agent. Btw, the magnetic stripe on the back of the old tickets expired in 2010.

Old Passenger Ticket without barcode (Image Public Domain)

The BCBP standard defines PDF417 (public domain standard, no fees or licenses) as the barcode symbol format as well defines the encoded content. The content in the barcode contains the same information as printed on the standard boarding pass, though some airlines omit information on the self-printed version in favor of simplicity, some extra info is optionally encoded.

Sample PDF 417 barcode

M1SMITH/JOHN          EHJK345 FRASINLH 3456 280C015A0001 100

The standard covers 3 additional barcodes that are not used for printing, but used for mobile apps, these are Aztec and QR Code.

The encoding is straight foward using fix-length fields and the code can carry up to 4 legs of a journey.

Element	Size	Sample	Remark
Format Code	1	M	Always “M”
Number of legs encoded	1	1
Passenger Name	20
Electronic Ticket Indicator	2	E
Operating carrier PNR Code	7
Origin IATA Code	3	FRA	Airport Code
Destination IATA Code	3	SIN	Airport Code
Operating carrier IATA Code	3	LH	Airline
Flight Number	5	3456
Date of Flight	3	280	Julian Date
Compartment Code	1	B	First, Business, Economy
Seat Number	4	25A
Check-in Sequence Number	5	0012
Passenger Status	1	00

These are the mandatory fields, there are additional optional fields and blocks for baggage info, document info, frequent flyer number or security data.

To be noted, the IATA PADIS XML message standard shall be used for the exchange of BCBP data between systems, defined in Resolution 783 – Passenger and Airport Data Interchange Standards.

I like to add also, the printed barcode is the current common nominator for international travel, but there are initiatives on the way to simplify the passenger journey even further with newer technology such as biometric ID’s and identity management, eg. IATA OneIdentity Initiative.

In the next post we will assemble a simple Android application to read the boarding pass barcode. Stay tuned.

Disclaimer: The information provided here might not be correct or complete. It is for educational purpose only. For reliable information please refer to the IATA manuals.

Online IATA Telex Processor

I launched a first version of a Telex processor with a web frontend. It is a beta version and currently only processes MVT standard messages.

Some words about the requirements for a flexible interface processor

• Though IATA Telexes are defined by a standard, variations are common because some are produced automatically by other systems and some are created manually, which causes more errors. The processing of telexes, the pattern recognition, must be flexible enough to be able to handle extra inline whitespaces and dots, as well extra lines with free text or extra headers and trailer, eg. now it is more common to receive telexes via email and often some extra email information is added as header before it reaches your system. Customers also might create their own telex standards, meaning the whole message is transported as free text message, but inside the message the customer uses his own syntax for data transmission.
  This requires a message interpreter that can be configured for new or non-standard formats on the fly, without the need to change any sourcecode and to redeploy a system.
  (I saw a project at one airport where the change of LDM format interpretation would have cost the customer around 10.000 Euro because one of the cargo airlines send messages with an extra header line)
• Other standard messages, such as AFTN, NOTAM or CFMU should be processed by the same engine using the same approach. One interface engine with the flexibility of the scripts covers the various aspects of the different types.

A few words about concept and architecture

• ESB
  Certainly the word ESB sometimes might appear bloated like other IT buzzwords, but it hardly makes sense today to implement distinct own interface systems for every protocol or subsystem type you come across. In a heterogeneous IT landscape like an airport an ESB allows you to easily connect inbound and outbound to a number of other systems via TCPIP, Email, FTP,.. or even talk to other standard systems like SAP, Salesforce.com and so on. We use one connector to talk to the ESB, the rest we orchestrate in the ESB itself. With MULE ESB we have the freedom of an opensource product as well the power of enterprise support. The learning curve for MULE is not too steep.
  For the sample of telexes: Sometimes you ‘receive’ telexes by using the auto export function of the Sitatex application and retrieve the files with the messages via FTP, or you receive the messages as email or via a queuing server from a central corporate entrypoint. We can swing over to another source or run in parallel without touching the main system.
• Script Engine
  Instead of hardcoding the various formats, we use a Java Script engine executing Groovy Scripts. These scripts, one for each message type, are stored in the DB and can be adjusted or customized easily. The scripts produce an internal XML formatted standard output which easily can be un-marshalled during the downstream processing using proper XSD.
• Data Processing
  Whatever requirements you have how to handle the received data. In our sample system here, receive from the web frontend and make it human readable.

Please feel free to drop by http://xxxxx (currently not available, apologies) and try by yourself. Please note: Do not process confidential as the data is transmitted unsecured and might be stored (to improve the quality). This is NOT a commercial offering but a technology showcase. There is no warranty that the server is available or the processor correct. You can use the example message and modify it, otherwise copy and paste your own message.

The service is currently running on a Amazon EC2 micro instance, performance might decrease with a lot of traffic.

Online Telex Processor

Outlook

• Summary for errors and rejected messages.
• For the next versions I will add some of the other available telex types will follow such as LDM and CPM.
• Add AFTN message interpretation.
• Email Reply (send an email to the service and the human readable version is emailed back to the user).

IATA Telex Types Definition

 

Updates about the online telex processor here

Last update of the list: 2018-08-12

Working in the airport IT industry you are always challenged with integration tasks at each airport. Usually you face a heterogeneous landscape of home-brew or taylored solutions and standard software running on anything from mainframe to virtual instances in a private clouds. Using an ESB we can tackle a lot of interfacing work and focus on the data integration part. One interface that you will find on all airports that operate commercial flights, is a link to the SITA network to send and receive IATA Telexes.

It is hard to find any information online, so I summarised the available message types here. Btw, these telex types are often referred to as SITA Telex types, which is not correct, IATA (Air Transport Association) defines the available telex types and SITA is operating the network to distribute the messages between airlines, airports, ATC, groundhandling agents and other relevant members of the airport community.

This list should be almost complete, giving you the type, the description and the AHM (Airport Handling Manual) or RP (Recommended Practice) reference. The AHM that you can purchase from IATA gives you all the syntax and details for most of the available types.

Find more info about baggage messaging here: IATA Type B Bag Messages and Baggage Messaging Refresher

 

MVT	AIRCRAFT MOVEMENT MESSAGE	IATA AHM 780
LDM	LOAD MESSAGE	IATA AHM 583
PTM	PASSENGER TRANSFER MESSAGE	IATA RP 1718
PSM	PASSENGER SERVICE MESSAGE	IATA RP 1715
DIV	AIRCRAFT DIVERSION MESSAGE	IATA AHM 781
BSM	BAGGAGE SERVICE MESSAGES	IATA RP 1745
CPM	CONTAINER/PALLET DISTRIBUTION MESSAGE	IATA AHM 587
UCM	ULD CONTROL MESSAGE	IATA AHM 388
SCM	ULD STOCK CHECK MESSAGE	IATA AHM 385
SLS	STATISTICAL LOAD SUMMARY	IATA AHM 588
ASM	ADHOC SCHEDULED MESSAGE	IATA AHM 785
PAL	PASSENGER ASSISTANCE LIST	IATA RP1707b, 1708
LPM	LOAD PLANNING MESSAGE	IATA AHM 580
ALI	ABBREVIATED LOAD INFORMATION MESSAGE	IATA AHM 584
SOM	SEATS OCCUPIED MESSAGE	IATA RP 1712
SPM	SEATS PROTECTED MESSAGE	IATA RP 1711
PIL	PASSENGER INFORMATION LIST	IATA RP 1716
TPM	TELETYPE PASSENGER MANIFEST	IATA RP 1717
RQL	REQUEST LIST MESSAGE	IATA RP 1709
PNL	PASSENGER NAME LIST	IATA RP 1708
PRL	PASSENGER RECONCILE LIST	IATA RP 1719b
PNL	FREQUENT TRAVELLER LIST	IATA RP 1719a
PFS	PASSENGER FINAL SALES MESSAGE	IATA RP 1719
IDM	INDUSTRY DISCOUNT MESSAGE	IATA RP 1714
ASL	ADDITIONS AND DELETIONS LIST	IATA RP 1708
SAL	SEATS AVAILABLE LIST	IATA RP 1713
RQM	REQUEST INFORMATION MESSAGE	IATA AHM 783
UWS	ULD/BULK LOAD WEIGHT SIGNAL	IATA AHM 581
FMM	FUEL MONITORING MESSAGE	IATA AHM 782

Disclaimer: The list might not be correct or complete. It is for educational purpose only. For reliable information please refer to the IATA manuals.

MVT, LDM, PTM, TPM, CPM, PSM, UCM are among the most common telexes from my experience. If you implement a telex interpreter you definitely need to implement these types first.