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
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.
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.
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.
TED is always a source of inspiration and shows that not all people are putting monetary value upfront in what they do, but still doing research or look at complex dependencies from a different viewing angle. I dislike the way a lot of companies are hoarding data about me, my trails and patterns in the virtual world as well the attempt to track me down in the physical world too. Jer Thorp giving a talk at TEDx about visualisation which is quite interesting.
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, groundhandlingagents 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.
One of my favorite tools for evaluation, debugging and testing is virtualbox (link). I run it both Windows XP and Ubuntu as host and use it for Ubuntu, OpenSolaris, Fedorea, Suse and now with the latest Windows7 release candidate. We will start now testing our client applications on this release, which should be only servicepacks away from the final release version. Also check Netbeans and Glassfish.
Microsoft Windows7 RC (link) Runs fully until March (June 2010 with restrictions)