You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Service Description

 

 

asrv.aero

IATA Flight Message Submit Service

 

 

Until this note is removed the documentation is a work in progress, and revisions to the documentation will not be tracked.


NB!!!

Ikke bare iata-meldinger, endre navn??

 

Namespace: http://www.asrv.aero/webservices/1.0/IataFlightMsgSubmit

 

Document revisions

Date

Description

Author

yyyy-mm-dd First complete version of the documentation
Ole Nymoen

 

 

 

 

1. Introduction

1.1. Overview

This service description defines one service with a set of operations to set flight oriented data. All flight related data elements are defined by the Airport Data Dictionary.

The service is primarily designed to meet the need of airport partners, but availability is the decision of the service provider.

There is one operation for each of the IATA telex type flight leg messages (MVT, LDM, DIV, +++). While the data is defined using the Airport Data Dictionary the structure of the data closely matches the structure of the IATA messages. Mapping of IATA telex type data to Airport Data Dictionary elements is more closely described here: IATA mapping from telex format flight messages to ADD

All normal use of the IATA messages should be covered by the service.

1.2. Implementation considerations

Any implementation of this service MUST use the WSDL and XSD files provided here: WSDL and XSDs

It is however up to the service provider to decide which data elements to actually update.

Any service provider should make available documentation about the actual implementation, including:

    • the address of the service.
    • any limitations in the implementation.
    • any limitations on how often a client can use the service.

1.3. Purpose of this service description

This service description has the following purpose:

      • Describe of service in enough detail for a service provider to implement it.
      • Describe the service so that a client (of this service) developer can use it.
      • Make available the WSDL and XSD files necessary to implement and use the service.
      • Make it possible for relevant people at airports, airlines, handlers and other aviation partners to understand the available functionality and then to decide if to implement/use it or not.

1.4. Intended readership

    • IT architects
    • Developers
    • Business architects
    • Interested parties in the aviation community

2. Service overview

The figure below shows the available operations on the IataFlightLegMsgSubmit service. The operations are described in detail in Service operations. There is one operation for each of the IATA telex type flight leg oriented messages. The data for each operation closely matches the data in the corresponding IATA message, but all elements are defined using Airport Data Dictionary terms.

3. Service operations


3.1. SubmitAircraftDispositionData( transData : TransData, aircraftDispositionData : AircraftDispositionData ) : ResponseStatus

This operation can be used to set, or clear, the aircraft registration for one or more flights (all flight legs) or flight legs. If the flight(s)/flight leg(s) isn't specified by DepartureAirportIATA and ArrivalAirportIATA then AircraftRegistration is updated for all legs in the flight(s).


3.2. SubmitASMCancelData( transData : TransData, iataASMCancelData : IataASMCancelData ) : ResponseStatus

This operation covers the following ASM action identifiers (IataASMIdentifier):

  • CNL
    Cancels, but do not remove, one flight or flight leg. The flight (leg) can be reinstated.

3.3. SubmitASMChangeFlightIdData( transData : TransData, iataASMChangeFlightIdData : IataASMChangeFlightIdData ) : ResponseStatus

This operation covers the following ASM action identifiers (IataASMIdentifier):

  • FLT
    Updates the FlightId of the given flight (leg).

3.4. SubmitASMInsertUpdateData( transData : TransData, iataASMInsertUpdateData : IataASMInsertUpdateData ) : ResponseStatus

This operation covers the following ASM action identifiers (IataASMIdentifier):

  • NEW
    Inserts new flight (leg) information.

  • RPL
    Replaces all existing information for the relevant flight (legs).

  • ADM
    Updates only the given information for the relevant flight (legs).

  • CON
    Updates only the given information for the relevant flight (legs)    .

  • EQT
    Updates only the given information for the relevant flight (legs).

  • TIM
    Updates only the given information for the relevant flight (legs).

  • RRT
    Updates only routing data.

3.5. SubmitASMReinstateData( transData : TransData, iataASMReinstateData : IataASMReinstateData ) : ResponseStatus

This operation covers the following ASM action identifiers (IataASMIdentifier):

  • RIN
    Reinstates a previously cancelled flight (leg).

3.6. SubmitDivData( transData : TransData, iataDivData : IataDivData) : ResponseStatus

Submits an ADD based XML version of the IATA DIV message.

3.7. SubmitFuelRequestData( transData : TransData, fuelRequestData : FuelRequestData) : ResponseStatus

This operation can be used to request fuel.

3.8. SubmitLoadData( transData : TransData, iataLoadData : IataLoadData) : ResponseStatus

The load message contains, for each arrival airport, information about what actually is on board the aircraft that has the arrival airport as the final destination.
For a single leg flight there will be only one LoadDestinationIATA airport, and only one LoadDestinationData as defined in IataLoadData

