A FlightData message is sent for each flight, with the same content as if the operation publishFlightDataDistribution was triggered for all the flights, except that it is done through the FlightDataProvider interface. The whole set of messages (as many messages as flights) is sent within certain time tuned on providers platform (the time is constant whatever the number of flights).
Among the flights fulfilling the filter criteria of the request, the flights received are the ones existing at the time the request is performed. Following the sending of the request and before all the FlightData messages are received:
- if a flight is deleted, no FlightData message is received (if not yet received before deletion of the flight)
- if a flight is created, no FlightData message is received (the customer shall use the publishFlightDataDistribution message to be notified of this creation)
- if a flight is updated, the FlightData message received includes this update
The FlightDataRequestReport is received after the last FlightData message has been received.
In case no data fulfills the criteria of a getxxx request, a OK_BUT response will be sent to the customer, with an error description message.
In get/publish operations of other services regarding flights (operations of CORRD and MONAD services), no filtering is applied to flights. It is assumed that the Customer relies on publishFlightDataDistribution/flightDataRepositoryRequest filtering to determine if a flight is of interest for him or not.
As a consequence, a flight can be considered as relevant if a FlightData message has been received for this flight. Data received with the other services for any other flight could be ignored by the Customer.
Following this principle, when a flightDataRepositoryRequest is performed, it is advisable for the Customer to wait for a complete response from it before sending any request for the other services regarding flights.