AliTrip Tour Operations System
Complex Data Structures,
Integrated Workflow Automation,
Over 100 Connected APIs
A snippet of the database design of the system
To provide a seamless ordering experience for its customers, the operators had to manage the complexities of the products they were offering. We thought it through and created the most robust, sustainable database to tackle the situation.
Each product in the tourism industry can have many variations when it comes to both procurement and selling. The pricing and availability of rooms can differ by the time of inquiry and the purchase type (GIT, FIT, Free Sale). The process of calculating the selling price is different depending on the type of tour package (e.g. Shopping Tour, Free & Easy, etc.) as well. The types of products and services also include visa applications, MICE event bookings, sale of SIM cards, bookings of pre-/post-flight services, tour guide fees and tips, etc. Each of these has its own product structure, pricing rules and reporting rules. The system would need to work for future product types too.
Dr. Kelvyn Zhuang, our Senior System Architect, planned the database structure to allow for a flexible and scalable implementation of each product. The database structure allows entities to own other entities, items, and inventory of each item – each of which can have its own set of different properties – from purchase, redemption, usage and expiry dates, to promo codes, item description specifics and more. This also provided the ability for many types of APIs from many different vendors to be integrated at various levels of the system.
Static products were not the only challenges in complexity. Each vendor had a preferred workflow for the procurement and sale of each product as well. A task normally managed by an entire department. Replaced by our management system.
Each product from each vendor can have different workflows that are required. For example, RWS requires the final name list of groups that are staying in their rooms to be submitted 3 days before their stay. In another example, the ICA also has different deadlines for visa application depending on whether it is a group application or individual application. Hardcoding each workflow tied to specific products is not scalable, therefore we also created an internal workflow system.
Through various dashboards, the operators are able to view general statuses and details statuses on the preparedness of order deliveries. Each of these statuses are drawn from the completion of different workflows, which may include connecting with various external APIs. For example, if there are 10 attraction tickets to be booked for the order, only when all 10 are successfully booked, will the overall status be recognized as successful. Individual booking successes / failures can be viewed and manually adjusted if necessary. To help with external workflow, we also created APIs for vendors to connect to for accounts matching purposes.
The operators’ forms continuously grew in size and form. We designed a user experience that ensured maximum usability and utility for the customers and management alike.
The forms ranged from basic ones, to ones that could be pre-filled by operators and passed on to customers for final details, to even ones that contain more than 8000 fields in the case of a fully customizable itinerary.
There were 2 outstanding challenges –
- Performance intensive forms with many fields would typically crash a browser – special optimization was needed
- For each product (e.g. an attraction ticket), different types of information would have to be collected, e.g. physical ticket vs e-Ticket; self-print-out vs redemption at tour agency; tour guide redemption vs self-redemption
Ervin Kwan, our senior developer, lead a team of 3 developers to create three multi-page forms that passed over 8,000 data fields across the pages, while also developing a drag & drop-based itinerary builder based on that information. He worked closely with Dr. Kelvyn to build part of the API framework, optimizing the presentation of information between the API and the frontend.
Dr. Kelvyn also played an important role in developing an automatic form builder based on the conditions of purchase, and allowed operators to pre-fill information before sending it to the customer online to gather more information. The data from all the forms feed back into the central database that he created as well.
APIs were the first step to automating the business processes of AliTrip. Processing individual APIs from different vendors was the next step. We did that through creating an API management system.
Each vendor either has their own API, or has a specific way they would like to send or receive information. The information can come in a variety of formats, from AliTrip’s API to TaoBao’s API (written by different teams), from Excel files provided by tour agencies to individual PDF files (Klook). Some vendors prefer to not use APIs but perform redemptions directly from the system instead. Other vendors provided no APIs and required manual submissions through their systems.
To solve this, we created an API management system to issue each vendor and their various endpoints appropriate credentials. This relation allowed customized workflow with revisioning and logging to be defined for each API and resulted in a secure environment of accountability. Furthermore, we developed additional layers of “Simulated APIs” for vendors without APIs to achieve more holistic automation.
The lifespan of products in the tourism industry is too short and the quantity too limited to allow operators to realistically hold a large inventory. We stepped in to shorten response time for inventory checks to ensure that operators can give quotes with maximum confidence in procurement.
To allow operators to retrieve the most updated inventory while conforming to their SLA and security policies, many considerations had to be taken to build the infrastructure that holds the system’s backend. The difference in geographical proximity between the HQ in Singapore and China caused significant connection issues.
To achieve that, a part of the system is hosted in China, while another part is hosted in Singapore. The database is mirrored across geographical regions to achieve the best time response on each side, achieving a 2-second response time that AliTrip required for the most updated inventory checks.
Furthermore, we set up multiple levels of checks, including uptime checks, data integrity checks and bandwidth usage checks. Contingency plans were also created to handle any issues that might arise.
You can also reach us at hello@searix.net.