funnel.travel has always had a mechanism to check that fundamental data fields are properly populated. These are:
- Participants
- Providers (aka vendors)
- Destinations
The participant check is redundant if the account is set up to use an external profile system (see e.g. Integrating Umbrella Faces), and is automatically disabled with such a configuration.
False positives
Recently, a funnel.travel customer started adding quite a few manual hotel segments in Amadeus. These segments are quite flexible, or in software-development terms, a nightmare. The list of quality issues with “unknown destination” quickly grew, change was needed. Interestingly, for the data stream this specific customer had set up in funnel.travel, the destination of the hotel segments was irrelevant.
Extensions, extensions, extension
It seemed obvious once the idea was out there: the quality check should not be part of core funnel.travel at all! So welcome the newest extension, which runs a simple check for participants, providers and destinations, and marks the booking if something is amiss. Now, each funnel.travel customer can choose whether or not to run these checks at all, and on the extension itself can toggle each check individually.
The destination check even discerns between transport destinations (flight, train, bus) and stay destinations (hotel). Sometimes, the former are relevant but the latter are not.
On a personal note: I really enjoyed the thrill of experiencing this architectural validation. It was very easy to remove the quality checks from funnel.travel core, and the new “Trip quality checks” extension was written in a few hours. The fact that this refactoring was so straight-forward, backed by over 1’000 automated tests, was a nice validation of the overall solution architecture.
In the process of developing funnel.travel, a corporate post-booking travel management tool, I’m sharing some hopefully useful insights into Angular 8, Spring Boot, jOOQ, or any other technology we’ll be using.
funnel.travel 