LHG:DAS Interface

From Kordeus Wiki
Jump to navigation Jump to search

DAS is a Lufthansa tool which holds flight information. It is required for these interface dependent use cases in SARA and Portals,

Usecase

Lufthansa MOC team needs to be notified by our SARA system as fast as possible on certain changes relevant to PAX. Currently the team is checking on a regular (daily) basis if any relevant flights have changed which transport passengers. Relevant changes are:

  • changes on aircraft
  • changes on aircraft type
  • delays
  • status change (on plan / delayed / cancelled )

So we would like to listen to DAS over Kafka to receive all changes and select from the stream messages, which affect passengers with special assistance requests being filed.

Contained data in DAS

We interested from DAS system with this information stream, for each planned flight:

  • status (on plan / delayed / cancelled )
  • delay time
  • Operating craft
    • type (e.g. Boing 747-8)
    • tail code

Planned interface approach

KORDEUS is building a KAFKA interface, which subscribes to a "MOC/SARA" KAFKA Topic. Through this it which recieves messages of this type:

Operations updates

This information containing all operations planning items (typically 1-2 weeks ahead of the flight), but also for adhoc travel informaiton

  • Departure date
  • Flight number
  • Planned craft type
  • Tailcode
  • status (on plan / delayed / cancelled )
  • delay time

Implementation

  • On the Bridge Digitals side
    • We implement an indexed local business cache which consists of a set of files. For each day, we have one file. The DAS-Files adhere to this structure.
    • We implement a proprietary service which constantly receives update messages from the KAFKA Topic and updates the Local DAS Cache (files)
    • We implement a Shared Data Cache controller (indexed: per day), which shares these files to any digital (e.g. LH MOC Digital), to which a trust relation is established with the TCI "Send DAS information" and "Accept DAS information"
  • On the MOC side this SDC is received holding the entire known rotation planning:
    • MOC digital builds a shared cache with list of relevant flights (departure date, flight number, planned departure data) which bear future flights with passengers with SAR-Requests on it
    • A background service detects relevant changes to the flight planning, whenever the shared cache (rotation planning) or the local cache (with flights with SAR on them) is updated and triggers:
      • an update of the service delivery tree
      • (optionally) a task creation for MOC team
    • Relevant changes are:
      • Plane change (Tailcode change) of an earlier assigned flight (chage from unplanned to planned is no change)
      • Departure information change
      • Passenger journey change

See also