3.9. SubmitMvtData( transData : TransData, iataMvtData : IataMvtData) : ResponseStatus

Submits an ADD based XML version of the IATA MVT message.

3.10. SubmitPassengerLoadEstimateData( transData : TransData, passengerLoadEstimeateData : PassengerLoadEstimateData ) : ResponseStatus

Submits an ADD based XML version of the IATA based PassengerLoadEstimate messages. 

3.11. SubmitPrmData( transData : TransData, iataPrmData : IataPrmData ) : ResponseStatus

Submits an ADD based XML version of the IATA PAL/CAL/PSM messages. 

3.12. SubmitPtmData( transData : TransData, iataPtmData : IataPtmData ) : ResponseStatus

Submits an ADD based XML version of the IATA Passenger Transfer Message (PTM)

3.13. SubmitSSIMData( transData : TransData, iataSSIMData : IataSSIMData ) : ResponseStatus

Submits an ADD based XML version of the IATA SSIM file row.

3.14. SubmitSSMChangeFlightIdData( transData : TransData, iataSSMChangeFlightIdData : IataSSMChangeFlightIdData ) : ResponseStatus

This operation covers the following SSM action identifiers (IataSSMIdentifier):

3.15. SubmitSSMChangePeriodData ( transData : TransData, iataSSMChangePeriodData : IataSSMChangePeriodData ) : ResponseStatus

This operation covers the following SSM action identifiers (IataSSMIdentifier):

  • REV (Revision of Period of Operation and/or Day(s) of Operation )
    This operation can only change the period of operation (ScheduleStartDate - ScheduleEndDate) and/or ScheduleFlightDays (and ScheduleFlightWeeks if used). There are no change to routing, equipment (aircraft) or timing. 
    The period of operation can be extended and ScheduleFlightDays added if there are no change to routing, equipment (aircraft) or timing.
    NB!  The period of operation can be shortened and ScheduleFlightDays removed. This is an implicit cancel of flights.

3.16. SubmitSSMDeleteData( transData : TransData, iataSSMDeleteData : IataSSMDeleteData ) : ResponseStatus

This operation covers the following SSM action identifiers (IataSSMIdentifier):

3.17. SubmitSSMInsertUpdateData( transData : TransData, iataSSMInsertUpdateData : IataSSMInsertUpdateData ) : ResponseStatus

This operation covers the following SSM action identifiers (IataSSMIdentifier):

  • NEW (Insertion of New Flight Information)
    This operation inserts a new flight, or adds new periods to an existing flight, given the period (ScheduleStartDate - ScheduleEndDate) and ScheduleFlightDays (and ScheduleFlightWeeks if used).

  • RPL (Replacement of Existing Flight Information)
    This operation replaces all schedule data with the elements included, for the given period/days. Elements not included are deleted.

  • ADM (Change of Existing Information)
    This operation changes the data elements included, for the given period/days, and leaves the other elements unchanged. Elements can be deleted (set to NIL). 

  • CON (Change of Aircraft Configuration/Version)
    This operation changes aircraft data elements included, for the given period/days, and leaves the other elements unchanged.

  • EQT (Change of Equipment Information)
    This operation changes equipment data elements included, for the given period/days, and leaves the other elements unchanged.

  • TIM (Change of Time Information)
    This operation changes timing data elements included, for the given period/days, and leaves the other elements unchanged.

4. Data entities


4.1. AircraftDispositionData

Aircraft disposition data is aircraft oriented - not flight (leg) oriented. It will result in the update of one or more flight legs for the given FlightDepartureDate
Entity / ADD element

AircraftDispositionFlightData 0..*

  • 0 only if DeleteAllRegistrations = true
  • DeleteAllRegistrations can be true and AircraftDispositionFlightData contains data. The defined flight legs should then be updated.


4.2. FuelRequestData
Entity / ADD element
FuelRequestData

4.3. IataASMCancelData

The figure below shows the Airport Data Dictionary based data structure representing the following IATA ASM message types:

  • CNL 

For more information on the mapping from IATA ASM data to ADD, see: ASM data to ADD data
Entity / ADD element
IataASMCancelData


IataASMRoutingData 0..*
Only departure/arrival airport are used for SubmitASMCancelData.

4.4. IataASMChangeFlightIdData

The figure below shows the Airport Data Dictionary based data structure representing the following IATA ASM message types:

  • FLT

For more information on the mapping from IATA ASM data to ADD, see: ASM data to ADD data
Entity / ADD element


IataASMRoutingData 0..*
Only departure/arrival airport are used for IataASMChangeFlightIdData.

4.5. IataASMInsertUpdateData

The figure below shows the Airport Data Dictionary based data structure representing the following IATA ASM message types:

  • NEW
  • RPL
  • ADM
  • CON
  • EQT
  • TIM
  • RRT

