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
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
DAS is a Lufthansa tool which holds flight information. It is required for these i[[LHG:Interface dependent use cases|nterface dependent use cases]] in SARA and Portals,
DAS is a Lufthansa tool which holds flight information. It is required for these i[[LHG:Interface dependent use cases|nterface dependent use cases]] in SARA and Portals,


== Contained data ==
== Usecase ==
We interested from DAS system with this information stream
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:


==== Dispatch data ====
* changes on aircraft
This holds for each planned flight
* changes on aircraft type
* delays
* status change (on plan / delayed / cancelled )


* status (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.
* delay time
* Operating craft
** type (e.g. Boing 747-8)
** tail code


== Planned interface approach ==
== Implementation ==
KORDEUS is building a KAFKAA interface, which subscribes to a '''"MOC/SARA" KAFKA Topic'''. Through this it which recieves messages of this type:
This is a two components concept


====== Operations updates ======
====== Bridge server digital (residing inside LH intranet) ======
This information containing all operations planning items (typically 1-2 weeks ahead of the flight), but also for adhoc travel informaiton
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 [[Dev:LHG DAS-Interface Technical description|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''.


* Departure date
====== LH Operation Center (MOC) digital ======
* Flight number
On the MOC side the
* Planned craft type
* Tailcode
* status (on plan / delayed / cancelled )
* delay time


== Solution ==
* DAS-Files containing the LH rotation planning are received through the SDC controller, if the trust relation on receiving side has ''Accept-DAS-information''
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
* 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
* 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.
* 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:
* detects, if any of the operational data of the relevant flights receive operations updates, which do not match the planned information.
** an update of the service delivery tree
** Relevant changes:
** (optionally) a task creation for MOC team
*** Plane change (Tailcode change) of an earlier assigned flight (chage from unplanned to planned is no change)
* Relevant changes are:
*** Departure information change
** Plane change (Tailcode change) of an earlier assigned flight (chage from unplanned to planned is no 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.
** Departure information change
** Passenger journey change


== 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"