Service Description



aci.aero

Bag Information Service v 1.0



Namespace: http://www.aci.aero/webservices/1.0/BagInformationSubmitService/



Document revisions

Date

Description

Author


Not under version control yet

Ole Nymoen 



1. Service facts 

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 Bag Information Submit Service v 1.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 error response

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.

If a service specific error occurs the entity below will be returned. Any service specific errors will be documented with the actual service implementation.
ErrorResponse is typically used with HTTP Response Code: 400 Bad Request
timestamp: TimestampUTC

Timestamp when the error was generated by the service.

A precise time for when something happened. Always UTC.
serviceErrorCode : ServiceErrorCode

An integer code representing a service specific error. The actual values are described in the service definition.

serviceErrorDescription: ServiceErrorDescription

 A textual description of ServiceErrorCode.

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
ADD Term Description
IataBagInformationMessage

Text string containing one of the IATA Bag-oriented messages in teletype format, for instance a BSM (Baggage Source Message) or a BPM (Baggage Processed Message).  NB! Start and end token ("BSM"/"ENDBSM", "BPM"/"ENDBPM") must be included in the text string. Only one message per BagInformationMessage text string.

The messages are defined by IATA Resolution 1745.

BSM example:

BSM
.V/1LOSL
.F/SK4416/05FEB/TOS/C
.N/0117814872001
.S/N/05A/C/051/051//N/I
.W/P/1
.P/XXXXXXXX/XXXXXXX
.E/PRIO
ENDBSM

BPM example:

BPM
.V/1LOSL
.J/S/BGFUSION/CI621/05FEB/1059L/LB9/LB9
.F/SK4416/05FEB/TOS
.N/0117814872001
.R/DIVERTEDOK
.X//CLR///HBS302/HBSLEVEL1
ENDBPM





4.2. BagInformationMessageIn
TransactionData
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.
ACI DD Term
Notes
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 TransactionData can for instance be a GUID, or something based on site specific rules.
TransactionData is primarily used to simplify distributed debugging/tracing. To be able to easily search for the same thing across systems is very helpful.
SourceParty
Name of the Party that created/sent/supplied the data. This might be an Airline, a Handler, an Airport or any relevant partner. The value set are site specific.
PartyIdentifier: string (32)  System specific identifier of a Party. 

SourceTimestamp
UTC timestamp for when the source (data) was updated. If unknown, use current (UTC) time.


5. Service use cases

6. Overview

This section describes use cases for the service.

7. Use cases

7.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.

8. XSDs


  • No labels