Service Description
asrv.aero
Baggage Information Exchange Service - BIX
Namespace: http://www.asrv.aero/webservices/1.1/BIXService
Document revisions
Date | Description | Author |
---|---|---|
2020-03-22 | First complete version of the documentation |
- 1. Introduction
- 2. Service overview
- 3. Service operations
- 3.1. SetBagCheckInData ( transData: TransData, bagCheckInData: BagCheckInData ): ResponseStatus
- 3.2. SetBhsEventData ( transData: TransData, bhsEventData: BhsEventData ): ResponseStatus
- 3.3. SetBagScanData ( transData: TransData, bagScanData: BagScanData ) : ResponseStatus
- 3.4. SetBagEventData ( transData: TransData, bagEventData: BagEventData ) : ResponseStatus
- 3.5. SetBagLostData ( transData: TransData, bagLostData: BagLostData ): ResponseStatus
- 3.6. SetBimData ( transData: TransData, bimData: BimData ): ResponseStatus
- 3.7. SetFlightBinData ( transData: TransData, flightBinData: FlightBinData ): ResponseStatus
- 4. Data entities
- 5. XML Usage
- 6. WSDL and XSDs
1. Introduction
1.1. Overview
This service description defines one service with a set of operations to set baggage oriented data. All baggage 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 are a set of use cases that can be realized using the operations and data available, for example:
-
-
- Set baggage data captured when a bag is checked in, manually or at a self service baggage drop (SBD). The SetBagCheckinData operation is meant to cover this.
- Set baggage data from a baggage handling system (BHS). The SetBhsEventData suited for this.
- Set data when a bag tag is scanned at some location, possibly as part of a baggage reconciliation system (BRS). The SetBagScanData cover this.
- Data about any baggage event can be set using the SetBagEventData operation.
-
.The SetBagEventData operation covers data in all the other operations. The reason to have multiple operations is:
-
-
- It makes it simpler for developers as the data model is restricted to what is (readily) available.
- It makes for more stable data definitions as the restricted entities for baggage related data are expected to change much less frequently than the all inclusive one.
-
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. And as clients vary wildly in their capabilities most elements are optional
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 BaggageInformationExchangeService. The operations are described in detail in Service operations.
3. Service operations
3.1. SetBagCheckInData ( transData: TransData, bagCheckInData: BagCheckInData ): ResponseStatus
Sets data collected when the passenger delivers the bag to an airport/airline/handler for further processing. This will typically be at a manual or self service baggage drop point.
Parameters:
- transData: TransData - See definition under Data entities.
Metadata related to this transaction. -
bagCheckInData: BagCheckInData - See definition under Data entities.
Returns: ResponseStatus - See definition under Data entities .
3.2. SetBhsEventData ( transData: TransData, bhsEventData: BhsEventData ): ResponseStatus
Sets data associated with a bag scanning or decision event in a BHS (baggage handling system). Typically this will be when
- the bag tag is actively scanned.
- the BHS makes a decision about the bag, typically where to route it.
Parameters:
-
transData: TransData - See definition under Data entities.
Metadata related to this transaction. -
bhsEventData: BhsEventData - See definition under Data entities.
Returns: ResponseStatus - See definition under Data entities .
3.3. SetBagScanData ( transData: TransData, bagScanData: BagScanData ) : ResponseStatus
Set data associated with the BagTag being scanned, manually or automatically.
Parameters:
-
transData: TransData - See definition under Data entities.
Metadata related to this transaction. -
bagScanData: BagScanData - See definition under Data entities.
Returns: ResponseStatus - See definition under Data entities .
3.4. SetBagEventData ( transData: TransData, bagEventData: BagEventData ) : ResponseStatus
Used to set data associated with any bag event.
Parameters:
-
transData: TransData - See definition under Data entities.
Metadata related to this transaction. -
bagEventData: BagEventData - See definition under Data entities.
Returns: ResponseStatus - See definition under Data entities.
3.5. SetBagLostData ( transData: TransData, bagLostData: BagLostData ): ResponseStatus
Sets data collected when the bag is reported lost. This operation is somewhat special as part of the data set is open ended, see BagLostData for details.
Parameters:
- transData: TransData - See definition under Data entities.
Metadata related to this transaction. -
bagLostData: BagLostData - See definition under Data entities.
Returns: ResponseStatus - See definition under Data entities .
3.6. SetBimData ( transData: TransData, bimData: BimData ): ResponseStatus
Sets IATA BIM (BaggageInformation Message) data. BimData contains a string element that is the actual IATA baggage information message (BSM, BUM, BPM, .....).
Parameters:
- transData: TransData - See definition under Data entities.
Metadata related to this transaction. -
bimData: BimData - See definition under Data entities.
Returns: ResponseStatus - See definition under Data entities .
3.7. SetFlightBinData ( transData: TransData, flightBinData: FlightBinData ): ResponseStatus
A flight leg oriented operation that sets all bins that are planned to be used, or actually being used, for one flight leg departure.
Parameters:
- transData: TransData - See definition under Data entities.
Metadata related to this transaction. -
flightBinData: FlightBinData - See definition under Data entities.
Returns: ResponseStatus - See definition under Data entities .
4. Data entities
4.1. BagCheckInData
|
|
4.2. BagEvent
|
|
4.3. BagEventData
|
|
4.3.1. BagEventData - all entities
4.4. BagImage
4.5. BagLostData
|
|
4.6. BagPhysical
|
|
4.7. BagScanData
|
|
4.8. BhsEventData
|
|
4.9. BimData
|
|
4.10. FlightBinData
|
|
4.11. ResponseStatus
|
|
4.12. TransData
|
|
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.