Spot Realtime SLA Breaches in Airline On-Boarding Process Using Striim

Post-COVID Travel plans have suddenly increased, and many people are visiting the places they had hoped to visit. The airway enables us to travel farther than we could otherwise go, and technology works in tandem with it to make travel easier. Due to increased travel and commuters, it is difficult to manage and track the passengers to ensure that the on-boarding procedures are followed during flight boarding. The onboarding process is ensured from the initial stage of airport check-in to the passenger boarding a corresponding flight by combining the efforts of hardware sensors and online message queueing systems. We’ll see how Striim and the message queueing system work together to capture, process, and change the status of passengers as they go through a stage-by-stage preprocessing process within a SLA set for each one.

Problem Statement 

As we all know, going through each stage to board a flight at an airport can be stressful. As shown in the image, there are typically five steps in the processing process: obtaining a boarding pass, bagging, security inspection, immigration inspection, and finally boarding. To prevent boarding or flight delays, all five of these processes should be finished within a SLA established for each phase. Internally, airport authorities use the message queueing system to populate each stage of the event, but the challenge would be to spot SLA breaches in real-time and report them to address the delay.

Process of Boarding at the Airport

The procedure would be monitored using MQ systems, where each step emits an event with the flight and passenger information. Finding the stage that exceeds the SLA required to pass a certain stage of checking is the challenge here. If any of the processes were to miss the SLA cut-off, the following effects would result.

1. Delaying the current flight and any subsequent flights
2. Panic among the passengers
3. Longer wait times.
4. A process could be missing.
5. There would be a security breach as a result.

The illustration below shows how MQ events are produced as passengers go through the airline’s onboarding procedure.

How does Striim contribute to process improvement?

Striim is a real-time replication tool that enables data streaming from a variety of source systems and aids in event migration to the target systems. Windowing technique is one of its key features, and it can hold data based on options like time, count, and fields to process on-the-fly. The best course of action in this situation is to hold/cache the event until the SAL/cut-off for the boarding process is determined. We can review the events that have occurred after the deadline to force the airport authorities to act right away from the cache. Assumedly, the events that are generated at each stage include the passenger’s boarding and flight information so that the specific passenger can be tracked throughout the boarding process.

Also Read: Use Cases for a Unified Data Integration and Streaming Platform like Striim

Striim Windowing Techniques

Real-time data is constrained within a window by time (for instance, five minutes), event count (for instance, 10,000 events), or both. The creation of a window is necessary for a replication flow to aggregate or process data, fill the dashboard, or send alerts when conditions deviate from expected ranges. An application can only evaluate and respond to individual events without a window to bind the data.

The three types of windows that Striim supports are sliding, jumping, and session windows. When a query’s contents change (sliding), expire (jumping), or there has been a lull in use activity, Windows sends data to the queries that follow (session). Jumping windows, which are regularly updated with an entirely new set of events, are the best fit for our use case out of these three types. Data sets for the hours of 8:00 am–8:04:59 am, 8:05 am–8:09 am, and so on would be produced, for instance, by a five-minute jumping window. A new data set would be produced by a 10,000-event jumping window after each 10,000 events. The window would output a new data set each time it accumulated 10,000 events or five minutes had passed since the previous data set was output if both five minutes and 10,000 events were specified. With the help of this Windows feature, we are putting forth an architecture that will both capture events coming from MQ systems and those that are approaching the cut-off time.

Proposed Architecture for the Airline On-Boarding System

With this suggested architecture, the airline onboarding processing can detect an SLA breach during passenger check-in for a flight with speed and accuracy. By storing the data in a designated window, it operates using the caching technique. The Striim partitioning feature enables us to classify every passenger according to their boarding pass number, allowing us to identify anyone having trouble during the flight. Striim’ s SQL-like queries are used to group and aggregate the events from jumping windows for each stage, from checking in to boarding flights.

CREATE OR REPLACE JUMPING WINDOW Boarding_Data_Window OVER admin.Boarding_Data_Win KEEP 2 ROWS WITHIN 90 SECOND PARTITION BY BoardingPassNo;

CREATE OR REPLACE CQ Passenger_Data_Boarding INSERT INTO admin.NotBoarded SELECT p.flightNo as flightNo, p.boardingPassNo as boardingPassNo , case when b.boardingPassNo is null then “Not Boarded” else “Boarded” END as BoardingStatus, b.boardingPassNo as bagBoardingPassNo FROM Boarding_Data_Window b right join PassengerDataWindow p on p.boardingPassNo = b.boardingPassNo;

CREATE OR REPLACE CQ NotBoarded INSERT INTO admin.NotBoardedResult SELECT * FROM NotBoarded n where BoardingStatus=”Not Boarded” group by n.boardingPassNo having count(*) <2 ;

Here are some benefits of using Striim as a replication tool in this scenario to record and modify SLA beaches during the flight boarding:

1. Real-time data collection that aids in processing the event at every stage.

2. Windowing the events until the designated interval to process and modify.

3. The dashboard and alerting system provides a nearly real-time progress of each passenger’s stages.

4. Quick fixes considerably shorter airport wait times and delays.

5. More accurate reporting.

An elaborate use case for Striim services: Striim-Powered Real-Time Data Integration of Core Banking System with Azure Synapse Analytics

Conclusion

The lengthy part of flying is waiting in line for the boarding process due to the densely populated airport. A more effective tracking system offers a practical way to track individual passengers for a comfortable journey. Using Striim’s windows technique, we can process and change airport authorities at any stage of the boarding process by holding every individual passenger detail in-memory directly from the real-time queuing system. Additionally, Striim aids in the migration of events to alternative target systems for better visual representations.

The Striim experts at Indium have cross-domain experience and can create solutions specifically for each of our clients’ individual needs.