Brussels Airport Flightplanner is the official Brussels Airport iPhone and Android app. It's a valuable tool used to plan or track a flight. The app will map out a personal itinerary from your front door to the gate. You will receive updates through push notifications, browse the shopping, food and drinks listing for special promotions. You're able to find the cheapest parking rate with the parking widget or stay up-to-date with the actual waiting times at security or last minute gate changes. All essential info is just a finger swipe away.

We were appointed by Momads (Belgium), a creative mobile agency, creating and producing mobile apps and websites to build the backend for the mobile apps using Drupal.

[[{
"type" : "media",
"view_mode" : "teaser",
"fid" : "42",
"attributes" : {
"class" : "media-image",
"typeof" : "foaf:Image"
}
}]]

In the “back-office“ the application allows site managers and airport business owners to manage their data.

[[{
"type" : "media",
"view_mode" : "teaser",
"fid" : "43",
"attributes" : {
"class" : "media-image",
"typeof" : "foaf:Image"
}
}]]
[[{
"type" : "media",
"view_mode" : "teaser",
"fid" : "44",
"attributes" : {
"class" : "media-image",
"typeof" : "foaf:Image"
}
}]]

How it was built?

We used the power of Drupal 7 to generate and serve content for mobile devices. In fact Drupal was shaped to proxy, aggregate and normalize data coming from several sources, like: airport flight information software, airport parking system, weather data providers and Brussels public transportation feeds. This was the one side of the problem: Drupal as service consumer. On the other side there's Drupal as REST server, providing webservices to mobile devices.

Here's a logical scheme of how Brussels Airport Flightplanner application works.

[[{
"type" : "media",
"view_mode" : "teaser",
"fid" : "45",
"attributes" : {
"class" : "media-image",
"typeof" : "foaf:Image"
}
}]]

Consuming services

Data coming from airport system

Due to high restrictions on accessing the airport software API, finding a solution to import huge chunks of data into Drupal became a critical task. First of all, there was no access to the source data. That became a problem because flight information data is refreshing each 1-2 minutes bringing new records about flight delays, cancellations along with other news about checkin, security check gates and boarding changes. So, Drupal has to face this big amount of incoming data without losing the responsiveness and also without affecting in any way the airport system from where data is collected.

Finally, the decision was to dump the needed information in CSV files each 2 minutes. Each kind of information (flights, flight statuses, operational messages, waiting line) has their own CSV file and structure.

We tried first to use Migrate, this great Drupal data manipulation module. With Migrate we could create migrations that check each record timestamp and import only the fresh data but we weren't able to bypass the entire file if the CSV file timestamp was not changed. So, we took the decision to build our own import module to deal with this requirement: import only fresh data and keep the server loading on normal level.

Our custom import module was built with UI and also Drush support. The Drush support was critical in order to perform data import each 2 minutes in the production environment. Rich UI were built to define CSV data structure for each data source. Also the Drush command has been provided with tagging mechanism allowing to group import sources by frequencies. Finally, on production, several cronjobs are running the Drush command at different time intervals (the most often being 2 minutes).

This import is running for 1 year already and the client reported no problems, no bottlenecks and no load issues with the massive import of data into Drupal.

Weather, parking, public transportation

All are imported by consuming and parsing webservices from specific provides and then save all as Drupal objects (entities). Nothing special here.

Admin interfaces

On the website there are specific admin interfaces for managing other categories of content like shop, offers, deals, etc. All were built by using Drupal great content features (fields, views, etc).

Serving mobile devices

As I mentioned earlier, we turned the same Drupal instance into a REST Server by using the Services module. Mobile devices are consuming JSON data provided by Drupal and then parse all data within iPhone or Android apps.

Push notifications

There was a request for phones to receive push notifications about changes related to the flights they plan or track. We used a third party service provider: Urban Airship.

Here's a brief scheme, showing how we've implemented pushing of flight event notifications to mobile phones:

[[{
"type" : "media",
"view_mode" : "teaser",
"fid" : "46",
"attributes" : {
"class" : "media-image",
"typeof" : "foaf:Image"
}
}]]

Performance

Drupal is doing a good job by playing both roles: consumer and server for services. We did a lot of code and environment optimisation. The most critical part, as I mentioned before, was the import of flight data.

Our data module was mainly based on nodes with fields (Field API) so we were aware of the loading resulting from the MySQL joins. We installed Entity cache module and Memcache key-value cache store and (voilà!) node manipulation became an easy operation in terms of loading.

For very big quantity objects, like event messages (see Push Notifications), because in that case the cache has to be rebuild too often, we created our own entity type that uses a single table for its fields, making the query very fast and cheap.

Development constrains

Due to the nature of this project we had no access to the production and staging environment. The final client asked that all updates should be deployed programatically without accessing the shell, the database or the Drupal administration interface. All changes, including configurations or content, were deployed through code, via Git.

We tried first to use Features module but that was not a reliable solution. We end up by writing update scripts [hook_update_N()] for each configuration needed on production. The airport staff has only to git pull and then run drush updatedb.

Conclusions

This project was a challenge for us. First we thought that a single Drupal instance, playing both roles (importing and serving content) will not be enough to keep the all services on and reliable. The good planning and custom module design phase was the key to offload the system and make the application really rock.