For more information on the mapping from IATA ASM data to ADD, see: ASM data to ADD data
Entity / ADD element
IataASMInsertUpdateData


IataASMAircraftData 0..*


IataASMRoutingData 0..*

4.6. IataASMReinstateData

The figure below shows the Airport Data Dictionary based data structure representing the following IATA ASM message types:

  • RIN

For more information on the mapping from IATA ASM data to ADD, see: ASM data to ADD data
Entity / ADD element
IataASMReinstateData


IataASMRoutingData 0..*
Only departure/arrival airport are used for SubmitASMReinstateData.

4.7. IataDivData

The figure shows the elements and structure of an Airport Data Dictionary (ADD) based entity representing an IATA Diversion Message (DIV) as defined in the Airport Handling Manual (AHM) 781.
Entity / ADD element
  • ELDT (at diversion airport)
  • EIBT (at diversion airport)

4.8. IataLoadData

The figure shows the elements and structure of an Airport Data Dictionary (ADD) based entity representing an IATA Load Message (LDM) as defined in the Airport Handling Manual (AHM). 

For more mapping information, see: LDM data to ADD data 
Entity / ADD element
IataLoadData

IataLoadDestinationData  


IataLoadCompartmentData 

4.9. IataMvtData

The figure shows the elements and structure of an Airport Data Dictionary (ADD) based entity representing an IATA Movement Message (MVT) as defined in the Airport Handling Manual (AHM). For details about mapping from AHM 780 AIRCRAFT MOVEMENT MESSAGE to ADD, see MVT data to ADD data
Entity / ADD element
IataMvtData
  • EOBT 0..1 NILLABLE
  • ETOT 0..1 NILLABLE
  • AOBT 0..1 NILLABLE
  • ATOT 0..1 NILLABLE
  • ELDT 0..1 NILLABLE
  • EIBT 0..1 NILLABLE
  • ALDT 0..1 NILLABLE
  • AIBT 0..1 NILLABLE

IataDelay


4.10. IataPrmData

The figure shows the elements and structure of an Airport Data Dictionary (ADD) based entity representing an IATA Passenger Assistance List (PAL), Change Assistance List (CAL) and Passenger Service Message (PSM).

PAL and CAL are defined in the Passenger Services Conference Resolutions Manual (PSCRM) Recommended Practice 1708a.
PSM is defined in the Passenger Services Conference Resolutions Manual (PSCRM) Recommended Practice 1715.

For more mapping information, see: PRM data to ADD data
Entity / ADD element
IataPrmData

IataPrmDestinationData 0..*

If PRM destination-data is missing it means that all PRM data related to this flight leg should be removed.

  • IataPrmPassengerInformation 
  • SOBTlocal   (For the outbound flight leg)

  • IataPrmPassengerService 



4.11. IataPtmData

The figure shows the elements and structure of an Airport Data Dictionary (ADD) based entity representing an IATA Passenger Transfer Message (PTM) as defined in the Passenger Services Conference Resolutions Manual (PSCRM) RP 1718.


Entity / ADD element Comments
IataPtmData Identifies the flight leg passengers transfer from and to other light legs.
The transfers will be on the arrival airport.

If part '1' comes again all transfer data previously received for this flight leg should be discarded, as it will be resent.

For IATA messages with multiple "parts".

IATA based identifier for this flight, usually issued long before the flight actually takes place.

FlightId is normally the concatenation of OperatingAirlineIATA, FlightNumber and OperationalSuffix.

FlightId typically identifies a flight to the majority of systems, but it is not unique across time. It's unique only in conjunction with FlightDepartureDate.

Exception: Some airlines use their ICAO code (OperatingAirlineICAO) instead of OperatingAirlineIATA. This might be because they aren't an IATA member or because they just prefer the ICAO code. Regardless, this means that it is allowed to use OperatingAirlineICAO as part of FlightId.

FlightId is then defined as the concatenation of AirlineIATAorICAO, FlightNumber and OperationalSuffix.

Date part of SOBTlocal.

Departure airport IATA code (see AirportIATA for description of term).

Arrival airport IATA code (see AirportIATA for description of term).


IataPtmTransferToData 0..*

This is the flight leg passengers on the flight leg identified above transfer to. 
There will often be multiple data sets for the same flight leg. 

NB! If IataPtmTransferToData is "missing" then all previously received PTM data for this flight should be deleted. New PTM data will most likely be forthcoming.





The name string as it appears on a ticket. Can contain multiple names.

The number of adult passengers in some context.

The number of children in some context.

The number of infants in some context.

The number of bags in some context.

4.12. 110626443

The figure shows the elements and structure of an Airport Data Dictionary (ADD) based entity representing an IATA SSIM file row.
Entity / ADD element

4.13. IataSSMChangeFlightIdData

The figure below shows the Airport Data Dictionary based data structure representing the following IATA SSM message types:

  • FLT

