LHG:DAS Interface: Difference between revisions

From Kordeus Wiki
Jump to navigation Jump to search
← Older edit
VisualWikitext
Stefanseiler (talk | contribs)
Bureaucrats, dev-team, developer, Interface administrators, iroc-team, Suppressors, Administrators, yousee-team
1,381 edits
Stefanseiler (talk | contribs)
Bureaucrats, dev-team, developer, Interface administrators, iroc-team, Suppressors, Administrators, yousee-team
1,381 edits
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 11: Line 11:
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.
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 ==
== Implementation ==
We interested from DAS system with this information stream, for each planned flight:
This is a two components concept


* status (on plan / delayed / cancelled )
====== Bridge server digital (residing inside LH intranet) ======
* delay time
On the Bridge Server Digital:
* Operating craft
* We implement an indexed local data cache (LDC controller) which consists of a set of files. For each day, we have one file. The [[Dev:LHG DAS-Interface Technical description|DAS-Files adhere to this structure]].
** type (e.g. Boing 747-8)
* We implement a proprietary service which constantly receives update messages from the KAFKA Topic and stores it in local files.
** tail code
* We implement a Shared Data Cache controller (indexed: per day), which shares the DAS-Files to any digital (e.g. LH MOC Digital) where an adequate trust relation exists
* Required trust on sending side has TCI ''Share-DAS-information''.


== Planned interface approach ==
====== LH Operation Center (MOC) digital ======
KORDEUS is building a KAFKA interface, which subscribes to a '''"MOC/SARA" KAFKA Topic'''. Through this it which recieves messages of this type:
On the MOC side the


====== Operations updates ======
* DAS-Files containing the LH rotation planning are received through the SDC controller, if the trust relation on receiving side has ''Accept-DAS-information''
This information containing all operations planning items (typically 1-2 weeks ahead of the flight), but also for adhoc travel informaiton


* Departure date
* MOC digital builds a local data cache (LDC) with list of relevant flights (departure date, flight number, planned departure data) which bear future flights with passengers with SAR-Requests on it
* Flight number
* 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:
* Planned craft type
** an update of the service delivery tree
* Tailcode
** (optionally) a task creation for MOC team
* status (on plan / delayed / cancelled )
* Relevant changes are:
* delay time
** Plane change (Tailcode change) of an earlier assigned flight (chage from unplanned to planned is no change)
 
** Departure information change
== Solution ==
** Passenger journey change
On the bridge server, the interface ''':'''
 
* recieves from SARA 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
* reads all the operations messages and builds a local cache with all future flights on it. Information older than one day will be deleted. This local cache can be queries by SARA at any time through an LAN-api.
* detects, if any of the operational data of the relevant flights receive operations updates, which do not match the planned information.
** Relevant changes:
*** Plane change (Tailcode change) of an earlier assigned flight (chage from unplanned to planned is no change)
*** Departure information change
** If this happens sends an MT-message to '''LH MOC digital''' that an operational flight change has occured providing the new operational information. Once received, this may trigger a task creation.


== See also ==
== See also ==

Latest revision as of 12:43, 23 December 2025

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.

Implementation

This is a two components concept

Bridge server digital (residing inside LH intranet)

On the Bridge Server Digital:

  • We implement an indexed local data cache (LDC controller) 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 stores it in local files.
  • We implement a Shared Data Cache controller (indexed: per day), which shares the DAS-Files to any digital (e.g. LH MOC Digital) where an adequate trust relation exists
  • Required trust on sending side has TCI Share-DAS-information.
LH Operation Center (MOC) digital

On the MOC side the

  • DAS-Files containing the LH rotation planning are received through the SDC controller, if the trust relation on receiving side has Accept-DAS-information
  • MOC digital builds a local data cache (LDC) 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

Retrieved from "https://wiki.kordeus.com/index.php?title=LHG:DAS_Interface&oldid=2931"