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 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 error response

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. SubmitBagEventData ( BagEventDataIn )

Submits bag event data ( BagEventData ). This is data related to one bag, and with BagTagNumber as the key. The BHS must call this operation for all significant bag events. See BagEventCode for a list of relevant events.

This operation is an extended version of the Baggage Information Exchange Service.SetBhsEventData operation.

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.

3.3.2. SubmitBaggageData ( BaggageDataIn )

Submits baggage data (BaggageData). This is FlightLeg oriented baggage data the BHS might have. First/last bag and bin data, if relevant, is of particular interest.

This operation is identical to the Flight Data Submit Service v 2.0.SubmitBaggageData operation.

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.

3.3.3. SubmitBatchEventData ( BatchEventDataIn )

Submits batch event data ( BatchEventData ). 

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. BagEventData
ADD Term Description

BagTagNumber
Uniquely identifier for the bag for a period of time. Will be reused.
BhsBatchId The batch, if any, this bag belongs to.
BagEventAirportIATA

BagEventCode 

BagEventTimestamp

BagEventDescription

BagEventLocation

BagDepartureFlightId

BagNextAirportIATA

BagFinalAirportIATA

BEBFT
Estimated time for when the BHS expects to have delivered this bag to it's final, in the BHS setting, destination. This would typically be at a bin, a speed loader or a baggage belt.
BagPlannedBin



BagPhysical

BagTypeIndicator
Indication if baggage contains special goods.

BagSizeIndicator

 Indication if baggage is unconventional size or weight.
BagWeightPrecise


BagImage Used if the BHS can have images of the bag.
MediaType
Image





4.2. BagEventDataIn

TransData

BagEventData


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

SourceOrganization

SourceSystem

SourceTimestamp


5. Service use cases

6. Overview

This section describes use cases for the service.

7. Use cases


8. XSDs


  • No labels