For more information on the mapping from IATA SSM data to ADD, see: SSM data to ADD data


Entity / ADD element

4.14. IataSSMChangePeriodData

The figure below shows the Airport Data Dictionary based data structure representing the following IATA SSM message types:

  • REV

The table below lists, for ease of reference, the elements included in the entity. For more information on the mapping from IATA SSM data to ADD, see: SSM data to ADD data

Entity / ADD element Comments
IataSSMChangePeriodData


  • oldIataSSMPeriod
 See definition → 
  • newIataSSMPeriod
 See definition → 
Entity / ADD element Comments
IataSSMPeriodData





4.15. IataSSMDeleteData

The figure below shows the Airport Data Dictionary based data structure representing the following IATA SSM message types:

  • CNL 
  • SKD

The table below lists, for ease of reference, the elements included in the IataSSMDeleteData. For more information on the mapping from IATA SSM data to ADD, see: SSM data to ADD data

Entity / ADD element
IataSSMDeleteData




4.16. IataSSMInsertUpdateData

The figure below shows the Airport Data Dictionary based data structure representing the following IATA SSM message types:

  • NEW
  • RPL
  • ADM
  • CON
  • EQT
  • TIM

The table below lists, for ease of reference, the elements included in the IataSSMInsertUpdateData. For more information on the mapping from IATA SSM data to ADD, see: SSM data to ADD data


Entity / ADD element
IataSSMInsertUpdateData


IataSSMPeriodData 


IataSSMAircraftData 


IataSSMRoutingData 




4.17. 70550297
Entity / ADD element Comments


If departure and arrival airport is omitted FlightId and FlightDepartureDate must identify a single leg in the relevant context.






4.18. ResponseStatus
statusCode : ResponseStatusCode

ResponseStatusCode indicates if the operation succeeded or failed, and if it failed - why. ResponseStatusText is a textual description of ResponseStatusCode. For all operations the set of response codes must be defined. The actual set is dependent upon the context.

 

  • "OK": Operation succeded.
  • "ERR01":
  • "ERR02":
  • "":
  • "":
  • "ERR99": Other error. "statusText" should describe the error.

 

Must be defined!
statusText : ResponseStatusText
A textual description of ResponseStatusCode.

4.19. TransData
CorrelationId
Identifier that can be used to correlate messages, transactions, log entries etc. The identifier should be unique across all relevant systems. It is the responsibility of the creator of the message/transaction/log entry/...  to guarantee uniqueness. The CorrelationId can for instance be a GUID, or something shorter based on site specific rules.
SourceOrganization
Name of the organization/company that created the original data. This will typically be an airline company or an handler. The value set are site specific.

SourceTimestamp
UTC timestamp for when the source was updated. If unknown, use current (UTC) time.
SourceData
SourceData will only exist when the source data is something else than XML or JSON. SourceData will typically be the IATA message or an EFD message from Eurocontrol.

5. XML Usage

5.1. Nil Values in Schema

For any particular data element, there is an important distinction between the following cases:

(a) the element is missing
(b) the element is present but has a 'nil' attribute assigned to it

In the first case, this means that the sender is supplying no information about the element. This would typically be because no information is available, or because there has been no change in the value of the element. A recipient would not be expected to take any action as a result of this. In particular, it would not be expected to clear any existing value.

In the second case, this means that the sender has explicitly cleared the element. As a result of this, a recipient would typically clear any value that it had previously stored for this element.

The following table shows an example sequence of messages, and the expected actions taken by the data recipient. It should be noted, however, that the action is up to the recipient. The message from the sender is a notification, and not a command for the recipient to take action.

Message contents

Expected action by recipient

aircraftRegistration element missing

Does not set or change aircraft registration value

<aircraftRegistration>ABC123</aircraftRegistration>

Sets the value to ABC123

aircraftRegistration element missing

Does not change the value

<aircraftRegistration xs:nil=’true’>

Clears the aircraftRegistration value

Note that the sender should not use blank data elements such as <aircraftRegistration/> or <aircraftRegistration></aircraftRegistration> as these may cause validation errors. For example, if the schema specifies a format or a minimum length for an element, then a zero-length element will be invalid. This problem does not occur if using the nil attribute.

Note - Where a field is defined as mandatory in the schema, it must not contain a nil value.

6. WSDL and XSDs

  File Modified
ZIP Archive iata_flight_message_submit_service.3.68.2.zip 2022-01-13 by Ole Nymoen
ZIP Archive iata_flight_message_submit_service.3.70.1.zip 2022-04-22 by Ole Nymoen

7. Examples

7.1. Introduction

The following are example invocations of the service.

7.2. Example SOAP templates

7.2.1. xxxx SOAP template

xxxx SOAP template 
<soapenv:Envelope
   
</soapenv:Envelope>

  • No labels