Service Description
aci.aero
Bag Information Service v 1.0
Namespace: http://www.aci.aero/webservices/1.0/BagInformationSubmitService/
1. Service facts
-
Operations, see Service operations.
- REST based service. Operations are accessed using HTTPS POST.
- Service security: Decided by implementation.
-
Standard return codes are described here: Service Return Codes
2. Introduction
2.1. Overview
This service defines one operation to submit IATA Baggage Information Message information to the service provider. This makes it possible for the airport (provider) to receive IATA teletype baggage messages directly.
The service is designed to meet the need of a Baggage Information Message provider.
A set of use cases are described here: Service use cases
The service is defined using ACI Data Dictionary terms. Naming of entities are service specific.
2.2. Implementation considerations
Any implementation of this service MUST use the XSD files provided here: XSDs
It is however up to the service provider which data elements to support.
Any service provider should make available documentation about the actual implementation, including:
-
- the address of the service.
- any limitations in the implementation.
2.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 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.
-
2.4. Intended readership
-
- IT architects
- Developers
- Business architects
- Interested parties in the aviation community
3. Service operations
3.1. Overview
The operations in BHS Submit Service v1.0 submits data that will be asynchronously processed. This means that all data that follow the syntax will be accepted, but it might not be used by downstream systems.
3.2. Service Return Codes
The service uses standard HTTP return codes - as follows:
- 200 OK - the request has succeeded.
- 400 Bad Request - The server will not process the request due to XML-schema validation error.
- 401 Unauthorized - The request has not been applied because it lacks valid authentication credentials.
- 403 Forbidden - The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource.
- 500 Internal Server Error - The server encountered an unexpected condition that prevented it from fulfilling the request.
- 503 Service Unavailable - The server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded.
Different implementations might extend the set of return codes.
3.3. Operations
3.3.1. SubmitBagInformationMessage ( BagInformationMessageIn )
Submits an IataBagInformationMessage in BagInformationMessage. This is IATA teletype data related to one bag.
Parameters
Returns
- 200 OK if everything went well. The data is sent on for further processing.
- 400 Bad Request if there were any issues with the input data. The text string returned will give more information about the actual problem.
- Other error/warning returns are possible.
4. Data entities
4.1. BagInformationMessage
|
|
|
4.3. TransactionData
TransactionData contains additional data related to the submitted data. This is for instance to make logging more complete and distributed debugging possible.
|
|
|
5. Service use cases
5.1. Overview
This section describes use cases for the service.
5.2. Use cases
5.2.1. Submit an IATA Bag Information Message to an Airport
This is the typical use case. A provider of IATA BIMs want to submit them directly to an airport. The Bag Information Submit Service v 1.0 receives the BIMs, one at a time, and ensures further processing.
The receiver can of course be any service provider, not necessarily an airport.
6. XSDs
Overview
Content Tools