LHG:DAS Interface - Revision history

Stefanseiler at 12:43, 23 December 2025

2025-12-23T12:43:33Z

← Older revision		Revision as of 12:43, 23 December 2025
Line 10:		Line 10:

	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 ==~~
	~~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 ==		== Implementation ==

Stefanseiler: /* Implementation */

2025-12-23T12:43:20Z

Implementation

← Older revision		Revision as of 12:43, 23 December 2025
Line 38:		Line 38:
	====== Bridge server digital (residing inside LH intranet) ======		====== Bridge server digital (residing inside LH intranet) ======
	On the Bridge Server Digital:		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:~~LBC~~ DAS-Interface\|DAS-Files adhere to this structure]].		* 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 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		* 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

Stefanseiler: /* Implementation */

2025-12-23T12:40:53Z

Implementation

← Older revision		Revision as of 12:40, 23 December 2025
Line 34:		Line 34:

	== Implementation ==		== Implementation ==
			This is a two components concept

	* On the Bridge ~~Digitals side~~		====== Bridge server digital (residing inside LH intranet) ======
	** We implement an indexed local ~~business~~ cache which consists of a set of files. For each day, we have one file. The [[Dev:LBC DAS-Interface\|DAS-Files adhere to this structure]].		On the Bridge Server Digital:
	** We implement a proprietary service which constantly receives update messages from the KAFKA Topic and ~~updates the [[Dev:LBC DAS-Interface\|Local DAS Cache (~~files~~)]]~~		* 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:LBC DAS-Interface\|DAS-Files adhere to this structure]].
	** 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"~~		* We implement a proprietary service which constantly receives update messages from the KAFKA Topic and stores it in local files.
	* On the MOC side ~~this SDC is received holding~~ the ~~entire known~~ rotation planning:		* 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
	** 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		* Required trust on sending side has TCI ''Share-DAS-information''.
	** 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		====== LH Operation Center (MOC) digital ======
	*** (optionally) a task creation for MOC team		On the MOC side the
	** Relevant changes are:
	*** Plane change (Tailcode change) of an earlier assigned flight (chage from unplanned to planned is no change)		* DAS-Files containing the LH rotation planning are received through the SDC controller, if the trust relation on receiving side has ''Accept-DAS-information''
	*** Departure information change
	*** Passenger journey change		* 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 ==		== See also ==

Stefanseiler: /* Implementation */

2025-12-23T11:56:31Z

Implementation

← Older revision		Revision as of 11:56, 23 December 2025
Line 35:		Line 35:
	== Implementation ==		== Implementation ==

	* We implement an indexed local business cache which consists of a set of files. For each day, we have one file. The [[Dev:LBC DAS-Interface\|DAS-Files adhere to this structure]].		* On the Bridge Digitals side
	* We implement a proprietary service which constantly receives update messages from the KAFKA Topic and updates the [[Dev:LBC DAS-Interface\|Local DAS Cache (files)]]		** We implement an indexed local business cache which consists of a set of files. For each day, we have one file. The [[Dev:LBC DAS-Interface\|DAS-Files adhere to this structure]].
	* 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"		** We implement a proprietary service which constantly receives update messages from the KAFKA Topic and updates the [[Dev:LBC DAS-Interface\|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:		* 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		** 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

Stefanseiler: /* Operations updates */

2025-12-23T11:56:10Z

Operations updates

← Older revision		Revision as of 11:56, 23 December 2025
Line 33:		Line 33:
	* delay time		* delay time

	== ~~Solution~~ ==		== Implementation ==
	~~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		* We implement an indexed local business cache which consists of a set of files. For each day, we have one file. The [[Dev:LBC DAS-Interface\|DAS-Files adhere to this structure]].
	* ~~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.~~		* We implement a proprietary service which constantly receives update messages from the KAFKA Topic and updates the [[Dev:LBC DAS-Interface\|Local DAS Cache (files)]]
	* ~~detects, if any~~ of the ~~operational data of the relevant flights receive operations updates, which do not match the planned information.~~		* 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"
	** Relevant changes:		* 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)		*** Plane change (Tailcode change) of an earlier assigned flight (chage from unplanned to planned is no change)
	*** Departure information 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.~~		*** Passenger journey change

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

Stefanseiler: /* Usecase */

2025-11-28T12:51:53Z

Usecase

← Older revision		Revision as of 12:51, 28 November 2025
Line 2:		Line 2:

	== Usecase ==		== Usecase ==
	Lufthansa MOC team needs to be notified by our SARA system as fast as possible. Currently the team is checking on a regular (daily) basis if any relevant flights have changed which transport passengers. Relevant changes are:		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

Stefanseiler at 12:45, 28 November 2025

2025-11-28T12:45:51Z

← Older revision		Revision as of 12:45, 28 November 2025
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. 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 )

			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 )		* status (on plan / delayed / cancelled )

Stefanseiler: /* Planned interface approach */

2025-11-20T09:39:22Z

Planned interface approach

← Older revision		Revision as of 09:39, 20 November 2025
Line 14:		Line 14:

	== Planned interface approach ==		== Planned interface approach ==
	KORDEUS is building a ~~KAFKAA~~ interface, which subscribes to a '''"MOC/SARA" KAFKA Topic'''. Through this it which recieves messages of this type:		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 ======		====== Operations updates ======

Stefanseiler: /* Solution */

2025-11-20T09:38:32Z

Solution

← Older revision		Revision as of 09:38, 20 November 2025
Line 35:		Line 35:
	*** Plane change (Tailcode change) of an earlier assigned flight (chage from unplanned to planned is no change)		*** Plane change (Tailcode change) of an earlier assigned flight (chage from unplanned to planned is no change)
	*** Departure information 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.		** 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 ==

Stefanseiler: /* Planned interface approach */

2025-11-20T09:37:58Z

Planned interface approach

← Older revision		Revision as of 09:37, 20 November 2025
Line 14:		Line 14:

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

	~~====== Flight plan updates ======~~
	~~This information containing a list~~ of ~~all flights planned and scheduled for the next 6 months? Contained information~~:

	* FLIGHT NUMBER
	* FROM
	* TO
	* LOCAL DEPARTURE TIME
	* LOCAL ARRIVAL TIME
	* Planned flight duration
	* Planned craft type
	* Repetition pattern (weekdays, monthly, exact dates)

	====== Operations updates ======		====== Operations updates ======
Line 39:		Line 27:

	== Solution ==		== Solution ==
	~~From this information SARA builds a local application cache~~, ~~which holds for each planned flight within~~ the ~~upcoming 3 months a status, which is used within SARA for MOC for~~:		On the bridge server, the interface ''':'''

	* ~~Display information for~~ SAR-~~Request handling/management~~		* 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
	* ~~Creating tasks~~ - ~~in case~~ of ~~rotation~~ changes		* 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.

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